doc: Add RFC documents

1 files changed, 1459 insertions, 0 deletions

diff --git a/doc/rfc/rfc7657.txt b/doc/rfc/rfc7657.txt
new file mode 100644
index 0000000..95228ee
--- /dev/null
+++ b/doc/rfc/rfc7657.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                     D. Black, Ed.
+Request for Comments: 7657                                           EMC
+Category: Informational                                         P. Jones
+ISSN: 2070-1721                                                    Cisco
+                                                           November 2015
+
+
+     Differentiated Services (Diffserv) and Real-Time Communication
+
+Abstract
+
+   This memo describes the interaction between Differentiated Services
+   (Diffserv) network quality-of-service (QoS) functionality and real-
+   time network communication, including communication based on the
+   Real-time Transport Protocol (RTP).  Diffserv is based on network
+   nodes applying different forwarding treatments to packets whose IP
+   headers are marked with different Diffserv Codepoints (DSCPs).
+   WebRTC applications, as well as some conferencing applications, have
+   begun using the Session Description Protocol (SDP) bundle negotiation
+   mechanism to send multiple traffic streams with different QoS
+   requirements using the same network 5-tuple.  The results of using
+   multiple DSCPs to obtain different QoS treatments within a single
+   network 5-tuple have transport protocol interactions, particularly
+   with congestion control functionality (e.g., reordering).  In
+   addition, DSCP markings may be changed or removed between the traffic
+   source and destination.  This memo covers the implications of these
+   Diffserv aspects for real-time network communication, including
+   WebRTC.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   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).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7657.
+
+
+
+
+
+
+
+Black & Jones                 Informational                     [Page 1]
+
+RFC 7657              Diffserv and RT Communication        November 2015
+
+
+Copyright Notice
+
+   Copyright (c) 2015 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
+   (http://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  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Real-Time Communications  . . . . . . . . . . . . . . . . . .   3
+     2.1.  RTP Background  . . . . . . . . . . . . . . . . . . . . .   4
+     2.2.  RTP Multiplexing  . . . . . . . . . . . . . . . . . . . .   6
+   3.  Differentiated Services (Diffserv)  . . . . . . . . . . . . .   7
+     3.1.  Diffserv Per-Hop Behaviors (PHBs) . . . . . . . . . . . .  10
+     3.2.  Traffic Classifiers and DSCP Remarking  . . . . . . . . .  10
+   4.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  12
+   5.  Diffserv Interactions . . . . . . . . . . . . . . . . . . . .  13
+     5.1.  Diffserv, Reordering, and Transport Protocols . . . . . .  13
+     5.2.  Diffserv, Reordering, and Real-Time Communication . . . .  15
+     5.3.  Drop Precedence and Transport Protocols . . . . . . . . .  16
+     5.4.  Diffserv and RTCP . . . . . . . . . . . . . . . . . . . .  17
+   6.  Guidelines  . . . . . . . . . . . . . . . . . . . . . . . . .  18
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
+   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
+     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  20
+     8.2.  Informative References  . . . . . . . . . . . . . . . . .  22
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  26
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Black & Jones                 Informational                     [Page 2]
+
+RFC 7657              Diffserv and RT Communication        November 2015
+
+
+1.  Introduction
+
+   This memo describes the interactions between Differentiated Services
+   (Diffserv) network quality-of-service (QoS) functionality [RFC2475]
+   and real-time network communication, including communication based on
+   the Real-time Transport Protocol (RTP) [RFC3550].  Diffserv is based
+   on network nodes applying different forwarding treatments to packets
+   whose IP headers are marked with different Diffserv Codepoints
+   (DSCPs) [RFC2474].  In the past, distinct RTP streams have been sent
+   over different transport-level flows, sometimes multiplexed with the
+   RTP Control Protocol (RTCP).  WebRTC applications, as well as some
+   conferencing applications, are now using the Session Description
+   Protocol (SDP) [RFC4566] bundle negotiation mechanism [SDP-BUNDLE] to
+   send multiple traffic streams with different QoS requirements using
+   the same network 5-tuple.  The results of using multiple DSCPs to
+   obtain different QoS treatments within a single network 5-tuple have
+   transport protocol interactions, particularly with congestion control
+   functionality (e.g., reordering).  In addition, DSCP markings may be
+   changed or removed between the traffic source and destination.  This
+   memo covers the implications of these Diffserv aspects for real-time
+   network communication, including WebRTC traffic [WEBRTC-OVERVIEW].
+
+   The memo is organized as follows.  Background is provided in
+   Section 2 on real-time communications and Section 3 on Differentiated
+   Services.  Section 4 describes some examples of Diffserv usage with
+   real-time communications.  Section 5 explains how use of Diffserv
+   features interacts with both transport and real-time communications
+   protocols and Section 6 provides guidance on Diffserv feature usage
+   to control undesired interactions.  Security considerations are
+   discussed in Section 7.
+
+2.  Real-Time Communications
+
+   Real-time communications enables communication in real time over an
+   IP network using voice, video, text, content sharing, etc.  It is
+   possible to use more than one of these modes concurrently to provide
+   a rich communication experience.
+
+   A simple example of real-time communications is a voice call placed
+   over the Internet where an audio stream is transmitted in each
+   direction between two users.  A more complex example is an immersive
+   videoconferencing system that has multiple video screens, multiple
+   cameras, multiple microphones, and some means of sharing content.
+   For such complex systems, there may be multiple media and non-media
+   streams transmitted via a single IP address and port or via multiple
+   IP addresses and ports.
+
+
+
+
+
+Black & Jones                 Informational                     [Page 3]
+
+RFC 7657              Diffserv and RT Communication        November 2015
+
+
+2.1.  RTP Background
+
+   The most common protocol used for real-time media is RTP [RFC3550].
+   RTP defines a common encapsulation format and handling rules for
+   real-time data transmitted over the Internet.  Unfortunately, RTP
+   terminology usage has been inconsistent.  For example, RFC 7656
+   [RFC7656] on RTP terminology observes that:
+
+      RTP [RFC3550] uses media stream, audio stream, video stream, and a
+      stream of (RTP) packets interchangeably, which are all RTP
+      streams.
+
+   Terminology in this memo is based on that RTP terminology document
+   with the following terms being of particular importance (see that
+   terminology document for full definitions):
+
+   Source Stream:  A reference clock synchronized, time progressing,
+      digital media stream.
+
+   RTP Stream:  A stream of RTP packets containing media data, which may
+      be source data or redundant data.  The RTP stream is identified by
+      an RTP synchronization source (SSRC) belonging to a particular RTP
+      session.  An RTP stream may be a secured RTP stream when RTP-based
+      security is used.
+
+   In addition, this memo follows [RFC3550] in using the term "SSRC" to
+   designate both the identifier of an RTP stream and the entity that
+   sends that RTP stream.
+
+   Media encoding and packetization of a source stream results in a
+   source RTP stream plus zero or more redundancy RTP streams that
+   provide resilience against loss of packets from the source RTP stream
+   [RFC7656].  Redundancy information may also be carried in the same
+   RTP stream as the encoded source stream, e.g., see Section 7.2 of
+   [RFC5109].  With most applications, a single media type (e.g., audio)
+   is transmitted within a single RTP session.  However, it is possible
+   to transmit multiple, distinct source streams over the same RTP
+   session as one or more individual RTP streams.  This is referred to
+   as RTP multiplexing.  In addition, an RTP stream may contain multiple
+   source streams, e.g., components or programs in an MPEG Transport
+   Stream [H.221].
+
+   The number of source streams and RTP streams in an overall real-time
+   interaction can be surprisingly large.  In addition to a voice source
+   stream and a video source stream, there could be separate source
+   streams for each of the cameras or microphones on a videoconferencing
+   system.  As noted above, there might also be separate redundancy RTP
+   streams that provide protection to a source RTP stream, using
+
+
+
+Black & Jones                 Informational                     [Page 4]
+
+RFC 7657              Diffserv and RT Communication        November 2015
+
+
+   techniques such as forward error correction.  Another example is
+   simulcast transmission, where a video source stream can be
+   transmitted as high resolution and low resolution RTP streams at the
+   same time.  In this case, a media processing function might choose to
+   send one or both RTP streams onward to a receiver based on bandwidth
+   availability or who the active speaker is in a multipoint conference.
+   Lastly, a transmitter might send the same media content concurrently
+   as two RTP streams using different encodings (e.g., video encoded as
+   VP8 [RFC6386] in parallel with H.264 [H.264]) to allow a media
+   processing function to select a media encoding that best matches the
+   capabilities of the receiver.
+
+   For the WebRTC protocol suite [WEBRTC-TRANSPORTS], an individual
+   source stream is a MediaStreamTrack, and a MediaStream contains one
+   or more MediaStreamTracks [W3C.WD-mediacapture-streams-20130903].  A
+   MediaStreamTrack is transmitted as a source RTP stream plus zero or
+   more redundant RTP streams, so a MediaStream that consists of one
+   MediaStreamTrack is transmitted as a single source RTP stream plus
+   zero or more redundant RTP streams.  For more information on use of
+   RTP in WebRTC, see [RTP-USAGE].
+
+   RTP is usually carried over a datagram protocol, such as UDP
+   [RFC768], UDP-Lite [RFC3828], or the Datagram Congestion Control
+   Protocol (DCCP) [RFC4340]; UDP is most commonly used, but a non-
+   datagram protocol (e.g., TCP [RFC793]) may also be used.  Transport
+   protocols other than UDP or UDP-Lite may also be used to transmit
+   real-time data or near-real-time data.  For example, the Stream
+   Control Transmission Protocol (SCTP) [RFC4960] can be utilized to
+   carry application-sharing or whiteboarding information as part of an
+   overall interaction that includes real-time media.  These additional
+   transport protocols can be multiplexed with an RTP session via UDP
+   encapsulation, thereby using a single pair of UDP ports.
+
+   The WebRTC protocol suite encompasses a number of forms of
+   multiplexing:
+
+   1.  Individual source streams are carried in one or more individual
+       RTP streams.  These RTP streams can be multiplexed onto a single
+       transport-layer flow or sent as separate transport-layer flows.
+       This memo only considers the case where the RTP streams are to be
+       multiplexed onto a single transport-layer flow, forming a single
+       RTP session as described in [RFC3550];
+
+   2.  RTCP (see [RFC3550]) may be multiplexed onto the same transport-
+       layer flow as the RTP streams with which it is associated, as
+       described in [RFC5761], or it may be sent on a separate
+       transport-layer flow;
+
+
+
+
+Black & Jones                 Informational                     [Page 5]
+
+RFC 7657              Diffserv and RT Communication        November 2015
+
+
+   3.  An RTP session could be multiplexed with a single SCTP
+       association over Datagram Transport Layer Security (DTLS) and
+       with both Session Traversal Utilities for NAT (STUN) [RFC5389]
+       and TURN [RFC5766] traffic into a single transport-layer flow as
+       described in [RFC5764] with the updates in [SRTP-DTLS].  The STUN
+       [RFC5389] and Traversal Using Relays around NAT (TURN) [RFC5766]
+       protocols provide NAT/FW (Network Address Translator / Firewall)
+       traversal and port mapping.
+
+   The resulting transport-layer flow is identified by a network
+   5-tuple, i.e., a combination of two IP addresses (source and
+   destination), two ports (source and destination), and the transport
+   protocol used (e.g., UDP).  SDP bundle negotiation restrictions
+   [SDP-BUNDLE] limit WebRTC to using at most a single DTLS session per
+   network 5-tuple.  In contrast to WebRTC use of a single SCTP
+   association with DTLS, multiple SCTP associations can be directly
+   multiplexed over a single UDP 5-tuple as specified in [RFC6951].
+
+   The STUN and TURN protocols were originally designed to use UDP as a
+   transport; however, TURN has been extended to use TCP as a transport
+   for situations in which UDP does not work [RFC6062].  When TURN
+   selects use of TCP, the entire real-time communications session is
+   carried over a single TCP connection (i.e., 5-tuple).
+
+   For IPv6, addition of the flow label [RFC6437] to network 5-tuples
+   results in network 6-tuples (or 7-tuples for bidirectional flows),
+   but in practice, use of a flow label is unlikely to result in a
+   finer-grain traffic subset than the corresponding network 5-tuple
+   (e.g., the flow label is likely to represent the combination of two
+   ports with use of the UDP protocol).  For that reason, discussion in
+   this document focuses on UDP 5-tuples.
+
+2.2.  RTP Multiplexing
+
+   Section 2.1 explains how source streams can be multiplexed in a
+   single RTP session, which can in turn be multiplexed over UDP with
+   packets generated by other transport protocols.  This section
+   provides background on why this level of multiplexing is desirable.
+   The rationale in this section applies both to multiplexing of source
+   streams in a single RTP session and multiplexing of an RTP session
+   with traffic from other transport protocols via UDP encapsulation.
+
+   Multiplexing reduces the number of ports utilized for real-time and
+   related communication in an overall interaction.  While a single
+   endpoint might have plenty of ports available for communication, this
+   traffic often traverses points in the network that are constrained on
+   the number of available ports or whose performance degrades as the
+   number of ports in use increases.  A good example is a NAT/FW device
+
+
+
+Black & Jones                 Informational                     [Page 6]
+
+RFC 7657              Diffserv and RT Communication        November 2015
+
+
+   sitting at the network edge.  As the number of simultaneous protocol
+   sessions increases, so does the burden placed on these devices to
+   provide port mapping.
+
+   Another reason for multiplexing is to help reduce the time required
+   to establish bidirectional communication.  Since any two
+   communicating users might be situated behind different NAT/FW
+   devices, it is necessary to employ techniques like STUN and TURN
+   along with Interactive Connectivity Establishment (ICE) [RFC5245] to
+   get traffic to flow between the two devices [WEBRTC-TRANSPORTS].
+   Performing the tasks required by these protocols takes time,
+   especially when multiple protocol sessions are involved.  While tasks
+   for different sessions can be performed in parallel, it is
+   nonetheless necessary for applications to wait for all sessions to be
+   opened before communication between two users can begin.  Reducing
+   the number of STUN/ICE/TURN steps reduces the likelihood of loss of a
+   packet for one of these protocols; any such loss adds delay to
+   setting up a communication session.  Further, reducing the number of
+   STUN/ICE/TURN tasks places a lower burden on the STUN and TURN
+   servers.
+
+   Multiplexing may reduce the complexity and resulting load on an
+   endpoint.  A single instance of STUN/ICE/TURN is simpler to execute
+   and manage than multiple instances STUN/ICE/TURN operations happening
+   in parallel, as the latter require synchronization and create more
+   complex failure situations that have to be cleaned up by additional
+   code.
+
+3.  Differentiated Services (Diffserv)
+
+   The Diffserv architecture [RFC2475][RFC4594] is intended to enable
+   scalable service discrimination in the Internet without requiring
+   each node in the network to store per-flow state and participate in
+   per-flow signaling.  The services may be end to end or within a
+   network; they include both those that can satisfy quantitative
+   performance requirements (e.g., peak bandwidth) and those based on
+   relative performance (e.g., "class" differentiation).  Services can
+   be constructed by a combination of well-defined building blocks
+   deployed in network nodes that:
+
+   o  classify traffic and set bits in an IP header field at network
+      boundaries or hosts,
+
+   o  use those bits to determine how packets are forwarded by the nodes
+      inside the network, and
+
+   o  condition the marked packets at network boundaries in accordance
+      with the requirements or rules of each service.
+
+
+
+Black & Jones                 Informational                     [Page 7]
+
+RFC 7657              Diffserv and RT Communication        November 2015
+
+
+   Traffic conditioning may include changing the DSCP in a packet
+   (remarking it), delaying the packet (as a consequence of traffic
+   shaping), or dropping the packet (as a consequence of traffic
+   policing).
+
+   A network node that supports Diffserv includes a classifier that
+   selects packets based on the value of the DS field in IP headers (the
+   Diffserv codepoint or DSCP), along with buffer management and packet
+   scheduling mechanisms capable of delivering the specific packet
+   forwarding treatment indicated by the DS field value.  Setting of the
+   DS field and fine-grain conditioning of marked packets need only be
+   performed at network boundaries; internal network nodes operate on
+   traffic aggregates that share a DS field value, or in some cases, a
+   small set of related values.
+
+   The Diffserv architecture [RFC2475] maintains distinctions among:
+
+   o  the QoS service provided to a traffic aggregate,
+
+   o  the conditioning functions and per-hop behaviors (PHBs) used to
+      realize services,
+
+   o  the DSCP in the IP header used to mark packets to select a per-hop
+      behavior, and
+
+   o  the particular implementation mechanisms that realize a per-hop
+      behavior.
+
+   This memo focuses on PHBs and the usage of DSCPs to obtain those
+   behaviors.  In a network node's forwarding path, the DSCP is used to
+   map a packet to a particular forwarding treatment, or to a per-hop
+   behavior (PHB) that specifies the forwarding treatment.
+
+   The specification of a PHB describes the externally observable
+   forwarding behavior of a network node for network traffic marked with
+   a DSCP that selects that PHB.  In this context, "forwarding behavior"
+   is a general concept - for example, if only one DSCP is used for all
+   traffic on a link, the observable forwarding behavior (e.g., loss,
+   delay, jitter) will often depend only on the loading of the link.  To
+   obtain useful behavioral differentiation, multiple traffic subsets
+   are marked with different DSCPs for different PHBs for which node
+   resources such as buffer space and bandwidth are allocated.  PHBs
+   provide the framework for a Diffserv network node to allocate
+   resources to traffic subsets, with network-scope Differentiated
+   Services constructed on top of this basic hop-by-hop resource
+   allocation mechanism.
+
+
+
+
+
+Black & Jones                 Informational                     [Page 8]
+
+RFC 7657              Diffserv and RT Communication        November 2015
+
+
+   The codepoints (DSCPs) may be chosen from a small set of fixed values
+   (the class selector codepoints), from a set of recommended values
+   defined in PHB specifications, or from values that have purely local
+   meanings to a specific network that supports Diffserv; in general,
+   packets may be forwarded across multiple such networks between source
+   and destination.
+
+   The mandatory DSCPs are the class selector codepoints as specified in
+   [RFC2474].  The class selector codepoints (CS0-CS7) extend the
+   deprecated concept of IP Precedence in the IPv4 header; three bits
+   are added, so that the class selector DSCPs are of the form 'xxx000'.
+   The all-zero DSCP ('000000' or CS0) is always assigned to a Default
+   PHB that provides best-effort forwarding behavior, and the remaining
+   class selector codepoints are intended to provide relatively better
+   per-hop-forwarding behavior in increasing numerical order, but:
+
+   o  A network endpoint cannot rely upon different class selector
+      codepoints providing Differentiated Services via assignment to
+      different PHBs, as adjacent class selector codepoints may use the
+      same pool of resources on each network node in some networks.
+      This generalizes to ranges of class selector codepoints, but with
+      limits -- for example, CS6 and CS7 are often used for network
+      control (e.g., routing) traffic [RFC4594] and hence are likely to
+      provide better forwarding behavior under network load to
+      prioritize network recovery from disruptions.  There is no
+      effective way for a network endpoint to determine which PHBs are
+      selected by the class selector codepoints on a specific network,
+      let alone end to end.
+
+   o  CS1 ('001000') was subsequently designated as the recommended
+      codepoint for the Lower Effort (LE) PHB [RFC3662].  An LE service
+      forwards traffic with "lower" priority than best effort and can be
+      "starved" by best-effort and other "higher" priority traffic.  Not
+      all networks offer an LE service, hence traffic marked with the
+      CS1 DSCP may not receive lower effort forwarding; such traffic may
+      be forwarded with a different PHB (e.g., the Default PHB),
+      remarked to another DSCP (e.g., CS0) and forwarded accordingly, or
+      dropped.  A network endpoint cannot rely upon the presence of an
+      LE service that is selected by the CS1 DSCP on a specific network,
+      let alone end to end.  Packets marked with the CS1 DSCP may be
+      forwarded with best-effort service or another "higher" priority
+      service; see [RFC2474].  See [RFC3662] for further discussion of
+      the LE PHB and service.
+
+
+
+
+
+
+
+
+Black & Jones                 Informational                     [Page 9]
+
+RFC 7657              Diffserv and RT Communication        November 2015
+
+
+3.1.  Diffserv Per-Hop Behaviors (PHBs)
+
+   Although Differentiated Services is a general architecture that may
+   be used to implement a variety of services, three fundamental
+   forwarding behaviors (PHBs) have been defined and characterized for
+   general use.  These are:
+
+   1.  Default Forwarding (DF) for elastic traffic [RFC2474].  The
+       Default PHB is always selected by the all-zero DSCP and provides
+       best-effort forwarding.
+
+   2.  Assured Forwarding (AF) [RFC2597] to provide Differentiated
+       Service to elastic traffic.  Each instance of the AF behavior
+       consists of three PHBs that differ only in drop precedence, e.g.,
+       AF11, AF12, and AF13; such a set of three AF PHBs is referred to
+       as an AF class, e.g., AF1x.  There are four defined AF classes,
+       AF1x through AF4x, with higher numbered classes intended to
+       receive better forwarding treatment than lower numbered classes.
+       Use of multiple PHBs from a single AF class (e.g., AF1x) does not
+       enable network traffic reordering within a single network
+       5-tuple, although such reordering may occur for other transient
+       reasons (e.g., routing changes or ECMP rebalancing).
+
+   3.  Expedited Forwarding (EF) [RFC3246] intended for inelastic
+       traffic.  Beyond the basic EF PHB, the VOICE-ADMIT PHB [RFC5865]
+       is an admission-controlled variant of the EF PHB.  Both of these
+       PHBs are based on preconfigured limited forwarding capacity;
+       traffic in excess of that capacity is expected to be dropped.
+
+3.2.  Traffic Classifiers and DSCP Remarking
+
+   DSCP markings are not end to end in general.  Each network can make
+   its own decisions about what PHBs to use and which DSCP maps to each
+   PHB.  While every PHB specification includes a recommended DSCP, and
+   RFC 4594 [RFC4594] recommends their end-to-end usage, there is no
+   requirement that every network support any PHBs (aside from the
+   Default PHB for best-effort forwarding) or use any specific DSCPs,
+   with the exception of the support requirements for the class selector
+   codepoints (see RFC 2474 [RFC2474]).  When Diffserv is used, the edge
+   or boundary nodes of a network are responsible for ensuring that all
+   traffic entering that network conforms to that network's policies for
+   DSCP and PHB usage, and such nodes may change DSCP markings on
+   traffic to achieve that result.  As a result, DSCP remarking is
+   possible at any network boundary, including the first network node
+   that traffic sent by a host encounters.  Remarking is also possible
+   within a network, e.g., for traffic shaping.
+
+
+
+
+
+Black & Jones                 Informational                    [Page 10]
+
+RFC 7657              Diffserv and RT Communication        November 2015
+
+
+   DSCP remarking is part of traffic conditioning; the traffic
+   conditioning functionality applied to packets at a network node is
+   determined by a traffic classifier [RFC2475].  Edge nodes of a
+   Diffserv network classify traffic based on selected packet header
+   fields; typical implementations do not look beyond the traffic's
+   network 5-tuple in the IP and transport protocol headers (e.g., for
+   SCTP or RTP encapsulated in UDP, header-based classification is
+   unlikely to look beyond the outer UDP header).  As a result, when
+   multiple DSCPs are used for traffic that shares a network 5-tuple,
+   remarking at a network boundary may result in all of the traffic
+   being forwarded with a single DSCP, thereby removing any
+   differentiation within the network 5-tuple downstream of the
+   remarking location.  Network nodes within a Diffserv network
+   generally classify traffic based solely on DSCPs, but may perform
+   finer-grain traffic conditioning similar to that performed by edge
+   nodes.
+
+   So, for two arbitrary network endpoints, there can be no assurance
+   that the DSCP set at the source endpoint will be preserved and
+   presented at the destination endpoint.  Rather, it is quite likely
+   that the DSCP will be set to zero (e.g., at the boundary of a network
+   operator that distrusts or does not use the DSCP field) or to a value
+   deemed suitable by an ingress classifier for whatever network 5-tuple
+   it carries.
+
+   In addition, remarking may remove application-level distinctions in
+   forwarding behavior - e.g., if multiple PHBs within an AF class are
+   used to distinguish different types of frames within a video RTP
+   stream, token-bucket-based remarkers operating in color-blind mode
+   (see [RFC2697] and [RFC2698] for examples) may remark solely based on
+   flow rate and burst behavior, removing the drop precedence
+   distinctions specified by the source.
+
+   Backbone and other carrier networks may employ a small number of
+   DSCPs (e.g., less than half a dozen) to manage a small number of
+   traffic aggregates; hosts that use a larger number of DSCPs can
+   expect to find that much of their intended differentiation is removed
+   by such networks.  Better results may be achieved when DSCPs are used
+   to spread traffic among a smaller number of Diffserv-based traffic
+   subsets or aggregates; see [DIFFSERV-INTERCON] for one proposal.
+   This is of particular importance for MPLS-based networks due to the
+   limited size of the Traffic Class (TC) field in an MPLS label
+   [RFC5462] that is used to carry Diffserv information and the use of
+   that TC field for other purposes, e.g., Explicit Congestion
+   Notification (ECN) [RFC5129].  For further discussion on use of
+   Diffserv with MPLS, see [RFC3270] and [RFC5127].
+
+
+
+
+
+Black & Jones                 Informational                    [Page 11]
+
+RFC 7657              Diffserv and RT Communication        November 2015
+
+
+4.  Examples
+
+   For real-time communications, one might want to mark the audio
+   packets using EF and the video packets as AF41.  However, a video
+   conference receiving the audio packets significantly ahead of the
+   video is not useful because lip sync is necessary between audio and
+   video.  It may still be desirable to send audio with a PHB that
+   provides better service, because more reliable arrival of audio helps
+   assure smooth audio rendering, which is often more important than
+   fully faithful video rendering.  There are also limits, as some
+   devices have difficulties in synchronizing voice and video when
+   packets that need to be rendered together arrive at significantly
+   different times.  It makes more sense to use different PHBs when the
+   audio and video source streams do not share a strict timing
+   relationship.  For example, video content may be shared within a
+   video conference via playback, perhaps of an unedited video clip that
+   is intended to become part of a television advertisement.  Such
+   content sharing video does not need precise synchronization with
+   video conference audio, and could use a different PHB, as content
+   sharing video is more tolerant to jitter, loss, and delay.
+
+   Within a layered video RTP stream, ordering of frame communication is
+   preferred, but importance of frame types varies, making use of PHBs
+   with different drop precedences appropriate.  For example, I-frames
+   that contain an entire image are usually more important than P-frames
+   that contain only changes from the previous image because loss of a
+   P-frame (or part thereof) can be recovered (at the latest) via the
+   next I-frame, whereas loss of an I-frame (or part thereof) may cause
+   rendering problems for all of the P-frames that depend on the missing
+   I-frame.  For this reason, it is appropriate to mark I-frame packets
+   with a PHB that has lower drop precedence than the PHB used for
+   P-frames, as long as the PHBs preserve ordering among frames (e.g.,
+   are in a single AF class) - AF41 for I-frames and AF43 for P-frames
+   is one possibility.  Additional spatial and temporal layers beyond
+   the base video layer could also be marked with higher drop precedence
+   than the base video layer, as their loss reduces video quality, but
+   does not disrupt video rendering.
+
+   Additional RTP streams in a real-time communication interaction could
+   be marked with CS0 and carried as best-effort traffic.  One example
+   is real-time text transmitted as specified in RFC 4103 [RFC4103].
+   Best-effort forwarding suffices because such real-time text has loose
+   timing requirements; RFC 4103 recommends sending text in chunks every
+   300 ms.  Such text is technically real-time, but does not need a PHB
+   promising better service than best effort, in contrast to audio or
+   video.
+
+
+
+
+
+Black & Jones                 Informational                    [Page 12]
+
+RFC 7657              Diffserv and RT Communication        November 2015
+
+
+   A WebRTC application may use one or more RTP streams, as discussed
+   above.  In addition, it may use an SCTP-based data channel
+   [DATA-CHAN] whose QoS treatment depends on the nature of the
+   application.  For example, best-effort treatment of data channels is
+   likely to suffice for messaging, shared white board, and guided
+   browsing applications, whereas latency-sensitive games might desire
+   better QoS for their data channels.
+
+5.  Diffserv Interactions
+
+5.1.  Diffserv, Reordering, and Transport Protocols
+
+   Transport protocols provide data communication behaviors beyond those
+   possible at the IP layer.  An important example is that TCP [RFC793]
+   provides reliable in-order delivery of data with congestion control.
+   SCTP [RFC4960] provides additional properties such as preservation of
+   message boundaries, and the ability to avoid head-of-line blocking
+   that may occur with TCP.
+
+   In contrast, UDP [RFC768] is a basic unreliable datagram protocol
+   that provides port-based multiplexing and demultiplexing on top of
+   IP.  Two other unreliable datagram protocols are UDP-Lite [RFC3828],
+   a variant of UDP that may deliver partially corrupt payloads when
+   errors occur, and DCCP [RFC4340], which provides a range of
+   congestion control modes for its unreliable datagram service.
+
+   Transport protocols that provide reliable delivery (e.g., TCP, SCTP)
+   are sensitive to network reordering of traffic.  When a protocol that
+   provides reliable delivery receives a packet other than the next
+   expected packet, the protocol usually assumes that the expected
+   packet has been lost and updates the peer, which often causes a
+   retransmission.  In addition, congestion control functionality in
+   transport protocols (including DCCP) usually infers congestion when
+   packets are lost.  This creates additional sensitivity to significant
+   network packet reordering, as such reordering may be (mis)interpreted
+   as loss of the out-of-order packets, causing a congestion control
+   response.
+
+   This sensitivity to reordering remains even when ECN [RFC3168] is in
+   use, as ECN receivers are required to treat missing packets as
+   potential indications of congestion, because:
+
+   o  Severe congestion may cause ECN-capable network nodes to drop
+      packets, and
+
+   o  ECN traffic may be forwarded by network nodes that do not support
+      ECN and hence drop packets to indicate congestion.
+
+
+
+
+Black & Jones                 Informational                    [Page 13]
+
+RFC 7657              Diffserv and RT Communication        November 2015
+
+
+   Congestion control is an important aspect of the Internet
+   architecture; see [RFC2914] for further discussion.
+
+   In general, marking packets with different DSCPs results in different
+   PHBs being applied at nodes in the network, making reordering very
+   likely due to use of different pools of forwarding resources for each
+   PHB.  This should not be done within a single network 5-tuple for
+   current transport protocols, with the important exceptions of UDP and
+   UDP-Lite.
+
+   When PHBs that enable reordering are mixed within a single network
+   5-tuple, the effect is to mix QoS-based traffic classes within the
+   scope of a single transport protocol connection or association.  As
+   these QoS-based traffic classes receive different network QoS
+   treatments, they use different pools of network resources and hence
+   may exhibit different levels of congestion.  The result for
+   congestion-controlled protocols is that a separate instance of
+   congestion control functionality is needed per QoS-based traffic
+   class.  Current transport protocols support only a single instance of
+   congestion control functionality for an entire connection or
+   association; extending that support to multiple instances would add
+   significant protocol complexity.  Traffic in different QoS-based
+   classes may use different paths through the network; this complicates
+   path integrity checking in connection- or association-based
+   protocols, as those paths may fail independently.
+
+   The primary example where usage of multiple PHBs does not enable
+   reordering within a single network 5-tuple is use of PHBs from a
+   single AF class (e.g., AF1x).  Traffic reordering within the scope of
+   a network 5-tuple that uses a single PHB or AF class may occur for
+   other transient reasons (e.g., routing changes or ECMP rebalancing).
+
+   Reordering also affects other forms of congestion control, such as
+   techniques for RTP congestion control that were under development
+   when this memo was published; see [RMCAT-CC] for requirements.  These
+   techniques prefer use of a common (coupled) congestion controller for
+   RTP streams between the same endpoints to reduce packet loss and
+   delay by reducing competition for resources at any shared bottleneck.
+
+   Shared bottlenecks can be detected via techniques such as correlation
+   of one-way delay measurements across RTP streams.  An alternate
+   approach is to assume that the set of packets on a single network
+   5-tuple marked with DSCPs that do not enable reordering will utilize
+   a common network path and common forwarding resources at each network
+   node.  Under that assumption, any bottleneck encountered by such
+   packets is shared among all of them, making it safe to use a common
+   (coupled) congestion controller (see [COUPLED-CC]).  This is not a
+   safe assumption when the packets involved are marked with DSCP values
+
+
+
+Black & Jones                 Informational                    [Page 14]
+
+RFC 7657              Diffserv and RT Communication        November 2015
+
+
+   that enable reordering because a bottleneck may not be shared among
+   all such packets (e.g., when the DSCP values result in use of
+   different queues at a network node, but only one queue is a
+   bottleneck).
+
+   UDP and UDP-Lite are not sensitive to reordering in the network,
+   because they do not provide reliable delivery or congestion control.
+   On the other hand, when used to encapsulate other protocols (e.g., as
+   UDP is used by WebRTC; see Section 2.1), the reordering
+   considerations for the encapsulated protocols apply.  For the
+   specific usage of UDP by WebRTC, every encapsulated protocol (i.e.,
+   RTP, SCTP, and TCP) is sensitive to reordering as further discussed
+   in this memo.  In addition, [RFC5405] provides general guidelines for
+   use of UDP (and UDP-Lite); the congestion control guidelines in that
+   document apply to protocols encapsulated in UDP (or UDP-Lite).
+
+5.2.  Diffserv, Reordering, and Real-Time Communication
+
+   Real-time communications are also sensitive to network reordering of
+   packets.  Such reordering may lead to unneeded retransmission and
+   spurious retransmission control signals (such as NACK) in reliable
+   delivery protocols (see Section 5.1).  The degree of sensitivity
+   depends on protocol or stream timers, in contrast to reliable
+   delivery protocols that usually react to all reordering.
+
+   Receiver jitter buffers have important roles in the effect of
+   reordering on real-time communications:
+
+   o  Minor packet reordering that is contained within a jitter buffer
+      usually has no effect on rendering of the received RTP stream
+      because packets that arrive out of order are retrieved in order
+      from the jitter buffer for rendering.
+
+   o  Packet reordering that exceeds the capacity of a jitter buffer can
+      cause user-perceptible quality problems (e.g., glitches, noise)
+      for delay-sensitive communication, such as interactive
+      conversations for which small jitter buffers are necessary to
+      preserve human perceptions of real-time interaction.  Interactive
+      real-time communication implementations often discard data that is
+      sufficiently late so that it cannot be rendered in source stream
+      order, making retransmission counterproductive.  For this reason,
+      implementations of interactive real-time communication often do
+      not use retransmission.
+
+   o  In contrast, replay of recorded media can tolerate significantly
+      longer delays than interactive conversations, so replay is likely
+      to use larger jitter buffers than interactive conversations.
+      These larger jitter buffers increase the tolerance of replay to
+
+
+
+Black & Jones                 Informational                    [Page 15]
+
+RFC 7657              Diffserv and RT Communication        November 2015
+
+
+      reordering by comparison to interactive conversations.  The size
+      of the jitter buffer imposes an upper bound on replay tolerance to
+      reordering but does enable retransmission to be used when the
+      jitter buffer is significantly larger than the amount of data that
+      can be expected to arrive during the round-trip latency for
+      retransmission.
+
+   Network packet reordering has no effective upper bound and can exceed
+   the size of any reasonable jitter buffer.  In practice, the size of
+   jitter buffers for replay is limited by external factors such as the
+   amount of time that a human is willing to wait for replay to start.
+
+5.3.  Drop Precedence and Transport Protocols
+
+   Packets within the same network 5-tuple that use PHBs within a single
+   AF class can be expected to draw upon the same forwarding resources
+   on network nodes (e.g., use the same router queue), and hence use of
+   multiple drop precedences within an AF class is not expected to cause
+   latency variation.  When PHBs within a single AF class are mixed
+   within a flow, the resulting overall likelihood that packets will be
+   dropped from that flow is a mix of the drop likelihoods of the PHBs
+   involved.
+
+   There are situations in which drop precedences should not be mixed.
+   A simple example is that there is little value in mixing drop
+   precedences within a TCP connection, because TCP's ordered delivery
+   behavior results in any drop requiring the receiver to wait for the
+   dropped packet to be retransmitted.  Any resulting delay depends on
+   the RTT and not the packet that was dropped.  Hence a single DSCP
+   should be used for all packets in a TCP connection.
+
+   As a consequence, when TCP is selected for NAT/FW traversal (e.g., by
+   TURN), a single DSCP should be used for all traffic on that TCP
+   connection.  An additional reason for this recommendation is that
+   packetization for STUN/ICE/TURN occurs before passing the resulting
+   packets to TCP; TCP resegmentation may result in a different
+   packetization on the wire, breaking any association between DSCPs and
+   specific data to which they are intended to apply.
+
+   SCTP [RFC4960] differs from TCP in a number of ways, including the
+   ability to deliver messages in an order that differs from the order
+   in which they were sent and support for unreliable streams.  However,
+   SCTP performs congestion control and retransmission across the entire
+   association, and not on a per-stream basis.  Although there may be
+   advantages to using multiple drop precedence across SCTP streams or
+   within an SCTP stream that does not use reliable ordered delivery,
+   there is no practical operational experience in doing so (e.g., the
+   SCTP sockets API [RFC6458] does not support use of more than one DSCP
+
+
+
+Black & Jones                 Informational                    [Page 16]
+
+RFC 7657              Diffserv and RT Communication        November 2015
+
+
+   for an SCTP association).  As a consequence, the impacts on SCTP
+   protocol and implementation behavior are unknown and difficult to
+   predict.  Hence a single DSCP should be used for all packets in an
+   SCTP association, independent of the number or nature of streams in
+   that association.  Similar reasoning applies to a DCCP connection; a
+   single DSCP should be used because the scope of congestion control is
+   the connection and there is no operational experience with using more
+   than one DSCP.  This recommendation may be revised in the future if
+   experiments, analysis, and operational experience provide compelling
+   reasons to change it.
+
+   Guidance on transport protocol design and implementation to provide
+   support for use of multiple PHBs and DSCPs in a transport protocol
+   connection (e.g., DCCP) or transport protocol association (e.g.,
+   SCTP) is out of scope for this memo.
+
+5.4.  Diffserv and RTCP
+
+   RTCP [RFC3550] is used with RTP to monitor quality of service and
+   convey information about RTP session participants.  A sender of RTCP
+   packets that also sends RTP packets (i.e., originates an RTP stream)
+   should use the same DSCP marking for both types of packets.  If an
+   RTCP sender doesn't send any RTP packets, it should mark its RTCP
+   packets with the DSCP that it would use if it did send RTP packets
+   with media similar to the RTP traffic that it receives.  If the RTCP
+   sender uses or would use multiple DSCPs that differ only in drop
+   precedence for RTP, then it should use the DSCP with the least
+   likelihood of drop for RTCP to increase the likelihood of RTCP packet
+   delivery.
+
+   If the SDP bundle extension [SDP-BUNDLE] is used to negotiate sending
+   multiple types of media in a single RTP session, then receivers will
+   send separate RTCP reports for each type of media, using a separate
+   SSRC for each media type; each RTCP report should be marked with the
+   DSCP corresponding to the type of media handled by the reporting
+   SSRC.
+
+   This guidance may result in different DSCP markings for RTP streams
+   and RTCP receiver reports about those RTP streams.  The resulting
+   variation in network QoS treatment by traffic direction is necessary
+   to obtain representative round-trip time (RTT) estimates that
+   correspond to the media path RTT, which may differ from the transport
+   protocol RTT.  RTCP receiver reports may be relatively infrequent,
+   and hence the resulting RTT estimates are of limited utility for
+   transport protocol congestion control (although those RTT estimates
+   have other important uses; see [RFC3550]).  For this reason, it is
+   important that RTCP receiver reports sent by an SSRC receive the same
+   network QoS treatment as the RTP stream being sent by that SSRC.
+
+
+
+Black & Jones                 Informational                    [Page 17]
+
+RFC 7657              Diffserv and RT Communication        November 2015
+
+
+6.  Guidelines
+
+   The only use of multiple standardized PHBs and DSCPs that does not
+   enable network reordering among packets marked with different DSCPs
+   is use of PHBs within a single AF class.  All other uses of multiple
+   PHBs and/or the class selector DSCPs enable network reordering of
+   packets that are marked with different DSCPs.  Based on this and the
+   foregoing discussion, the guidelines in this section apply to use of
+   Diffserv with real-time communications.
+
+   Applications and other traffic sources (including RTP SSRCs):
+
+   o  Should limit use of DSCPs within a single RTP stream to those
+      whose corresponding PHBs do not enable packet reordering.  If this
+      is not done, significant network reordering may overwhelm
+      implementation assumptions about reordering limits, e.g., jitter
+      buffer size, causing poor user experiences (see Section 5.2).
+      This guideline applies to all of the RTP streams that are within
+      the scope of a common (coupled) congestion controller when that
+      controller does not use per-RTP-stream measurements for bottleneck
+      detection.
+
+   o  Should use a single DSCP for RTCP packets, which should be a DSCP
+      used for RTP packets that are or would be sent by that SSRC (see
+      Section 5.4).
+
+   o  Should use a single DSCP for all packets within a reliable
+      transport protocol session (e.g., TCP connection, SCTP
+      association) or DCCP connection (see Sections 5.1 and 5.3).  For
+      SCTP, this requirement applies across the entire SCTP association,
+      and not just to individual streams within an association.  When
+      TURN selects TCP for NAT/FW traversal, this guideline applies to
+      all traffic multiplexed onto that TCP connection, in contrast to
+      use of UDP for NAT/FW traversal.
+
+   o  May use different DSCPs whose corresponding PHBs enable reordering
+      within a single UDP or UDP-Lite 5-tuple, subject to the above
+      constraints.  The service differentiation provided by such usage
+      is unreliable, as it may be removed or changed by DSCP remarking
+      at network boundaries as described in Section 3.2 above.
+
+   o  Cannot rely on end-to-end preservation of DSCPs as network node
+      remarking can change DSCPs and remove drop precedence distinctions
+      (see Section 3.2).  For example, if a source uses drop precedence
+      distinctions within an AF class to identify different types of
+      video frames, using those DSCP values at the receiver to identify
+      frame type is inherently unreliable.
+
+
+
+
+Black & Jones                 Informational                    [Page 18]
+
+RFC 7657              Diffserv and RT Communication        November 2015
+
+
+   o  Should limit use of the CS1 codepoint to traffic for which best
+      effort forwarding is acceptable, as network support for use of CS1
+      to select a "less than best-effort" PHB is inconsistent.  Further,
+      some networks may treat CS1 as providing "better than best-effort"
+      forwarding behavior.
+
+   There is no guidance in this memo on how network operators should
+   differentiate traffic.  Networks may support all of the PHBs
+   discussed herein, classify EF and AFxx traffic identically, or even
+   remark all traffic to best effort at some ingress points.
+   Nonetheless, it is useful for applications and other traffic sources
+   to provide finer granularity DSCP marking on packets for the benefit
+   of networks that offer QoS service differentiation.  A specific
+   example is that traffic originating from a browser may benefit from
+   QoS service differentiation in within-building and residential access
+   networks, even if the DSCP marking is subsequently removed or
+   simplified.  This is because such networks and the boundaries between
+   them are likely traffic bottleneck locations (e.g., due to customer
+   aggregation onto common links and/or speed differences among links
+   used by the same traffic).
+
+7.  Security Considerations
+
+   The security considerations for all of the technologies discussed in
+   this memo apply; in particular, see the security considerations for
+   RTP in [RFC3550] and Diffserv in [RFC2474] and [RFC2475].
+
+   Multiplexing of multiple protocols onto a single UDP 5-tuple via
+   encapsulation has implications for network functionality that
+   monitors or inspects individual protocol flows, e.g., firewalls and
+   traffic monitoring systems.  When implementations of such
+   functionality lack visibility into encapsulated traffic (likely for
+   many current implementations), it may be difficult or impossible to
+   apply network security policy and associated controls at a finer
+   granularity than the overall UDP 5-tuple.
+
+   Use of multiple DSCPs that enable reordering within an overall real-
+   time communication interaction enlarges the set of network forwarding
+   resources used by that interaction, thereby increasing exposure to
+   resource depletion or failure, independent of whether the underlying
+   cause is benign or malicious.  This represents an increase in the
+   effective attack surface of the interaction and is a consideration in
+   selecting an appropriate degree of QoS differentiation among the
+   components of the real-time communication interaction.  See
+   Section 3.3.2.1 of [RFC6274] for related discussion of DSCP security
+   considerations.
+
+
+
+
+
+Black & Jones                 Informational                    [Page 19]
+
+RFC 7657              Diffserv and RT Communication        November 2015
+
+
+   Use of multiple DSCPs to provide differentiated QoS service may
+   reveal information about the encrypted traffic to which different
+   service levels are provided.  For example, DSCP-based identification
+   of RTP streams combined with packet frequency and packet size could
+   reveal the type or nature of the encrypted source streams.  The IP
+   header used for forwarding has to be unencrypted for obvious reasons,
+   and the DSCP likewise has to be unencrypted to enable different IP
+   forwarding behaviors to be applied to different packets.  The nature
+   of encrypted traffic components can be disguised via encrypted dummy
+   data padding and encrypted dummy packets, e.g., see the discussion of
+   traffic flow confidentiality in [RFC4303].  Encrypted dummy packets
+   could even be added in a fashion that an observer of the overall
+   encrypted traffic might mistake for another encrypted RTP stream.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC768]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+              DOI 10.17487/RFC0768, August 1980,
+              <http://www.rfc-editor.org/info/rfc768>.
+
+   [RFC793]   Postel, J., "Transmission Control Protocol", STD 7,
+              RFC 793, DOI 10.17487/RFC0793, September 1981,
+              <http://www.rfc-editor.org/info/rfc793>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc2474>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc2475>.
+
+   [RFC2597]  Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
+              "Assured Forwarding PHB Group", RFC 2597,
+              DOI 10.17487/RFC2597, June 1999,
+              <http://www.rfc-editor.org/info/rfc2597>.
+
+   [RFC3246]  Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
+              J., Courtney, W., Davari, S., Firoiu, V., and D.
+              Stiliadis, "An Expedited Forwarding PHB (Per-Hop
+              Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
+              <http://www.rfc-editor.org/info/rfc3246>.
+
+
+
+
+Black & Jones                 Informational                    [Page 20]
+
+RFC 7657              Diffserv and RT Communication        November 2015
+
+
+   [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, <http://www.rfc-editor.org/info/rfc3550>.
+
+   [RFC3662]  Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
+              Per-Domain Behavior (PDB) for Differentiated Services",
+              RFC 3662, DOI 10.17487/RFC3662, December 2003,
+              <http://www.rfc-editor.org/info/rfc3662>.
+
+   [RFC3828]  Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed.,
+              and G. Fairhurst, Ed., "The Lightweight User Datagram
+              Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July
+              2004, <http://www.rfc-editor.org/info/rfc3828>.
+
+   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
+              Congestion Control Protocol (DCCP)", RFC 4340,
+              DOI 10.17487/RFC4340, March 2006,
+              <http://www.rfc-editor.org/info/rfc4340>.
+
+   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
+              RFC 4960, DOI 10.17487/RFC4960, September 2007,
+              <http://www.rfc-editor.org/info/rfc4960>.
+
+   [RFC5405]  Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
+              for Application Designers", BCP 145, RFC 5405,
+              DOI 10.17487/RFC5405, November 2008,
+              <http://www.rfc-editor.org/info/rfc5405>.
+
+   [RFC5865]  Baker, F., Polk, J., and M. Dolly, "A Differentiated
+              Services Code Point (DSCP) for Capacity-Admitted Traffic",
+              RFC 5865, DOI 10.17487/RFC5865, May 2010,
+              <http://www.rfc-editor.org/info/rfc5865>.
+
+   [RFC6951]  Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
+              Control Transmission Protocol (SCTP) Packets for End-Host
+              to End-Host Communication", RFC 6951,
+              DOI 10.17487/RFC6951, May 2013,
+              <http://www.rfc-editor.org/info/rfc6951>.
+
+   [RFC7656]  Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
+              B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
+              for the Real-Time Transport Protocol (RTP) Sources",
+              RFC 7656, DOI 10.17487/RFC7656, November 2015,
+              <http://www.rfc-editor.org/info/rfc7656>.
+
+
+
+
+
+
+Black & Jones                 Informational                    [Page 21]
+
+RFC 7657              Diffserv and RT Communication        November 2015
+
+
+8.2.  Informative References
+
+   [COUPLED-CC]
+              Welzl, M., Islam, S., and S. Gjessing, "Coupled congestion
+              control for RTP media", Work in Progress,
+              draft-welzl-rmcat-coupled-cc-05, June 2015.
+
+   [DATA-CHAN]
+              Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
+              Channels", Work in Progress, draft-ietf-rtcweb-data-
+              channel-13, January 2015.
+
+   [DIFFSERV-INTERCON]
+              Geib, R., Ed. and D. Black, "Diffserv interconnection
+              classes and practice", Work in Progress, draft-ietf-tsvwg-
+              diffserv-intercon-03, October 2015.
+
+   [H.221]    ITU-T, "Frame structure for a 64 to 1920 kbit/s channel in
+              audiovisual teleservices", Recommendation H.221, March
+              2009.
+
+   [H.264]    ITU-T, "Advanced video coding for generic audiovisual
+              services", Recommendation H.264, February 2014.
+
+   [RFC2697]  Heinanen, J. and R. Guerin, "A Single Rate Three Color
+              Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999,
+              <http://www.rfc-editor.org/info/rfc2697>.
+
+   [RFC2698]  Heinanen, J. and R. Guerin, "A Two Rate Three Color
+              Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999,
+              <http://www.rfc-editor.org/info/rfc2698>.
+
+   [RFC2914]  Floyd, S., "Congestion Control Principles", BCP 41,
+              RFC 2914, DOI 10.17487/RFC2914, September 2000,
+              <http://www.rfc-editor.org/info/rfc2914>.
+
+   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
+              of Explicit Congestion Notification (ECN) to IP",
+              RFC 3168, DOI 10.17487/RFC3168, September 2001,
+              <http://www.rfc-editor.org/info/rfc3168>.
+
+   [RFC3270]  Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
+              P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
+              Protocol Label Switching (MPLS) Support of Differentiated
+              Services", RFC 3270, DOI 10.17487/RFC3270, May 2002,
+              <http://www.rfc-editor.org/info/rfc3270>.
+
+
+
+
+
+Black & Jones                 Informational                    [Page 22]
+
+RFC 7657              Diffserv and RT Communication        November 2015
+
+
+   [RFC4103]  Hellstrom, G. and P. Jones, "RTP Payload for Text
+              Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005,
+              <http://www.rfc-editor.org/info/rfc4103>.
+
+   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
+              RFC 4303, DOI 10.17487/RFC4303, December 2005,
+              <http://www.rfc-editor.org/info/rfc4303>.
+
+   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+              Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
+              July 2006, <http://www.rfc-editor.org/info/rfc4566>.
+
+   [RFC4594]  Babiarz, J., Chan, K., and F. Baker, "Configuration
+              Guidelines for DiffServ Service Classes", RFC 4594,
+              DOI 10.17487/RFC4594, August 2006,
+              <http://www.rfc-editor.org/info/rfc4594>.
+
+   [RFC5109]  Li, A., Ed., "RTP Payload Format for Generic Forward Error
+              Correction", RFC 5109, DOI 10.17487/RFC5109, December
+              2007, <http://www.rfc-editor.org/info/rfc5109>.
+
+   [RFC5127]  Chan, K., Babiarz, J., and F. Baker, "Aggregation of
+              Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127,
+              February 2008, <http://www.rfc-editor.org/info/rfc5127>.
+
+   [RFC5129]  Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
+              Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January
+              2008, <http://www.rfc-editor.org/info/rfc5129>.
+
+   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
+              (ICE): A Protocol for Network Address Translator (NAT)
+              Traversal for Offer/Answer Protocols", RFC 5245,
+              DOI 10.17487/RFC5245, April 2010,
+              <http://www.rfc-editor.org/info/rfc5245>.
+
+   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
+              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
+              DOI 10.17487/RFC5389, October 2008,
+              <http://www.rfc-editor.org/info/rfc5389>.
+
+   [RFC5462]  Andersson, L. and R. Asati, "Multiprotocol Label Switching
+              (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
+              Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
+              2009, <http://www.rfc-editor.org/info/rfc5462>.
+
+
+
+
+
+
+
+Black & Jones                 Informational                    [Page 23]
+
+RFC 7657              Diffserv and RT Communication        November 2015
+
+
+   [RFC5761]  Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
+              Control Packets on a Single Port", RFC 5761,
+              DOI 10.17487/RFC5761, April 2010,
+              <http://www.rfc-editor.org/info/rfc5761>.
+
+   [RFC5764]  McGrew, D. and E. Rescorla, "Datagram Transport Layer
+              Security (DTLS) Extension to Establish Keys for the Secure
+              Real-time Transport Protocol (SRTP)", RFC 5764,
+              DOI 10.17487/RFC5764, May 2010,
+              <http://www.rfc-editor.org/info/rfc5764>.
+
+   [RFC5766]  Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
+              Relays around NAT (TURN): Relay Extensions to Session
+              Traversal Utilities for NAT (STUN)", RFC 5766,
+              DOI 10.17487/RFC5766, April 2010,
+              <http://www.rfc-editor.org/info/rfc5766>.
+
+   [RFC6062]  Perreault, S., Ed. and J. Rosenberg, "Traversal Using
+              Relays around NAT (TURN) Extensions for TCP Allocations",
+              RFC 6062, DOI 10.17487/RFC6062, November 2010,
+              <http://www.rfc-editor.org/info/rfc6062>.
+
+   [RFC6274]  Gont, F., "Security Assessment of the Internet Protocol
+              Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011,
+              <http://www.rfc-editor.org/info/rfc6274>.
+
+   [RFC6386]  Bankoski, J., Koleszar, J., Quillio, L., Salonen, J.,
+              Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding
+              Guide", RFC 6386, DOI 10.17487/RFC6386, November 2011,
+              <http://www.rfc-editor.org/info/rfc6386>.
+
+   [RFC6437]  Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
+              "IPv6 Flow Label Specification", RFC 6437,
+              DOI 10.17487/RFC6437, November 2011,
+              <http://www.rfc-editor.org/info/rfc6437>.
+
+   [RFC6458]  Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.
+              Yasevich, "Sockets API Extensions for the Stream Control
+              Transmission Protocol (SCTP)", RFC 6458,
+              DOI 10.17487/RFC6458, December 2011,
+              <http://www.rfc-editor.org/info/rfc6458>.
+
+   [RMCAT-CC] Jesup, R. and Z. Sarker, "Congestion Control Requirements
+              for Interactive Real-Time Media", Work in Progress,
+              draft-ietf-rmcat-cc-requirements-09, December 2014.
+
+
+
+
+
+
+Black & Jones                 Informational                    [Page 24]
+
+RFC 7657              Diffserv and RT Communication        November 2015
+
+
+   [RTP-USAGE]
+              Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time
+              Communication (WebRTC): Media Transport and Use of RTP",
+              Work in Progress, draft-ietf-rtcweb-rtp-usage-25, June
+              2015.
+
+   [SDP-BUNDLE]
+              Holmberg, C., Alvestrand, H., and C. Jennings,
+              "Negotiating Media Multiplexing Using the Session
+              Description Protocol (SDP)", Work in Progress, draft-ietf-
+              mmusic-sdp-bundle-negotiation-23, July 2015.
+
+   [SRTP-DTLS]
+              Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme
+              Updates for Secure Real-time Transport Protocol (SRTP)
+              Extension for Datagram Transport Layer Security (DTLS)",
+              Work in Progress, draft-petithuguenin-avtcore-rfc5764-mux-
+              fixes-02, March 2015.
+
+   [W3C.WD-mediacapture-streams-20130903]
+              Burnett, D., Bergkvist, A., Jennings, C., and A.
+              Narayanan, "Media Capture and Streams", World Wide Web
+              Consortium Recommendation WD-mediacapture-streams-
+              20130903, September 2013, <http://www.w3.org/TR/2013/
+              WD-mediacapture-streams-20130903>.
+
+   [WEBRTC-OVERVIEW]
+              Alvestrand, H., "Overview: Real Time Protocols for
+              Browser-based Applications", Work in Progress,
+              draft-ietf-rtcweb-overview-14, June 2015.
+
+   [WEBRTC-TRANSPORTS]
+              Alvestrand, H., "Transports for WebRTC", Work in
+              Progress, draft-ietf-rtcweb-transports-10, October 2015.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Black & Jones                 Informational                    [Page 25]
+
+RFC 7657              Diffserv and RT Communication        November 2015
+
+
+Acknowledgements
+
+   This memo is the result of many conversations that have occurred
+   within the DART working group and other working groups in the RAI and
+   Transport areas.  Many thanks to Aamer Akhter, Harald Alvestrand,
+   Fred Baker, Richard Barnes, Erin Bournival, Ben Campbell, Brian
+   Carpenter, Spencer Dawkins, Keith Drage, Gorry Fairhurst, Ruediger
+   Geib, Cullen Jennings, Jonathan Lennox, Karen Nielsen, Colin Perkins,
+   James Polk, Robert Sparks, Tina Tsou, Michael Welzl, Dan York, and
+   the DART WG participants for their reviews and comments.
+
+Authors' Addresses
+
+   David Black (editor)
+   EMC
+   176 South Street
+   Hopkinton, MA  01748
+   United States
+
+   Phone: +1 508 293-7953
+   Email: david.black@emc.com
+
+
+   Paul Jones
+   Cisco
+   7025 Kit Creek Road
+   Research Triangle Park, NC  27502
+   United States
+
+   Phone: +1 919 476 2048
+   Email: paulej@packetizer.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Black & Jones                 Informational                    [Page 26]
+