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

[Jonathan Morton <[e-mail]>]

>>> Can someone explain for the record how using a DSCP as an L4S identifier would solve the CE ambiguity problem?
>> 
>> It doesn't.  It only allows containing the resulting harm to participating networks, thereby protecting (most) innocent bystanders.  It's enough, I think, to conduct a field experiment to discover just how bad the problem really is in practice.
>> 
>> This is predicated on the notion that the L4S-ID DSCP(s) are bleached or dropped at the participating networks' border, and in the case of border bleaching, that L4S endpoints interpret CE marks *not* carrying the L4S-ID DSCP as per RFC-3168 or RFC-8511.
> 
> [BB] "Predicated on the notion" is posh for "it depends on a string of leaps of faith" (LoFs).

I really don't like your tone with this phrasing.  But let's put that aside.

> Specifically:
> 
> LoF (1) The receiver somehow feeds back the arriving DSCP to the sender, which would require new IETF work in QUIC, TCPM, RTCP, etc. The only use-case to justify DSCP feedback would be to make this L4S-ID DSCP idea work. And this work hasn't started anywhere yet. That's not just a leap of faith. It's a leap into the abyss.

Are you arguing here that the current L4S design is so thoroughly baked into existing standardisation work and/or implementations that not even minor changes can be made?  It sounds very much like it to me, and that is very troubling for the prospect of making L4S safe to deploy beyond an Option 1 (completely isolated) context.

In any case, I have already shown you a way to feed back the presence or absence of a particular DSCP.  Simply refrain from emitting the special DSCP, except on the initial SYN, unless you received the appropriate special DSCP on all valid packets received on the connection.  That gives you a very easy way to switch the connection into "Classic mode" if it strays outside the approved path.

> LoF (2) There are no FIFO RFC3168 AQMs a) upstream of the participating network, b) downstream of it, or c) within it (see details below).

Incorrect.  Remember that when using a DSCP as a containment mechanism, it is assumed (as I spelled out previously) that the borders of the network at least bleach that DSCP, and may even block traffic carrying it.  That's how containment works.  So if the L4S traffic crosses a border of the participating network, it automatically switches to Classic mode and there is no more problem with RFC-3168 AQMs on any part of the path.

Which leaves open two scenarios where an RFC-3168 could be encountered without crossing a border:

1: Within the participating network.  But all RFC-3168 AQMs are supposed to have been removed from such a network before L4S was deployed on it.  So either the onus is on the network operator (who is at least an "interested observer") to deal with the problem, *or* the RFC-3168 AQM is present specifically for the purpose of experimentation, eg. to find out how the combination with L4S traffic really works in the real world.

2: The path runs entirely outside the participating network.  This implies that two communicating L4S endpoints were deployed outside the experimental network, which would violate the spirit of the experimental deployment and should not be allowed.  The two-DSCP scheme I outlined in my other post specifically attempts to detect and protect against this eventuality.

> LoF (3) That's before we get to all the other reasons for why using two fields (ECN and Diffserv) as a classifier would rarely work for those who /do/ want to use L4S (in Appx B.4 of ecn-l4s-id already pointed to on this thread).

I do not accept Appendix B.4 to be a valid set of arguments against using DSCP for this purpose.  If nothing else, it does not appear to consider any form of the two-DSCP scheme I recently described.  I would encourage you to give it a serious, principled consideration.

> Now let's see how realistic LoF (2) is by putting this DSCP idea to the test - by hiding these needles in each type of haystack:
> 
> a). Upstream:
> Imagine a FIFO RFC3168 AQM in the queue of a home router in the upstream direction. An L4S client sends L4S packets through this AQM, which marks some as CE. Then the network participating in the L4S experiment delivers them, with the L4S-ID DSCP intact, to an on-net server. But the CE markings were RFC3168 not L4S. 
> 
> b) Downstream: 
> Consider an RFC3168 AQM in the network of a corporate site or campus network receiving traffic from a connected L4S-participating network. Or perhaps on the access into a data centre connected to the participating L4S network. Same problem; the DSCP says its L4S, but the CE was RFC3168. 
> 
> c) Within: 
> Consider an RFC3168 AQM within the network participating in the L4S experiment. Same problem. The participating network delivers the packet with the L4S-ID DSCP intact, but the CE marking is RFC3168, not L4S. 
> 
> In this last case, the L4S-paticipating network has to use techniques like those in l4sops to make sure any FIFO RFC3168 AQMs don't mark ECT(1). That's no different to if ECT(1) alone was the identifier.

Thank you for confirming that you understand that using ECT(1) alone as the identifier suffers from all of these problems.  That was a big sticking point over the past two years, and I'm glad we can now get past that.

>> I refer you also to my recent post titled "L4S, DSCP, and RFC-4774 Option 2" in which I give a more detailed explanation of a two-DSCP proposal.  The short version is that a version of L4S using that scheme would have *some* positive confidence whether or not they were receiving L4S or conventional marking, without the need for heuristic probing or monitoring.
> 
> This requires the same 3 leaps of faith as above. 

No, it does not.  I encourage you to re-read that and carefully absorb my explanation of how it works.  I think you will find the exercise very enlightening.

 - Jonathan Morton