idnits 2.17.1 draft-ietf-dart-dscp-rtp-10.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 (November 10, 2014) is 3426 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 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-07 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-12 == Outdated reference: A later version (-09) exists of draft-ietf-rmcat-cc-requirements-07 == Outdated reference: A later version (-13) exists of draft-ietf-rtcweb-data-channel-12 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-12 == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-rtp-usage-19 == Outdated reference: A later version (-17) exists of draft-ietf-rtcweb-transports-07 == Outdated reference: A later version (-02) exists of draft-petithuguenin-avtcore-rfc5764-mux-fixes-01 == Outdated reference: A later version (-05) exists of draft-welzl-rmcat-coupled-cc-04 -- 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: 3 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: May 14, 2015 Cisco 6 November 10, 2014 8 Differentiated Services (DiffServ) and Real-time Communication 9 draft-ietf-dart-dscp-rtp-10 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. The results of using 23 multiple DSCPs to obtain different QoS treatments within a single 24 network 5-tuple have transport protocol interactions, particularly 25 with congestion control functionality (e.g., reordering). 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 May 14, 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 . . . . . . 13 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. Security Considerations . . . . . . . . . . . . . . . . . . . 19 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 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 requirements using the same network 102 5-tuple. The results of using multiple DSCPs to obtain different QoS 103 treatments within a single network 5-tuple have transport protocol 104 interactions, particularly with congestion control functionality 105 (e.g., reordering). 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 7. 119 2. Real Time Communications 121 Real-time communications enables communication in real time over an 122 IP network using voice, video, text, content sharing, etc. It is 123 possible to use more than one of these modes concurrently to provide 124 a rich communication experience. 126 A simple example of real-time communications is a voice call placed 127 over the Internet where an audio stream is transmitted in each 128 direction between two users. A more complex example is an immersive 129 videoconferencing system that has multiple video screens, multiple 130 cameras, multiple microphones, and some means of sharing content. 131 For such complex systems, there may be multiple media and non-media 132 streams transmitted via a single IP address and port or via multiple 133 IP addresses and ports. 135 2.1. RTP Background 137 The most common protocol used for real time media is the Real-Time 138 Transport Protocol (RTP) [RFC3550]. RTP defines a common 139 encapsulation format and handling rules for real-time data 140 transmitted over the Internet. Unfortunately, RTP terminology usage 141 has been inconsistent. For example, the document on RTP grouping 142 terminology [I-D.ietf-avtext-rtp-grouping-taxonomy] observes that: 144 RFC 3550 [RFC3550] uses the terms media stream, audio stream, 145 video stream and streams of (RTP) packets interchangeably. 147 Terminology in this memo is based on that RTP grouping terminology 148 document with the following terms being of particular importance (see 149 that terminology document for full definitions): 151 Source Stream: A reference clock synchronized, time progressing, 152 digital media stream. 154 RTP Stream: A stream of RTP packets containing media data, which may 155 be source data or redundant data. The RTP Stream is identified by 156 an RTP synchronization source (SSRC) belonging to a particular RTP 157 session. 159 In addition, this memo follows [RFC3550] in using the term "SSRC" to 160 designate both the identifier of an RTP stream and the entity that 161 sends that RTP stream. 163 Media encoding and packetization of a source stream results in a 164 source RTP stream plus zero or more redundancy RTP streams that 165 provide resilience against loss of packets from the source RTP stream 166 [I-D.ietf-avtext-rtp-grouping-taxonomy]. Redundancy information may 167 also be carried in the same RTP stream as the encoded source stream, 168 e.g., see Section 7.2 of [RFC5109]. With most applications, a single 169 media type (e.g., audio) is transmitted within a single RTP session. 170 However, it is possible to transmit multiple, distinct source streams 171 over the same RTP session as one or more individual RTP streams. 172 This is referred to as RTP multiplexing. In addition, an RTP stream 173 may contain multiple source streams, e.g., components or programs in 174 an MPEG Transport Stream [H.221]. 176 The number of source streams and RTP streams in an overall real-time 177 interaction can be surprisingly large. In addition to a voice source 178 stream and a video source stream, there could be separate source 179 streams for each of the cameras or microphones on a videoconferencing 180 system. As noted above, there might also be separate redundancy RTP 181 streams that provide protection to a source RTP stream, using 182 techniques such as Forward Error Correction. Another example is 183 simulcast transmission, where a video source stream can be 184 transmitted as high resolution and low resolution RTP streams at the 185 same time. In this case, a media processing function might choose to 186 send one or both RTP streams onward to a receiver based on bandwidth 187 availability or who the active speaker is in a multipoint conference. 188 Lastly, a transmitter might send the same media content concurrently 189 as two RTP streams using different encodings (e.g., video encoded as 190 VP8 [RFC6386] in parallel with H.264 [H.264]) to allow a media 191 processing function to select a media encoding that best matches the 192 capabilities of the receiver. 194 For the WebRTC protocol suite [I-D.ietf-rtcweb-transports], an 195 individual source stream is a MediaStreamTrack, and a MediaStream 196 contains one or more MediaStreamTracks 197 [W3C.WD-mediacapture-streams-20130903]. A MediaStreamTrack is 198 transmitted as a source RTP stream plus zero or more redundant RTP 199 streams, so a MediaStream that consists of one MediaStreamTrack is 200 transmitted as a single source RTP stream plus zero or more redundant 201 RTP streams. For more information on use of RTP in WebRTC, see 202 [I-D.ietf-rtcweb-rtp-usage]. 204 RTP is usually carried over a datagram protocol, such as 205 UDP[RFC0768], UDP-Lite [RFC3828] or DCCP [RFC4340]; UDP is most 206 commonly used, but a non-datagram protocol (e.g., TCP 207 [I-D.ietf-tcpm-tcp-rfc4614bis]) may also be used. Transport 208 protocols other than UDP or UDP-Lite may also be used to transmit 209 real-time data or near-real-time data. For example, SCTP [RFC4960] 210 can be utilized to carry application sharing or whiteboarding 211 information as part of an overall interaction that includes real-time 212 media. These additional transport protocols can be multiplexed with 213 an RTP session via UDP encapsulation, thereby using a single pair of 214 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 to use UDP as a 250 transport, however, TURN has been extended to use TCP as a transport 251 for situations in which UDP does not work [RFC6062]. When TURN 252 selects use of TCP, the entire real-time communications session is 253 carried over a single TCP connection (i.e., 5-tuple). 255 For IPv6, addition of the flow label [RFC6437] to network 5-tuples 256 results in network 6-tuples (or 7-tuples for bidirectional flows), 257 but in practice, use of a flow label is unlikely to result in a 258 finer-grain traffic subset than the corresponding network 5-tuple 259 (e.g., the flow label is likely to represent the combination of two 260 ports with use of the UDP protocol). For that reason, discussion in 261 this draft focuses on UDP 5-tuples. 263 2.2. RTP Multiplexing 265 Section 2.1 explains how source streams can be multiplexed in a 266 single RTP session, which can in turn be multiplexed over UDP with 267 packets generated by other transport protocols. This section 268 provides background on why this level of multiplexing is desirable. 269 The rationale in this section applies both to multiplexing of source 270 streams in a single RTP session and multiplexing of an RTP session 271 with traffic from other transport protocols via UDP encapsulation. 273 Multiplexing reduces the number of ports utilized for real-time and 274 related communication in an overall interaction. While a single 275 endpoint might have plenty of ports available for communication, this 276 traffic often traverses points in the network that are constrained on 277 the number of available ports or whose performance degrades as the 278 number of ports in use increases. A good example is a Network 279 Address Translator and Firewall (NAT/FW) device sitting at the 280 network edge. As the number of simultaneous protocol sessions 281 increases, so does the burden placed on these devices to provide port 282 mapping. 284 Another reason for multiplexing is to help reduce the time required 285 to establish bi-directional communication. Since any two 286 communicating users might be situated behind different NAT/FW 287 devices, it is necessary to employ techniques like STUN and TURN 288 along with ICE [RFC5245] to get traffic to flow between the two 289 devices [I-D.ietf-rtcweb-transports]. Performing the tasks required 290 by these protocols takes time, especially when multiple protocol 291 sessions are involved. While tasks for different sessions can be 292 performed in parallel, it is nonetheless necessary for applications 293 to wait for all sessions to be opened before communication between 294 two users can begin. Reducing the number of STUN/ICE/TURN steps 295 reduces the likelihood of loss of a packet for one of these 296 protocols; any such loss adds delay to setting up a communication 297 session. Further, reducing the number of STUN/ICE/TURN tasks places 298 a lower burden on the STUN and TURN servers. 300 Multiplexing may reduce the complexity and resulting load on an 301 endpoint. A single instance of STUN/ICE/TURN is simpler to execute 302 and manage than multiple instances STUN/ICE/TURN operations happening 303 in parallel, as the latter require synchronization and create more 304 complex failure situations that have to be cleaned up by additional 305 code. 307 3. Differentiated Services (DiffServ) 309 The DiffServ architecture [RFC2475][RFC4594] is intended to enable 310 scalable service discrimination in the Internet without requiring 311 each node in the network to store per-flow state and participate in 312 per-flow signaling. The services may be end-to-end or within a 313 network; they include both those that can satisfy quantitative 314 performance requirements (e.g., peak bandwidth) and those based on 315 relative performance (e.g., "class" differentiation). Services can 316 be constructed by a combination of well-defined building blocks 317 deployed in network nodes that: 319 o classify traffic and set bits in an IP header field at network 320 boundaries or hosts, 322 o use those bits to determine how packets are forwarded by the nodes 323 inside the network, and 325 o condition the marked packets at network boundaries in accordance 326 with the requirements or rules of each service. 328 Traffic conditioning may include changing the DSCP in a packet 329 (remarking it), delaying the packet (as a consequence of traffic 330 shaping) or dropping the packet (as a consequence of traffic 331 policing). 333 A network node that supports DiffServ includes a classifier that 334 selects packets based on the value of the DS field in IP headers (the 335 DiffServ codepoint or DSCP), along with buffer management and packet 336 scheduling mechanisms capable of delivering the specific packet 337 forwarding treatment indicated by the DS field value. Setting of the 338 DS field and fine-grain conditioning of marked packets need only be 339 performed at network boundaries; internal network nodes operate on 340 traffic aggregates that share a DS field value, or in some cases, a 341 small set of related values. 343 The DiffServ architecture [RFC2475] maintains distinctions among: 345 o the QoS service provided to a traffic aggregate, 347 o the conditioning functions and per-hop behaviors (PHBs) used to 348 realize services, 350 o the DSCP in the IP header used to mark packets to select a per-hop 351 behavior, and 353 o the particular implementation mechanisms that realize a per-hop 354 behavior. 356 This memo focuses on PHBs and the usage of DSCPs to obtain those 357 behaviors. In a network node's forwarding path, the DSCP is used to 358 map a packet to a particular forwarding treatment, or per-hop 359 behavior (PHB) that specifies the forwarding treatment. 361 The specification of a PHB describes the externally observable 362 forwarding behavior of a network node for network traffic marked with 363 a DSCP that selects that PHB. In this context, "forwarding behavior" 364 is a general concept - for example, if only one DSCP is used for all 365 traffic on a link, the observable forwarding behavior (e.g., loss, 366 delay, jitter) will often depend only on the loading of the link. To 367 obtain useful behavioral differentiation, multiple traffic subsets 368 are marked with different DSCPs for different PHBs for which node 369 resources such as buffer space and bandwidth are allocated. PHBs 370 provide the framework for a DiffServ network node to allocate 371 resources to traffic subsets, with network-scope differentiated 372 services constructed on top of this basic hop-by-hop resource 373 allocation mechanism. 375 The codepoints (DSCPs) may be chosen from a small set of fixed values 376 (the class selector codepoints), or from a set of recommended values 377 defined in PHB specifications, or from values that have purely local 378 meanings to a specific network that supports DiffServ; in general, 379 packets may be forwarded across multiple such networks between source 380 and destination. 382 The mandatory DSCPs are the class selector code points as specified 383 in [RFC2474]. The class selector codepoints (CS0-CS7) extend the 384 deprecated concept of IP Precedence in the IPv4 header; three bits 385 are added, so that the class selector DSCPs are of the form 'xxx000'. 386 The all-zero DSCP ('000000' or CS0) is always assigned to a Default 387 PHB that provides best-effort forwarding behavior and the remaining 388 class selector code points are intended to provide relatively better 389 per-hop-forwarding behavior in increasing numerical order, but: 391 o A network endpoint cannot rely upon different class selector 392 codepoints providing differentiated services via assignment to 393 different PHBs, as adjacent class selector codepoints may use the 394 same pool of resources on each network node in some networks. 395 This generalizes to ranges of class selector codepoints, but with 396 limits - for example CS6 and CS7 are often used for network 397 control (e.g., routing) traffic [RFC4594] and hence are likely to 398 provide better forwarding behavior under network load to 399 prioritize network recovery from disruptions. There is no 400 effective way for a network endpoint to determine which PHBs are 401 selected by the class selector codepoints on a specific network, 402 let alone end-to-end. 404 o CS1 ('001000') was subsequently designated as the recommended 405 codepoint for the Lower Effort (LE) PHB [RFC3662]. An LE service 406 forwards traffic with "lower" priority than best effort and can be 407 "starved" by best effort and other "higher" priority traffic. Not 408 all networks offer an LE service, hence traffic marked with the 409 CS1 DSCP may not receive lower effort forwarding; such traffic may 410 be forwarded with a different PHB (e.g., the Default PHB), 411 remarked to another DSCP (e.g., CS0) and forwarded accordingly, or 412 dropped. A network endpoint cannot rely upon the presence of an 413 LE service that is selected by the CS1 DSCP on a specific network, 414 let alone end-to-end. Packets marked with the CS1 DSCP may be 415 forwarded with best effort service or another "higher" priority 416 service; see [RFC2474]. See [RFC3662] for further discussion of 417 the LE PHB and service. 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. 437 Use of multiple PHBs from a single AF class (e.g., AF1x) does not 438 enable network traffic reordering within a single network 439 5-tuple, although such reordering may occur for other transient 440 reasons (e.g., routing changes or ECMP rebalancing). 442 3. Expedited Forwarding (EF) [RFC3246] intended for inelastic 443 traffic. Beyond the basic EF PHB, the VOICE-ADMIT PHB [RFC5865] 444 is an admission controlled variant of the EF PHB. Both of these 445 PHBs are based on pre-configured limited forwarding capacity; 446 traffic in excess of that capacity is expected to be dropped. 448 3.2. Traffic Classifiers and DSCP Remarking 450 DSCP markings are not end-to-end in general. Each network can make 451 its own decisions about what PHBs to use and which DSCP maps to each 452 PHB. While every PHB specification includes a recommended DSCP, and 453 RFC 4594 [RFC4594] recommends their end-to-end usage, there is no 454 requirement that every network support any PHBs (aside from the 455 Default PHB for best effort forwarding) or use any specific DSCPs, 456 with the exception of the support requirements for the class selector 457 codepoints (see RFC 2474 [RFC2474]). When DiffServ is used, the edge 458 or boundary nodes of a network are responsible for ensuring that all 459 traffic entering that network conforms to that network's policies for 460 DSCP and PHB usage, and such nodes may change DSCP markings on 461 traffic to achieve that result. As a result, DSCP remarking is 462 possible at any network boundary, including the first network node 463 that traffic sent by a host encounters. Remarking is also possible 464 within a network, e.g., for traffic shaping. 466 DSCP remarking is part of traffic conditioning; the traffic 467 conditioning functionality applied to packets at a network node is 468 determined by a traffic classifier [RFC2475]. Edge nodes of a 469 DiffServ network classify traffic based on selected packet header 470 fields; typical implementations do not look beyond the traffic's 471 network 5-tuple in the IP and transport protocol headers (e.g., for 472 SCTP or RTP enapsulated in UDP, header-based classification is 473 unlikely to look beyond the outer UDP header). As a result, when 474 multiple DSCPs are used for traffic that shares a network 5-tuple, 475 remarking at a network boundary may result in all of the traffic 476 being forwarded with a single DSCP, thereby removing any 477 differentiation within the network 5-tuple downstream of the 478 remarking location. Network nodes within a DiffServ network 479 generally classify traffic based solely on DSCPs, but may perform 480 finer grain traffic conditioning similar to that performed by edge 481 nodes. 483 So, for two arbitrary network endpoints, there can be no assurance 484 that the DSCP set at the source endpoint will be preserved and 485 presented at the destination endpoint. Rather, it is quite likely 486 that the DSCP will be set to zero (e.g., at the boundary of a network 487 operator that distrusts or does not use the DSCP field) or to a value 488 deemed suitable by an ingress classifier for whatever network 5-tuple 489 it carries. 491 In addition, remarking may remove application-level distinctions in 492 forwarding behavior - e.g., if multiple PHBs within an AF class are 493 used to distinguish different types of frames within a video RTP 494 stream, token-bucket-based remarkers operating in Color-Blind mode 495 (see [RFC2697] and [RFC2698] for examples) may remark solely based on 496 flow rate and burst behavior, removing the drop precedence 497 distinctions specified by the source. 499 Backbone and other carrier networks may employ a small number of 500 DSCPs (e.g., less than half a dozen) to manage a small number of 501 traffic aggregates; hosts that use a larger number of DSCPs can 502 expect to find that much of their intended differentiation is removed 503 by such networks. Better results may be achieved when DSCPs are used 504 to spread traffic among a smaller number of DiffServ-based traffic 505 subsets or aggregates; see [I-D.geib-tsvwg-diffserv-intercon] for one 506 proposal. This is of particular importance for MPLS-based networks 507 due to the limited size of the Traffic Class (TC) field in an MPLS 508 label [RFC5462] that is used to carry DiffServ information and the 509 use of that TC field for other purposes, e.g., ECN [RFC5129]. For 510 further discussion on use of DiffServ with MPLS, see [RFC3270] and 511 [RFC5127]. 513 4. Examples 515 For real-time communications, one might want to mark the audio 516 packets using EF and the video packets as AF41. However, in a video 517 conference receiving the audio packets significantly ahead of the 518 video is not useful because lip sync is necessary between audio and 519 video. It may still be desirable to send audio with a PHB that 520 provides better service, because more reliable arrival of audio helps 521 assure smooth audio rendering, which is often more important than 522 fully faithful video rendering. There are also limits, as some 523 devices have difficulties in synchronizing voice and video when 524 packets that need to be rendered together arrive at significantly 525 different times. It makes more sense to use different PHBs when the 526 audio and video source streams do not share a strict timing 527 relationship. For example, video content may be shared within a 528 video conference via playback, perhaps of an unedited video clip that 529 is intended to become part of a television advertisement. Such 530 content sharing video does not need precise synchronization with 531 video conference audio, and could use a different PHB, as content 532 sharing video is more tolerant to jitter, loss, and delay. 534 Within a layered video RTP stream, ordering of frame communication is 535 preferred, but importance of frame types varies, making use of PHBs 536 with different drop precedences appropriate. For example, I-frames 537 that contain an entire image are usually more important than P-frames 538 that contain only changes from the previous image because loss of a 539 P-frame (or part thereof) can be recovered (at the latest) via the 540 next I-frame, whereas loss of an I-frame (or part thereof) may cause 541 rendering problems for all of the P-frames that depend on the missing 542 I-frame. For this reason, it is appropriate to mark I-frame packets 543 with a PHB that has lower drop precedence than the PHB used for 544 P-frames, as long as the PHBs preserve ordering among frames (e.g., 545 are in a single AF class) - AF41 for I-frames and AF43 for P-frames 546 is one possibility. Additional spatial and temporal layers beyond 547 the base video layer could also be marked with higher drop precedence 548 than the base video layer, as their loss reduces video quality, but 549 does not disrupt video rendering. 551 Additional RTP streams in a real-time communication interaction could 552 be marked with CS0 and carried as best effort traffic. One example 553 is real-time text transmitted as specified in RFC 4103 [RFC4103]. 554 Best effort forwarding suffices because such real-time text has loose 555 timing requirements; RFC 4103 recommends sending text in chunks every 556 300ms. Such text is technically real-time, but does not need a PHB 557 promising better service than best effort, in contrast to audio or 558 video. 560 A WebRTC application may use one or more RTP streams, as discussed 561 above. In addition, it may use an SCTP-based data channel 562 [I-D.ietf-rtcweb-data-channel] whose QoS treatment depends on the 563 nature of the application. For example, best effort treatment of 564 data channels is likely to suffice for messaging, shared white board, 565 and guided browsing applications, whereas latency-sensitive games 566 might desire better QoS for their data channels. 568 5. DiffServ Interactions 569 5.1. DiffServ, Reordering and Transport Protocols 571 Transport protocols provide data communication behaviors beyond those 572 possible at the IP layer. An important example is that TCP 573 [I-D.ietf-tcpm-tcp-rfc4614bis] provides reliable in-order delivery of 574 data with congestion control. SCTP [RFC4960] provides additional 575 properties such as preservation of message boundaries, and the 576 ability to avoid head-of-line blocking that may occur with TCP. 578 In contrast, UDP [RFC0768] is a basic unreliable datagram protocol 579 that provides port-based multiplexing and demultiplexing on top of 580 IP. Two other unreliable datagram protocols are UDP-Lite [RFC3828], 581 a variant of UDP that may deliver partially corrupt payloads when 582 errors occur, and DCCP [RFC4340], which provides a range of 583 congestion control modes for its unreliable datagram service. 585 Transport protocols that provide reliable delivery (e.g., TCP, SCTP) 586 are sensitive to network reordering of traffic. When a protocol that 587 provides reliable delivery receives a packet other than the next 588 expected packet, the protocol usually assumes that the expected 589 packet has been lost and updates the peer, which often causes a 590 retransmission. In addition, congestion control functionality in 591 transport protocols (including DCCP) usually infers congestion when 592 packets are lost. This creates additional sensitivity to significant 593 network packet reordering, as such reordering may be 594 (mis-)interpreted as loss of the out-of-order packets, causing a 595 congestion control response. 597 This sensitivity to reordering remains even when ECN [RFC3168] is in 598 use, as ECN receivers are required to treat missing packets as 599 potential indications of congestion, because: 601 o Severe congestion may cause ECN-capable network nodes to drop 602 packets, and 604 o ECN traffic may be forwarded by network nodes that do not support 605 ECN and hence drop packets to indicate congestion. 607 Congestion control is an important aspect of the Internet 608 architecture; see [RFC2914] for further discussion. 610 In general, marking packets with different DSCPs results in different 611 PHBs being applied at nodes in the network, making reordering very 612 likely due to use of different pools of forwarding resources for each 613 PHB. This should not be done within a single network 5-tuple for 614 current transport protocols, with the important exceptions of UDP and 615 UDP-Lite. 617 When PHBs that enable reordering are mixed within a single network 618 5-tuple, the effect is to mix QoS-based traffic classes within the 619 scope of a single transport protocol connection or association. As 620 these QoS-based traffic classes receive different network QoS 621 treatments, they use different pools of network resources and hence 622 may exhibit different levels of congestion. The result for 623 congestion-controlled protocols is that a separate instance of 624 congestion control functionality is needed per QoS-based traffic 625 class. Current transport protocols support only a single instance of 626 congestion control functionality for an entire connection or 627 association; extending that support to multiple instances would add 628 significant protocol complexity. Traffic in different QoS-based 629 classes may use different paths through the network; this complicates 630 path integrity checking in connection- or association-based 631 protocols, as those paths may fail independently. 633 The primary example where usage of multiple PHBs does not enable 634 reordering within a single network 5-tuple is use of PHBs from a 635 single AF class (e.g., AF1x). Traffic reordering within the scope of 636 a network 5-tuple that uses a single PHB or AF class may occur for 637 other transient reasons (e.g., routing changes or ECMP rebalancing). 639 Reordering also affects other forms of congestion control, such as 640 techniques for RTP congestion control that were under development 641 when this memo was published; see [I-D.ietf-rmcat-cc-requirements] 642 for requirements. These techniques prefer use of a common (coupled) 643 congestion controller for RTP streams between the same endpoints to 644 reduce packet loss and delay by reducing competition for resources at 645 any shared bottleneck. 647 Shared bottlenecks can be detected via techniques such as correlation 648 of one-way delay measurements across RTP streams. An alternate 649 approach is to assume that the set of packets on a single network 650 5-tuple marked with DSCPs that do not enable reordering will utilize 651 a common network path and common forwarding resources at each network 652 node. Under that assumption, any bottleneck encountered by such 653 packets is shared among all of them, making it safe to use a common 654 (coupled) congestion controller (see [I-D.welzl-rmcat-coupled-cc]). 655 This is not a safe assumption when the packets involved are marked 656 with DSCP values that enable reordering because a bottleneck may not 657 be shared among all such packets (e.g., if the DSCPs result in use of 658 different queues at a network node, only one of which is a 659 bottleneck). 661 UDP and UDP-Lite are not sensitive to reordering in the network, 662 because they do not provide reliable delivery or congestion control. 663 On the other hand, when used to encapsulate other protocols (e.g., as 664 UDP is used by WebRTC, see Section 2.1), the reordering 665 considerations for the encapsulated protocols apply. For the 666 specific usage of UDP by WebRTC, every encapsulated protocol (i.e., 667 RTP, SCTP and TCP) is sensitive to reordering as further discussed in 668 this memo. In addition, [RFC5405] provides general guidelines for 669 use of UDP (and UDP-Lite); the congestion control guidelines in that 670 document apply to protocols encapsulated in UDP (or UDP-Lite). 672 5.2. DiffServ, Reordering and Real-Time Communication 674 Real-time communications are also sensitive to network reordering of 675 packets. Such reordering may lead to unneeded retransmission, and 676 spurious retransmission control signals (such as NACK) in reliable 677 delivery protocols (see Section 5.1). The degree of sensitivity 678 depends on protocol or stream timers, in contrast to reliable 679 delivery protocols that usually react to all reordering. 681 Receiver jitter buffers have important roles in the effect of 682 reordering on real time communications: 684 o Minor packet reordering that is contained within a jitter buffer 685 usually has no effect on rendering of the received RTP stream 686 because packets that arrive out of order are retrieved in order 687 from the jitter buffer for rendering. 689 o Packet reordering that exceeds the capacity of a jitter buffer can 690 cause user-perceptible quality problems (e.g., glitches, noise) 691 for delay sensitive communication, such as interactive 692 conversations for which small jitter buffers are necessary to 693 preserve human perceptions of real-time interaction. Interactive 694 real-time communication implementations often discard data that is 695 sufficiently late that it cannot be rendered in source stream 696 order, making retransmission counterproductive. For this reason, 697 implementations of interactive real-time communication often do 698 not use retransmission. 700 o In contrast, replay of recorded media can tolerate significantly 701 longer delays than interactive conversations, so replay is likely 702 to use larger jitter buffers than interactive conversations. 703 These larger jitter buffers increase the tolerance of replay to 704 reordering by comparison to interactive conversations. The size 705 of the jitter buffer imposes an upper bound on replay tolerance to 706 reordering, but does enable retransmission to be used when the 707 jitter buffer is significantly larger than the amount of data that 708 can be expected to arrive during the round-trip latency for 709 retransmission. 711 Network packet reordering has no effective upper bound, and can 712 exceed the size of any reasonable jitter buffer. In practice, the 713 size of jitter buffers for replay is limited by external factors such 714 as the amount of time that a human is willing to wait for replay to 715 start. 717 5.3. Drop Precedence and Transport Protocols 719 Packets within the same network 5-tuple that use PHBs within a single 720 AF class can be expected to draw upon the same forwarding resources 721 on network nodes (e.g., use the same router queue) and hence use of 722 multiple drop precedences within an AF class is not expected to cause 723 latency variation. When PHBs within a single AF class are mixed 724 within a flow, the resulting overall likelihood that packets will be 725 dropped from that flow is a mix of the drop likelihoods of the PHBs 726 involved. 728 There are situations in which drop precedences should not be mixed. 729 A simple example is that there is little value in mixing drop 730 precedences within a TCP connection, because TCP's ordered delivery 731 behavior results in any drop requiring the receiver to wait for the 732 dropped packet to be retransmitted. Any resulting delay depends on 733 the RTT and not the packet that was dropped. Hence a single DSCP 734 should be used for all packets in a TCP connection. 736 As a consequence, when TCP is selected for NAT/FW traversal (e.g., by 737 TURN), a single DSCP should be used for all traffic on that TCP 738 connection. An additional reason for this recommendation is that 739 packetization for STUN/ICE/TURN occurs before passing the resulting 740 packets to TCP; TCP resegmentation may result in a different 741 packetization on the wire, breaking any association between DSCPs and 742 specific data to which they are intended to apply. 744 SCTP [RFC4960] differs from TCP in a number of ways, including the 745 ability to deliver messages in an order that differs from the order 746 in which they were sent and support for unreliable streams. However, 747 SCTP performs congestion control and retransmission across the entire 748 association, and not on a per-stream basis. Although there may be 749 advantages to using multiple drop precedence across SCTP streams or 750 within an SCTP stream that does not use reliable ordered delivery, 751 there is no practical operational experience in doing so (e.g., the 752 SCTP sockets API [RFC6458] does not support use of more than one DSCP 753 for an SCTP association). As a consequence, the impacts on SCTP 754 protocol and implementation behavior are unknown and difficult to 755 predict. Hence a single DSCP should be used for all packets in an 756 SCTP association, independent of the number or nature of streams in 757 that association. Similar reasoning applies to a DCCP connection; a 758 single DSCP should be used because the scope of congestion control is 759 the connection and there is no operational experience with using more 760 than one DSCP. This recommendation may be revised in the future if 761 experiments, analysis and operational experience provide compelling 762 reasons to change it. 764 Guidance on transport protocol design and implementation to provide 765 support for use of multiple PHBs and DSCPs in a transport protocol 766 connection (e.g., DCCP) or transport protocol association (e.g., 767 SCTP) is out of scope for this memo. 769 5.4. DiffServ and RTCP 771 The RTP Control Protocol (RTCP) [RFC3550] is used with RTP to monitor 772 quality of service and convey information about RTP session 773 participants. A sender of RTCP packets that also sends RTP packets 774 (i.e., originates an RTP stream) should use the same DSCP marking for 775 both types of packets. If an RTCP sender doesn't send any RTP 776 packets, it should mark its RTCP packets with the DSCP that it would 777 use if it did send RTP packets with media similar to the RTP traffic 778 that it receives. If the RTCP sender uses or would use multiple 779 DSCPs that differ only in drop precedence for RTP, then it should use 780 the DSCP with the least likelihood of drop for RTCP to increase the 781 likelihood of RTCP packet delivery. 783 If the SDP bundle extension [I-D.ietf-mmusic-sdp-bundle-negotiation] 784 is used to negotiate sending multiple types of media in a single RTP 785 session, then receivers will send separate RTCP reports for each type 786 of media, using a separate SSRC for each media type; each RTCP report 787 should be marked with the DSCP corresponding to the type of media 788 handled by the reporting SSRC. 790 This guidance may result in different DSCP markings for RTP streams 791 and RTCP receiver reports about those RTP streams. The resulting 792 variation in network QoS treatment by traffic direction is necessary 793 to obtain representative round trip time (RTT) estimates that 794 correspond to the media path RTT, which may differ from the transport 795 protocol RTT. RTCP receiver reports may be relatively infrequent and 796 hence the resulting RTT estimates are of limited utility for 797 transport protocol congestion control (although those RTT estimates 798 have other important uses, see [RFC3550]). For this reason, it is 799 important that RTCP receiver reports sent by an SSRC receive the same 800 network QoS treatment as the RTP stream being sent by that SSRC. 802 6. Guidelines 804 The only use of multiple standardized PHBs and DSCPs that does not 805 enable network reordering among packets marked with different DSCPs 806 is use of PHBs within a single AF class. All other uses of multiple 807 PHBs and/or the class selector DSCPs enable network reordering of 808 packets that are marked with different DSCPs. Based on this and the 809 foregoing discussion, the guidelines in this section apply to use of 810 DiffServ with real-time communications. 812 Applications and other traffic sources (including RTP SSRCs): 814 o Should limit use of DSCPs within a single RTP stream to those 815 whose corresponding PHBs do not enable packet reordering. If this 816 is not done, significant network reordering may overwhelm 817 implementation assumptions about reordering limits, e.g., jitter 818 buffer size, causing poor user experiences (see Section 5.2). 819 This guideline applies to all of the RTP streams that are within 820 the scope of a common (coupled) congestion controller when that 821 controller does not use per-RTP-stream measurements for bottleneck 822 detection. 824 o Should use a single DSCP for RTCP packets, which should be a DSCP 825 used for RTP packets that are or would be sent by that SSRC (see 826 Section 5.4). 828 o Should use a single DSCP for all packets within a reliable 829 transport protocol session (e.g., TCP connection, SCTP 830 association) or DCCP connection (see Section 5.1 and Section 5.3). 831 For SCTP, this requirement applies across the entire SCTP 832 association, and not just to individual streams within an 833 association. When TURN selects TCP for NAT/FW traversal, this 834 guideline applies to all traffic multiplexed onto that TCP 835 connection, in contrast to use of UDP for NAT/FW traversal. 837 o May use different DSCPs whose corresponding PHBs enable reordering 838 within a single UDP or UDP-Lite 5-tuple, subject to the above 839 constraints. The service differentiation provided by such usage 840 is unreliable, as it may be removed or changed by DSCP remarking 841 at network boundaries as described in Section 3.2 above. 843 o Cannot rely on end-to-end preservation of DSCPs as network node 844 remarking can change DSCPs and remove drop precedence distinctions 845 (see Section 3.2). For example, if a source uses drop precedence 846 distinctions within an AF class to identify different types of 847 video frames, using those DSCP values at the receiver to identify 848 frame type is inherently unreliable. 850 o Should limit use of the CS1 codepoint to traffic for which best 851 effort forwarding is acceptable, as network support for use of CS1 852 to select a "less than best effort" PHB is inconsistent. Further, 853 some networks may treat CS1 as providing "better than best effort" 854 forwarding behavior. 856 There is no guidance in this memo on how network operators should 857 differentiate traffic. Networks may support all of the PHBs 858 discussed herein, classify EF and AFxx traffic identically, or even 859 remark all traffic to best effort at some ingress points. 860 Nonetheless, it is useful for applications and other traffic sources 861 to provide finer granularity DSCP marking on packets for the benefit 862 of networks that offer QoS service differentiation. A specific 863 example is that traffic originating from a browser may benefit from 864 QoS service differentiation in within-building and residential access 865 networks, even if the DSCP marking is subsequently removed or 866 simplified. This is because such networks and the boundaries between 867 them are likely traffic bottleneck locations (e.g., due to customer 868 aggregation onto common links and/or speed differences among links 869 used by the same traffic). 871 7. 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 enable 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. See 894 Section 3.3.2.1 of [RFC6274] for related discussion of DSCP security 895 considerations. 897 Use of multiple DSCPs to provide differentiated QoS service may 898 reveal information about the encrypted traffic to which different 899 service levels are provided. For example, DSCP-based identification 900 of RTP streams combined with packet frequency and packet size could 901 reveal the type or nature of the encrypted source streams. The IP 902 header used for forwarding has to be unencrypted for obvious reasons, 903 and the DSCP likewise has to be unencrypted to enable different IP 904 forwarding behaviors to be applied to different packets. The nature 905 of encrypted traffic components can be disguised via encrypted dummy 906 data padding and encrypted dummy packets, e.g., see the discussion of 907 traffic flow confidentiality in [RFC4303]. Encrypted dummy packets 908 could even be added in a fashion that an observer of the overall 909 encrypted traffic might mistake for another encrypted RTP stream. 911 8. IANA Considerations 913 This memo includes no request to IANA. 915 9. Acknowledgements 917 This memo is the result of many conversations that have occurred 918 within the dart working group and other working groups in the RAI and 919 Transport areas. Many thanks to Aamer Akhter, Harald Alvestrand, 920 Fred Baker, Erin Bournival, Richard Barnes, Ben Campbell, Brian 921 Carpenter, Spencer Dawkins, Keith Drage, Gorry Fairhurst, Ruediger 922 Geib, Cullen Jennings, Jonathan Lennox, Karen Nielsen, Colin Perkins, 923 James Polk, Robert Sparks, Tina Tsou, Michael Welzl, Dan York and the 924 dart WG participants for their reviews and comments. 926 10. References 928 10.1. Normative References 930 [I-D.ietf-avtext-rtp-grouping-taxonomy] 931 Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, 932 "A Taxonomy of Grouping Semantics and Mechanisms for Real- 933 Time Transport Protocol (RTP) Sources", draft-ietf-avtext- 934 rtp-grouping-taxonomy-02 (work in progress), June 2014. 936 [I-D.ietf-tcpm-tcp-rfc4614bis] 937 Duke, M., Braden, R., Eddy, W., Blanton, E., and A. 938 Zimmermann, "A Roadmap for Transmission Control Protocol 939 (TCP) Specification Documents", draft-ietf-tcpm-tcp- 940 rfc4614bis-08 (work in progress), August 2014. 942 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 943 August 1980. 945 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 946 "Definition of the Differentiated Services Field (DS 947 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 948 1998. 950 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 951 and W. Weiss, "An Architecture for Differentiated 952 Services", RFC 2475, December 1998. 954 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 955 "Assured Forwarding PHB Group", RFC 2597, June 1999. 957 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 958 J., Courtney, W., Davari, S., Firoiu, V., and D. 959 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 960 Behavior)", RFC 3246, March 2002. 962 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 963 Jacobson, "RTP: A Transport Protocol for Real-Time 964 Applications", STD 64, RFC 3550, July 2003. 966 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 967 Per-Domain Behavior (PDB) for Differentiated Services", 968 RFC 3662, December 2003. 970 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 971 G. Fairhurst, "The Lightweight User Datagram Protocol 972 (UDP-Lite)", RFC 3828, July 2004. 974 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 975 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 977 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 978 4960, September 2007. 980 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 981 for Application Designers", BCP 145, RFC 5405, November 982 2008. 984 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 985 Services Code Point (DSCP) for Capacity-Admitted Traffic", 986 RFC 5865, May 2010. 988 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 989 Control Transmission Protocol (SCTP) Packets for End-Host 990 to End-Host Communication", RFC 6951, May 2013. 992 10.2. Informative References 994 [H.221] ITU-T, "Recommendation H.221: Frame structure for a 64 to 995 1920 kbit/s channel in audiovisual teleservices", March 996 2009. 998 [H.264] ITU-T, "Recommendation H.264: Advanced video coding for 999 generic audiovisual services", February 2014. 1001 [I-D.geib-tsvwg-diffserv-intercon] 1002 Geib, R. and D. Black, "DiffServ interconnection classes 1003 and practice", draft-geib-tsvwg-diffserv-intercon-07 (work 1004 in progress), October 2014. 1006 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1007 Holmberg, C., Alvestrand, H., and C. Jennings, 1008 "Negotiating Media Multiplexing Using the Session 1009 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1010 negotiation-12 (work in progress), October 2014. 1012 [I-D.ietf-rmcat-cc-requirements] 1013 Jesup, R. and Z. Sarker, "Congestion Control Requirements 1014 for Interactive Real-Time Media", draft-ietf-rmcat-cc- 1015 requirements-07 (work in progress), October 2014. 1017 [I-D.ietf-rtcweb-data-channel] 1018 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 1019 Channels", draft-ietf-rtcweb-data-channel-12 (work in 1020 progress), September 2014. 1022 [I-D.ietf-rtcweb-overview] 1023 Alvestrand, H., "Overview: Real Time Protocols for 1024 Browser-based Applications", draft-ietf-rtcweb-overview-12 1025 (work in progress), October 2014. 1027 [I-D.ietf-rtcweb-rtp-usage] 1028 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 1029 Communication (WebRTC): Media Transport and Use of RTP", 1030 draft-ietf-rtcweb-rtp-usage-19 (work in progress), October 1031 2014. 1033 [I-D.ietf-rtcweb-transports] 1034 Alvestrand, H., "Transports for WebRTC", draft-ietf- 1035 rtcweb-transports-07 (work in progress), October 2014. 1037 [I-D.petithuguenin-avtcore-rfc5764-mux-fixes] 1038 Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme 1039 Updates for Secure Real-time Transport Protocol (SRTP) 1040 Extension for Datagram Transport Layer Security (DTLS)", 1041 draft-petithuguenin-avtcore-rfc5764-mux-fixes-01 (work in 1042 progress), October 2014. 1044 [I-D.welzl-rmcat-coupled-cc] 1045 Welzl, M., Islam, S., and S. Gjessing, "Coupled congestion 1046 control for RTP media", draft-welzl-rmcat-coupled-cc-04 1047 (work in progress), October 2014. 1049 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 1050 Marker", RFC 2697, September 1999. 1052 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 1053 Marker", RFC 2698, September 1999. 1055 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 1056 2914, September 2000. 1058 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1059 of Explicit Congestion Notification (ECN) to IP", RFC 1060 3168, September 2001. 1062 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 1063 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 1064 Protocol Label Switching (MPLS) Support of Differentiated 1065 Services", RFC 3270, May 2002. 1067 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 1068 Conversation", RFC 4103, June 2005. 1070 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 1071 4303, December 2005. 1073 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1074 Description Protocol", RFC 4566, July 2006. 1076 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 1077 Guidelines for DiffServ Service Classes", RFC 4594, August 1078 2006. 1080 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 1081 Correction", RFC 5109, December 2007. 1083 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 1084 Diffserv Service Classes", RFC 5127, February 2008. 1086 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 1087 Marking in MPLS", RFC 5129, January 2008. 1089 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1090 (ICE): A Protocol for Network Address Translator (NAT) 1091 Traversal for Offer/Answer Protocols", RFC 5245, April 1092 2010. 1094 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1095 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1096 October 2008. 1098 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 1099 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 1100 Class" Field", RFC 5462, February 2009. 1102 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1103 Control Packets on a Single Port", RFC 5761, April 2010. 1105 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1106 Security (DTLS) Extension to Establish Keys for the Secure 1107 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1109 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1110 Relays around NAT (TURN): Relay Extensions to Session 1111 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 1113 [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays 1114 around NAT (TURN) Extensions for TCP Allocations", RFC 1115 6062, November 2010. 1117 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 1118 Version 4", RFC 6274, July 2011. 1120 [RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., 1121 Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding 1122 Guide", RFC 6386, November 2011. 1124 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1125 "IPv6 Flow Label Specification", RFC 6437, November 2011. 1127 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 1128 Yasevich, "Sockets API Extensions for the Stream Control 1129 Transmission Protocol (SCTP)", RFC 6458, December 2011. 1131 [W3C.WD-mediacapture-streams-20130903] 1132 Burnett, D., Bergkvist, A., Jennings, C., and A. 1133 Narayanan, "Media Capture and Streams", World Wide Web 1134 Consortium WD WD-mediacapture-streams-20130903, September 1135 2013, . 1138 Appendix A. Change History 1140 [To be removed before RFC publication.] 1142 Changes from draft-ietf-dart-dscp-rtp-00 to -01: 1144 o Merge the two TCP/SCTP guideline bullets. 1146 o Add DCCP and UDP-Lite material, plus reference to RFC 5405 for UDP 1147 (and UDP-Lite) usage guidelines. 1149 o Add "attack surface" security consideration. 1151 o Many editorial changes. 1153 o More references, and moved some references to normative. 1155 Changes from draft-ietf-dart-dscp-rtp-01 to -02: 1157 o Reorganize text for better topic flow and make related edits. 1159 Changes from draft-ietf-dart-dscp-rtp-02 to -03: 1161 o Correct text on treatment of excess EF traffic to indicate that 1162 excess traffic is dropped. 1164 o Say that transport protocol design and implementation guidance is 1165 not provided on use of multiple DSCPs and PHBs in a single 1166 transport protocol connection or association. 1168 o RTCWEB -> WebRTC, and correct problems in descriptions of how it 1169 uses multiplexing. 1171 o Fix DCCP congestion control discussion and text on coupled 1172 congestion controllers. 1174 o Strengthen text on what happens when TURN selects TCP for NAT 1175 traversal. 1177 o Note open issue on how to mark RTCP traffic. 1179 o Many editorial changes. 1181 Changes from draft-ietf-dart-dscp-rtp-03 to -04: 1183 o Add abstract/intro text on SDP bundle usage, e.g., by WebRTC 1185 o Remove erroneous use of SSRC w/source stream in Section 2.1 1186 o Add text on WebRTC data channel examples 1188 o Add text on transport protocol complexities that would be 1189 necessary to deal with multiple QoS levels in same protocol 1190 connection or association 1192 o Additional minor edits. 1194 Changes from draft-ietf-dart-dscp-rtp-04 to -05: 1196 o Rewrite RTCP text and guidelines, including new section 5.4. 1198 o Use "SSRC" as term for sender of RTP stream. 1200 o Additional minor edits. 1202 Changes from draft-ietf-dart-dscp-rtp-05 to -06: 1204 o Remove RTCP multi-stream optimization material - interaction of 1205 that with DiffServ will be covered in the multi-stream 1206 optimisation draft if/as appropriate. 1208 o Additional minor edits. 1210 Changes from draft-ietf-dart-dscp-rtp-06 to -07: 1212 o Revise RTCP RTT discussion in section 5.4 to focus on media path 1213 RTT 1215 o Remove pre-WG-adoption history 1217 o Additional minor edits from AD review. 1219 Changes from draft-ietf-dart-dscp-rtp-07 to -08: 1221 o Editorial updates from IETF Last Call 1223 o Add a few more references, including RFC 6274 for DSCP security 1224 considerations. 1226 Changes from draft-ietf-dart-dscp-rtp-08 to -09 & -10: 1228 o Editorial updates from IESG Evaluation 1230 o Update TCP reference. 1232 Authors' Addresses 1234 David Black (editor) 1235 EMC 1236 176 South Street 1237 Hopkinton, MA 01748 1238 USA 1240 Phone: +1 508 293-7953 1241 Email: david.black@emc.com 1243 Paul Jones 1244 Cisco 1245 7025 Kit Creek Road 1246 Research Triangle Park, MA 27502 1247 USA 1249 Phone: +1 919 476 2048 1250 Email: paulej@packetizer.com