Re: [tsvwg] L4S/3168 Coexistence

[Jonathan Morton <[e-mail]>]

> On 10 May, 2021, at 7:49 pm, Martin Duke <[e-mail]> wrote:
> 
> (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%)

Our data suggests it's more like 10% from an Eastern Europe perspective.  If you happen to be Norwegian or French or Mexican, the deployment prevalence in those places is even higher, due to active adoption by major consumer ISPs in those regions.  There is also evidence that deployment is increasing significantly over time, and I think Stuart Cheshire mentioned that he was aware of some impending major deployments.

Some brands of CPE routinely include RFC-3168 AQM as part of their wifi stack and/or "bufferbloat mitigation" features, which are advertised on the packaging.

> (2) These 3168 routers implement shared queues (no known examples, but it might happen), AND

As you note, single-queue RFC-3168 AQMs are RFC-compliant and should therefore be an expected occurrence on the Internet.  There are also various ways that the "flow aware" mechanisms in most of the actually-deployed AQMs can fail to distinguish flows.  I will leave most of that discussion to Jake for now.

> (3) The heuristics result in a false negative (<<1%?)

Said heuristics were disabled by default in the reference implementation after we published data showing they were nowhere near that level of reliability, and have not yet been replaced by a more reliable algorithm.  I refuse to rely on the reliability of something that I can successfully predict and provoke failure modes for.  These algorithms also have not been specified in an IETF document, only in an external white paper - so from a procedural perspective, it could be argued that they are not even part of the specification.

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

The above combination is also *not* the only scenario in which great harm may occur to conventional traffic.  Within the past week, we were introduced to the Replay Protection Window that is a feature of many VPN tunnels, and quickly realised that this interacted badly with DualQ to the point where an attacker could conduct a full DoS attack on it, even if the target did not use L4S traffic themselves.  See the other thread for details.

In my risk analysis chart, the RFC-3168 interaction is a potential Major category occurrence, while the VPN Replay Window attack is a Serious category occurrence.  Serious is only one step below Catastrophic, and would require correspondingly rigorous measures to ensure that it basically cannot happen.

Such measures are designed into VPNs to guard against a similar attack involving Diffserv (which has existed for a long time by now), but L4S is a new thing and no such protections yet exist.  Additionally, one of the main techniques for dealing with Diffserv (simply not copying the DSCP to the outer header) is not applicable to L4S, which REQUIRES the special ECN codepoint to avoid triggering the other pathology.

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

I think some participants in the discussion deliberately try to make it hard to follow, so that misconceptions easily arise in their favour.  Please be on guard against that.

 - Jonathan Morton