Skip to main content

A Service-Agnostic Semantics for Differentiated Services Code Point (DSCP)
draft-meng-tsvwg-service-agnostic-dscp-00

Document Type Active Internet-Draft (individual)
Authors Tong Meng , Yu Yin
Last updated 2023-03-13
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-meng-tsvwg-service-agnostic-dscp-00
TSVWG                                                            T. Meng
Internet-Draft                                                    Y. Yin
Intended status: Informational                       Huawei Technologies
Expires: 14 September 2023                                 13 March 2023

  A Service-Agnostic Semantics for Differentiated Services Code Point
                                 (DSCP)
               draft-meng-tsvwg-service-agnostic-dscp-00

Abstract

   This memo proposes a service-agnostic semantics for Differentiated
   Services Code Point (DSCP).  It disassociates DSCP from
   classification of service classes.  Instead, individual packets are
   marked dynamically in a Quality-of-Experience (QoE)-aware manner.
   Such a more flexible use of Differentiated Services (DiffServ)
   involves interactions with transport protocols on application hosts.
   Meanwhile, the semantics adds no complexity to traffic conditioning
   and Per-Hop-Behavior (PHB) enforcement within DiffServ network
   domain.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 14 September 2023.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights

Meng & Yin              Expires 14 September 2023               [Page 1]
Internet-Draft       Service Agnostic DSCP Semantics          March 2023

   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Limitations of Service-Dependent DSCP Semantics . . . . . . .   3
   4.  Service-Agnostic DSCP Semantics . . . . . . . . . . . . . . .   4
     4.1.  Semantics Overview  . . . . . . . . . . . . . . . . . . .   4
     4.2.  Example Scenario  . . . . . . . . . . . . . . . . . . . .   5
   5.  Interactions with Transport Protocols . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   This memo proposes a service-agnostic semantics for Differentiated
   Services Code Point (DSCP).  It treats each DSCP as simple as a
   network Quality-of-Service (QoS), without extra attributes of service
   class as recommended in other RFCs.  Being service-agnostic enables
   flexible use of Differentiated Services (DiffServ), and involves
   interactions with transport protocols.  In particular, application
   hosts can determine per-packet DSCP marking in a Quality-of-
   Experience (QoE)-aware manner.  Meanwhile, the semantics adds no
   complexity to traffic conditioning and Per-Hop-Behavior (PHB)
   enforcement in the network.

   This memo is organized as follows.  Section 2 explains important
   terms.  Section 3 illustrates the limitations of DSCP semantics
   associated with service class.  Section 4 describes the service-
   agnostic semantics and provides an illustrating example on DSCP
   marking.  Section 5 explains transport protocol interactions.
   Section 6 and Section 7 cover security and IANA considerations,
   respectively.

Meng & Yin              Expires 14 September 2023               [Page 2]
Internet-Draft       Service Agnostic DSCP Semantics          March 2023

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   Other terms used in this memo are explained below.

   Service class           A set of applications with similar traffic
                           characteristics and performance requirements,
                           as defined in [RFC4594].

   Subflow                 A flow of packets traversing an individual
                           path in a multipath connection, as defined in
                           [RFC8684].

   Transport connection    A transport connection refers to a transport-
                           layer flow using a single path or a multipath
                           connection composed of multiple subflows.

   Transport-layer flow    A single-path flow of packets identified by
                           the 5-tuple (i.e., source and destination IP
                           addresses, source and destination ports,
                           transport protocol), which has the same
                           meaning in [RFC7657].

3.  Limitations of Service-Dependent DSCP Semantics

   To achieve scalable QoS discrimination, existing discussion on
   Differentiated Services (DiffServ) architecture classifies the vast
   number of applications into a few service classes [RFC4594] according
   to their high-level traffic characteristics.  Differentiated Services
   Code Points (DSCPs) and Per-Hop-Behaviors (PHBs) are associated to
   those service classes.  Such a service-dependent DSCP semantics
   restricts the flexibility of DiffServ usage, and undermines its
   effectiveness in some cases.

   The coarse classification granularity may result in excessively high
   pressure on the network.  A typical scenario is when a single DSCP
   (or a group of DSCPs for an Assured Forwarding (AF) class [RFC2597])
   is used for a transport-layer flow, which multiplexes multiple
   traffic streams corresponding to heterogeneous types of services.
   The flow-level DSCP marking should be determined by the highest QoS
   requirements for all streams, such that the employed PHB group is
   effectively over-provisioned for any individual stream.  Although
   [RFC7657] and [RFC8837] recommend different DSCP markings for

