idnits 2.17.1 draft-ietf-dart-dscp-rtp-08.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 (October 16, 2014) is 3473 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-12 == Outdated reference: A later version (-09) exists of draft-ietf-rmcat-cc-requirements-06 == 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-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: April 19, 2015 Cisco 6 October 16, 2014 8 Differentiated Services (DiffServ) and Real-time Communication 9 draft-ietf-dart-dscp-rtp-08 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 (e.g., reordering) have 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 April 19, 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. 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 . . . . . . . . . . . . . . . . . . . . . . . 26 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 (e.g., reordering) have 104 transport protocol interactions, particularly with congestion control 105 functionality. In addition, DSCP markings may be changed or removed 106 between the traffic source and destination. This memo covers the 107 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) may also be 207 used. Transport protocols other than UDP or UDP-Lite may also be 208 used to transmit real-time data or near-real-time data. For example, 209 SCTP [RFC4960] can be utilized to carry application sharing or 210 whiteboarding information as part of an overall interaction that 211 includes real-time media. These additional transport protocols can 212 be multiplexed with an RTP session via UDP encapsulation, thereby 213 using a single pair of UDP ports. 215 The WebRTC protocol suite encompasses a number of forms of 216 multiplexing: 218 1. Individual source streams are carried in one or more individual 219 RTP streams. These RTP streams can be multiplexed onto a single 220 transport-layer flow or sent as separate transport-layer flows. 221 This memo only considers the case where the RTP streams are to be 222 multiplexed onto a single transport-layer flow, forming a single 223 RTP session as described in [RFC3550]; 225 2. The RTP Control Protocol (RTCP) (see [RFC3550]) may be 226 multiplexed onto the same transport-layer flow as the RTP streams 227 with which it is associated, as described in [RFC5761] or it may 228 be sent on a separate transport-layer flow; 230 3. An RTP session could be multiplexed with a single SCTP 231 association over DTLS and with both STUN [RFC5389] and TURN 232 [RFC5766] traffic into a single transport-layer flow as described 233 in [RFC5764] with the updates in 234 [I-D.petithuguenin-avtcore-rfc5764-mux-fixes]. The STUN 235 [RFC5389] and TURN [RFC5766] protocols provide NAT/FW (Network 236 Address Translator / Firewall) traversal and port mapping. 238 The resulting transport layer flow is identified by a network 239 5-tuple, i.e., a combination of two IP addresses (source and 240 destination), two ports (source and destination), and the transport 241 protocol used (e.g., UDP). SDP bundle negotiation restrictions 242 [I-D.ietf-mmusic-sdp-bundle-negotiation] limit WebRTC to using at 243 most a single DTLS session per network 5-tuple. In contrast to 244 WebRTC use of a single SCTP association with DTLS, multiple SCTP 245 associations can be directly multiplexed over a single UDP 5-tuple as 246 specified in [RFC6951]. 248 The STUN and TURN protocols were originally designed for use of UDP, 249 however, TURN has been extended to use TCP as a transport for 250 situations in which UDP does not work [RFC6062]. When TURN selects 251 use of TCP, the entire real-time communications session is carried 252 over a single TCP connection (i.e., 5-tuple). 254 For IPv6, addition of the flow label [RFC6437] to network 5-tuples 255 results in network 6-tuples (or 7-tuples for bidirectional flows), 256 but in practice, use of a flow label is unlikely to result in a 257 finer-grain traffic subset than the corresponding network 5-tuple 258 (e.g., the flow label is likely to represent the combination of two 259 ports with use of the UDP protocol). For that reason, discussion in 260 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 A network endpoint cannot rely upon different class selector 391 codepoints providing differentiated services via assignment to 392 different PHBs, as adjacent class selector codepoints may use the 393 same pool of resources on each network node in some networks. 394 This generalizes to ranges of class selector codepoints, but with 395 limits - for example CS6 and CS7 are often used for network 396 control (e.g., routing) traffic [RFC4594] and hence are likely to 397 provide better forwarding behavior under network load to 398 prioritize network recovery from disruptions. There is no 399 effective way for a network endpoint to determine which PHBs are 400 selected by the class selector codepoints on a specific network, 401 let alone end-to-end. 403 o CS1 ('001000') was subsequently designated as the recommended 404 codepoint for the Lower Effort (LE) PHB [RFC3662]. An LE service 405 forwards traffic with "lower" priority than best effort and can be 406 "starved" by best effort and other "higher" priority traffic. Not 407 all networks offer an LE service, hence traffic marked with the 408 CS1 DSCP may not receive lower effort forwarding; such traffic may 409 be forwarded with a different PHB (e.g., the Default PHB), 410 remarked to another DSCP (e.g., CS0) and forwarded accordingly, or 411 dropped. A network endpoint cannot rely upon the presence of an 412 LE service that is selected by the CS1 DSCP on a specific network, 413 let alone end-to-end. Packets marked with the CS1 DSCP may be 414 forwarded with best effort service or another "higher" priority 415 service; see [RFC2474]. See [RFC3662] for further discussion of 416 the LE PHB and service. 418 3.1. Diffserv PHBs (Per-Hop Behaviors) 420 Although Differentiated Services is a general architecture that may 421 be used to implement a variety of services, three fundamental 422 forwarding behaviors (PHBs) have been defined and characterized for 423 general use. These are: 425 1. Default Forwarding (DF) for elastic traffic [RFC2474]. The 426 Default PHB is always selected by the all-zero DSCP and provides 427 best-effort forwarding. 429 2. Assured Forwarding (AF) [RFC2597] to provide differentiated 430 service to elastic traffic. Each instance of the AF behavior 431 consists of three PHBs that differ only in drop precedence, e.g., 432 AF11, AF12 and AF13; such a set of three AF PHBs is referred to 433 as an AF class, e.g., AF1x. There are four defined AF classes, 434 AF1x through AF4x, with higher numbered classes intended to 435 receive better forwarding treatment than lower numbered classes. 436 Use of multiple PHBs from a single AF class (e.g., AF1x) does not 437 enable network traffic reordering within a single network 438 5-tuple, although such reordering may occur for other transient 439 reasons (e.g., routing changes or ECMP rebalancing). 441 3. Expedited Forwarding (EF) [RFC3246] intended for inelastic 442 traffic. Beyond the basic EF PHB, the VOICE-ADMIT PHB [RFC5865] 443 is an admission controlled variant of the EF PHB. Both of these 444 PHBs are based on pre-configured limited forwarding capacity; 445 traffic in excess of that capacity is expected to be dropped. 447 3.2. Traffic Classifiers and DSCP Remarking 449 DSCP markings are not end-to-end in general. Each network can make 450 its own decisions about what PHBs to use and which DSCP maps to each 451 PHB. While every PHB specification includes a recommended DSCP, and 452 RFC 4594 [RFC4594] recommends their end-to-end usage, there is no 453 requirement that every network support any PHBs or use any specific 454 DSCPs, with the exception of the support requirements for the class 455 selector codepoints (see RFC 2474 [RFC2474]). When DiffServ is used, 456 the edge or boundary nodes of a network are responsible for ensuring 457 that all traffic entering that network conforms to that network's 458 policies for DSCP and PHB usage, and such nodes may change DSCP 459 markings on traffic to achieve that result. As a result, DSCP 460 remarking is possible at any network boundary, including the first 461 network node that traffic sent by a host encounters. Remarking is 462 also possible within a network, e.g., for traffic shaping. 464 DSCP remarking is part of traffic conditioning; the traffic 465 conditioning functionality applied to packets at a network node is 466 determined by a traffic classifier [RFC2475]. Edge nodes of a 467 DiffServ network classify traffic based on selected packet header 468 fields; typical implementations do not look beyond the traffic's 469 network 5-tuple in the IP and transport protocol headers (e.g., for 470 SCTP or RTP enapsulated in UDP, header-based classification is 471 unlikely to look beyond the outer UDP header). As a result, when 472 multiple DSCPs are used for traffic that shares a network 5-tuple, 473 remarking at a network boundary may result in all of the traffic 474 being forwarded with a single DSCP, thereby removing any 475 differentiation within the network 5-tuple downstream of the 476 remarking location. Network nodes within a DiffServ network 477 generally classify traffic based solely on DSCPs, but may perform 478 finer grain traffic conditioning similar to that performed by edge 479 nodes. 481 So, for two arbitrary network endpoints, there can be no assurance 482 that the DSCP set at the source endpoint will be preserved and 483 presented at the destination endpoint. Rather, it is quite likely 484 that the DSCP will be set to zero (e.g., at the boundary of a network 485 operator that distrusts or does not use the DSCP field) or to a value 486 deemed suitable by an ingress classifier for whatever network 5-tuple 487 it carries. 489 In addition, remarking may remove application-level distinctions in 490 forwarding behavior - e.g., if multiple PHBs within an AF class are 491 used to distinguish different types of frames within a video RTP 492 stream, token-bucket-based remarkers operating in Color-Blind mode 493 (see [RFC2697] and [RFC2698] for examples) may remark solely based on 494 flow rate and burst behavior, removing the drop precedence 495 distinctions specified by the source. 497 Backbone and other carrier networks may employ a small number of 498 DSCPs (e.g., less than half a dozen) to manage a small number of 499 traffic aggregates; hosts that use a larger number of DSCPs can 500 expect to find that much of their intended differentiation is removed 501 by such networks. Better results may be achieved when DSCPs are used 502 to spread traffic among a smaller number of DiffServ-based traffic 503 subsets or aggregates; see [I-D.geib-tsvwg-diffserv-intercon] for one 504 proposal. This is of particular importance for MPLS-based networks 505 due to the limited size of the Traffic Class (TC) field in an MPLS 506 label [RFC5462] that is used to carry DiffServ information and the 507 use of that TC field for other purposes, e.g., ECN [RFC5129]. For 508 further discussion on use of DiffServ with MPLS, see [RFC3270] and 509 [RFC5127]. 511 4. Examples 513 For real-time communications, one might want to mark the audio 514 packets using EF and the video packets as AF41. However, in a video 515 conference receiving the audio packets significantly ahead of the 516 video is not useful because lip sync is necessary between audio and 517 video. It may still be desirable to send audio with a PHB that 518 provides better service, because more reliable arrival of audio helps 519 assure smooth audio rendering, which is often more important than 520 fully faithful video rendering. There are also limits, as some 521 devices have difficulties in synchronizing voice and video when 522 packets that need to be rendered together arrive at significantly 523 different times. It makes more sense to use different PHBs when the 524 audio and video source streams do not share a strict timing 525 relationship. For example, video content may be shared within a 526 video conference via playback, perhaps of an unedited video clip that 527 is intended to become part of a television advertisement. Such 528 content sharing video does not need precise synchronization with 529 video conference audio, and could use a different PHB, as content 530 sharing video is more tolerant to jitter, loss, and delay. 532 Within a layered video RTP stream, ordering of frame communication is 533 preferred, but importance of frame types varies, making use of PHBs 534 with different drop precedences appropriate. For example, I-frames 535 that contain an entire image are usually more important than P-frames 536 that contain only changes from the previous image because loss of a 537 P-frame (or part thereof) can be recovered (at the latest) via the 538 next I-frame, whereas loss of an I-frame (or part thereof) may cause 539 rendering problems for all of the P-frames that depend on the missing 540 I-frame. For this reason, it is appropriate to mark I-frame packets 541 with a PHB that has lower drop precedence than the PHB used for 542 P-frames, as long as the PHBs preserve ordering among frames (e.g., 543 are in a single AF class) - AF41 for I-frames and AF43 for P-frames 544 is one possibility. Additional spatial and temporal layers beyond 545 the base video layer could also be marked with higher drop precedence 546 than the base video layer, as their loss reduces video quality, but 547 does not disrupt video rendering. 549 Additional RTP streams in a real-time communication interaction could 550 be marked with CS0 and carried as best effort traffic. One example 551 is real-time text transmitted as specified in RFC 4103 [RFC4103]. 552 Best effort forwarding suffices because such real-time text has loose 553 timing requirements; RFC 4103 recommends sending text in chunks every 554 300ms. Such text is technically real-time, but does not need a PHB 555 promising better service than best effort, in contrast to audio or 556 video. 558 A WebRTC application may use one or more RTP streams, as discussed 559 above. In addition, it may use an SCTP-based data channel 560 [I-D.ietf-rtcweb-data-channel] whose QoS treatment depends on the 561 nature of the application. For example, best effort treatment of 562 data channels is likely to suffice for messaging, shared white board, 563 and guided browsing applications, whereas latency-sensitive games 564 might desire better QoS for their data channels. 566 5. DiffServ Interactions 568 5.1. DiffServ, Reordering and Transport Protocols 570 Transport protocols provide data communication behaviors beyond those 571 possible at the IP layer. An important example is that TCP [RFC0793] 572 provides reliable in-order delivery of data with congestion control. 574 SCTP [RFC4960] provides additional properties such as preservation of 575 message boundaries, and the ability to avoid head-of-line blocking 576 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. 861 Nonetheless, it is useful for applications and other traffic sources 862 to provide finer granularity DSCP marking on packets for the benefit 863 of networks that offer QoS service differentiation. A specific 864 example is that traffic originating from a browser may benefit from 865 QoS service differentiation in within-building and residential access 866 networks, even if the DSCP marking is subsequently removed or 867 simplified. This is because such networks and the boundaries between 868 them are likely traffic bottleneck locations (e.g., due to customer 869 aggregation onto common links and/or speed differences among links 870 used by the same traffic). 872 7. Security Considerations 874 The security considerations for all of the technologies discussed in 875 this memo apply; in particular see the security considerations for 876 RTP in [RFC3550] and DiffServ in [RFC2474] and[RFC2475]. 878 Multiplexing of multiple protocols onto a single UDP 5-tuple via 879 encapsulation has implications for network functionality that 880 monitors or inspects individual protocol flows, e.g., firewalls and 881 traffic monitoring systems. When implementations of such 882 functionality lack visibility into encapsulated traffic (likely for 883 many current implementations), it may be difficult or impossible to 884 apply network security policy and associated controls at a finer 885 granularity than the overall UDP 5-tuple. 887 Use of multiple DSCPs that enable reordering within an overall real- 888 time communication interaction enlarges the set of network forwarding 889 resources used by that interaction, thereby increasing exposure to 890 resource depletion or failure, independent of whether the underlying 891 cause is benign or malicious. This represents an increase in the 892 effective attack surface of the interaction, and is a consideration 893 in selecting an appropriate degree of QoS differentiation among the 894 components of the real-time communication interaction. See 895 Section 3.3.2.1 of [RFC6274] for related discussion of DSCP security 896 considerations. 898 Use of multiple DSCPs to provide differentiated QoS service may 899 reveal information about the encrypted traffic to which different 900 service levels are provided. For example, DSCP-based identification 901 of RTP streams combined with packet frequency and packet size could 902 reveal the type or nature of the encrypted source streams. The IP 903 header used for forwarding has to be unencrypted for obvious reasons, 904 and the DSCP likewise has to be unencrypted to enable different IP 905 forwarding behaviors to be applied to different packets. The nature 906 of encrypted traffic components can be disguised via encrypted dummy 907 data padding and encrypted dummy packets, e.g., see the discussion of 908 traffic flow confidentiality in [RFC4303]. Encrypted dummy packets 909 could even be added in a fashion that an observer of the overall 910 encrypted traffic might mistake for another encrypted RTP stream. 912 8. IANA Considerations 914 This memo includes no request to IANA. 916 9. Acknowledgements 918 This memo is the result of many conversations that have occurred 919 within the dart working group and other working groups in the RAI and 920 Transport areas. Many thanks to Aamer Akhter, Harald Alvestrand, 921 Fred Baker, Erin Bournival, Richard Barnes, Ben Campbell, Brian 922 Carpenter, Keith Drage, Gorry Fairhurst, Ruediger Geib, Cullen 923 Jennings, Jonathan Lennox, Karen Nielsen, Colin Perkins, James Polk, 924 Robert Sparks, Tina Tsou, Michael Welzl, Dan York and the dart WG 925 participants for their reviews and comments. 927 10. References 929 10.1. Normative References 931 [I-D.ietf-avtext-rtp-grouping-taxonomy] 932 Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, 933 "A Taxonomy of Grouping Semantics and Mechanisms for Real- 934 Time Transport Protocol (RTP) Sources", draft-ietf-avtext- 935 rtp-grouping-taxonomy-02 (work in progress), June 2014. 937 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 938 August 1980. 940 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 941 793, September 1981. 943 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 944 "Definition of the Differentiated Services Field (DS 945 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 946 1998. 948 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 949 and W. Weiss, "An Architecture for Differentiated 950 Services", RFC 2475, December 1998. 952 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 953 "Assured Forwarding PHB Group", RFC 2597, June 1999. 955 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 956 J., Courtney, W., Davari, S., Firoiu, V., and D. 957 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 958 Behavior)", RFC 3246, March 2002. 960 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 961 Jacobson, "RTP: A Transport Protocol for Real-Time 962 Applications", STD 64, RFC 3550, July 2003. 964 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 965 Per-Domain Behavior (PDB) for Differentiated Services", 966 RFC 3662, December 2003. 968 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 969 G. Fairhurst, "The Lightweight User Datagram Protocol 970 (UDP-Lite)", RFC 3828, July 2004. 972 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 973 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 975 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 976 4960, September 2007. 978 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 979 for Application Designers", BCP 145, RFC 5405, November 980 2008. 982 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 983 Services Code Point (DSCP) for Capacity-Admitted Traffic", 984 RFC 5865, May 2010. 986 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 987 Control Transmission Protocol (SCTP) Packets for End-Host 988 to End-Host Communication", RFC 6951, May 2013. 990 10.2. Informative References 992 [H.221] ITU-T, "Recommendation H.221: Frame structure for a 64 to 993 1920 kbit/s channel in audiovisual teleservices", March 994 2009. 996 [H.264] ITU-T, "Recommendation H.264: Advanced video coding for 997 generic audiovisual services", February 2014. 999 [I-D.geib-tsvwg-diffserv-intercon] 1000 Geib, R., "DiffServ interconnection classes and practice", 1001 draft-geib-tsvwg-diffserv-intercon-06 (work in progress), 1002 July 2014. 1004 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1005 Holmberg, C., Alvestrand, H., and C. Jennings, 1006 "Negotiating Media Multiplexing Using the Session 1007 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1008 negotiation-12 (work in progress), October 2014. 1010 [I-D.ietf-rmcat-cc-requirements] 1011 Jesup, R., "Congestion Control Requirements For RMCAT", 1012 draft-ietf-rmcat-cc-requirements-06 (work in progress), 1013 October 2014. 1015 [I-D.ietf-rtcweb-data-channel] 1016 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 1017 Channels", draft-ietf-rtcweb-data-channel-12 (work in 1018 progress), September 2014. 1020 [I-D.ietf-rtcweb-overview] 1021 Alvestrand, H., "Overview: Real Time Protocols for 1022 Browser-based Applications", draft-ietf-rtcweb-overview-12 1023 (work in progress), October 2014. 1025 [I-D.ietf-rtcweb-rtp-usage] 1026 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 1027 Communication (WebRTC): Media Transport and Use of RTP", 1028 draft-ietf-rtcweb-rtp-usage-17 (work in progress), August 1029 2014. 1031 [I-D.ietf-rtcweb-transports] 1032 Alvestrand, H., "Transports for WebRTC", draft-ietf- 1033 rtcweb-transports-06 (work in progress), August 2014. 1035 [I-D.petithuguenin-avtcore-rfc5764-mux-fixes] 1036 Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme 1037 Updates for Secure Real-time Transport Protocol (SRTP) 1038 Extension for Datagram Transport Layer Security (DTLS)", 1039 draft-petithuguenin-avtcore-rfc5764-mux-fixes-00 (work in 1040 progress), July 2014. 1042 [I-D.welzl-rmcat-coupled-cc] 1043 Welzl, M., Islam, S., and S. Gjessing, "Coupled congestion 1044 control for RTP media", draft-welzl-rmcat-coupled-cc-03 1045 (work in progress), May 2014. 1047 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 1048 Marker", RFC 2697, September 1999. 1050 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 1051 Marker", RFC 2698, September 1999. 1053 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 1054 2914, September 2000. 1056 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1057 of Explicit Congestion Notification (ECN) to IP", RFC 1058 3168, September 2001. 1060 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 1061 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 1062 Protocol Label Switching (MPLS) Support of Differentiated 1063 Services", RFC 3270, May 2002. 1065 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 1066 Conversation", RFC 4103, June 2005. 1068 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 1069 4303, December 2005. 1071 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1072 Description Protocol", RFC 4566, July 2006. 1074 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 1075 Guidelines for DiffServ Service Classes", RFC 4594, August 1076 2006. 1078 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 1079 Correction", RFC 5109, December 2007. 1081 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 1082 Diffserv Service Classes", RFC 5127, February 2008. 1084 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 1085 Marking in MPLS", RFC 5129, January 2008. 1087 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1088 (ICE): A Protocol for Network Address Translator (NAT) 1089 Traversal for Offer/Answer Protocols", RFC 5245, April 1090 2010. 1092 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1093 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1094 October 2008. 1096 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 1097 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 1098 Class" Field", RFC 5462, February 2009. 1100 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1101 Control Packets on a Single Port", RFC 5761, April 2010. 1103 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1104 Security (DTLS) Extension to Establish Keys for the Secure 1105 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1107 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1108 Relays around NAT (TURN): Relay Extensions to Session 1109 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 1111 [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays 1112 around NAT (TURN) Extensions for TCP Allocations", RFC 1113 6062, November 2010. 1115 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 1116 Version 4", RFC 6274, July 2011. 1118 [RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., 1119 Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding 1120 Guide", RFC 6386, November 2011. 1122 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1123 "IPv6 Flow Label Specification", RFC 6437, November 2011. 1125 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 1126 Yasevich, "Sockets API Extensions for the Stream Control 1127 Transmission Protocol (SCTP)", RFC 6458, December 2011. 1129 [W3C.WD-mediacapture-streams-20130903] 1130 Burnett, D., Bergkvist, A., Jennings, C., and A. 1131 Narayanan, "Media Capture and Streams", World Wide Web 1132 Consortium WD WD-mediacapture-streams-20130903, September 1133 2013, . 1136 Appendix A. Change History 1138 [To be removed before RFC publication.] 1140 Changes from draft-ietf-dart-dscp-rtp-00 to -01: 1142 o Merge the two TCP/SCTP guideline bullets. 1144 o Add DCCP and UDP-Lite material, plus reference to RFC 5405 for UDP 1145 (and UDP-Lite) usage guidelines. 1147 o Add "attack surface" security consideration. 1149 o Many editorial changes. 1151 o More references, and moved some references to normative. 1153 Changes from draft-ietf-dart-dscp-rtp-01 to -02: 1155 o Reorganize text for better topic flow and make related edits. 1157 Changes from draft-ietf-dart-dscp-rtp-02 to -03: 1159 o Correct text on treatment of excess EF traffic to indicate that 1160 excess traffic is dropped. 1162 o Say that transport protocol design and implementation guidance is 1163 not provided on use of multiple DSCPs and PHBs in a single 1164 transport protocol connection or association. 1166 o RTCWEB -> WebRTC, and correct problems in descriptions of how it 1167 uses multiplexing. 1169 o Fix DCCP congestion control discussion and text on coupled 1170 congestion controllers. 1172 o Strengthen text on what happens when TURN selects TCP for NAT 1173 traversal. 1175 o Note open issue on how to mark RTCP traffic. 1177 o Many editorial changes. 1179 Changes from draft-ietf-dart-dscp-rtp-03 to -04: 1181 o Add abstract/intro text on SDP bundle usage, e.g., by WebRTC 1183 o Remove erroneous use of SSRC w/source stream in Section 2.1 1185 o Add text on WebRTC data channel examples 1187 o Add text on transport protocol complexities that would be 1188 necessary to deal with multiple QoS levels in same protocol 1189 connection or association 1191 o Additional minor edits. 1193 Changes from draft-ietf-dart-dscp-rtp-04 to -05: 1195 o Rewrite RTCP text and guidelines, including new section 5.4. 1197 o Use "SSRC" as term for sender of RTP stream. 1199 o Additional minor edits. 1201 Changes from draft-ietf-dart-dscp-rtp-05 to -06: 1203 o Remove RTCP multi-stream optimization material - interaction of 1204 that with DiffServ will be covered in the multi-stream 1205 optimisation draft if/as appropriate. 1207 o Additional minor edits. 1209 Changes from draft-ietf-dart-dscp-rtp-06 to -07: 1211 o Revise RTCP RTT discussion in section 5.4 to focus on media path 1212 RTT 1214 o Remove pre-WG-adoption history 1216 o Additional minor edits from AD review. 1218 Changes from draft-ietf-dart-dscp-rtp-07 to -08: 1220 o Editorial updates from IETF Last Call 1222 o Add a few more references, including RFC 6274 for DSCP security 1223 considerations. 1225 Authors' Addresses 1227 David Black (editor) 1228 EMC 1229 176 South Street 1230 Hopkinton, MA 01748 1231 USA 1233 Phone: +1 508 293-7953 1234 Email: david.black@emc.com 1236 Paul Jones 1237 Cisco 1238 7025 Kit Creek Road 1239 Research Triangle Park, MA 27502 1240 USA 1242 Phone: +1 919 476 2048 1243 Email: paulej@packetizer.com