From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8837.txt | 493 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 493 insertions(+) create mode 100644 doc/rfc/rfc8837.txt (limited to 'doc/rfc/rfc8837.txt') diff --git a/doc/rfc/rfc8837.txt b/doc/rfc/rfc8837.txt new file mode 100644 index 0000000..953ed6d --- /dev/null +++ b/doc/rfc/rfc8837.txt @@ -0,0 +1,493 @@ + + + + +Internet Engineering Task Force (IETF) P. Jones +Request for Comments: 8837 Cisco Systems +Category: Standards Track S. Dhesikan +ISSN: 2070-1721 Individual + C. Jennings + Cisco Systems + D. Druta + AT&T + January 2021 + + +Differentiated Services Code Point (DSCP) Packet Markings for WebRTC QoS + +Abstract + + Networks can provide different forwarding treatments for individual + packets based on Differentiated Services Code Point (DSCP) values on + a per-hop basis. This document provides the recommended DSCP values + for web browsers to use for various classes of Web Real-Time + Communication (WebRTC) traffic. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8837. + +Copyright Notice + + Copyright (c) 2021 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 Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 2. Terminology + 3. Relation to Other Specifications + 4. Inputs + 5. DSCP Mappings + 6. Security Considerations + 7. IANA Considerations + 8. Downward References + 9. References + 9.1. Normative References + 9.2. Informative References + Acknowledgements + Dedication + Authors' Addresses + +1. Introduction + + Differentiated Services Code Point (DSCP) [RFC2474] packet marking + can help provide QoS in some environments. This specification + provides default packet marking for browsers that support WebRTC + applications, but does not change any advice or requirements in other + RFCs. The contents of this specification are intended to be a simple + set of implementation recommendations based on previous RFCs. + + Networks in which these DSCP markings are beneficial (likely to + improve QoS for WebRTC traffic) include: + + 1. Private, wide-area networks. Network administrators have control + over remarking packets and treatment of packets. + + 2. Residential Networks. If the congested link is the broadband + uplink in a cable or DSL scenario, residential routers/NAT often + support preferential treatment based on DSCP. + + 3. Wireless Networks. If the congested link is a local wireless + network, marking may help. + + There are cases where these DSCP markings do not help but, aside from + possible priority inversion for "Less-than-Best-Effort traffic" (see + Section 5), they seldom make things worse if packets are marked + appropriately. + + DSCP values are, in principle, site specific with each site selecting + its own code points for controlling per-hop behavior to influence the + QoS for transport-layer flows. However, in the WebRTC use cases, the + browsers need to set them to something when there is no site-specific + information. This document describes a subset of DSCP code point + values drawn from existing RFCs and common usage for use with WebRTC + applications. These code points are intended to be the default + values used by a WebRTC application. While other values could be + used, using a non-default value may result in unexpected per-hop + behavior. It is RECOMMENDED that WebRTC applications use non-default + values only in private networks that are configured to use different + values. + + This specification defines inputs that are provided by the WebRTC + application hosted in the browser that aid the browser in determining + how to set the various packet markings. The specification also + defines the mapping from abstract QoS policies (flow type, priority + level) to those packet markings. + +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. + + The terms "browser" and "non-browser" are defined in [RFC7742] and + carry the same meaning in this document. + +3. Relation to Other Specifications + + This document is a complement to [RFC7657], which describes the + interaction between DSCP and real-time communications. That RFC + covers the implications of using various DSCP values, particularly + focusing on the Real-time Transport Protocol (RTP) [RFC3550] streams + that are multiplexed onto a single transport-layer flow. + + There are a number of guidelines specified in [RFC7657] that apply to + marking traffic sent by WebRTC applications, as it is common for + multiple RTP streams to be multiplexed on the same transport-layer + flow. Generally, the RTP streams would be marked with a value as + appropriate from Table 1. A WebRTC application might also multiplex + data channel [RFC8831] traffic over the same 5-tuple as RTP streams, + which would also be marked per that table. The guidance in [RFC7657] + says that all data channel traffic would be marked with a single + value that is typically different from the value(s) used for RTP + streams multiplexed with the data channel traffic over the same + 5-tuple, assuming RTP streams are marked with a value other than + Default Forwarding (DF). This is expanded upon further in the next + section. + + This specification does not change or override the advice in any + other RFCs about setting packet markings. Rather, it simply selects + a subset of DSCP values that is relevant in the WebRTC context. + + The DSCP value set by the endpoint is not trusted by the network. In + addition, the DSCP value may be remarked at any place in the network + for a variety of reasons to any other DSCP value, including the DF + value to provide basic best-effort service. Even so, there is a + benefit to marking traffic even if it only benefits the first few + hops. The implications are discussed in Section 3.2 of [RFC7657]. + Further, a mitigation for such action is through an authorization + mechanism. Such an authorization mechanism is outside the scope of + this document. + +4. Inputs + + This document recommends DSCP values for two classes of WebRTC flows: + + * media flows that are RTP streams [RFC8834] + + * data flows that are data channels [RFC8831] + + Each of the RTP streams and distinct data channels consist of all of + the packets associated with an independent media entity, so an RTP + stream or distinct data channel is not always equivalent to a + transport-layer flow defined by a 5-tuple (source address, + destination address, source port, destination port, and protocol). + There may be multiple RTP streams and data channels multiplexed over + the same 5-tuple, with each having a different level of importance to + the application and, therefore, potentially marked using different + DSCP values than another RTP stream or data channel within the same + transport-layer flow. (Note that there are restrictions with respect + to marking different data channels carried within the same Stream + Control Transmission Protocol (SCTP) association as outlined in + Section 5.) + + The following are the inputs provided by the WebRTC application to + the browser: + + * Flow Type: The application provides this input because it knows if + the flow is audio, interactive video ([RFC4594] [G.1010]) with or + without audio, or data. + + * Application Priority: Another input is the relative importance of + an RTP stream or data channel. Many applications have multiple + flows of the same flow type and some flows are often more + important than others. For example, in a video conference where + there are usually audio and video flows, the audio flow may be + more important than the video flow. JavaScript applications can + tell the browser whether a particular flow is of High, Medium, + Low, or Very Low importance to the application. + + [RFC8835] defines in more detail what an individual flow is within + the WebRTC context and priorities for media and data flows. + + Currently in WebRTC, media sent over RTP is assumed to be interactive + [RFC8835] and browser APIs do not exist to allow an application to + differentiate between interactive and non-interactive video. + +5. DSCP Mappings + + The DSCP values for each flow type of interest to WebRTC based on + application priority are shown in Table 1. These values are based on + the framework and recommended values in [RFC4594]. A web browser + SHOULD use these values to mark the appropriate media packets. More + information on Expedited Forwarding (EF) and Assured Forwarding (AF) + can be found in [RFC3246] and [RFC2597], respectively. DF is Default + Forwarding, which provides the basic best-effort service [RFC2474]. + + WebRTC's use of multiple DSCP values may result in packets with + certain DSCP values being blocked by a network. See Section 4.2 of + [RFC8835] for further discussion, including how WebRTC + implementations establish and maintain connectivity when such + blocking is encountered. + + +=======================+==========+=====+============+============+ + | Flow Type | Very Low | Low | Medium | High | + +=======================+==========+=====+============+============+ + | Audio | LE (1) | DF | EF (46) | EF (46) | + | | | (0) | | | + +-----------------------+----------+-----+------------+------------+ + +-----------------------+----------+-----+------------+------------+ + | Interactive Video | LE (1) | DF | AF42, AF43 | AF41, AF42 | + | with or without Audio | | (0) | (36, 38) | (34, 36) | + +-----------------------+----------+-----+------------+------------+ + +-----------------------+----------+-----+------------+------------+ + | Non-Interactive Video | LE (1) | DF | AF32, AF33 | AF31, AF32 | + | with or without Audio | | (0) | (28, 30) | (26, 28) | + +-----------------------+----------+-----+------------+------------+ + +-----------------------+----------+-----+------------+------------+ + | Data | LE (1) | DF | AF11 | AF21 | + | | | (0) | | | + +-----------------------+----------+-----+------------+------------+ + + Table 1: Recommended DSCP Values for WebRTC Applications + + The application priority, indicated by the columns "Very Low", "Low", + "Medium", and "High", signifies the relative importance of the flow + within the application. It is an input that the browser receives to + assist in selecting the DSCP value and adjusting the network + transport behavior. + + The above table assumes that packets marked with LE are treated as + lower effort (i.e., "less than best effort"), such as the LE behavior + described in [RFC8622]. However, the treatment of LE is + implementation dependent. If an implementation treats LE as other + than "less than best effort", then the actual priority (or, more + precisely, the per-hop behavior) of the packets may be changed from + what is intended. It is common for LE to be treated the same as DF, + so applications and browsers using LE cannot assume that LE will be + treated differently than DF [RFC7657]. During development of this + document, the CS1 DSCP was recommended for "very low" application + priority traffic; implementations that followed that recommendation + SHOULD be updated to use the LE DSCP instead of the CS1 DSCP. + + Implementers should also note that excess EF traffic is dropped. + This could mean that a packet marked as EF may not get through, + although the same packet marked with a different DSCP value would + have gotten through. This is not a flaw, but how excess EF traffic + is intended to be treated. + + The browser SHOULD first select the flow type of the flow. Within + the flow type, the relative importance of the flow SHOULD be used to + select the appropriate DSCP value. + + Currently, all WebRTC video is assumed to be interactive [RFC8835], + for which the interactive video DSCP values in Table 1 SHOULD be + used. Browsers MUST NOT use the AF3x DSCP values (for non- + interactive video in Table 1) for WebRTC applications. Non-browser + implementations of WebRTC MAY use the AF3x DSCP values for video that + is known not to be interactive, e.g., all video in a WebRTC video + playback application that is not implemented in a browser. + + The combination of flow type and application priority provides + specificity and helps in selecting the right DSCP value for the flow. + All packets within a flow SHOULD have the same application priority. + In some cases, the selected application priority cell may have + multiple DSCP values, such as AF41 and AF42. These offer different + drop precedences. The different drop precedence values provide + additional granularity in classifying packets within a flow. For + example, in a video conference, the video flow may have medium + application priority, thus either AF42 or AF43 may be selected. More + important video packets (e.g., a video picture or frame encoded + without any dependency on any prior pictures or frames) might be + marked with AF42 and less important packets (e.g., a video picture or + frame encoded based on the content of one or more prior pictures or + frames) might be marked with AF43 (e.g., receipt of the more + important packets enables a video renderer to continue after one or + more packets are lost). + + It is worth noting that the application priority is utilized by the + coupled congestion control mechanism for media flows per [RFC8699] + and the SCTP scheduler for data channel traffic per [RFC8831]. + + For reasons discussed in Section 6 of [RFC7657], if multiple flows + are multiplexed using a reliable transport (e.g., TCP), then all of + the packets for all flows multiplexed over that transport-layer flow + MUST be marked using the same DSCP value. Likewise, all WebRTC data + channel packets transmitted over an SCTP association MUST be marked + using the same DSCP value, regardless of how many data channels + (streams) exist or what kind of traffic is carried over the various + SCTP streams. In the event that the browser wishes to change the + DSCP value in use for an SCTP association, it MUST reset the SCTP + congestion controller after changing values. However, frequent + changes in the DSCP value used for an SCTP association are + discouraged, as this would defeat any attempts at effectively + managing congestion. It should also be noted that any change in DSCP + value that results in a reset of the congestion controller puts the + SCTP association back into slow start, which may have undesirable + effects on application performance. + + For the data channel traffic multiplexed over an SCTP association, it + is RECOMMENDED that the DSCP value selected be the one associated + with the highest priority requested for all data channels multiplexed + over the SCTP association. Likewise, when multiplexing multiple + flows over a TCP connection, the DSCP value selected SHOULD be the + one associated with the highest priority requested for all + multiplexed flows. + + If a packet enters a network that has no support for a flow-type- + application priority combination specified in Table 1, then the + network node at the edge will remark the DSCP value based on + policies. This could result in the flow not getting the network + treatment it expects based on the original DSCP value in the packet. + Subsequently, if the packet enters a network that supports a larger + number of these combinations, there may not be sufficient information + in the packet to restore the original markings. Mechanisms for + restoring such original DSCP is outside the scope of this document. + + In summary, DSCP marking provides neither guarantees nor promised + levels of service. However, DSCP marking is expected to provide a + statistical improvement in real-time service as a whole. The service + provided to a packet is dependent upon the network design along the + path, as well as the network conditions at every hop. + +6. Security Considerations + + Since the JavaScript application specifies the flow type and + application priority that determine the media flow DSCP values used + by the browser, the browser could consider application use of a large + number of higher priority flows to be suspicious. If the server + hosting the JavaScript application is compromised, many browsers + within the network might simultaneously transmit flows with the same + DSCP marking. The Diffserv architecture requires ingress traffic + conditioning for reasons that include protecting the network from + this sort of attack. + + Otherwise, this specification does not add any additional security + implications beyond those addressed in the following DSCP-related + specifications. For security implications on use of DSCP, please + refer to Section 7 of [RFC7657] and Section 6 of [RFC4594]. Please + also see [RFC8826] as an additional reference. + +7. IANA Considerations + + This document has no IANA actions. + +8. Downward References + + This specification contains downwards references to [RFC4594] and + [RFC7657]. However, the parts of the former RFCs used by this + specification are sufficiently stable for these downward references. + The guidance in the latter RFC is necessary to understand the + Diffserv technology used in this document and the motivation for the + recommended DSCP values and procedures. + +9. References + +9.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, + . + + [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration + Guidelines for DiffServ Service Classes", RFC 4594, + DOI 10.17487/RFC4594, August 2006, + . + + [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services + (Diffserv) and Real-Time Communication", RFC 7657, + DOI 10.17487/RFC7657, November 2015, + . + + [RFC7742] Roach, A.B., "WebRTC Video Processing and Codec + Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8622] Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for + Differentiated Services", RFC 8622, DOI 10.17487/RFC8622, + June 2019, . + + [RFC8826] Rescorla, E., "Security Considerations for WebRTC", + RFC 8826, DOI 10.17487/RFC8826, January 2021, + . + + [RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data + Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021, + . + + [RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport + and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834, + January 2021, . + + [RFC8835] Alvestrand, H., "Transports for WebRTC", RFC 8835, + DOI 10.17487/RFC8835, January 2021, + . + +9.2. Informative References + + [G.1010] ITU-T, "End-user multimedia QoS categories", ITU-T + Recommendation G.1010, November 2001, + . + + [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, + "Definition of the Differentiated Services Field (DS + Field) in the IPv4 and IPv6 Headers", RFC 2474, + DOI 10.17487/RFC2474, December 1998, + . + + [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, + "Assured Forwarding PHB Group", RFC 2597, + DOI 10.17487/RFC2597, June 1999, + . + + [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, + . + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, + July 2003, . + + [RFC8699] Islam, S., Welzl, M., and S. Gjessing, "Coupled Congestion + Control for RTP Media", RFC 8699, DOI 10.17487/RFC8699, + January 2020, . + +Acknowledgements + + Thanks to David Black, Magnus Westerlund, Paolo Severini, Jim + Hasselbrook, Joe Marcus, Erik Nordmark, Michael Tüxen, and Brian + Carpenter for their invaluable input. + +Dedication + + This document is dedicated to the memory of James Polk, a long-time + friend and colleague. James made important contributions to this + specification, including serving initially as one of the primary + authors. The IETF global community mourns his loss and he will be + missed dearly. + +Authors' Addresses + + Paul E. Jones + Cisco Systems + + Email: paulej@packetizer.com + + + Subha Dhesikan + Individual + + Email: sdhesikan@gmail.com + + + Cullen Jennings + Cisco Systems + + Email: fluffy@cisco.com + + + Dan Druta + AT&T + + Email: dd5826@att.com -- cgit v1.2.3