Re: [tsvwg] DSCPs and L4S: Label DSCP

[Jonathan Morton <[e-mail]>]

> 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