diff options
Diffstat (limited to 'doc/rfc/rfc7657.txt')
| -rw-r--r-- | doc/rfc/rfc7657.txt | 1459 |
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] + |