Meng & Yin              Expires 14 September 2023               [Page 3]
Internet-Draft       Service Agnostic DSCP Semantics          March 2023

   multiplexed Real-time Transport Protocol (RTP) streams in Real-Time
   Communication (RTC), a single media stream of immersive and
   interactive applications can still have stringent throughput and
   latency requirements, e.g., a responsive UHD video stream in cloud
   gaming.  The resulting provision pressure makes it hard for the
   network bottleneck to scale to a large volume of concurrent traffic.
   Besides, involved peering parties may have to deal with excessive
   settlement fees.

   More importantly, those flow-level or stream-level requirements may
   involve conflicting QoS indicators.  For example, cellular base
   station usually conducts low-layer retransmission and reordering to
   compensate the unreliable wireless communication media.  That has
   been demonstrated to cause the tradeoff between high throughput and
   low latency [L4S5G].  Therefore, an atomic PHB group ensuring both
   high throughput and low latency consumes considerable physical
   resources (e.g., frequency and time slot), impacting network
   utilization efficiency.  What is worse, such an atomic PHB group may
   exceed the QoS capabilities of some network bottlenecks, especially
   those highly fluctuating wireless access links.

   In addition, DSCP marking strictly following classification of
   service classes may be inadequate to guarantee consistently
   satisfying QoE.  An individual media stream may require a higher
   priority than RFC recommendations, e.g., to resist temporary network
   fluctuation or experience degradation.  For example, according to
   [RFC8837], the highest priority recommended for a non-interactive
   video stream is the AF3 class.  However, the AF4 class may benefit
   the stream when it needs to recover from rebuffering.  Different from
   relatively static per-stream priority considered in [RFC8837], the
   above priority escalation is dynamically triggered for a limited time
   period within the stream lifetime.

   To summarize, the fundamental issue of service-dependent DSCP
   semantics is that it ignores packet-level dynamics of traffic
   priorities and requirements.  Not all packets of the same high-
   priority service class demand better-than-best-effort treatment.
   Similarly, any service class may have individual packets with higher-
   than-recommended priority.  That motivates a service-agnostic
   semantics.

4.  Service-Agnostic DSCP Semantics

4.1.  Semantics Overview

   There are two fundamental requirements on a service-agnostic DSCP
   semantics:

Meng & Yin              Expires 14 September 2023               [Page 4]
Internet-Draft       Service Agnostic DSCP Semantics          March 2023

   (1)  Flexibility.  The DiffServ architecture already enables
        decoupling of service classes from particular applications
        [RFC2475].  On that basis, DSCPs and corresponding PHB groups
        SHOULD further be decoupled from classification of service
        classes.

   (2)  Scalability.  Inherited from the service-dependent DSCPs, per-
        flow state and hop-by-hop signaling SHOULD continue to be
        avoided at core network nodes [RFC2475].  The classification and
        conditioning at network boundaries SHOULD not be complicated,
        either.

   To ensure flexibility, application hosts SHOULD mark DSCPs on a per-
   packet basis, based on the following inputs:

   *  packet-level dynamic priority and requirement such as significance
      to real-time application QoE, possibly subject to differences in
      client preferences,

   *  service class to which each packet belongs to, used as a reference
      marking policy,

   *  service-level agreements (SLAs) with peering network domains,
      including traffic conditioning rules.

   Briefly, from application hosts' perspective, each DSCP, along with
   its associated PHB, represents a network QoS subject to SLAs.  The
   core objective of DSCP marking is to optimize application QoE, while
   conforming to possible conditioning rules on premium QoS in SLAs.

   Other than that, the service-agnostic DSCP semantics requires no
   changes to network nodes in a DiffServ domain, and thus maintain the
   scalability of DiffServ.  Application hosts still rely on the same
   set of PHBs.  The traffic conditioning and queueing mechanisms
   specific to each PHB group may be kept the same, as well.  Note that
   this memo does not obsolete the recommendations in other RFCs.
   Service-dependent DSCP marking may still be employed, e.g., when the
   required transport protocol interactions in Section 5 are not
   supported.

   The remainder of this section gives an example to illustrate how per-
   packet dynamic DSCP marking is conducted.

4.2.  Example Scenario

   A CDN server needs to send a live video stream to a client.  The
   following types of packets are transmitted over the same transport
   connection.

