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

[Jonathan Morton <[e-mail]>]

> On 29 Mar, 2021, at 4:23 pm, [e-mail] wrote:
> 
> I can see that the idea of using a guard DSCP is proposed as a pragmatic way to make progress. However, I think an experiment isolated from RFC3168 AQMs by a DSCP would not, of itself, resolve the problem of L4S and RFC3168 AQMs. 
> 
> Suppose the L4S folks go away and deploy L4S in such a DSCP-guarded domain. They  make progress on some of the experimental goals listed in draft-ietf-tsvwg-ecn-l4s-id, and come back and say it works really well, and now they want to deploy it on the full internet. At that point, the WG is pretty much in the same position it is now - not knowing how to resolve the RFC3168 issue. Except that the stakes would be even higher, because:
> 
> - the L4S folks would have made even more investment in L4S, in a production deployment across multiple companies
> - Other folks would potentially have deployed more RFC3168 AQMs
> 
> So unfortunately it seems to me that, although it now seems pretty hard for the WG to reach consensus on  how to resolve the RFC3168 issue, waiting for a DSCP-isolated experiment will make this harder, not easier. I think if would be better for the WG to find a path to that resolution sooner rather than later. That's not to say that a DSCP-guarded experiment couldn't contribute to such a resolution, but without some agreement on what the path to a decision looks like, it's not obvious that one is essential.

I think I can agree with the above.

A single-DSCP containment can limit the harm directly caused by the experiment, but it's not a long-term solution since it still leaves L4S as an RFC-4774 Option 1 scheme which *needs* to be contained to specially prepared networks.  I note also that even this minimal protection is not being greeted with any enthusiasm by L4S proponents.  Your argument against it is, however, the most coherent that I've heard so far.

I suggested a two-DSCP scheme as something with more robustness and longevity than a single-DSCP scheme, while still fitting the "L4S way" of doing things and requiring only minor implementation changes to try out.  The aim here is RFC-4774 Option 2, ie. explicitly detecting which signalling scheme is used by the network.  It doesn't solve all of the problems, but I think it does illuminate one path towards success.

Since two years ago, SCE has been available as an RFC-4774 Option 3 solution, though it has been opposed by Team L4S as an existential threat.  Adding DSCP labelling to SCE allows it to be used with simple dual-queue middleboxes, so far as the DSCP survives in the network, as well as the preferred FQ/AF AQMs, and without the serious compatibility problems that seem to be inherent to the conditional redefinition of a CE mark.  The same DSCP label could be used temporarily as an experiment containment mechanism, though SCE doesn't really need it.

What do you think of the latter two approaches?

 - Jonathan Morton