[tsvwg] DSCPs and L4S: Label DSCP

["Black, David" <[e-mail]>]

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