Re: [tsvwg] DSCPs and L4S: Label DSCP

[Gorry Fairhurst <[e-mail]>]

On 29/05/2021 22:48, Jonathan Morton wrote:
>> On 29 May, 2021, at 1:01 am, Black, David <[e-mail]> wrote:
>>
>> The "Label DSCP" approach takes that assumption as a suggestion and accepts the suggestion, i.e., network domains experimenting with L4S MUST use DSCPs to indicate the alternate semantics of the ECN field, specifically the ECT(1) and CE codepoints.
> Okay, let me summarise this proposal from a different perspective, to be sure that everyone understands it correctly.  Specifically, in terms of concrete requirements on implementations and deployments.
>
> L4S senders are required to emit the Label DSCP, either natively or by passing through a filter before the first possible bottleneck.  L4S receivers are *not* required to verify the Label DSCP is still on the packet.
>
> The paragraph quoted above implies that any traffic reaching a DualQ instance and *not* carrying the Label DSCP, will go into the C queue and receive RFC-3168 compliant treatment.  For this traffic, DualQ will behave exactly like a single-queue RFC-3168 AQM.
>
> Traffic that *does* carry the Label DSCP will be sorted between the C and L queues based primarily on the ECN field.  Such traffic that goes to the L queue will receive L4S type CE marking, while the C queue will still apply conventional CE marking and/or dropping.
>
> This does not imply that *only* L4S traffic carries the Label DSCP, but that using the Label DSCP indicates at least passive participation in the L4S experiment, which includes the interactions between conventional and L4S traffic.  Non-participating traffic receives only conventional treatment, and is thus independent of L4S' redefinitions of ECN field codepoints and semantics.
>
> L4S traffic reaching the boundary of the participating network will encounter the existing DSCP filtering infrastructure.  It is this which takes primary responsibility for "containment" of the L4S experiment within the participating networks.  (Another necessary aspect of this containment is refraining from deploying L4S endpoints outside that boundary.)  Merely bleaching the DSCP field will simply lead to L4S traffic that crosses the boundary passing through single-queue RFC-3168 AQMs with all the attendant adverse effects on conventional traffic.  Therefore, some more robust measure (rate limiting, blocking) must be applied at the boundary.
>
> VPNs ensure that a single DSCP is applied to outer packet headers of a given SA, by default CS0, regardless of the inner packet's DSCP or ECN fields.  VPNs *may* be configured to create a distinct SA for traffic carrying the Label DSCP, and apply the Label DSCP to the outer header of that SA.  If packets with CS0 on the outer header will all go into the C queue, this avoids accidentally enabling the VPN Replay Window DoS attack for existing VPNs.  Only VPNs specifically configured for the Label DSCP will be vulnerable, and this can be used to explore the problem space.
>
> Obviously, L4S traffic entering a default VPN SA will also go through the C queue, as well as through the same FQ bucket as the rest of the SA, and its modified response to CE marks will have the same effects as have been widely discussed so far.  This is why *all* L4S senders must emit the Label DSCP under this proposal.
>
> If I managed to fundamentally misunderstand anything here, please do clarify.
>
>   - Jonathan Morton

Thank you Jonathon,

 From my own view, I also see a few more things:

* This proposed approach is/was already possible for an operator/network 
using DiffServ without any IETF specification using an Experimental or 
Local Use DSCP from Pool 2.  One key aspect of the proposed re-design is 
to require assignment of a specific Pool1/3 DSCP or set of DSCPs to  
identify L4S traffic. It seems highly unlikely the IETF will want to 
standardise a large set of DSCPs.

* I expect the proposed experiment will not be attractive to people who 
are already using a set of DSCPs (e.g. to ensure traffic is 
queued/mapped in a way that reduces the latency of WiFI, MPLS and other 
subnets). How would such a DSCP assignment consider methods that expect 
some DSCPs to be mapped to lower latency treatments that are below IP? 
Is that OK?

* Specifically, I don't think the current proposed behaviour of the DSCP 
Label is what was requested in the NQB draft. I think the latter seeks 
codepoints that can work end-to-end, and wouldn't be remarked at 
DiffServ domain edges. I'm not sure whether NQB traffic would therefore 
be counted as L4S?

*  l can see the proposal could be used to defer the assignment of the 
ECT(1) codepoint, and would postpone any decisions about the need to 
obsolete the current ECT(0) usage - perhaps this is good for those who 
are focussed on other proposals, but is this delay to allow more 
experiments what is also wanted by others?

I see this as David's individual email - so, also as an individual, I'd 
love everyone to know they are welcome to send emails to support this 
proposal or not.

Gorry

(as individual)