Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

[Sebastian Moeller <[e-mail]>]

> On Mar 21, 2019, at 07:04, Bob Briscoe <[e-mail]> 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
> [e-mail]
> https://lists.bufferbloat.net/listinfo/bloat