Meng & Yin              Expires 14 September 2023               [Page 5]
Internet-Draft       Service Agnostic DSCP Semantics          March 2023

   *  Packets belonging to an I-frame and sent for the first time, which
      contain a complete image and can be rendered independently.

   *  Packets belonging to a P-frame and sent for the first time, which
      contain changes from the previous I-frame or P-frame and should be
      rendered on basis of that previous frame.

   *  Retransmitted packets, which are passive retransmission happening
      after a lost packet/frame is detected.

   *  Redundancy packets, which are proactively injected duplicates of
      first-time packets to lower the possibility of rebuffering.  Such
      redundancy injection may be triggered for a short time after
      several consecutive packet losses.  The server may also transmit
      duplicates of selective packets when it estimates that there is a
      risk of video rebuffering based on packet reception feedback.

   Table 1 gives recommended DSCP marking for different packets.
   Details on AF and Expedited Forwarding (EF) can be found in [RFC2597]
   and [RFC3246], respectively.

     +=============================+=========+=======================+
     | Packet Type                 | Default | (Risk of) Rebuffering |
     +=============================+=========+=======================+
     | I-frame (first-time packet) | DF      | AF                    |
     +-----------------------------+---------+-----------------------+
     | P-frame (first-time packet) | DF      | DF                    |
     +-----------------------------+---------+-----------------------+
     | Retransmission              | EF      | EF                    |
     +-----------------------------+---------+-----------------------+
     | Redundancy                  | EF      | EF/AF                 |
     +-----------------------------+---------+-----------------------+

                 Table 1: Recommended DSCPs for Live Video

   By default, DF is recommended for both I-frames and P-frames.  The
   server mainly relies on injected redundancy and retransmission to
   resist packet losses and recover from rebuffering.  They are assigned
   higher priority than first time packets, and use EF for low-latency
   low-loss delivery.

   Meanwhile, the server keeps monitoring QoE based on packet reception
   feedback from the client.  When it estimates that there is the risk
   of rebuffering, or when rebuffering already happens, first-time
   packets of I-frames are escalated to AF from DF.  For illustration,
   Table 1 uses AF to represent network QoS that can provide assured
   average bandwidth, and does not limit which AF class to use.  In that
   situation, the server is expected to inject more redundancy.  Thus,

Meng & Yin              Expires 14 September 2023               [Page 6]
Internet-Draft       Service Agnostic DSCP Semantics          March 2023

   both EF and AF may be used for redundancy packets, in case excessive
   packets marked with EF are dropped.  The mechanisms used for QoE
   monitoring and the algorithms used for rebuffering estimation are out
   of scope for this memo.

   Compared with using an atomic DSCP for the whole video stream, the
   above service-agnostic DSCP marking policy reduces the amount of data
   requiring low latency QoS.  On the other hand, transport protocols
   should be able to process the resulting out-of-order packets
   (explained in Section 5).

5.  Interactions with Transport Protocols

   Per-packet DSCP marking under a service-agnostic semantics interacts
   with transport protocols on two functionalities: congestion control
   and packet scheduling.  First, packet reordering caused by different
   DSCPs and PHBs should not trigger loss recovery and congestion
   avoidance of the congestion controller.  Second, steering packets to
   different PHBs should not create head-of-line blocking intra and
   inter media streams.

   In fact, part of the reason why other RFCs associate DSCPs to service
   classes is to avoid negative interactions with transport protocols.
   For example, it is recommended that a single DSCP SHOULD be used
   within a reliable transport-layer flow, because reliable transport
   protocols are sensitive to packet reordering.  [RFC7657] recognizes
   that mixed DSCPs and QoS-based traffic classes necessitate multiple
   instances of congestion controllers, and claims the resulting
   complexity to extend transport protocols to be a major obstacle to
   that usage.

   Fortunately, recent maturity of multipath transport protocol stacks
   such as MPTCP [RFC8684] and multipath QUIC [I-D.ietf-quic-multipath]
   facilitates the above interactions.  A multipath connection
   simultaneously runs multiple subflows to improve network resource
   usage and user experience.  Those subflows go through disjoint paths
   originated from different host network interfaces (e.g., WiFi and
   cellular) or different ports (e.g., equal-cost multipath).  A subflow
   should be explicitly authenticated to be associated with a multipath
   connection (e.g., through path initiation and validation as explained
   in Section 4 of [I-D.ietf-quic-multipath]).

   In the context of service-agnostic DSCPs, packets marked with
   different DSCPs can be effectively seen as multiple logical subflows.
   Those subflows are logical because they may traverse the same
   physical network path.  They can be explicitly established through
   procedures defined in multipath transport protocols.  To avoid
   reliance on availability of multiple network interfaces and to enable

