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

[Bob Briscoe <[e-mail]>]

Jonathan,

I was trying to tease apart the merits of the L4S + DSCP approach for a 
/single/ network that you were proposing. So I'd like to go back to 
before the point where Koen sent the thread off in a different direction 
(to do with the merits of a DSCP for end-to-end signalling).

Although David started this thread, I don't think he had a detailed 
proposal. And I think Sebastian's  proposal is slightly different from 
yours (using the DSCP as a classifier at an L4S AQM, which I think is 
unnecessarily restrictive). I'd like to take one step at a time and 
focus on your approach first. Inline tagged [BB]...


On 25/03/2021 16:58, Jonathan Morton wrote:
>>>> 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] it depends on a string of leaps of faith (LoFs).
>> 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.

[BB] There is no L4S design 'baked in' to existing standardization work. 
L4S is on the experimental track, and designed to build /on/ ECN 
feedback in existing standards track IETF transport protocols. 
Specifically QUIC, RTCP and TCP.

An L4S congestion control acts at the sender in one direction. The other 
direction might use a completely different congestion control. This is 
outlined in l4s-arch, but it's no different from the architecture of any 
CC. For instance, if Cubic is acting in one direction, you can have 
Vegas or BBR or whatever in the other.

You are proposing that, in a connection between host X and host Y, if X 
sends using a scalable CC, it has to set both ECT(1) and a defined L4S 
DSCP. Then when peer Y sends, it has to set the same DSCP on the packets 
it sends to X. There are a number of problems with this:
a) There is no reason or need for peer Y to know anything about L4S. So 
how does it know to set this DSCP? A host doesn't normally even check 
what the incoming DSCP is.
b) This currently would only be useful to make the L4S DSCP scheme work. 
So it would seem unlikely to be adopted in any of the busy WGs working 
on these transport protocols. Particularly given it's unorthodox 
architecture (overloading a L3 protocol with an additional L4 meaning)
c) You seem to be assuming (or perhaps requiring) that the peer at one 
end of a connection can only use a scalable CC if the other peer also 
uses a scalable CC.
d) This also means that a scalable CC cannot be tested with a Classic CC 
in the reverse direction.
e) Requiring a 2-ended deployment greatly reduces the chances that any 
flow will use L4S.

Let's say there are 10 million hosts on a network participating in the 
L4S experiment. Even once 10,000 hosts deploy L4S with your DSCP scheme, 
they will still find 9.99M hosts without L4S support. In your scheme, 
both ends have to support L4S, which is a probability of 1 in a million 
(1 in 1000 squared) that any particular flow will support L4S. That 
makes the deployment incentives awful. And it's not such a great 
experiment either with so little L4S traffic.

Because AccECN for TCP is still being held back, we will anyway have 
this 2-ended deployment problem over TCP. But we don't want to 
unnecessarily create a 2-ended deployment over the other transports 
(QUIC, RTCP, etc).

>> 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.

[BB] The a/b/c examples I gave (still below) solely involved /customers/ 
attaching to a single ISP participating in the L4S experiment. If an L4S 
network bleaches at the border where its own customers attach, how can 
any L4S traffic ever enter or leave the network? I'm not understanding 
you. Specifically:
* at the first IP hop controlled by the L4S network, if it bleaches the 
L4S DSCP from attached L4S sending customers, how does any L4S traffic 
ever enter the network?
* at the last IP hop controlled by the L4S network, if it bleaches the 
L4S DSCP before forwarding to attached customers, how does any host ever 
receive L4S traffic?

Please don't answer this here. Instead, please address the specific 
examples below (a/b/c), to keep the discussion concrete.


>
> 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.

[BB] It is good practice to read someone else's email right through 
before you start answering it. Here, you are telling me what I told you 
further down this email, but without responding to the follow-on point I 
made about this (find "l4sops" below).

>
> 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.

[BB] I am trying to first understand the single DSCP approach you appear 
to be describing here. But I will not be able to understand you if you 
don't explain how your approach will work in the examples I give at 
a/b/c below.

And no-one is going to write your idea into a working group draft unless 
you individually address each of the criticisms of DSCP-based schemes in 
Appx B.4. You cannot seriously expect to be granted a free pass to 
ignore all the problems with DSCPs by simply pronouncing that every one 
of the arguments is invalid.

Now, please address the a/b/c points below.

>
>> 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.

[BB] We identified these potential problems before we brought L4S to the 
IETF, and at the very first ad hoc meeting about L4S (Prague Jul 2015), 
we proposed that this should be on the list of requirements that would 
need to be solved.

Here, we are putting your idea for using a DSCP to the test. So please 
address the point about how an L4S-participating network still has to 
use the techniques in l4sops, whether it adds a DSCP or not.


>>> 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.

[BB] Let's stick to one scheme at a time for now.



Bob


>
>   - Jonathan Morton
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/