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