Meng & Yin              Expires 14 September 2023               [Page 7]
Internet-Draft       Service Agnostic DSCP Semantics          March 2023

   differentiated logical subflows under a single interface, application
   hosts SHOULD bind each DSCP usage and corresponding logical subflow
   to a dedicated port.  In addition, a logical subflow can be
   implicitly established by directly adding a DSCP to the same 5-tuple.
   Existing multipath transport protocols need to be extended to support
   implicit subflow establishment though, e.g., creating per-subflow
   soft states and bypassing the mandatory explicit procedures.

   Leveraging multipath transport, each logical subflow may have its own
   congestion control state and packet number space, and conduct
   reliable in-order delivery independently.  Out-of-order packets with
   different DSCPs do not influence a specific logical subflow.
   Depending on whether associated PHBs use isolated network resources,
   logical subflows of the same transport connection may adopt coupled
   congestion control schemes such as [RFC6356], or per-subflow
   decoupled congestion controllers.  Then, the problem of determining
   which DSCP to use for each packet is reduced to multipath packet
   scheduling.  Some recent works such as [XLINK] demonstrate the
   benefits of QoE-aware multipath scheduling, and can be combined with
   the usage of service-agnostic DSCPs.  The multipath scheduler is
   responsible for mitigating head-of-line blocking (e.g., by injecting
   duplicate packets).  Note that although application hosts proactively
   indicate the desired QoS treatment for a logical subflow by marking
   corresponding DSCP, that does not safely guarantee the actual subflow
   QoS.  Passive round-trip time (RTT) measurements are still necessary
   for the congestion controller and multipath scheduler.

6.  Security Considerations

   Tba.

7.  IANA Considerations

   Tbd.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
              <https://www.rfc-editor.org/info/rfc2475>.

Meng & Yin              Expires 14 September 2023               [Page 8]
Internet-Draft       Service Agnostic DSCP Semantics          March 2023

   [RFC4594]  Babiarz, J., Chan, K., and F. Baker, "Configuration
              Guidelines for DiffServ Service Classes", RFC 4594,
              DOI 10.17487/RFC4594, August 2006,
              <https://www.rfc-editor.org/info/rfc4594>.

   [RFC7657]  Black, D., Ed. and P. Jones, "Differentiated Services
              (Diffserv) and Real-Time Communication", RFC 7657,
              DOI 10.17487/RFC7657, November 2015,
              <https://www.rfc-editor.org/info/rfc7657>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8684]  Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
              Paasch, "TCP Extensions for Multipath Operation with
              Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March
              2020, <https://www.rfc-editor.org/info/rfc8684>.

   [RFC8837]  Jones, P., Dhesikan, S., Jennings, C., and D. Druta,
              "Differentiated Services Code Point (DSCP) Packet Markings
              for WebRTC QoS", RFC 8837, DOI 10.17487/RFC8837, January
              2021, <https://www.rfc-editor.org/info/rfc8837>.

   [I-D.ietf-quic-multipath]
              Liu, Y., Ma, Y., De Coninck, Q., Bonaventure, O., Huitema,
              C., and M. K├╝hlewind, "Multipath Extension for QUIC", Work
              in Progress, Internet-Draft, draft-ietf-quic-multipath-03,
              24 October 2022, <https://datatracker.ietf.org/doc/html/
              draft-ietf-quic-multipath-03>.

8.2.  Informative References

   [RFC2597]  Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
              "Assured Forwarding PHB Group", RFC 2597,
              DOI 10.17487/RFC2597, June 1999,
              <https://www.rfc-editor.org/info/rfc2597>.

   [RFC3246]  Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le
              Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., and D.
              Stiliadis, "An Expedited Forwarding PHB (Per-Hop
              Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
              <https://www.rfc-editor.org/info/rfc3246>.

   [RFC6356]  Raiciu, C., Handley, M., and D. Wischik, "Coupled
              Congestion Control for Multipath Transport Protocols",
              RFC 6356, DOI 10.17487/RFC6356, October 2011,
              <https://www.rfc-editor.org/info/rfc6356>.

Meng & Yin              Expires 14 September 2023               [Page 9]
Internet-Draft       Service Agnostic DSCP Semantics          March 2023

   [L4S5G]    Johansson, I., "5G and L4S Congestion Control
              Considerations", 2022,
              <https://datatracker.ietf.org/meeting/115/materials/
              slides-115-iccrg-5g-and-l4s-congestion-control-
              considerations>.

   [XLINK]    Zheng, Z., Ma, Y., Liu, Y., Yang, F., Li, Z., Zhang, Y.,
              Zhang, J., Shi, W., Chen, W., Li, D., An, Q., Hong, H.,
              and M. Zhang, "XLINK: QoE-Driven Multi-Path QUIC Transport
              in Large-Scale Video Services", SIGCOMM 2021,
              DOI 10.1145/3452296.3472893, 2021,
              <https://dl.acm.org/doi/10.1145/3452296.3472893>.

Authors' Addresses

   Tong Meng
   Huawei Technologies
   Shanghai
   China
   Email: mengtong1@huawei.com

   Yu Yin
   Huawei Technologies
   Shanghai
   China
   Email: rain.yinyu@huawei.com

Meng & Yin              Expires 14 September 2023              [Page 10]