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

[Bob Briscoe <[e-mail]>]

Jonathan, David,

On 24/03/2021 22:23, Jonathan Morton wrote:
>> On 25 Mar, 2021, at 12:10 am, Bob Briscoe <[e-mail]> 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] "Predicated on the notion" is posh for "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.

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

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


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.


ecn-l4s-id correctly summarizes all the above with the following para:

    Hard to distinguish Classic ECN AQM:  Defining a DSCP to indicate L4S
       is a way to help network nodes identify L4S packets (albeit
       unreliable due to the likelihood of bleaching - see above).
       However, it does not help hosts distinguish between ECN markings
       from L4S and Classic AQMs.  This is because Classic AQMs would
       have been implemented without any logic to recognize an L4S DSCP
       or apply L4S marking behaviour.


More frankly, the amount of time wasted discussing this idea is down to 
an extremely sloppy characterization of the problem in some people's 
minds as something vaguely to do with classifiers. Added to extreme 
vagueness in the distinction between receivers and senders. This is not 
how the IETF should be.


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



Bob

>
>   - Jonathan Morton

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