| Internet-Draft | Service Agnostic DSCP Semantics | March 2023 |
| Meng & Yin | Expires 14 September 2023 | [Page] |
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.¶
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 (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 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.¶
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.¶
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.¶
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 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.¶
There are two fundamental requirements on a service-agnostic DSCP semantics:¶
To ensure flexibility, application hosts SHOULD mark DSCPs on a per-packet basis, based on the following inputs:¶
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.¶
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.¶
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 |
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, 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).¶
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 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.¶
Tbd.¶