A Service-Agnostic Semantics for Differentiated Services Code Point (DSCP)

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. explains important terms. illustrates the limitations of DSCP semantics associated with service class. describes the service-agnostic semantics and provides an illustrating example on DSCP marking. explains transport protocol interactions. and cover security and IANA considerations, respectively.

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 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 .
Subflow: A flow of packets traversing an individual path in a multipath connection, as defined in .
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 .

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 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 ) 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 and recommend different DSCP markings for 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 . 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 , 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 , 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.

Service-Agnostic DSCP Semantics

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

Flexibility. The DiffServ architecture already enables decoupling of service classes from particular applications . On that basis, DSCPs and corresponding PHB groups SHOULD further be decoupled from classification of service classes.
Scalability. Inherited from the service-dependent DSCPs, per-flow state and hop-by-hop signaling SHOULD continue to be avoided at core network nodes . 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 are not supported. The remainder of this section gives an example to illustrate how per-packet dynamic DSCP marking is conducted.

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.

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.

gives recommended DSCP marking for different packets. Details on AF and Expedited Forwarding (EF) can be found in and , respectively. Recommended DSCPs for Live Video

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

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

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. 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 and multipath QUIC 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 ). 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 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 , 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 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.

Security Considerations Tba.

IANA Considerations Tbd.