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

From: "[email-masked]" <[email-masked]>
Date: Sat, 3 Apr 2021 11:06:39 +0000 (UTC)

Jonathan,see below [AB]

    On Monday, March 29, 2021, 3:05:05 PM GMT+1, Jonathan Morton <[email-masked]> wrote:  
 
 > On 29 Mar, 2021, at 4:23 pm, [email-masked] 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?

[AB] 
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? I thought you might be saying that it allows the experiment to detect RFC3168 AQMs. But if we see CE on a packet that doesn't have the Y DSCP, it might just have been bleached. 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?
As someone who is merely an interested bystander, I am trying to be careful for to comment where I can't add value; where I don't comment this is not necessarily a criticism. I don't think I have much of value to say about SCE; AFAICT the no-one questions that using two bits would have been better if it could be managed, but the question is deployability (and incentives to deploy) in operators, on which I don't have the background to have an informed opinion. Similarly on the deployability of guard-DSCP schemes.

Alex

---

From: Jonathan Morton <[email-masked]>
Date: Sat, 3 Apr 2021 14:53:46 +0300

> On 3 Apr, 2021, at 2:06 pm, [email-masked] 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