> On Mar 21, 2019, at 07:04, Bob Briscoe <i...@bobbriscoe.net> wrote:
>
> [...]
> As regards the desire to use SCE instead of the L4S approach of using a
> classifier, please answer all the reasons I gave for why that won't work,
> which I sent in response to your draft some days ago.
Is there any work planned showing why the heuristic based on CE is not
going to cause problems? Because as it stands ECT(1) might be a useful piece of
information for a traffic classifier, but it certainly is not a reliable
traffic category identifier (unless you are interested in the category: packets
that promise to respond in the L4S-way if they should encounter congestion).
> The main one is incremental deployment: the source does not identify its
> packets as distinct from others, so the source needs the network to use some
> other identifier if it wants the network to put it in a queue with latency
> that is isolated from packets not using the scheme. The only way I can see to
> so this would be to use per-flow-queuing. I think that is an unstated
> assumption of SCE.
You write a whole section on alternative labeling schemes in
https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05#appendix-B that you
rule out, but that is based on hand-waving over the fact that CE-marking
destroys the neat L4S labeling by ECT(1) scheme in two ways (mis-classifiaction
of by AQM and mis-interpretation by end-point).
You write: "Given shortage of codepoints, both L4S and classic ECN sides of an
AQM would have to use the same CE codepoint to indicate that a packet had
experienced congestion. If a packet that had already been marked CE in an
upstream buffer arrived at a subsequent AQM, this AQM would then have to guess
whether to classify CE packets as L4S or classic ECN. Choosing the L4S
treatment would be a safer choice, because then a few classic packets might
arrive early, rather than a few L4S packets arriving late;" but in all
honestly this simply assumes the rate of CE-marked packets of non-L4S flows
will be low, otherwise your four Ls will suffer.
Regarding the second ambiguity you write:
"A.1.4. Fall back to Reno-friendly congestion control on classic ECN
bottlenecks [side note on
https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05#page-23 bottleneck
appears in normal font instead of bold]
It would take time for endpoints to distinguish classic and L4S ECN marking.
An increase in queuing delay or in delay variation would be a tell-tale sign,
but it is not yet clear where a line would be drawn between the two behaviours.
It might be possible to cache what was learned about the path to help
subsequent attempts to detect the type of marking."
This has issues that IMHO need empirical data instead of hand-waving. Competent
AQM solutions will control traffic rates without introducing massively
increasing delays which will make it harder to do a heuristic based on RTT or
RTT variation, this is the same mis-design LEDBAT suffers from, making
inportant decisions based on un-reliable information... And trying to cache the
L4S-ness of the active AQM assumes a steady-state behaviour of the network,
which will not work for all cases.
>
> In contrast, L4S works with either per-flow queuing or dualQ, so it is more
> appropriate for a wider spread of scenarios. Again, in that same unanswered
> email, I described a way L4S can use per-flow queuing, and Greg has since
> given pseudocode. There are other problems with doing the codepoints the SCE
> way round - pls see that email.
>
> There has been a general statement that the SCE way round is purer. However,
> that concept is in the eye of the beholder. The SCE way round does not allow
> the ECN field to be used as a classifier,
Nor does the proposed L4S interpretation, as elaborated above.
> so you don't get the benefit above about support for per-flow-queueing and
> dual queue. You also don't get the benefit of being able to relax
> resequencing in the network,
I am still failing to grasp how this is supposed to work, and I had a
look at the RACK RFC already. IMHO the link technology people should think
about how much slack they require and ask the RACK developers to add that as a
minimum to the specification, assuming it is reasonable. Say, lower level ARQ
is expected to take 5ms worst-case, than ask RACK to specify a minimum
reordering window of 10ms. The current RACK draft with re-ordering window bound
to be <= RTT will not give reliable re-odering allowance to the lower levels
unless they measure the RTT for each flow independently, I am sure that that is
not going to fly...
> because the network has no classifier to look at.
Same here CE-marked packets have no reliable label, and I assume that
with L4S at steady-state and link capacity one can expect quite a number of
CE-marked packets.
I begin to wonder whether there is a nomenclature mismatch here, and I have a
definition of classification that is alien to the field here.
> For these, the SCE codepoint would need to be combined with a DSCP, and I
> assume you don't want to do that.
>
> The L4S way round signifies an alternative meaning of the ECN field, which is
> exactly what it is. The problem of having to guess which type of packet a CE
> used to be has been roundly discussed at the IETF in TCPM and TSVWG WGs and
> it has been decided it is a non-problem
This is not something to "decide" but something to experimentally test,
but I guess I am just getting disillusioned how internet sausage is made...
Best Regards
Sebastian
> if it is assumed to have been ECT(1) even if it was not - as written up in
> draft-ietf-ecn-l4s-id. And that discussion assumed TCP with 3DupACK
> reordering tolerance, not the more liberal use of RACK (or a RACK-like
> approach in other transports). With a RACK-like approach, it becomes even
> less of a problem.
>
>
> Bob
>
>> - Jonathan Morton
>>
>
> --
> ________________________________________________________________
> Bob Briscoe http://bobbriscoe.net/
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
