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

From: Sebastian Moeller <[email-masked]>
Date: Mon, 2 Dec 2019 22:01:59 +0100

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

---

From: "Black, David" <[email-masked]>
Date: Tue, 3 Dec 2019 21:24:46 +0000

Hi Sebastian,

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

It's not easy to tell from how the tracker is displayed in a browser, but that text is part of a comment from Bob Briscoe.

> 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.

Please add a short summary of this concern as a comment to this issue in the tracker, including some of the text after "But, the truth of the matter is,"  (above) to shed some light on the specific scenario(s) of concern.  That'll help ensure that this concern is not overlooked.

Thanks, --David

> -----Original Message-----
> From: tsvwg <[email-masked]> On Behalf Of Sebastian Moeller
> Sent: Monday, December 2, 2019 4:02 PM
> To: tsvwg IETF list
> Subject: [tsvwg] [tsvw] regarding L4S issue #22 new defect Deployment
> feasibility
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi all,
> 
> 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
>