[tsvwg] FW: path forward on L4S issue #16

["Black, David" <[e-mail]>]

Without stupid confidential tag this time ...

Thanks, --David

> I think fixing this is part of making the classic queue detection and 
> end-host performance robust in as many cases as possible when trying 
> to take advantage of L4S in the network, but doesn't lead to a safety 
> issue.
>
> Are there any plans or thoughts on how to proceed on issue #16 that people can share?

[Writing as an individual, not WG chair] I have an alternate perspective on this issue, and suggest an alternate approach to addressing it.

Under the heading of TCP Prague, an enormous amount of work has gone into endpoint detection of RFC 3168 ECN bottlenecks and endpoint-based problem avoidance.   Of the test results that have been posted, Pete Heist's scenario 8 results (https://mailarchive.ietf.org/arch/msg/tsvwg/-gx8R1jcwiCsX1_5cdnvl3kKlOs/) ought to give everyone pause, as they show TCP Prague flows getting into trouble competing among themselves.

This TCP Prague work on bottleneck detection and problem avoidance has been going on for a year, and while it's produced some very interesting results and I'm sure that more progress will be made, I'm skeptical that relying on it to close issue #16 will yield much more than rounds of finding new problems in the next five versions of TCP Prague.   Beyond that, I'd expect to see quite a bit of L4S low latency traffic from protocols whose endpoint implementations have not been scrutinized to anything approaching the degree of attention that has been recently devoted to TCP Prague, and hence are at more risk of getting into trouble.

As an alternative, I suggest starting from Neil Cardwell's network and operator perspective (from https://mailarchive.ietf.org/arch/msg/tsvwg/kyDZ7vYLeOk1V15nZfNXGmaUNxk/):

	- L4S flows potentially causing unfairness in RFC3168 ECN bottlenecks has
	been mentioned as a potential concern. However, a robust RFC3168 ECN
	bottleneck should already have a mechanism to avoid unfairness caused by
	flows that are marked as ECT(0|1) and yet not performing RFC3168 responses.
	In particular, many of the large sources of known deployments of  RFC3168
	--  Linux fq_codel and cake -- are already deployed with fair queueing. In
	such bottlenecks L4S traffic should not cause harm to other non-L4S flows.
	Furthermore, if there really are ISPs with deployments of RFC3168
	bottlenecks that have neither FQ nor any other protection from
	non-RFC3168-ECT(1) flows, then they can bleach incoming ECT(1) code points
	to Not-ECT and treat L4S as Not-ECT (ISPs typically already transform the
	DSCP byte at their ingress anyway). So I do not see harm to RFC3168 ECN
	bottlenecks as a prohibitive concern.

	- More generally, if there is any problem discovered with the L4S
	experiment, either the algorithm or particular implementations, bottlenecks
	can easily identify L4S traffic and bleach it into Not-ECT, and treat it
	like Reno/CUBIC traffic.

TCP Prague is not only not mentioned in the text quoted above, it appears nowhere in the entire email from which that was extracted.  Nonetheless, the email lays out an approach to L4S safety, although as initially proposed, it invites operator bleaching of ECT(1), which would be unfortunate, as ECT(1) not being subject to bleaching is among the key reasons for using it.  Refining that approach might produce something more robust that doesn't invite ECT(1) bleaching, and that recognizes that FQ is not a 100% solution to flow interference (e.g., courtesy of the birthday paradox for the number of hash buckets in an FQ implementation).  As noted before, please don't cast aspersions in Neal's direction for introducing the notion of operator bleaching of ECT(1).

So, I would suggest focusing attention on networks and operators as an alternative approach to focusing on endpoints.

Thanks, --David

> -----Original Message-----
> From: tsvwg <[e-mail]> On Behalf Of Wesley Eddy
> Sent: Thursday, June 4, 2020 4:54 PM
> To: [e-mail]
> Subject: [tsvwg] path forward on L4S issue #16
> 
> 
> [EXTERNAL EMAIL]
> 
> I think we should discuss the path forward on L4S issue #16 and what 
> people are working on, planning to do, or expecting to see in this regard.
> 
> This is the issue on interaction with RFC 3168 ECN AQMs in the network.
> 
> I think this is one of the more important ones in many recent 
> discussions, so would like to make sure we're agreeing on what it will 
> take to complete or what success will look like.
> 
> The classic bottleneck detection work is a key part of this.  In that 
> vein, I'd like to subsume issue #29 (that it looks like Pete Heist
> opened) under this one and close #29.  Issue #29 shows some cases 
> where an L4S queue is misidentified as a classic one.  I think fixing 
> this is part of making the classic queue detection and end-host 
> performance robust in as many cases as possible when trying to take 
> advantage of L4S in the network, but doesn't lead to a safety issue.
> 
> Are there any plans or thoughts on how to proceed on issue #16 that 
> people can share?