Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)

[Jonathan Morton <[e-mail]>]

> On 31 Mar, 2021, at 2:12 am, Wesley Eddy <[e-mail]> wrote:
> 
>> Okay, so what mechanism do you propose to contain the L4S experiment to the participating networks?
> 
> I think the notion of a strong containment guarantee to participating networks that you mention is a bit extreme in contrast to just reducing the likelihood or severity of issues.

Certainly I would prefer to see the underlying problems fixed, rather than adding safety barriers around the edges. Does that open the door to SCE-type signalling?  If not, why not?

> There has been a lot of congestion control experimentation on Internet paths that strong containment has not been expected of.

That's likely because the expected problems from most well-designed congestion controls, which are explicitly intended to coexist with existing traffic, are quite minor.  Once upon a time, TCP CUBIC was such an experiment.

I can also point to a major counterexample in the form of DCTCP.  L4S is a direct descendant of DCTCP, requiring a similar level of caution.  The main difference between the two is that L4S is capable of coexisting with conventional congestion controls in a correctly prepared network - but the "correctly prepared" part is crucial.

> I think the sense of the working group has been to take an approach of collecting and recommending reasonable measures to identify and avoid issues when experimenting with L4S.  This is mainly in Section 4 of the ops draft right now.  I have not understood the general working group direction to be asking for strong containment guarantees though, and I don't think that needs to be a goal.

My best read of L4S proponents' intentions is that the very moment they have an Experimental RFC published that sanctions a deployment of L4S (as required by RFC-8311), they will start pushing firmware updates and new kernels across a wide variety of cable networks in order to deploy "Low Latency DOCSIS", which includes L4S functionality as a core feature.  Far from a small-scale, carefully controlled experiment, this would be a large-scale deployment with the explicit intention of being hard to roll back.

I believe this has a strong likelihood of causing L4S traffic to flow not only within these networks and their attached CDNs, but as an unintended side effect, over other networks as well.  We have already discussed at length the problems this is likely to cause to uninvolved bystanders, which may even include unsuspecting cable ISP subscribers who suddenly start having L4S-enabled set-top boxes alongside their conventional-traffic computers.

Nothing I have heard in the past week has reassured me on those points.  Rather, the most basic of precautions is rejected as unworkable, and the simplest of modifications to L4S to enable them dismissed as infeasible.  Bob Briscoe even seems to think simultaneously that an ISP's customers are outside the "prepared network" for the experiment, and that putting a firewall to prevent L4S traffic reaching them would be absurd.  The cognitive dissonance is strong with that one.

Hence the question at the top.  I think it has reached maximum relevance.

- Jonathan Morton