Re: [tsvwg] FQ & VPNs

[Jonathan Morton <[e-mail]>]

> On 21 Feb, 2021, at 11:23 pm, Ingemar Johansson S <[e-mail]> wrote:
> 
> Help me to understand this right. 
> 
> You argue that Tom's suggestion is not possible because it requires that the
> group agrees to start an L4S experiment that stipulates an alternate
> interpretation for the ECT(1) codepoint (as per RFC8311). 
> And further you point at the problem that RFC3168 AQMs cannot distinguish
> between ECT(0) and ECT(1) as evidence that the L4S experiment cannot be
> (safely) run, and consequently the L4S experiment should not run.
> 
> Do I understand right?, I am really confused. It all sounds like a catch-22
> situation to me ?

It's not a Catch 22.  It's just the heart of the problem with L4S.

L4S cannot safely be deployed on existing networks - that is axiomatic in its current form.  Therefore, you have to prepare the network as fully L4S-aware before you can safely deploy your first endpoints - on Internet scale, that is not really feasible within a decade.  It would be easier to start deployment if you had a good way of containing L4S traffic to a small portion of the network (eg. a CDN and an associated ISP) in which dealing with the network preparation is actually feasible in the short term.

Using a DSCP as the L4S identifier would be such a method, permitting fencing off the L4S traffic at the network boundaries, and because the network needs to be prepared anyway, there should be no problem with DSCP bleaching.  Therefore there is actually no reason to consume ECT(1) as the L4S ID.

Until you figure out the above, you will not get a published Experimental RFC, which is what RFC-8311 requires to override that requirement in RFC-3168.  But there *is* a path forward to success, and therefore it is not a Catch 22.  It's just going to be a very difficult and drawn-out process to deploy L4S, unless some relatively significant design change occurs (which we haven't seen in the past two years) to cure some of the deficiencies.


Conversely, let's look at SCE from the same perspective.  Remember, SCE is capable of achieving the same performance as L4S, given similar marking and response algorithms.  The difference is in backwards compatibility.

SCE is specifically designed to be compatible with existing networks, and to behave identically to conventional traffic in that case.  Instead of identifying itself to the network and trusting that the network understands that message, the network distinguishes the SCE signal from the existing ECN signal unambiguously, and trusts that existing receivers will merely ignore a signal that is currently specified to be ignored.  This means SCE endpoints and middleboxes can be deployed safely on independent schedules, and it is not necessary to eliminate old equipment, nor to fence off the edges of networks to contain SCE traffic.

It is of course possible to label SCE traffic with a DSCP at source, and thus use the simplest possible two-queue AQM structure that can run at a bajillion packets per second.  It doesn't cause any safety problems if the DSCP is bleached en route, because the receiver can still distinguish the intent of the marks.  In practice, most people are likely to use flow-aware AQM or none at all, just as they do today, and this does not require a DSCP.

SCE also requires an Experimental RFC to be published before its new use of ECT(1) is permitted in public networks.  This is no different from the situation with L4S.  But because there are few if any safety concerns of the type that L4S raises (in particular, SCE's failure modes tend to *reduce* its load on the network, not increase it), this should not be a big obstacle - if only the WG would adopt it.  Currently L4S stands in the way of that.

But that is why we proposed SCE as an alternative to L4S in the same problem space.  It works just as well in the ideal case, and is much easier to deploy.

 - Jonathan Morton