Opened 3 years ago

Last modified 3 years ago

#22 new defect

Deployment feasibility

Reported by: wes@… Owned by: draft-ietf-tsvwg-l4s-arch@…
Priority: major Milestone: L4S Suite - WGLC Preparation
Component: l4s-arch Version:
Severity: - Keywords:

Description (last modified by wes@…)

There are general concerns with deployment feasibility.

Incremental deployment possibilities are not clear.

This was discussed at IETF 105 (issue G). Jonathan Morton specifically mentioned it as a concern at the open microphone.

This is related to (at least) issues A, B, and H.

It might be helpful to hear more about this from operators, vendors, etc. who have interest and/or plans for L4S.

Change History (5)

comment:1 Changed 3 years ago by wes@…

  • Description modified (diff)

comment:2 Changed 3 years ago by chromatix99@…

Resolution of this issue is dependent on resolving issues #16, #20, #21 at minimum.

comment:3 Changed 3 years ago by ietf@…

Issue #16 is the only identified incremental deployment issue. The phrase "general concerns with deployment feasibility" adds nothing. Unless these other concerns are articulated, this issue needs to be closed.

Similarly, I have just added comments to issues #20 and #21 that they are also redundant given issue #16.

Please, let's focus on the real issue (#16).

comment:4 Changed 3 years ago by jholland@…

Bob has pointed out that the semantic change to CE can cause reordering of CE packets in a dualq, and also that reordering for non-RACK stacks causes problems because of the dupacks. This seems like it could have a bearing on the incremental deployability question until RACK is more ubiquitous. (Consider especially an upload from a dualq-fq_codel-home topology with an asymmetric link.)

I don't recall seeing test results examining the issue or trying to determine the scope of the problem, were there any?

comment:5 Changed 3 years ago by moeller0@…

IMHO the fact that the L4S reference scheduler does not manage to guarantee robust equal sharing between L4S' two traffic categories/queues, is a deployment issue.

Both the L4S team and the SCE team have independently confirmed that at low RTTs the dual queue coupled AQM will fail to share equitable between the two queues, but will give a clear latency and bandwidth advantage to L4S traffic at the expense of traffic in the non-L4S queue.* L4S team data: ratio L4S/non-L4S ~ 7:1 SCE team data: ratio L4S/non-L4S ~ 7:1

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 see this being addressed in the L4S arch draft and the dualq draft and implementation, please. So either this failure is accepted as a bug and hopefully fixed soon, or the drafts need to make explicitly clear that L4S/dualq do not aim for equitable sharing (which IMHO should pretty much rule out to deploy dualq into the wider internet). As it stands the draft text might be technically correct but also misleading as it gives the impression that equitable sharing is one of the goals, while hedging with "under roughly equal conditions" (without mentioning that dualq will make sure that (minimum RTT) L4S and non-L4S traffic will never see roughly equal conditions).

*) This issue is also not helped by the default choice of 1 and 15 ms AQM (acceptable standing queue) target delays, since theory predicts that for the targeted ~100ms internet-scale RTT for 1/sqrt(p) traffic a target of 5ms will be sufficient, and for the considerably shorter RTTs in the situation that highlights dualq's failure the 1/sqrt(p) target should be well below 1ms.

Version 0, edited 3 years ago by moeller0@… (next)
Note: See TracTickets for help on using tickets.