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

[Sebastian Moeller <[e-mail]>]

Hi Bob,


I top post, because this is related, but not a point by point response to your argument why you consider Jonathans proposal unpalatable.




Here is my back of the envelop version of how to use a guard DSCP to secure an L4S experiment over existing networks without increasing the risk for innocent bystanders.

1) make the reference AQM configurable to require both the guard DSCP and ECT(1) (or CE) to steer a packet into the LL-queue.

2) make the reference protocols configurable to only negotiate "L4S-mode" if the initiator packets also carried the guard DSCP.

3) make the reference protocols configurable to only treat CEs as HF-CC signals if they are accompanied with the guard DSCP, otherwise treat them as a drop

4) optionally, configure the non-LL queue to not use ECN, so that any ECN marking in packet captures will come from upstream for unguarded packets.


Require for the duration of the experiment (by a MUST in the ID/RFC), that all L4S-protocols and L4S-AQMs ofparticipating networks/entities be configured to follow rules 1 to 3, and also require participating networks to use SLAs/TCAs to make sure to only pass the guard DSCP into networks that are also participating in the experiment, otherwise that DSCP should be re-marked to something else.

Given that neither the L4S AQM nor the protocols are finished and deployed yet, adding these features for the sake of a safe experiment seems not unfeasible, no?

The important idea here is not to reach 100% certainty, but really to use the DSCP as a tool for all participating networks to signal " I am L4S-aware and so is the next hop". It is still expected that these networks then follow the L4S-ops draft. What this should achieve is to avoid leaking L4S signaling into networks that are not prepared to handle L4S behavior.

This will allow to finally perform all those safety and functionality measurements and tests, that you believe can only be won over live networks, without externalizing the risk to innocent bystanders significantly.

This is also orthogonal to the question what identifier a L4S PS might use in the end.
I note your objections to Jonathan's proposal of incorporating DSCPs into L4S proper (which I think would be a good idea, but orthogonal to my idea here). I commented upon these in the context of this limited guard DSCP proposal (seatch for text prefixed [SM]) and think none of them would be show-stopper, but all are addressed. No leaps of faith required...

Best Regards
	Sebastian




> On Mar 25, 2021, at 15:00, Bob Briscoe <[e-mail]> wrote:
> 
> 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. 

	[SM] In my proposal that only happens if the end-network invalidly claims to be L4S-aware, by asserting the guard DSCP while employing an rfc3168 AQM. This clearly would be the responsibility of the end-point network to remedy. 


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

	[SM] Unless the receiving network declared L4S awareness via an SLA/TCA to conserve the guard DSCP un-mapped, the L4S-participating network would remap the guard DSCP and de-fang the L4S signaling. The whole idea is to make sure that the L4S experiment happens between/in L4S-participating network...


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

	[SM] The L4S-participating network needs to follow the L4S-ops ID/RFC to make sure this can not happen.


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

	[SM] In the context of guarding an L4S experiment bleaching is part of the safety mechanism and not an issue.


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

	[SM] For the scope of an experiment, it would be in the responsibility of participating networks to assure the lack of sensitive rfc3168 AQMs, side-stepping this issue as well.

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