Re: [tsvwg] L4S/3168 Coexistence

[Greg White <[e-mail]>]

Hi Martin,

I think you’ve mostly got that right.  The clarifications I’d make to your 3 conditions are:

2a) OR, the router implementation is a non-L4S-aware FQ (all known examples of 3168), and it’s carrying a tunnel with mixed L4S/Classic traffic (??%)

4) AND, a long-running (multiple seconds), capacity-seeking L4S flow exists in the queue at the same time as a Classic flow


But, the current heuristics result in more false positives than we’d like, and introduce complexity that we’d like to avoid where possible.
So, L4Sops says: if you are intending to use L4S for long-running flows, first determine whether the network/path you are using has a likelihood of containing a 3168 bottleneck, then decide whether real-time heuristics and/or fallback are needed.

In Akamai’s data, there were 3 small ASNs (out of ~800) where the apparent prevalence of 3168 was over 20%, another 4 small ASNs where the prevalence was over 10%, and somewhere between 6 and 25 ASNs where the prevalence was over 3%.  So: either avoid using L4S on those networks, or run the heuristics with real-time fallback, or reach out to those networks and let them know what remedies they can implement (listed in L4Sops) to enable L4S in their network.

-Greg


From: tsvwg <[e-mail]> on behalf of Martin Duke <[e-mail]>
Date: Monday, May 10, 2021 at 10:50 AM
To: tsvwg <[e-mail]>
Subject: [tsvwg] L4S/3168 Coexistence

(As an individual)

I have not been able to follow these threads as well as I'd like. Assuming I'm not the only one, I would like to confirm that the current state of the coexistence discussion is that L4S will create problems for "classic flows" under the following conditions:

(1) There are 3168 routers in the path (order of 1%)
(2) These 3168 routers implement shared queues (no known examples, but it might happen), AND
(3) The heuristics result in a false negative (<<1%?)

On the face of it (1% * 1%? * <<1%?) seems to be a small price to pay in the aggregate. I hope we'd agree on that! So the argument against, ISTM, would rest on two things:

(A) These failures are not uniformly distributed, and there is some non-negligible use case that will suffer grievously. It would be very helpful to me if someone could concisely state what this use case is and where it exists. Nothing in the congestion control space is provably optimal across all parameters and generalized fear that bad parameters might exist somewhere is IMO not constructive.

(B) Because you can't have a vague MUST, we aren't REQUIRING any particular limit to false negatives. If experiment participants are going to agree to do something, I wonder if we can't converge on some words here that prevent really dumb stuff?

Maybe I have this wrong! The debate is quite hard to follow.

Martin