doc: Add RFC documents

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