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

[Jonathan Morton <[e-mail]>]

> On 3 Apr, 2021, at 2:06 pm, [e-mail] wrote:
> 
> Regarding the two DSCP scheme, I'm not sure that I follow you as to how it avoids my argument above. Specifically, what outcomes of such an experiment would help us decide how L4S should interact with RFC3168 AQMs in the long term?

It is clear that L4S aims squarely for actual, operational deployments as quickly as the standardisation process permits.  My aim here is to ensure that whatever passes the process is safely deployable.  My view is that the "experiment" should be to verify that the system *is* safely deployable, before committing permanent allocations of codepoints to it.

I am convinced that L4S' current form is not up to the task, so this is a modification which tries to make it so without too many implementation changes.  Without modifications like these, I firmly believe this particular problem space would be better served by a wholesale move to non-ambiguous signalling than by any further work on L4S.

> I thought you might be saying that it allows the experiment to detect RFC3168 AQMs.

Not precisely.  Rather, it gives a way to verify that the path is wholly over a participating network.  If such verification is not forthcoming, the safe thing to do is to drop back to AIMD mode, and behave as much like conventional TCP as is practical.  Anything else risks misinterpreting RFC-3168 signals as L4S signals; the reverse is much less harmful.

> But if we see CE on a packet that doesn't have the Y DSCP, it might just have been bleached.

If the X or Y DSCP was bleached, we can infer that the path either crosses a participating network's border (where such bleaching is expected) or is wholly in a non-participating network (where random bleaching often occurs).  We should expect participating networks to preserve the X and Y DSCPs over the relevant paths, because the system would rely on that to function.  Initially these networks will be relatively small and manageable islands within the greater Internet.

> If we see a CE marked packet with the X DSCP, I guess that's more evidence of an RFC3618 AQM, which would at least give us a lower bound?

Yes.  Receiving the X DSCP indicates that the path does *not* pass through an L4S middlebox, but also does not pass through a participating network's border, so the path should be assumed to lie wholly outside the participating networks.  Any ECN AQMs in these networks will be RFC-3168 compliant and L4S ignorant.

The big advantage of this approach over that of applying a single "guard" DSCP is that it handles the case of L4S endpoints being deployed outside of the participating networks.  In a large-scale deployment scenario, that should be expected to happen.  However there is still the possibility of L4S middleboxes being deployed without the corresponding network preparations being undertaken, and that has the potential to defeat this measure.

Nevertheless, I hear David Black will put forward his notion of how a single guard DSCP should work, and we should pay attention to that.  Not necessarily to agree, but to take as a third possible option.  I'm sure it will at least draw from existing codified practice.

 - Jonathan Morton