[tsvwg] [tsvw] regarding L4S issue #22 new defect Deployment feasibility

[Sebastian Moeller <[e-mail]>]

Hi all,

I just had a look at the issue tracker and for L4S issue #22 I see the following text:

"Issue #16 is the only identified incremental deployment issue. "

And I am not convinced that is true. The fact that L4S's designated sharing mechanism the dual queue coupled AQM does not robustly and reliably share bandwidth equitably between the L4S and the standard queue looks like a relevant deployment issue.

I am pretty sure none of the end-users exposed to L4S will expect that (short) RTT L4S flows will basically throttle all other standard (internet-size-RTT) flows. A naive reading of the L4S and dual queue RFCs gives the reader the idea of equitable sharing between both traffic types, which already seems rather generous to the new comer L4S. Essentially with that prima facie reading, a single L4S flow might take the same 50% of the bandwidth as an arbitrarily sized flock of flows in the standard queue, giving L4S a noticeable boost given the relative likelihood to encounter L4S versus standard compliant traffic sources on the existing internet. 
But the truth of the matter is, the L4S reference scheduler does not even manage to guarantee that equal sharing robustly, as testing of both the L4S and the SCE team confirmed. This issue is especially relevant with the internet wide scope of the desired dual queue AQM roll-out, and can hence not be solved by affected end-users by imply not using L4S/ETC(1) flows unilaterally, and the fact that end-user to CDN RTTs are getting shorter and shorter.


I would like to kindly request this issue "failure of equitable sharing between L4S's two queues" to be added to the issue tracker and also being addressed in the L4S arch and the dualq drafts, please.


Best Regards
	Sebastian