Re: [tsvwg] L4S/3168 Coexistence

[Martin Duke <[e-mail]>]

Thanks all,

This thread has improved my understanding.

On Tue, May 11, 2021 at 3:00 AM Jonathan Morton <[e-mail]>
wrote:

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