summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8837.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8837.txt')
-rw-r--r--doc/rfc/rfc8837.txt493
1 files changed, 493 insertions, 0 deletions
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,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [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>.
+
+ [RFC7742] Roach, A.B., "WebRTC Video Processing and Codec
+ Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016,
+ <https://www.rfc-editor.org/info/rfc7742>.
+
+ [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>.
+
+ [RFC8622] Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for
+ Differentiated Services", RFC 8622, DOI 10.17487/RFC8622,
+ June 2019, <https://www.rfc-editor.org/info/rfc8622>.
+
+ [RFC8826] Rescorla, E., "Security Considerations for WebRTC",
+ RFC 8826, DOI 10.17487/RFC8826, January 2021,
+ <https://www.rfc-editor.org/info/rfc8826>.
+
+ [RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data
+ Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021,
+ <https://www.rfc-editor.org/info/rfc8831>.
+
+ [RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport
+ and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834,
+ January 2021, <https://www.rfc-editor.org/info/rfc8834>.
+
+ [RFC8835] Alvestrand, H., "Transports for WebRTC", RFC 8835,
+ DOI 10.17487/RFC8835, January 2021,
+ <https://www.rfc-editor.org/info/rfc8835>.
+
+9.2. Informative References
+
+ [G.1010] ITU-T, "End-user multimedia QoS categories", ITU-T
+ Recommendation G.1010, November 2001,
+ <https://www.itu.int/rec/T-REC-G.1010-200111-I/en>.
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc2474>.
+
+ [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>.
+
+ [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, <https://www.rfc-editor.org/info/rfc3550>.
+
+ [RFC8699] Islam, S., Welzl, M., and S. Gjessing, "Coupled Congestion
+ Control for RTP Media", RFC 8699, DOI 10.17487/RFC8699,
+ January 2020, <https://www.rfc-editor.org/info/rfc8699>.
+
+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