Subject: [tsvwg] DSCPs and L4S: Label DSCP

From: "Black, David" <[email-masked]>
Date: Fri, 28 May 2021 22:01:43 +0000

This note proposes a simple usage of DSCPs with L4S, hereafter called "Label DSCP". This is a proposal for the WG to consider, adopt, reject, fold, spindle and/or mutilate as the WG sees fit. This note is not direction to the WG from a WG chair.  The Label DSCP proposal is based on Section 3 of RFC 4774, which assumes (but does not require) use of DSCPs to indicate alternate ECN semantics:

   The assumption of this document is that when alternate semantics are
   defined for the ECN field, a codepoint in the diffserv field is used
   to signal the use of these alternate ECN semantics to the router.
   That is, the end host sets the codepoint in the diffserv field to
   indicate to routers that alternate semantics to the ECN field are
   being used.  (https://datatracker.ietf.org/doc/html/rfc4774#section-3)

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. Please note that DSCP usage is not required by RFC 4774 - this approach is proposed as a path forward to get on with L4S activity in actual networks (e.g., in line with Stuart Cheshire's comments in the interim meeting, among others).

The "Label DSCP" approach also adds a goal to the L4S experiment: Evaluate the utility and necessity (or lack thereof) of using DSCPs to indicate alternate L4S ECN semantics. Results in this area would be expected to help determine whether the DSCP requirement can be removed as part of evaluating results of experimenting with L4S. While specific DSCP usage remains up to network operators (see RFC 2475), the WG ought to recommend a small number of DSCPs as appropriate for experimental use with L4S. In addition, existing or proposed DSCPs could be used, e.g., one or both DSCPs that have been proposed for the NQB PHB.

The "Label DSCP" approach does not change two important aspects of L4S:

              A. The L4S queue selector is ECT(1).  Other classifiers
                            (e.g., based on DSCP) may include/exclude traffic
                            from L4S handling as already specified in Section 5.1
                            of the -17 version of draft-ietf-tsvwg-ecn-l4s-id.
              (https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-17#section-5.1)

              B. Transport protocols do not react to receipt of specific
                            DSCPs from the network. DSCPs on end systems continue
                            to function as inputs to the network, not as outputs
                            from the network.

The rationale for "Label DSCP" is that Differentiated Services (Diffserv) is an established Internet quality of service architecture, and this use of DSCPs for L4S improves compatibility/alignment of the L4S service with Diffserv. One surprise has already been encountered in IPsec anti-replay, where the IPsec standards expect DSCPs to identify QoS differences, and more may well turn up. The "Label DSCP" approach provides the ability to address IPsec anti-replay via existing Diffserv support in the IPsec architecture (RFC 4301), in contrast to alternative suggestions of revising the IPsec architecture to enable experimentation with L4S, which seem extremely unlikely to be implemented. This approach does not resolve all problematic interactions between L4S and IPsec anti-replay, rather it is a "reduce to previous case" approach that takes advantage of prior work on Diffserv interactions with IPsec anti-replay.

A primary purpose of using DSCPs is to enable use of existing Diffserv tools and techniques to better manage L4S traffic - in particular, enable operators to apply traffic conditioning (and even discarding, which one would hope is not necessary) without having to extend existing tools and techniques to discriminate or classify traffic based on ECN codepoints, which poses risks to the end-to-end transparency of the ECN field. The preference for ECT(1) as the L4S indicator was significantly motivated by end-to-end transparency of the ECN field, hence damage to that transparency would be a most unfortunate side effect of experimental L4S deployment.

RFC 4774 assumes that DSCPs are set by end systems.  As an alternative, under a "Label DSCP" approach, a fine-grained multi-flow classifier at an appropriate end-system-facing network node could set L4S DSCPs in packets based on operator knowledge and confidence that the traffic involved is using congestion control that meets the "Prague requirements" specified in draft-ietf-l4s-ecn-id.

The alternate semantics of the CE codepoint are subtle.  If all traffic using a DSCP is L4S traffic, the indicated alternate CE semantics are the L4S semantics. If there is a mix of L4S and Classic traffic using a DSCP, the indicated alternate CE semantics are that the congestion indication could be either an L4S congestion indication or a Classic congestion indication.

The proposal ends here - I'll be happy to explain further, provide additional rationale, etc. in discussion. I'm hoping that this provides a possible path forward for the WG as a whole.

Thanks, --David (as an individual, not a WG chair).

---

From: Jonathan Morton <[email-masked]>
Date: Sun, 30 May 2021 00:48:56 +0300

> On 29 May, 2021, at 1:01 am, Black, David <[email-masked]> 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

---

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 30 May 2021 12:20:01 +0100

> If I managed to fundamentally misunderstand anything here, please do clarify.

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)

---

From: Jonathan Morton <[email-masked]>
Date: Sun, 30 May 2021 17:30:52 +0300

> On 30 May, 2021, at 2:20 pm, Gorry Fairhurst <[email-masked]> wrote:
> 
> * 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 think this is consistent with the initial use of a Pool 2 DSCP.  Discussion of whether an allocation in the other pools is warranted can take place later, with the benefit of field experience.

> * 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?

I doubt that the set of DSCPs in use on any single network precludes the temporary allocation of one more for experimental purposes.  If that is an actual concern, let the concerned speak up for themselves.

> * 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?

David Black's wording permits the use of other DSCPs to explicitly include or exclude traffic from the L queue.  I think this is compatible with parallel use of NQB.  You may be right that this consideration excludes the NQB DSCP from use as the Label DSCP.

> * 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?

No comment.

 - Jonathan Morton