idnits 2.17.1 draft-ietf-dart-dscp-rtp-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 30, 2014) is 3526 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-avtext-rtp-grouping-taxonomy-02 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 3662 (Obsoleted by RFC 8622) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5405 (Obsoleted by RFC 8085) == Outdated reference: A later version (-08) exists of draft-geib-tsvwg-diffserv-intercon-06 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-08 == Outdated reference: A later version (-09) exists of draft-ietf-rmcat-cc-requirements-05 == Outdated reference: A later version (-13) exists of draft-ietf-rtcweb-data-channel-11 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-11 == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-rtp-usage-17 == Outdated reference: A later version (-17) exists of draft-ietf-rtcweb-transports-06 == Outdated reference: A later version (-02) exists of draft-petithuguenin-avtcore-rfc5764-mux-fixes-00 == Outdated reference: A later version (-05) exists of draft-welzl-rmcat-coupled-cc-03 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DiffServ Applied to Real-time Transports D. Black, Ed. 3 Internet-Draft EMC 4 Intended status: Informational P. Jones 5 Expires: March 3, 2015 Cisco 6 August 30, 2014 8 Differentiated Services (DiffServ) and Real-time Communication 9 draft-ietf-dart-dscp-rtp-06 11 Abstract 13 This memo describes the interaction between Differentiated Services 14 (DiffServ) network quality of service (QoS) functionality and real- 15 time network communication, including communication based on the 16 Real-time Transport Protocol (RTP). DiffServ is based on network 17 nodes applying different forwarding treatments to packets whose IP 18 headers are marked with different DiffServ Code Points (DSCPs). 19 WebRTC applications, as well as some conferencing applications, have 20 begun using the Session Description Protocol (SDP) bundle negotiation 21 mechanism to send multiple traffic streams with different QoS 22 requirements using the same network 5-tuple. Use of different DSCPs 23 to obtain different QoS treatments within a single network 5-tuple, 24 the results (e.g., reordering) may cause transport protocol 25 interactions, particularly with congestion control functionality. In 26 addition, DSCP markings may be changed or removed between the traffic 27 source and destination. This memo covers the implications of these 28 DiffServ aspects for real-time network communication, including 29 WebRTC. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on March 3, 2015. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Real Time Communications . . . . . . . . . . . . . . . . . . 3 67 2.1. RTP Background . . . . . . . . . . . . . . . . . . . . . 3 68 2.2. RTP Multiplexing . . . . . . . . . . . . . . . . . . . . 6 69 3. Differentiated Services (DiffServ) . . . . . . . . . . . . . 7 70 3.1. Diffserv PHBs (Per-Hop Behaviors) . . . . . . . . . . . . 9 71 3.2. Traffic Classifiers and DSCP Remarking . . . . . . . . . 10 72 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 5. DiffServ Interactions . . . . . . . . . . . . . . . . . . . . 12 74 5.1. DiffServ, Reordering and Transport Protocols . . . . . . 12 75 5.2. DiffServ, Reordering and Real-Time Communication . . . . 15 76 5.3. Drop Precedence and Transport Protocols . . . . . . . . . 16 77 5.4. DiffServ and RTCP . . . . . . . . . . . . . . . . . . . . 17 78 6. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 84 10.2. Informative References . . . . . . . . . . . . . . . . . 21 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 87 1. Introduction 89 This memo describes the interactions between Differentiated Services 90 (DiffServ) network quality of service (QoS) functionality [RFC2475] 91 and real-time network communication, including communication based on 92 the Real-time Transport Protocol (RTP) [RFC3550]. DiffServ is based 93 on network nodes applying different forwarding treatments to packets 94 whose IP headers are marked with different DiffServ Code Points 95 (DSCPs)[RFC2474]. In the past, distinct RTP streams have been sent 96 over different transport level flows, sometimes multiplexed with 97 RTCP. WebRTC applications, as well as some conferencing 98 applications, are now using the Session Description Protocol (SDP) 99 [RFC4566] bundle negotiation mechanism 100 [I-D.ietf-mmusic-sdp-bundle-negotiation] to send multiple traffic 101 streams with different QoS requirments using the same network 102 5-tuple. Use of different DSCPs to obtain different QoS treatments 103 within a single network 5-tuple, the results (e.g., reordering) may 104 cause transport protocol interactions, particularly with congestion 105 control functionality. In addition, DSCP markings may be changed or 106 removed between the traffic source and destination. This memo covers 107 the implications of these DiffServ aspects for real-time network 108 communication, including WebRTC traffic [I-D.ietf-rtcweb-overview]. 110 The memo is organized as follows. Background is provided in 111 Section 2 on real time communications and Section 3 on Differentiated 112 Services. Section 4 describes some examples of DiffServ usage with 113 real time communications. Section 5 explains how use of DiffServ 114 features interacts with both transport and real time communications 115 protocols and Section 6 provides guidance on DiffServ feature usage 116 to control undesired interactions. Security considerations are 117 discussed in Section 8 (Section 7 is an empty IANA Considerations 118 section). 120 2. Real Time Communications 122 Real-time communications enables communication in real time over an 123 IP network using voice, video, text, content sharing, etc. It is 124 possible to use one or more of these modalities in parallel to 125 provide a rich communication experience. 127 A simple example of real-time communications is a voice call placed 128 over the Internet where an audio stream is transmitted in each 129 direction between two users. A more complex example is an immersive 130 videoconferencing system that has multiple video screens, multiple 131 cameras, multiple microphones, and some means of sharing content. 132 For such complex systems, there may be multiple media and non-media 133 streams transmitted via a single IP address and port or via multiple 134 IP addresses and ports. 136 2.1. RTP Background 138 The most common protocol used for real time media is the Real-Time 139 Transport Protocol (RTP) [RFC3550]. RTP defines a common 140 encapsulation format and handling rules for real-time data 141 transmitted over the Internet. Unfortunately, RTP terminology usage 142 has been inconsistent. For example, the document on RTP grouping 143 terminology [I-D.ietf-avtext-rtp-grouping-taxonomy] observes that: 145 RFC 3550 [RFC3550] uses the terms media stream, audio stream, 146 video stream and streams of (RTP) packets interchangeably. 148 Terminology in this memo is based on that RTP grouping terminology 149 document with the following terms being of particular importance (see 150 that terminology document for full definitions): 152 Source Stream: A reference clock synchronized, time progressing, 153 digital media stream. 155 RTP Stream: A stream of RTP packets containing media data, which may 156 be source data or redundant data. The RTP Stream is identified by 157 an RTP synchronization source (SSRC) belonging to a particular RTP 158 session. 160 In addition, this memo follows [RFC3550] in using the term "SSRC" to 161 designate both the identifier of an RTP stream and the entity that 162 sends that RTP stream. 164 Media encoding and packetization of a source stream results in a 165 source RTP stream plus zero or more redundancy RTP streams that 166 provide resilience against loss of packets from the source RTP stream 167 [I-D.ietf-avtext-rtp-grouping-taxonomy]. Redundancy information may 168 also be carried in the same RTP stream as the encoded source stream, 169 e.g., see Section 7.2 of [RFC5109]. With most applications, a single 170 media type (e.g., audio) is transmitted within a single RTP session. 171 However, it is possible to transmit multiple, distinct source streams 172 over the same RTP session as one or more individual RTP streams. 173 This is referred to as RTP multiplexing. In addition, an RTP stream 174 may contain multiple source streams, e.g., components or programs in 175 an MPEG Transport Stream [H.222.0]. 177 The number of source streams and RTP streams in an overall real-time 178 interaction can be surprisingly large. In addition to a voice source 179 stream and a video source stream, there could be separate source 180 streams for each of the cameras or microphones on a videoconferencing 181 system. As noted above, there might also be separate redundancy RTP 182 streams that provide protection to a source RTP stream, using 183 techniques such as Forward Error Correction. Another example is 184 simulcast transmission, where a video source stream can be 185 transmitted as high resolution and low resolution RTP streams at the 186 same time. In this case, a media processing function might choose to 187 send one or both RTP streams onward to a receiver based on bandwidth 188 availability or who the active speaker is in a multipoint conference. 189 Lastly, a transmitter might send the same media content concurrently 190 as two RTP streams using different encodings (e.g., video encoded as 191 VP8 in parallel with H.264) to allow a media processing function to 192 select a media encoding that best matches the capabilities of the 193 receiver. 195 For the WebRTC protocol suite [I-D.ietf-rtcweb-transports], an 196 individual source stream is a MediaStreamTrack, and a MediaStream 197 contains one or more MediaStreamTracks 198 [W3C.WD-mediacapture-streams-20130903]. A MediaStreamTrack is 199 transmitted as a source RTP stream plus zero or more redundant RTP 200 streams, so a MediaStream that consists of one MediaStreamTrack is 201 transmitted as a single source RTP stream plus zero or more redundant 202 RTP streams. For more information on use of RTP in WebRTC, see 203 [I-D.ietf-rtcweb-rtp-usage]. 205 RTP is usually carried over a datagram protocol, such as 206 UDP[RFC0768], UDP-Lite [RFC3828] or DCCP [RFC4340]; UDP is most 207 commonly used, but a non-datagram protocol (e.g., TCP) may also be 208 used. Transport protocols other than UDP or UDP-Lite may also be 209 used to transmit real-time data or near-real-time data. For example, 210 SCTP [RFC4960] can be utilized to carry application sharing or 211 whiteboarding information as part of an overall interaction that 212 includes real-time media. These additional transport protocols can 213 be multiplexed with an RTP session via UDP encapsulation, thereby 214 using a single pair of UDP ports. 216 The WebRTC protocol suite encompasses a number of forms of 217 multiplexing: 219 1. Individual source streams are carried in one or more individual 220 RTP streams. These RTP streams can be multiplexed onto a single 221 transport-layer flow or sent as separate transport-layer flows. 222 This memo only considers the case where the RTP streams are to be 223 multiplexed onto a single transport-layer flow, forming a single 224 RTP session as described in [RFC3550]; 226 2. The RTP Control Protocol (RTCP) (see [RFC3550]) may be 227 multiplexed onto the same transport-layer flow as the RTP streams 228 with which it is associated, as described in [RFC5761] or it may 229 be sent on a separate transport-layer flow; 231 3. An RTP session could be multiplexed with a single SCTP 232 association over DTLS and with both STUN [RFC5389] and TURN 233 [RFC5766] traffic into a single transport-layer flow as described 234 in [RFC5764] with the updates in 235 [I-D.petithuguenin-avtcore-rfc5764-mux-fixes]. The STUN 236 [RFC5389] and TURN [RFC5766] protocols provide NAT/FW (Network 237 Address Translator / Firewall) traversal and port mapping. 239 The resulting transport layer flow is identified by a network 240 5-tuple, i.e., a combination of two IP addresses (source and 241 destination), two ports (source and destination), and the transport 242 protocol used (e.g., UDP). SDP bundle negotiation restrictions 243 [I-D.ietf-mmusic-sdp-bundle-negotiation] limit WebRTC to using at 244 most a single DTLS session per network 5-tuple. In contrast to 245 WebRTC use of a single SCTP association with DTLS, multiple SCTP 246 associations can be directly multiplexed over a single UDP 5-tuple as 247 specified in [RFC6951]. 249 The STUN and TURN protocols were originally designed for use of UDP, 250 however, TURN has been extended to use TCP as a transport for 251 situations in which UDP does not work [RFC6062]. When TURN selects 252 use of TCP, the entire real-time communications session is carried 253 over a single TCP 5-tuple. 255 For IPv6, addition of the flow label [RFC6437] to network 5-tuples 256 results in network 6-tuples, but in practice, use of a flow label is 257 unlikely to result in a finer-grain traffic subset than the 258 corresponding network 5-tuple (e.g., the flow label is likely to 259 represent the combination of two ports with use of the UDP protocol). 260 For that reason, discussion in this draft focuses on UDP 5-tuples. 262 2.2. RTP Multiplexing 264 Section 2.1 explains how source streams can be multiplexed in a 265 single RTP session, which can in turn be multiplexed over UDP with 266 packets generated by other transport protocols. This section 267 provides background on why this level of multiplexing is desirable. 268 The rationale in this section applies both to multiplexing of source 269 streams in a single RTP session and multiplexing of an RTP session 270 with traffic from other transport protocols via UDP encapsulation. 272 Multiplexing reduces the number of ports utilized for real-time and 273 related communication in an overall interaction. While a single 274 endpoint might have plenty of ports available for communication, this 275 traffic often traverses points in the network that are constrained on 276 the number of available ports or whose performance degrades as the 277 number of ports in use increases. A good example is a Network 278 Address Translator and Firewall (NAT/FW) device sitting at the 279 network edge. As the number of simultaneous protocol sessions 280 increases, so does the burden placed on these devices to provide port 281 mapping. 283 Another reason for multiplexing is to help reduce the time required 284 to establish bi-directional communication. Since any two 285 communicating users might be situated behind different NAT/FW 286 devices, it is necessary to employ techniques like STUN and TURN 287 along with ICE [RFC5245] to get traffic to flow between the two 288 devices [I-D.ietf-rtcweb-transports]. Performing the tasks required 289 by these protocols takes time, especially when multiple protocol 290 sessions are involved. While tasks for different sessions can be 291 performed in parallel, it is nonetheless necessary for applications 292 to wait for all sessions to be opened before communication between 293 two users can begin. Reducing the number of STUN/ICE/TURN steps 294 reduces the likelihood of loss of a packet for one of these 295 protocols; any such loss adds delay to setting up a communication 296 session. Further, reducing the number of STUN/ICE/TURN tasks places 297 a lower burden on the STUN and TURN servers. 299 Multiplexing may reduce the complexity and resulting load on an 300 endpoint. A single instance of STUN/ICE/TURN is simpler to execute 301 and manage than multiple instances STUN/ICE/TURN operations happening 302 in parallel, as the latter require synchronization and create more 303 complex failure situations that have to be cleaned up by additional 304 code. 306 3. Differentiated Services (DiffServ) 308 The DiffServ architecture [RFC2475][RFC4594] is intended to enable 309 scalable service discrimination in the Internet without requiring 310 each node in the network to store per-flow state and participate in 311 per-flow signaling. The services may be end-to-end or within a 312 network; they include both those that can satisfy quantitative 313 performance requirements (e.g., peak bandwidth) and those based on 314 relative performance (e.g., "class" differentiation). Services can 315 be constructed by a combination of well-defined building blocks 316 deployed in network nodes that: 318 o classify traffic and set bits in an IP header field at network 319 boundaries or hosts, 321 o use those bits to determine how packets are forwarded by the nodes 322 inside the network, and 324 o condition the marked packets at network boundaries in accordance 325 with the requirements or rules of each service. 327 Traffic conditioning may include changing the DSCP in a packet 328 (remarking it), delaying the packet (as a consequence of traffic 329 shaping) or dropping the packet (as a consequence of traffic 330 policing). 332 A network node that supports DiffServ includes a classifier that 333 selects packets based on the value of the DS field in IP headers (the 334 DiffServ codepoint or DSCP), along with buffer management and packet 335 scheduling mechanisms capable of delivering the specific packet 336 forwarding treatment indicated by the DS field value. Setting of the 337 DS field and fine-grain conditioning of marked packets need only be 338 performed at network boundaries; internal network nodes operate on 339 traffic aggregates that share a DS field value, or in some cases, a 340 small set of related values. 342 The DiffServ architecture[RFC2475] maintains distinctions among: 344 o the QoS service provided to a traffic aggregate, 346 o the conditioning functions and per-hop behaviors (PHBs) used to 347 realize services, 349 o the DSCP in the IP header used to mark packets to select a per-hop 350 behavior, and 352 o the particular implementation mechanisms that realize a per-hop 353 behavior. 355 This memo focuses on PHBs and the usage of DSCPs to obtain those 356 behaviors. In a network node's forwarding path, the DSCP is used to 357 map a packet to a particular forwarding treatment, or per-hop 358 behavior (PHB) that specifies the forwarding treatment. 360 The specification of a PHB describes the externally observable 361 forwarding behavior of a network node for network traffic marked with 362 a DSCP that selects that PHB. In this context, "forwarding behavior" 363 is a general concept - for example, if only one DSCP is used for all 364 traffic on a link, the observable forwarding behavior (e.g., loss, 365 delay, jitter) will often depend only on the loading of the link. To 366 obtain useful behavioral differentiation, multiple traffic subsets 367 are marked with different DSCPs for different PHBs for which node 368 resources such as buffer space and bandwidth are allocated. PHBs 369 provide the framework for a DiffServ network node to allocate 370 resources to traffic subsets, with network-scope differentiated 371 services constructed on top of this basic hop-by-hop resource 372 allocation mechanism. 374 The codepoints (DSCPs) may be chosen from a small set of fixed values 375 (the class selector codepoints), or from a set of recommended values 376 defined in PHB specifications, or from values that have purely local 377 meanings to a specific network that supports DiffServ; in general, 378 packets may be forwarded across multiple such networks between source 379 and destination. 381 The mandatory DSCPs are the class selector code points as specified 382 in [RFC2474]. The class selector codepoints (CS0-CS7) extend the 383 deprecated concept of IP Precedence in the IPv4 header; three bits 384 are added, so that the class selector DSCPs are of the form 'xxx000'. 385 The all-zero DSCP ('000000' or CS0) is always assigned to a Default 386 PHB that provides best-effort forwarding behavior and the remaining 387 class selector code points are intended to provide relatively better 388 per-hop-forwarding behavior in increasing numerical order, but: 390 o There is no requirement that any two adjacent class selector 391 codepoints be assigned to different PHBs; adjacent class selector 392 codepoints may use the same pool of resources on each network node 393 in some networks. This generalizes to ranges of class selector 394 codepoints, but with limits - for example CS6 and CS7 are often 395 used for network control (e.g., routing) traffic [RFC4594] and 396 hence are likely to provide better forwarding behavior under 397 network load to prioritize network recovery from disruptions. 399 o CS1 ('001000') was subsequently designated as the recommended 400 codepoint for the Lower Effort (LE) PHB [RFC3662]. An LE service 401 forwards traffic with "lower" priority than best effort and can be 402 "starved" by best effort and other "higher" priority traffic. Not 403 all networks offer an LE service, hence traffic marked with the 404 CS1 DSCP may not receive lower effort forwarding; such traffic may 405 be forwarded with a different PHB (e.g., the Default PHB), 406 remarked to another DSCP (e.g., CS0) and forwarded accordingly, or 407 dropped. See [RFC3662] for further discussion of the LE PHB and 408 service. 410 One cannot rely upon different class selector codepoints providing 411 differentiated services or upon the presence of an LE service that is 412 selected by the CS1 DSCP. There is no effective way for a network 413 endpoint to determine which PHBs are selected by the class selector 414 codepoints or whether the CS1 DSCP selects an LE service on a 415 specific network, let alone end-to-end. Packets marked with the CS1 416 DSCP may be forwarded with best effort service or another "higher" 417 priority service, see [RFC2474]. 419 3.1. Diffserv PHBs (Per-Hop Behaviors) 421 Although Differentiated Services is a general architecture that may 422 be used to implement a variety of services, three fundamental 423 forwarding behaviors (PHBs) have been defined and characterized for 424 general use. These are: 426 1. Default Forwarding (DF) for elastic traffic [RFC2474]. The 427 Default PHB is always selected by the all-zero DSCP and provides 428 best-effort forwarding. 430 2. Assured Forwarding (AF) [RFC2597] to provide differentiated 431 service to elastic traffic. Each instance of the AF behavior 432 consists of three PHBs that differ only in drop precedence, e.g., 433 AF11, AF12 and AF13; such a set of three AF PHBs is referred to 434 as an AF class, e.g., AF1x. There are four defined AF classes, 435 AF1x through AF4x, with higher numbered classes intended to 436 receive better forwarding treatment than lower numbered classes. 438 3. Expedited Forwarding (EF) [RFC3246] intended for inelastic 439 traffic. Beyond the basic EF PHB, the VOICE-ADMIT PHB [RFC5865] 440 is an admission controlled variant of the EF PHB. Both of these 441 PHBs are based on pre-configured limited forwarding capacity; 442 traffic in excess of that capacity is expected to be dropped. 444 3.2. Traffic Classifiers and DSCP Remarking 446 DSCP markings are not end-to-end in general. Each network can make 447 its own decisions about what PHBs to use and which DSCP maps to each 448 PHB. While every PHB specification includes a recommended DSCP, and 449 RFC 4594 [RFC4594] recommends their end-to-end usage, there is no 450 requirement that every network support any PHBs or use any specific 451 DSCPs, with the exception of the support requirements for the class 452 selector codepoints (see RFC 2474 [RFC2474]). When DiffServ is used, 453 the edge or boundary nodes of a network are responsible for ensuring 454 that all traffic entering that network conforms to that network's 455 policies for DSCP and PHB usage, and such nodes may change DSCP 456 markings on traffic to achieve that result. As a result, DSCP 457 remarking is possible at any network boundary, including the first 458 network node that traffic sent by a host encounters. Remarking is 459 also possible within a network, e.g., for traffic shaping. 461 DSCP remarking is part of traffic conditioning; the traffic 462 conditioning functionality applied to packets at a network node is 463 determined by a traffic classifier [RFC2475]. Edge nodes of a 464 DiffServ network classify traffic based on selected packet header 465 fields; typical implementations do not look beyond the traffic's 466 network 5-tuple in the IP and transport protocol headers (e.g., for 467 SCTP or RTP enapsulated in UDP, header-based classification is 468 unlikely to look beyond the outer UDP header). As a result, when 469 multiple DSCPs are used for traffic that shares a network 5-tuple, 470 remarking at a network boundary may result in all of the traffic 471 being forwarded with a single DSCP, thereby removing any 472 differentiation within the network 5-tuple downstream of the 473 remarking location. Network nodes within a DiffServ network 474 generally classify traffic based solely on DSCPs, but may perform 475 finer grain traffic conditioning similar to that performed by edge 476 nodes. 478 So, for two arbitrary network endpoints, there can be no assurance 479 that the DSCP set at the source endpoint will be preserved and 480 presented at the destination endpoint. Rather, it is quite likely 481 that the DSCP will be set to zero (e.g., at the boundary of a network 482 operator that distrusts or does not use the DSCP field) or to a value 483 deemed suitable by an ingress classifier for whatever network 5-tuple 484 it carries. 486 In addition, remarking may remove application-level distinctions in 487 forwarding behavior - e.g., if multiple PHBs within an AF class are 488 used to distinguish different types of frames within a video RTP 489 stream, token-bucket-based remarkers operating in Color-Blind mode 490 (see [RFC2697] and [RFC2698] for examples) may remark solely based on 491 flow rate and burst behavior, removing the drop precedence 492 distinctions specified by the source. 494 Backbone and other carrier networks may employ a small number of 495 DSCPs (e.g., less than half a dozen) to manage a small number of 496 traffic aggregates; hosts that use a larger number of DSCPs can 497 expect to find that much of their intended differentiation is removed 498 by such networks. Better results may be achieved when DSCPs are used 499 to spread traffic among a smaller number of DiffServ-based traffic 500 subsets or aggregates, see [I-D.geib-tsvwg-diffserv-intercon] for one 501 proposal. This is of particular importance for MPLS-based networks 502 due to the limited size of the Traffic Class (TC) field in an MPLS 503 label [RFC5462] that is used to carry DiffServ information and the 504 use of that TC field for other purposes, e.g., ECN [RFC5129]. For 505 further discussion on use of DiffServ with MPLS, see [RFC3270] and 506 [RFC5127]. 508 4. Examples 510 For real-time communications, one might want to mark the audio 511 packets using EF and the video packets as AF41. However, in a video 512 conference receiving the audio packets significantly ahead of the 513 video is not useful because lip sync is necessary between audio and 514 video. It may still be desirable to send audio with a PHB that 515 provides better service, because more reliable arrival of audio helps 516 assure smooth audio rendering, which is often more important than 517 fully faithful video rendering. There are also limits, as some 518 devices have difficulties in synchronizing voice and video when 519 packets that need to be rendered together arrive at significantly 520 different times. It makes more sense to use different PHBs when the 521 audio and video source streams do not share a strict timing 522 relationship. For example, video content may be shared within a 523 video conference via playback, perhaps of an unedited video clip that 524 is intended to become part of a television advertisement. Such 525 content sharing video does not need precise synchronization with 526 video conference audio, and could use a different PHB, as content 527 sharing video is more tolerant to jitter, loss, and delay. 529 Within a layered video RTP stream, ordering of frame communication is 530 preferred, but importance of frame types varies, making use of PHBs 531 with different drop precedences appropriate. For example, I-frames 532 that contain an entire image are usually more important than P-frames 533 that contain only changes from the previous image because loss of a 534 P-frame (or part thereof) can be recovered (at the latest) via the 535 next I-frame, whereas loss of an I-frame (or part thereof) may cause 536 rendering problems for all of the P-frames that depend on the missing 537 I-frame. For this reason, it is appropriate to mark I-frame packets 538 with a PHB that has lower drop precedence than the PHB used for 539 P-frames, as long as the PHBs preserve ordering among frames (e.g., 540 are in a single AF class) - AF41 for I-frames and AF43 for P-frames 541 is one possibility. Additional spatial and temporal layers beyond 542 the base video layer could also be marked with higher drop precedence 543 than the base video layer, as their loss reduces video quality, but 544 does not disrupt video rendering. 546 Additional RTP streams in a real-time communication interaction could 547 be marked with CS0 and carried as best effort traffic. One example 548 is real-time text transmitted as specified in RFC 4103 [RFC4103]. 549 Best effort forwarding suffices because such real-time text has loose 550 timing requirements; RFC 4103 recommends sending text in chunks every 551 300ms. Such text is technically real-time, but does not need a PHB 552 promising better service than best effort, in contrast to audio or 553 video. 555 A WebRTC application may use one or more RTP streams, as discussed 556 above. In addition, it may use an SCTP-based data channel 557 [I-D.ietf-rtcweb-data-channel] whose QoS treatment depends on the 558 nature of the application. For example, best effort treatment of 559 data channels is likely to suffice for messaging, shared white board, 560 and guided browsing applications, whereas latency-sensitive games 561 might desire better QoS for their data channels. 563 5. DiffServ Interactions 565 5.1. DiffServ, Reordering and Transport Protocols 567 Transport protocols provide data communication behaviors beyond those 568 possible at the IP layer. An important example is that TCP [RFC0793] 569 provides reliable in-order delivery of data with congestion control. 570 SCTP [RFC4960] provides additional properties such as preservation of 571 message boundaries, and the ability to avoid head-of-line blocking 572 that may occur with TCP. 574 In contrast, UDP [RFC0768] is a basic unreliable datagram protocol 575 that provides port-based multiplexing and demultiplexing on top of 576 IP. Two other unreliable datagram protocols are UDP-Lite [RFC3828], 577 a variant of UDP that may deliver partially corrupt payloads when 578 errors occur, and DCCP [RFC4340], which provides a range of 579 congestion control modes for its unreliable datagram service. 581 Transport protocols that provide reliable delivery (e.g., TCP, SCTP) 582 are sensitive to network reordering of traffic. When a protocol that 583 provides reliable delivery receives a packet other than the next 584 expected packet, the protocol usually assumes that the expected 585 packet has been lost and respond with a retransmission request for 586 that packet. In addition, congestion control functionality in 587 transport protocols (including DCCP) usually infers congestion when 588 packets are lost. This creates additional sensitivity to significant 589 network packet reordering, as such reordering may be 590 (mis-)interpreted as loss of the out-of-order packets, causing a 591 congestion control response. 593 This sensitivity to reordering remains even when ECN [RFC3168] is in 594 use, as ECN receivers are required to treat missing packets as 595 potential indications of congestion, because: 597 o Severe congestion may cause ECN-capable network nodes to drop 598 packets, and 600 o ECN traffic may be forwarded by network nodes that do not support 601 ECN and hence drop packets to indicate congestion. 603 Congestion control is an important aspect of the Internet 604 architecture, see [RFC2914] for further discussion. 606 In general, marking packets with different DSCPs results in different 607 PHBs being applied at nodes in the network, making reordering 608 possible due to use of different pools of forwarding resources for 609 each PHB. This should not be done for current transport protocols 610 within a single network 5-tuple, with the exception of UDP and UDP- 611 Lite. 613 When PHBs that allow reordering are mixed within a single network 614 5-tuple, the effect is to mix QoS-based traffic classes within the 615 scope of a single transport connection or association. Such QoS- 616 based traffic classes receive different network QoS treatments and 617 hence use different pools of network resources. Transport protocol 618 support for multiple QoS-based traffic classes within a single 619 network 5-tuple adds complexity to congestion-controlled transport 620 protocols by comparison to current designs because it requires that 621 network congestion information for each QoS-based traffic class be 622 disambiguated so that congestion control is managed separately for 623 each such traffic class. Traffic in different QoS-based traffic 624 classes may use different paths through the network; this complicates 625 path integrity checking in connection- or association-based 626 protocols, as those paths may fail independently. 628 The primary example where usage of multiple PHBs does not allow 629 reordering within a single network 5-tuple is use of PHBs from a 630 single AF class (e.g., AF1x). Traffic reordering within the scope of 631 a network 5-tuple that uses a single PHB or AF class may occur for 632 other transient reasons (e.g., routing changes or ECMP rebalancing). 634 Reordering also affects other forms of congestion control, such as 635 techniques for RTP congestion control that were under development 636 when this memo was published, see [I-D.ietf-rmcat-cc-requirements] 637 for requirements. These techniques prefer use of a common (coupled) 638 congestion controller for RTP streams between the same endpoints to 639 reduce packet loss and delay by reducing competition for resources at 640 any shared bottleneck. 642 Shared bottlenecks can be detected via techniques such as correlation 643 of one-way delay measurements across RTP streams. An alternate 644 approach is to assume that the set of packets on a single network 645 5-tuple marked with DSCPs that do not allow reordering will utilize a 646 common network path and common forwarding resources at each network 647 node. Under that assumption, any bottleneck encountered by such 648 packets is shared among all of them, making it safe to use a common 649 (coupled) congestion controller, see [I-D.welzl-rmcat-coupled-cc]. 650 This is not a safe assumption when the packets involved are marked 651 with DSCP values that allow reordering because a bottleneck may not 652 be shared among all such packets (e.g., if the DSCPs result in use of 653 different queues at a network node, only one of which is a 654 bottleneck). 656 UDP and UDP-Lite are not sensitive to reordering in the network, 657 because they do not provide reliable delivery or congestion control. 658 On the other hand, when used to encapsulate other protocols (e.g., as 659 UDP is used by WebRTC, see Section 2.1), the reordering 660 considerations for the encapsulated protocols apply. For the 661 specific usage of UDP by WebRTC, every encapsulated protocol (i.e., 662 RTP, SCTP and TCP) is sensitive to reordering as further discussed in 663 this memo. In addition, [RFC5405] provides general guidelines for 664 use of UDP (and UDP-Lite); the congestion control guidelines in that 665 document apply to protocols encapsulated in UDP (or UDP-Lite). 667 5.2. DiffServ, Reordering and Real-Time Communication 669 Real-time communications are also sensitive to network reordering of 670 packets. Such reordering may lead to spurious NACK generation and 671 unneeded retransmission, as is the case for reliable delivery 672 protocols (see Section 5.1). The degree of sensitivity depends on 673 protocol or stream timers, in contrast to reliable delivery protocols 674 that usually react to all reordering. 676 Receiver jitter buffers have important roles in the effect of 677 reordering on real time communications: 679 o Minor packet reordering that is contained within a jitter buffer 680 usually has no effect on rendering of the received RTP stream 681 because packets that arrive out of order are retrieved in order 682 from the jitter buffer for rendering. 684 o Packet reordering that exceeds the capacity of a jitter buffer can 685 cause user-perceptible quality problems (e.g., glitches, noise) 686 for delay sensitive communication, such as interactive 687 conversations for which small jitter buffers are necessary to 688 preserve human perceptions of real-time interaction. Interactive 689 real-time communication implementations often discard data that is 690 sufficiently late that it cannot be rendered in source stream 691 order, making retransmission counterproductive. For this reason, 692 implementations of interactive real-time communication often do 693 not use retransmission. 695 o In contrast, replay of recorded media can tolerate significantly 696 longer delays than interactive conversations, so replay is likely 697 to use larger jitter buffers than interactive conversations. 698 These larger jitter buffers increase the tolerance of replay to 699 reordering by comparison to interactive conversations. The size 700 of the jitter buffer imposes an upper bound on replay tolerance to 701 reordering, but does enable retransmission to be used when the 702 jitter buffer is significantly larger than the amount of data that 703 can be expected to arrive during the round-trip latency for 704 retransmission. 706 Network packet reordering has no effective upper bound, and can 707 exceed the size of any reasonable jitter buffer. In practice, the 708 size of jitter buffers for replay is limited by external factors such 709 as the amount of time that a human is willing to wait for replay to 710 start. 712 5.3. Drop Precedence and Transport Protocols 714 Packets within the same network 5-tuple that use PHBs within a single 715 AF class can be expected to draw upon the same forwarding resources 716 on network nodes (e.g., use the same router queue) and hence use of 717 multiple drop precedences within an AF class is not expected to cause 718 latency variation. When PHBs within a single AF class are mixed 719 within a flow, the resulting overall likelihood that packets will be 720 dropped from that flow is a mix of the drop likelihoods of the PHBs 721 involved. 723 There are situations in which drop precedences should not be mixed. 724 A simple example is that there is little value in mixing drop 725 precedences within a TCP connection, because TCP's ordered delivery 726 behavior results in any drop requiring the receiver to wait for the 727 dropped packet to be retransmitted. Any resulting delay depends on 728 the RTT and not the packet that was dropped. Hence a single DSCP 729 should be used for all packets in a TCP connection. 731 As a consequence, when TCP is selected for NAT/FW traversal (e.g., by 732 TURN), a single DSCP should be used for all traffic on that TCP 733 connection. An additional reason for this recommendation is that 734 packetization for STUN/ICE/TURN occurs before passing the resulting 735 packets to TCP; TCP resegmentation may result in a different 736 packetization on the wire, breaking any association between DSCPs and 737 specific data to which they are intended to apply. 739 SCTP [RFC4960] differs from TCP in a number of ways, including the 740 ability to deliver messages in an order that differs from the order 741 in which they were sent and support for unreliable streams. However, 742 SCTP performs congestion control and retransmission across the entire 743 association, and not on a per-stream basis. Although there may be 744 advantages to using multiple drop precedence across SCTP streams or 745 within an SCTP stream that does not use reliable ordered delivery, 746 there is no practical operational experience in doing so (e.g., the 747 SCTP sockets API [RFC6458] does not support use of more than one DSCP 748 for an SCTP association). As a consequence, the impacts on SCTP 749 protocol and implementation behavior are unknown and difficult to 750 predict. Hence a single DSCP should be used for all packets in an 751 SCTP association, independent of the number or nature of streams in 752 that association. Similar reasoning applies to a DCCP connection; a 753 single DSCP should be used because the scope of congestion control is 754 the connection and there is no operational experience with using more 755 than one DSCP. This recommendation may be revised in the future if 756 experiments, analysis and operational experience provide compelling 757 reasons to change it. 759 Guidance on transport protocol design and implementation to provide 760 support for use of multiple PHBs and DSCPs in a transport protocol 761 connection (e.g., DCCP) or transport protocol association (e.g., 762 SCTP) is out of scope for this memo. 764 5.4. DiffServ and RTCP 766 The RTP Control Protocol (RTCP) [RFC3550] is used with RTP to monitor 767 quality of service and convey information about RTP session 768 participants. A sender of RTCP packets that also sends RTP packets 769 (i.e., originates an RTP stream) should use the same DSCP marking for 770 both types of packets. If an RTCP sender doesn't send any RTP 771 packets, it should mark its RTCP packets with the DSCP that it would 772 use if it did send RTP packets with media similar to the RTP traffic 773 that it receives. If the RTCP sender uses or would use multiple 774 DSCPs that differ only in drop precedence for RTP, then it should use 775 the DSCP with the least likelihood of drop for RTCP to increase the 776 likelihood of RTCP packet delivery. 778 If the SDP bundle extension [I-D.ietf-mmusic-sdp-bundle-negotiation] 779 is used to negotiate sending multiple types of media in a single RTP 780 session, then receivers will send separate RTCP reports for each type 781 of media, using a separate SSRC for each media type; each RTCP report 782 should be marked with the DSCP corresponding to the type of media 783 handled by the reporting SSRC. 785 This guidance may result in different DSCP markings for RTP streams 786 and RTCP receiver reports about those RTP streams. The resulting 787 variation in network QoS treatment by traffic direction could result 788 in unrepresentative round trip time (RTT) estimates that don't 789 correspond to consistent network QoS treatment in both directions. 790 RTCP receiver reports may be relatively infrequent (e.g., may be sent 791 only once per video frame rendered) and hence the resulting RTT 792 estimates are of limited utility for congestion control (although 793 they have other important uses, see [RFC3550]). For this reason, it 794 is not important that RTCP receiver reports receive the same network 795 QoS treatment as the RTP stream or streams being reported on. 797 6. Guidelines 799 The only use of multiple standardized PHBs and DSCPs that prevents 800 network reordering among packets marked with different DSCPs is use 801 of PHBs within a single AF class. All other uses of multiple PHBs 802 and/or the class selector DSCPs allow network reordering of packets 803 that are marked with different DSCPs. Based on this and the 804 foregoing discussion, the guidelines in this section apply to use of 805 DiffServ with real-time communications. 807 Applications and other traffic sources (including RTP SSRCs): 809 o Should limit use of DSCPs within a single RTP stream to those 810 whose corresponding PHBs do not allow packet reordering. If this 811 is not done, significant network reordering may overwhelm 812 implementation assumptions about reordering limits, e.g., jitter 813 buffer size, causing poor user experiences, see Section 5.2 above. 814 This guideline applies to all of the RTP streams that are within 815 the scope of a common (coupled) congestion controller when that 816 controller does not use per-RTP-stream measurements for bottleneck 817 detection. 819 o Should use a single DSCP for RTCP packets, which should be a DSCP 820 used for RTP packets that are or would be sent by that SSRC, see 821 Section 5.4. 823 o Should use a single DSCP for all packets within a reliable 824 transport protocol session (e.g., TCP connection, SCTP 825 association) or DCCP connection, see Section 5.1 and Section 5.3. 826 For SCTP, this requirement applies across the entire SCTP 827 association, and not just to individual streams within an 828 association. When TURN selects TCP for NAT/FW traversal, this 829 guideline applies to all traffic multiplexed onto that TCP 830 connection, in contrast to use of UDP for NAT/FW traversal. 832 o May use different DSCPs whose corresponding PHBs allow reordering 833 within a single UDP or UDP-Lite 5-tuple, subject to the above 834 constraints. The service differentiation provided by such usage 835 is unreliable, as it may be removed or changed by DSCP remarking 836 at network boundaries as described in Section 3.2 above. 838 o Cannot rely on end-to-end preservation of DSCPs as network node 839 remarking can change DSCPs and remove drop precedence distinctions 840 (see Section 3.2 above). For example, if a source uses drop 841 precedence distinctions within an AF class to identify different 842 types of video frames, using those DSCP values at the receiver to 843 identify frame type is inherently unreliable. 845 o Should limit use of the CS1 codepoint to traffic for which best 846 effort forwarding is acceptable, as network support for use of CS1 847 to select a "less than best effort" PHB is inconsistent. Further, 848 some networks may treat CS1 as providing "better than best effort" 849 forwarding behavior. 851 There is no guidance in this memo on how network operators should 852 differentiate traffic. Networks may support all of the PHBs 853 discussed herein, classify EF and AFxx traffic identically, or even 854 remark all traffic to best effort at some ingress points. 856 Nonetheless, it is useful for applications and other traffic sources 857 to provide finer granularity DSCP marking on packets for the benefit 858 of networks that offer QoS service differentiation. A specific 859 example is that traffic originating from a browser may benefit from 860 QoS service differentiation in within-building and residential access 861 networks, even if the DSCP marking is subsequently removed or 862 simplified. This is because such networks and the boundaries between 863 them are likely traffic bottleneck locations (e.g., due to customer 864 aggregation onto common links and/or speed differences among links 865 used by the same traffic). 867 7. IANA Considerations 869 This memo includes no request to IANA. 871 8. Security Considerations 873 The security considerations for all of the technologies discussed in 874 this memo apply; in particular see the security considerations for 875 RTP in [RFC3550] and DiffServ in [RFC2474] and[RFC2475]. 877 Multiplexing of multiple protocols onto a single UDP 5-tuple via 878 encapsulation has implications for network functionality that 879 monitors or inspects individual protocol flows, e.g., firewalls and 880 traffic monitoring systems. When implementations of such 881 functionality lack visibility into encapsulated traffic (likely for 882 many current implementations), it may be difficult or impossible to 883 apply network security policy and associated controls at a finer 884 granularity than the overall UDP 5-tuple. 886 Use of multiple DSCPs that allow reordering within an overall real- 887 time communication interaction enlarges the set of network forwarding 888 resources used by that interaction, thereby increasing exposure to 889 resource depletion or failure, independent of whether the underlying 890 cause is benign or malicious. This represents an increase in the 891 effective attack surface of the interaction, and is a consideration 892 in selecting an appropriate degree of QoS differentiation among the 893 components of the real-time communication interaction. 895 Use of multiple DSCPs to provide differentiated QoS service may 896 reveal information about the encrypted traffic to which different 897 service levels are provided. For example, DSCP-based identification 898 of RTP streams combined with packet frequency and packet size could 899 reveal the type or nature of the encrypted source streams. The IP 900 header used for forwarding has to be unencrypted for obvious reasons, 901 and the DSCP likewise has to be unencrypted to enable different IP 902 forwarding behaviors to be applied to different packets. The nature 903 of encrypted traffic components can be disguised via encrypted dummy 904 data padding and encrypted dummy packets, e.g., see the discussion of 905 traffic flow confidentiality in [RFC4303]. Encrypted dummy packets 906 could even be added in a fashion that an observer of the overall 907 encrypted traffic might mistake for another encrypted RTP stream. 909 9. Acknowledgements 911 This memo is the result of many conversations that have occurred 912 within the dart working group and multiple other working groups in 913 the RAI and Transport areas. Many thanks to Aamer Akhter, Harald 914 Alvestrand, Erin Bournival, Ben Campbell, Brian Carpenter, Keith 915 Drage, Gorry Fairhurst, Ruediger Geib, Cullen Jennings, Jonathan 916 Lennox, Karen Nielsen, Colin Perkins, James Polk, Michael Welzl, Dan 917 York and the dart WG participants for their reviews and comments. 919 10. References 921 10.1. Normative References 923 [I-D.ietf-avtext-rtp-grouping-taxonomy] 924 Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, 925 "A Taxonomy of Grouping Semantics and Mechanisms for Real- 926 Time Transport Protocol (RTP) Sources", draft-ietf-avtext- 927 rtp-grouping-taxonomy-02 (work in progress), June 2014. 929 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 930 August 1980. 932 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 933 793, September 1981. 935 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 936 "Definition of the Differentiated Services Field (DS 937 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 938 1998. 940 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 941 and W. Weiss, "An Architecture for Differentiated 942 Services", RFC 2475, December 1998. 944 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 945 "Assured Forwarding PHB Group", RFC 2597, June 1999. 947 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 948 J., Courtney, W., Davari, S., Firoiu, V., and D. 949 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 950 Behavior)", RFC 3246, March 2002. 952 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 953 Jacobson, "RTP: A Transport Protocol for Real-Time 954 Applications", STD 64, RFC 3550, July 2003. 956 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 957 Per-Domain Behavior (PDB) for Differentiated Services", 958 RFC 3662, December 2003. 960 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 961 G. Fairhurst, "The Lightweight User Datagram Protocol 962 (UDP-Lite)", RFC 3828, July 2004. 964 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 965 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 967 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 968 4960, September 2007. 970 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 971 for Application Designers", BCP 145, RFC 5405, November 972 2008. 974 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 975 Services Code Point (DSCP) for Capacity-Admitted Traffic", 976 RFC 5865, May 2010. 978 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 979 Control Transmission Protocol (SCTP) Packets for End-Host 980 to End-Host Communication", RFC 6951, May 2013. 982 10.2. Informative References 984 [H.222.0] ITU-T, "H.222.0 : Information technology - Generic coding 985 of moving pictures and associated audio information", June 986 2012. 988 [I-D.geib-tsvwg-diffserv-intercon] 989 Geib, R., "DiffServ interconnection classes and practice", 990 draft-geib-tsvwg-diffserv-intercon-06 (work in progress), 991 July 2014. 993 [I-D.ietf-mmusic-sdp-bundle-negotiation] 994 Holmberg, C., Alvestrand, H., and C. Jennings, 995 "Negotiating Media Multiplexing Using the Session 996 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 997 negotiation-08 (work in progress), August 2014. 999 [I-D.ietf-rmcat-cc-requirements] 1000 Jesup, R., "Congestion Control Requirements For RMCAT", 1001 draft-ietf-rmcat-cc-requirements-05 (work in progress), 1002 July 2014. 1004 [I-D.ietf-rtcweb-data-channel] 1005 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 1006 Channels", draft-ietf-rtcweb-data-channel-11 (work in 1007 progress), July 2014. 1009 [I-D.ietf-rtcweb-overview] 1010 Alvestrand, H., "Overview: Real Time Protocols for 1011 Browser-based Applications", draft-ietf-rtcweb-overview-11 1012 (work in progress), August 2014. 1014 [I-D.ietf-rtcweb-rtp-usage] 1015 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 1016 Communication (WebRTC): Media Transport and Use of RTP", 1017 draft-ietf-rtcweb-rtp-usage-17 (work in progress), August 1018 2014. 1020 [I-D.ietf-rtcweb-transports] 1021 Alvestrand, H., "Transports for WebRTC", draft-ietf- 1022 rtcweb-transports-06 (work in progress), August 2014. 1024 [I-D.petithuguenin-avtcore-rfc5764-mux-fixes] 1025 Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme 1026 Updates for Secure Real-time Transport Protocol (SRTP) 1027 Extension for Datagram Transport Layer Security (DTLS)", 1028 draft-petithuguenin-avtcore-rfc5764-mux-fixes-00 (work in 1029 progress), July 2014. 1031 [I-D.welzl-rmcat-coupled-cc] 1032 Welzl, M., Islam, S., and S. Gjessing, "Coupled congestion 1033 control for RTP media", draft-welzl-rmcat-coupled-cc-03 1034 (work in progress), May 2014. 1036 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 1037 Marker", RFC 2697, September 1999. 1039 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 1040 Marker", RFC 2698, September 1999. 1042 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 1043 2914, September 2000. 1045 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1046 of Explicit Congestion Notification (ECN) to IP", RFC 1047 3168, September 2001. 1049 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 1050 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 1051 Protocol Label Switching (MPLS) Support of Differentiated 1052 Services", RFC 3270, May 2002. 1054 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 1055 Conversation", RFC 4103, June 2005. 1057 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 1058 4303, December 2005. 1060 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1061 Description Protocol", RFC 4566, July 2006. 1063 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 1064 Guidelines for DiffServ Service Classes", RFC 4594, August 1065 2006. 1067 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 1068 Correction", RFC 5109, December 2007. 1070 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 1071 Diffserv Service Classes", RFC 5127, February 2008. 1073 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 1074 Marking in MPLS", RFC 5129, January 2008. 1076 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1077 (ICE): A Protocol for Network Address Translator (NAT) 1078 Traversal for Offer/Answer Protocols", RFC 5245, April 1079 2010. 1081 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1082 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1083 October 2008. 1085 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 1086 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 1087 Class" Field", RFC 5462, February 2009. 1089 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1090 Control Packets on a Single Port", RFC 5761, April 2010. 1092 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1093 Security (DTLS) Extension to Establish Keys for the Secure 1094 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1096 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1097 Relays around NAT (TURN): Relay Extensions to Session 1098 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 1100 [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays 1101 around NAT (TURN) Extensions for TCP Allocations", RFC 1102 6062, November 2010. 1104 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1105 "IPv6 Flow Label Specification", RFC 6437, November 2011. 1107 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 1108 Yasevich, "Sockets API Extensions for the Stream Control 1109 Transmission Protocol (SCTP)", RFC 6458, December 2011. 1111 [W3C.WD-mediacapture-streams-20130903] 1112 Burnett, D., Bergkvist, A., Jennings, C., and A. 1113 Narayanan, "Media Capture and Streams", World Wide Web 1114 Consortium WD WD-mediacapture-streams-20130903, September 1115 2013, . 1118 Appendix A. Change History 1120 [To be removed before RFC publication.] 1122 Changes from draft-york-dart-dscp-rtp-00 to -01: 1124 o Added examples (Section 5) 1126 o Reworked text on RTP session multiplexing, at most one RTP session 1127 can be used per UDP 5-tuple. 1129 o Initial terminology alignment with RTP grouping taxonomy draft. 1131 o Added Section 2.5 on real-time communication interaction w/ 1132 reordering based on text from Harald Alvestrand. 1134 o Strengthened warnings on loss of differentiation, but indicate 1135 that differentiation may still be useful from source to point of 1136 loss. 1138 o Added a few sentences on DiffServ and MPLS. 1140 o Added discussion of UDP-encapsulated protocols that are reordering 1141 sensitive. 1143 o Added initial security considerations. 1145 o Many editorial changes 1147 Changes from draft-york-dart-dscp-rtp-01 to -02: 1149 o More terminology alignment with RTP grouping taxonomy draft: "RTP 1150 packet stream" -> "RTP stream" 1152 o Aligned terminology for less-than-best-effort with RFC 3662 - LE 1153 (Lower Effort) PHB and service 1155 o Minor reference updates 1157 Changes from draft-york-dart-dscp-rtp-02 to draft-ietf-dart-dscp-rtp- 1158 00: 1160 o Reduce author list and convert to Informational - remove RFC 2119 1161 reference and keywords 1163 o Strengthen TCP and SCTP text. 1165 o Add section 2.6 on drop precedence. 1167 o Remove discussion of multiplexing multiple RTP sessions on a 1168 single UDP 5-tuple 1170 o Add discussions of RTCP, STUN/ICE/TURN and coupled congestion 1171 control 1173 o Many editorial changes. 1175 o Lots of additional references 1177 Changes from draft-ietf-dart-dscp-rtp-00 to -01: 1179 o Merge the two TCP/SCTP guideline bullets. 1181 o Add DCCP and UDP-Lite material, plus reference to RFC 5405 for UDP 1182 (and UDP-Lite) usage guidelines. 1184 o Add "attack surface" security consideration. 1186 o Many editorial changes. 1188 o More references, and moved some references to normative. 1190 Changes from draft-ietf-dart-dscp-rtp-01 to -02: 1192 o Reorganize text for better topic flow and make related edits. 1194 Changes from draft-ietf-dart-dscp-rtp-02 to -03: 1196 o Correct text on treatment of excess EF traffic to indicate that 1197 excess traffic is dropped. 1199 o Say that transport protocol design and implementation guidance is 1200 not provided on use of multiple DSCPs and PHBs in a single 1201 transport protocol connection or association. 1203 o RTCWEB -> WebRTC, and correct problems in descriptions of how it 1204 uses multiplexing. 1206 o Fix DCCP congestion control discussion and text on coupled 1207 congestion controllers. 1209 o Strengthen text on what happens when TURN selects TCP for NAT 1210 traversal. 1212 o Note open issue on how to mark RTCP traffic. 1214 o Many editorial changes. 1216 Changes from draft-ietf-dart-dscp-rtp-03 to -04: 1218 o Add abstract/intro text on SDP bundle usage, e.g., by WebRTC 1220 o Remove erroneous use of SSRC w/source stream in Section 2.1 1222 o Add text on WebRTC data channel examples 1224 o Add text on transport protocol complexities that would be 1225 necessary to deal with multiple QoS levels in same protocol 1226 connection or association 1228 o Additional minor edits. 1230 Changes from draft-ietf-dart-dscp-rtp-04 to -05: 1232 o Rewrite RTCP text and guidelines, including new section 5.4. 1234 o Use "SSRC" as term for sender of RTP stream. 1236 o Additional minor edits. 1238 Changes from draft-ietf-dart-dscp-rtp-05 to -06: 1240 o Remove RTCP multi-stream optimization material - interaction of 1241 that with DiffServ will be covered in the multi-stream 1242 optimisation draft if/as appropriate. 1244 o Additional minor edits. 1246 Authors' Addresses 1248 David Black (editor) 1249 EMC 1250 176 South Street 1251 Hopkinton, MA 01748 1252 USA 1254 Phone: +1 508 293-7953 1255 Email: david.black@emc.com 1257 Paul Jones 1258 Cisco 1259 7025 Kit Creek Road 1260 Research Triangle Park, MA 27502 1261 USA 1263 Phone: +1 919 476 2048 1264 Email: paulej@packetizer.com