Internet DRAFT - draft-meng-tsvwg-service-agnostic-dscp
draft-meng-tsvwg-service-agnostic-dscp
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]
