idnits 2.17.1 draft-ietf-dart-dscp-rtp-01.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 8, 2014) is 3549 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 == Outdated reference: A later version (-02) exists of draft-petithuguenin-avtcore-rfc5764-mux-fixes-00 ** 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 (-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 9, 2015 Cisco 6 August 8, 2014 8 Differentiated Services (DiffServ) and Real-time Communication 9 draft-ietf-dart-dscp-rtp-01 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 RTCWEB. 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 9, 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. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. RTP Background . . . . . . . . . . . . . . . . . . . . . 3 63 2.2. Differentiated Services (DiffServ) Background . . . . . . 6 64 2.3. Diffserv PHBs (Per-Hop Behaviors) . . . . . . . . . . . . 8 65 2.4. DiffServ, Reordering and Transport Protocols . . . . . . 8 66 2.5. DiffServ, Reordering and Real-Time Communication . . . . 10 67 2.6. Drop Precedence . . . . . . . . . . . . . . . . . . . . . 11 68 2.7. Traffic Classifiers and DSCP Remarking . . . . . . . . . 12 69 3. RTP Multiplexing Background . . . . . . . . . . . . . . . . . 13 70 4. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 77 9.2. Informative References . . . . . . . . . . . . . . . . . 20 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 80 1. Introduction 82 This document describes the interactions between Differentiated 83 Services (DiffServ) network quality of service (QoS) functionality 84 [RFC2475] and real-time network communication, including 85 communication based on the Real-time Transport Protocol (RTP) 86 [RFC3550]. DiffServ is based on network nodes applying different 87 forwarding treatments to packets whose IP headers are marked with 88 different DiffServ Code Points (DSCPs)[RFC2474]. As a result use of 89 different DSCPs within a single traffic stream may cause transport 90 protocol interactions (e.g., reordering). In addition, DSCP markings 91 may be changed or removed between the traffic's source and 92 destination. This document covers the implications of these DiffServ 93 aspects for real-time network communication, including RTCWEB traffic 94 [I-D.ietf-rtcweb-overview]. 96 The document is organized as follows: Sections 2 and 3 provide 97 background, Section 4 provides guidance for DiffServ usage and 98 Section 5 contains examples. Security considerations are discussed 99 in Section 7 (Section 6 is an empty IANA Considerations section). 101 2. Background 103 [Editor's Note: Current section structure skips around topics 104 somewhat. The editor suggests restructuring to put real-time/RTP 105 material first (new section 2, consisting of current sections 2, 2.1 106 and 3), then DiffServ Background (new section 3, consisting of 107 current sections 2.2, 2.3, 2.6 and 2.7, followed by discussion of 108 interactions (new section 4, consisting of current sections 2.4, 2.5 109 and 5) and guidelines (current section 4, renumbered to new section 110 5).] 112 Real-time communications enables communication in real-time over an 113 IP network using voice, video, text, content sharing, etc. It is 114 possible to use one or more of these modalities in parallel to 115 provide a richer communication experience. 117 A simple example of real-time communications is a voice call placed 118 over the Internet wherein an audio stream is transmitted in each 119 direction between two users. A more complex example is an immersive 120 videoconferencing system that has multiple video screens, multiple 121 cameras, multiple microphones, and some means of sharing content. 122 For such complex systems, there may be multiple media streams that 123 may be transmitted via a single IP address and port or via multiple 124 IP addresses and ports. 126 2.1. RTP Background 128 The most common protocol used for real time media is the Real-Time 129 Transport Protocol (RTP) [RFC3550]. RTP defines a common 130 encapsulation format and handling rules for real-time data 131 transmitted over the Internet. Unfortunately, RTP terminology usage 132 has been inconsistent. For example, this document on RTP grouping 133 terminology [I-D.ietf-avtext-rtp-grouping-taxonomy] observes that: 135 RFC 3550 [RFC3550] uses the terms media stream, audio stream, 136 video stream and streams of (RTP) packets interchangeably. 138 Terminology in this document is based on that RTP grouping 139 terminology document with the following terms being of particular 140 importance (see that terminology document for full definitions): 142 Source Stream: A reference clock synchronized, time progressing, 143 digital media stream. 145 RTP Stream: A stream of RTP packets containing media data, which may 146 be source data or redundant data. The RTP Packet Stream is 147 identified by an RTP synchronization source (SSRC) belonging to a 148 particular RTP session. 150 Media encoding and packetization of a source stream results in a 151 source RTP stream plus zero or more redundancy RTP streams that 152 provide resilience against loss of packets from the source RTP stream 153 [I-D.ietf-avtext-rtp-grouping-taxonomy]. Redundancy information may 154 also be carried in the same RTP stream as the encoded source stream, 155 e.g., see Section 7.2 of [RFC5109]. With most applications, a single 156 media type (e.g., audio) is transmitted within a single RTP session. 157 However, it is possible to transmit multiple, distinct source streams 158 over the same RTP session as one or more individual RTP streams. 159 This is referred to as RTP multiplexing. In addition, an RTP stream 160 may contain multiple source streams that use the same reference clock 161 (SSRC), e.g., components or programs in an MPEG Transport Stream 162 [H.222.0]. 164 The number of source streams and RTP streams in an overall real-time 165 interaction can be surprisingly large. In addition to a voice source 166 stream and a video source stream, there could be separate source 167 streams for each of the cameras or microphones on a videoconferencing 168 system. As noted above, there might also be separate redundancy RTP 169 streams that provide protection to a source RTP stream, using 170 techniques such as Forward Error Correction. Another example is 171 simulcast transmission, where a video source stream can be 172 transmitted as high resolution and low resolution RTP streams at the 173 same time. In this case, a media processing function might choose to 174 send one or both RTP streams onward to a receiver based on bandwidth 175 availability or who the active speaker is in a multipoint conference. 176 Lastly, a transmitter might send a the same media content 177 concurrently as two RTP streams using different encodings (e.g., VP8 178 in parallel with H.264) to allow a media processing function to 179 select a media encoding that best matches the capabilities of the 180 receiver. 182 For the RTCWEB protocol suite [I-D.ietf-rtcweb-transports], an 183 individual source stream is a MediaStreamTrack, and a MediaStream 184 contains one or more MediaStreamTracks 185 [W3C.WD-mediacapture-streams-20130903]. A MediaStreamTrack is 186 transmitted as a source RTP stream plus zero or more redundancy RTP 187 streams, so a MediaStream that consists of one MediaStreamTrack is 188 transmitted as a single source RTP stream plus zero or more 189 redundancy RTP streams. For more information on use of RTP in 190 RTCWEB, see [I-D.ietf-rtcweb-rtp-usage]. 192 RTP is usually carried over an Internet Datagram Transport protocol, 193 such as UDP[RFC0768], UDP-Lite [RFC3828] or DCCP [RFC4340]; UDP is 194 most commonly used. Other transport protocols may also be used to 195 transmit real-time data or near-real-time data. For example, SCTP 196 [RFC4960] can be utilized to carry application sharing or 197 whiteboarding information as part of an overall interaction that 198 includes real time media. These additional transport protocols can 199 be multiplexed with an RTP session via UDP encapsulation, thereby 200 using a single pair of UDP ports. 202 The RTCWEB protocol suite encompasses a number of forms of 203 multiplexing: 205 1. Individual source streams are carried in one or more individual 206 RTP streams that can be multiplexed into a single RTP session as 207 described in [RFC3550]; 209 2. RTCP (see [RFC3550]) may be multiplexed with the RTP session as 210 described in [RFC5761]; 212 3. An RTP session could be multiplexed with other protocols via UDP 213 encapsulation over a common pair of UDP ports as described in 214 [RFC5764] as updated by 215 [I-D.petithuguenin-avtcore-rfc5764-mux-fixes]; and 217 4. The data may be further encapsulated via STUN [RFC5389] and TURN 218 [RFC5766] for NAT (Network Address Translator) traversal. 220 The resulting unidirectional UDP packet flow is identified by a 221 5-tuple, i.e., a combination of two IP addresses (source and 222 destination), two UDP ports (source and destination), and the use of 223 the UDP protocol. SDP bundle negotiation restrictions 224 [I-D.ietf-mmusic-sdp-bundle-negotiation] limit RTCWEB to using at 225 most a single DTLS session per UDP 5-tuple. In contrast, multiple 226 SCTP associations can be multiplexed over a single UDP 5-tuple 227 [RFC6951]. 229 For IPv6, addition of the flow label [RFC6437] to 5-tuples results in 230 6-tuples, but in practice, use of a flow label is unlikely to result 231 in a finer-grain traffic subset than the corresponding 5-tuple (e.g., 232 the flow label is likely to represent the combination of two ports 233 with use of the UDP protocol). For that reason, discussion in this 234 draft focuses on UDP 5-tuples. 236 2.2. Differentiated Services (DiffServ) Background 238 The DiffServ architecture [RFC2475][RFC4594] is intended to enable 239 scalable service discrimination in the Internet without requiring 240 each network node to store per-flow state and participate in per-flow 241 signaling. The services may be end-to-end or within a network; they 242 include both those that can satisfy quantitative performance 243 requirements (e.g., peak bandwidth) and those based on relative 244 performance (e.g., "class" differentiation). Services can be 245 constructed by a combination of well-defined building blocks deployed 246 in network nodes that: 248 o classify traffic and set bits in an IP header field at network 249 boundaries or hosts, 251 o use those bits to determine how packets are forwarded by the nodes 252 inside the network, and 254 o condition the marked packets at network boundaries in accordance 255 with the requirements or rules of each service. Traffic 256 conditioning may change the DSCP in a packet (remark it), delay 257 the packet (as a consequence of traffic shaping) or drop the 258 packet (as a consequence of traffic policing). 260 A network node that supports DiffServ includes a classifier that 261 selects packets based on the value of the DS field in IP headers (the 262 DiffServ codepoint or DSCP), along with buffer management and packet 263 scheduling mechanisms capable of delivering the specific packet 264 forwarding treatment indicated by the DS field value. Setting of the 265 DS field and fine-grain conditioning of marked packets need only be 266 performed at network boundaries; internal network nodes operate on 267 traffic aggregates that share a DS field value, or in some cases, a 268 small set of related values. 270 The DiffServ architecture[RFC2475] maintains distinctions among: 272 o the QoS service provided to a traffic aggregate, 274 o the conditioning functions and per-hop behaviors (PHBs) used to 275 realize services, 277 o the DSCP in the IP header used to mark packets to select a per-hop 278 behavior, and 280 o the particular implementation mechanisms that realize a per-hop 281 behavior. 283 This document focuses on PHBs and the usage of DSCPs to obtain those 284 behaviors. In a network node's forwarding path, the DSCP is used to 285 map a packet to a particular forwarding treatment, or per-hop 286 behavior (PHB) that specifies the forwarding treatment. 288 A per-hop behavior (PHB) is a description of the externally 289 observable forwarding behavior of a network node for network traffic 290 marked with a DSCP that selects that PHB. In this context, 291 "forwarding behavior" is a general concept - for example, if only one 292 DSCP is used for all traffic on a link, the observable forwarding 293 behavior (e.g., loss, delay, jitter) will often depend only on the 294 relative loading of the link. To obtain useful behavioral 295 differentiation, multiple traffic subsets are marked with different 296 DSCPs for different PHBs for which node resources such as buffer 297 space and bandwidth are allocated. PHBs provide the framework for a 298 DiffServ network node to allocate resources to traffic subsets, with 299 network-scope differentiated services constructed on top of this 300 basic hop-by-hop resource allocation mechanism. 302 The codepoints (DSCPs) may be chosen from a small set of fixed values 303 (the class selector codepoints), or from a set of recommended values 304 defined in PHB specifications, or from values that have purely local 305 meanings to a specific network that supports DiffServ; in general, 306 packets may be forwarded across multiple such networks between source 307 and destination. 309 The mandatory DSCPs are the class selector code points as specified 310 in [RFC2474]. The class selector codepoints (CS0-CS7) extend the 311 deprecated concept of IP Precedence in the IPv4 header; three bits 312 are added, so that the class selector DSCPs are of the form 'xxx000'. 313 The all-zero DSCP ('000000' or CS0) designates a Default PHB that 314 provides best-effort forwarding behavior and the remaining class 315 selector code points are intended to provide relatively better per- 316 hop-forwarding behavior in increasing numerical order, but: 318 o There is no requirement that any two adjacent class selector 319 codepoints select different PHBs; adjacent class selector 320 codepoints may use the same pool of resources on each network node 321 in some networks. This generalizes to ranges of class selector 322 codepoints, but with limits - for example CS6 and CS7 are often 323 used for network control (e.g., routing) traffic [RFC4594] and 324 hence are likely to provide better forwarding behavior under 325 network load in order to prioritize network recovery from 326 disruptions. 328 o CS1 ('001000') was subsequently designated as the recommended 329 codepoint for the Lower Effort (LE) PHB [RFC3662]. An LE service 330 forwards traffic with "lower" priority than best effort and can be 331 "starved" by best effort and other "higher" priority traffic. Not 332 all networks offer an LE service, hence traffic marked with the 333 CS1 DSCP may not receive lower effort forwarding; such traffic may 334 be forwarded with a different PHB (the Default PHB is likely), 335 remarked to another DSCP (CS0 is likely) and forwarded 336 accordingly, or dropped. See [RFC3662] for further discussion of 337 the LE PHB and service. 339 One cannot rely upon different class selector codepoints providing 340 differentiated services or upon the presence of an LE service that is 341 selected by the CS1 DSCP. There is no effective way for a network 342 endpoint to determine which PHBs are selected by the class selector 343 codepoints or whether the CS1 DSCP selects an LE service on a 344 specific network, let alone end-to-end. Packets marked with the CS1 345 DSCP may be forwarded with best effort service or another "higher" 346 priority service, see [RFC2474]. 348 2.3. Diffserv PHBs (Per-Hop Behaviors) 350 Although Differentiated Services is a general architecture that may 351 be used to implement a variety of services, three fundamental 352 forwarding behaviors (PHBs) have been defined and characterized for 353 general use. These are: 355 1. Default Forwarding (DF) for elastic traffic [RFC2474]. The 356 Default PHB is always selected by the all-zero DSCP and provides 357 best-effort forwarding. 359 2. Assured Forwarding (AF) [RFC2597] to provide differentiated 360 service to elastic traffic. Each instance of the AF behavior 361 consists of three PHBs that differ only in drop precedence, e.g., 362 AF11, AF12 and AF13; such a set of three AF PHBs is referred to 363 as an AF class, e.g., AF1x. There are four defined AF classes, 364 AF1x through AF4x, with higher numbered classes intended to 365 receive better forwarding treatment than lower numbered classes. 367 3. Expedited Forwarding (EF) [RFC3246] intended for inelastic 368 traffic. Beyond the basic EF PHB, the VOICE-ADMIT PHB [RFC5865] 369 is an admission controlled variant of the EF PHB. Both of these 370 PHBs are based on pre-configured limited forwarding capacity; 371 traffic that exceeds that capacity may be shaped, remarked to a 372 different DSCP, or dropped. 374 2.4. DiffServ, Reordering and Transport Protocols 376 Transport protocols provide data communication behaviors beyond those 377 possible at the IP layer. An important example is that TCP [RFC0793] 378 provides reliable in-order delivery of data with congestion control. 380 SCTP [RFC4960] provides additional properties such as preservation of 381 message boundaries, and the ability to avoid head-of-line blocking 382 that may occur with TCP. 384 In contrast, UDP [RFC0768] is a basic unreliable datagram protocol 385 that provides port-based multiplexing and demultiplexing on top of 386 IP. Two other unreliable datagram protocols are UDP-Lite [RFC3828], 387 a variant of UDP that may deliver partially corrupt payloads when 388 errors occur, and DCCP [RFC4340], which provides a range of 389 congestion control modes for its unreliable datagram service. 391 Transport protocols that provide reliable delivery (e.g., TCP, SCTP) 392 are sensitive to network reordering of traffic. When a protocol that 393 provides reliable delivery receives a packet other than the next 394 expected packet, the protocol usually assumes that the expected 395 packet has been lost and respond with a retransmission request for 396 that packet. In addition, congestion control functionality in 397 transport protocols usually infers congestion when packets are lost, 398 creating an additional sensitivity to significant reordering - such 399 reordering may be (mis-)interpreted as indicating congestion-caused 400 packet loss, causing a reduction in transmission rate. This remains 401 true even when ECN [RFC3168] is in use, as ECN receivers are required 402 to treat missing packets as potential indications of congestion. 403 This requirement is based on two factors: 405 o Severe congestion may cause ECN-capable network nodes to drop 406 packets, and 408 o ECN traffic may be forwarded by network nodes that do not support 409 ECN and hence use packet drops to indicate congestion. 411 Congestion control is an important aspect of the Internet 412 architecture, see [RFC2914] for further discussion. 414 In general, marking packets with different DSCPs results in different 415 PHBs being applied at network nodes, making reordering possible due 416 to use of different pools of forwarding resources for each PHB. The 417 primary exception is that reordering is prohibited within each AF 418 class (e.g., AF1x), as the three PHBs in an AF class differ solely in 419 drop precedence. Reordering within a PHB or AF class may occur for 420 other transient reasons (e.g., route flap or ECMP rebalancing). 422 Reordering also affects other forms of congestion control, such as 423 techniques for RTP congestion control that were under development 424 when this document was published, see 425 [I-D.ietf-rmcat-cc-requirements] for requirements. These techniques 426 prefer use of a common (coupled) congestion controller for RTP 427 streams between the same endpoints in order to reduce packet loss and 428 delay by reducing competition for resources at any shared bottleneck. 430 Shared bottlenecks can be detected via correlations of measured 431 metrics such as one-way delay. An alternative approach assumes that 432 the set of packets on a single 5-tuple marked with DSCPs that do not 433 allow reordering will utilize a common network path and common 434 forwarding resources at each network node. Under that assumption, 435 any bottleneck encountered by such packets is shared among all of 436 them, making it safe to use a common (coupled) congestion controller, 437 see [I-D.welzl-rmcat-coupled-cc]. This is not a safe assumption when 438 the packets involved are marked with DSCP values that allow 439 reordering because a bottleneck may not be shared among all such 440 packets (e.g., if the DSCPs result in use of different queues at a 441 network node, only one of which is a bottleneck). 443 Unreliable datagram protocols (e.g., UDP, UDP-Lite, DCCP) are not 444 sensitive to reordering in the network, because they do not provide 445 reliable delivery or congestion control. On the other hand, when 446 used to encapsulate other protocols (e.g., as UDP is used by RTCWEB, 447 see Section 2.1), the reordering considerations for the encapsulated 448 protocols apply. For the specific usage of UDP by RTCWEB, every 449 encapsulated protocol (i.e., RTP, SCTP and TCP) is sensitive to 450 reordering as further discussed in this document. In addition, 451 [RFC5405] provides general guidelines for use of UDP (and UDP-Lite); 452 the congestion control guidelines in that document apply to protocols 453 encapsulated in UDP (or UDP-Lite). 455 2.5. DiffServ, Reordering and Real-Time Communication 457 Real-time communications are also sensitive to network reordering of 458 packets. Such reordering may lead to spurious NACK generation and 459 unneeded retransmission, as is the case for reliable delivery 460 protocols (see Section 2.4). The degree of sensitivity depends on 461 protocol or stream timers, in contrast to reliable delivery protocols 462 that usually react to all reordering. 464 Receiver jitter buffers have important roles in the effect of 465 reordering on real time communications: 467 o Minor packet reordering that is contained within a jitter buffer 468 usually has no effect on rendering of the received RTP stream. 470 o Packet reordering that exceeds the capacity of a jitter buffer can 471 cause user-perceptible quality problems (e.g., glitches, noise) 472 for delay sensitive communication, such as interactive 473 conversations. Interactive real-time communication 474 implementations often discard data that is sufficiently late that 475 it cannot be rendered in source stream order, making 476 retransmission counterproductive. For this reason, 477 implementations of interactive real-time communication often do 478 not use retransmission. 480 o In contrast, replay of recorded media can tolerate significantly 481 longer delays than interactive conversations, so replay is likely 482 to use larger jitter buffers than interactive conversations. 483 These larger jitter buffers increase the tolerance of replay to 484 reordering by comparison to interactive conversations. The size 485 of the jitter buffer imposes an upper bound on replay tolerance to 486 reordering, but does enable retransmission to be used when the 487 jitter buffer is significantly larger than the amount of data that 488 can be expected to arrive during the round-trip latency for 489 retransmission. 491 Network packet reordering caused by use of different DSCPs has no 492 effective upper bound, and can exceed the size of any reasonable 493 jitter buffer - in practice, the size of jitter buffers for replay is 494 limited by external factors such as the amount of time that a human 495 is willing to wait for replay to start. 497 2.6. Drop Precedence 499 Each DiffServ AF class consists of three PHBs that differ solely in 500 drop precedence (e.g., AF3x consists of AF31, AF32 and AF33). 501 Reordering is prohibited among packets on the same 5-tuple that use 502 PHBs within a single AF class; further, these packets can be expected 503 to draw upon the same forwarding resources on network nodes (e.g., 504 use the same router queue) and hence use of multiple drop precedences 505 within an AF class is not expected to impact latency. 507 When PHBs within a single AF class are mixed for a protocol session, 508 the resulting drop likelihood is a mix of the drop likelihoods of the 509 PHBs involved. The primary effect of multiple drop precedences is to 510 influence decisions on what to drop with the goal that less important 511 packets are dropped in preference to more important packets. 513 There are situations in which drop precedences should not be mixed. 514 A simple example is that there is little value in mixing drop 515 precedences within a TCP connection, because TCP's ordered delivery 516 behavior results in any drop requiring the receiver to wait for the 517 dropped packet to be retransmitted. Any resulting delay depends on 518 the RTT and not the packet that was dropped. Hence a single PHB and 519 DSCP should be used for all packets in a TCP connection. 521 SCTP [RFC4960] differs from TCP in a number of ways, including the 522 ability to deliver messages in an order that differs from the order 523 in which they were sent and support for unreliable streams. However, 524 SCTP performs congestion control and retransmission across the entire 525 association, and not on a per-stream basis. Although there may be 526 advantages to using multiple drop precedence across SCTP streams or 527 within an SCTP stream that does not use reliable ordered delivery, 528 there is no practical operational experience in doing so (e.g., the 529 SCTP sockets API [RFC6458] does not support use of more than one DSCP 530 for an SCTP association). As a consequence, the impacts on SCTP 531 protocol and implementation behavior are unknown and difficult to 532 predict. Hence a single PHB and DSCP should be used for all packets 533 in an SCTP association, independent of the number or nature of 534 streams in that association. Similar reasoning applies to a DCCP 535 connection; a single PHB and DSCP should be used because the scope of 536 congestion control is the connection and there is no operational 537 experience with using more than one PHB or DSCP. 539 RTCP multi-stream reporting optimizations for an RTP session 540 [I-D.ietf-avtcore-rtp-multi-stream-optimisation] assume that the RTP 541 streams involved experience the same packet loss behavior. This 542 mechanism is highly inappropriate if the RTP streams involved use 543 different PHBs, even if those PHBs differ solely in drop precedence. 545 2.7. Traffic Classifiers and DSCP Remarking 547 DSCP markings are not end-to-end in general. Each network can make 548 its own decisions about what PHBs to use and which DSCP maps to each 549 PHB. While every PHB specification includes a recommended DSCP, and 550 RFC 4594 [RFC4594] recommends their end-to-end usage, there is no 551 requirement that every network support any PHBs or use any specific 552 DSCPs, with the exception of the class selector codepoint 553 requirements in RFC 2474 [RFC2474]. When DiffServ is used, the edge 554 or boundary nodes of a network are responsible for ensuring that all 555 traffic entering that network conforms to that network's policies for 556 DSCP and PHB usage, and such nodes remark traffic (change the DSCP 557 marking as part of traffic conditioning) accordingly. As a result, 558 DSCP remarking is possible at any network boundary, including the 559 first network node that traffic sent by a host encounters. Remarking 560 is also possible within a network, e.g., for traffic shaping. 562 DSCP remarking is part of traffic conditioning; the traffic 563 conditioning functionality applied to packets at a network node is 564 determined by a traffic classifier [RFC2475]. Edge nodes of a 565 DiffServ network classify traffic based on selected packet header 566 fields; typical implementations do not look beyond the traffic's 567 5-tuple in the IP and transport protocol headers. As a result, when 568 multiple DSCPs are used for traffic that shares a 5-tuple, remarking 569 at a network boundary may result in all of the traffic being 570 forwarded with a single DSCP, thereby removing any differentiation 571 within the 5-tuple downstream of the remarking location. Network 572 nodes within a DiffServ network generally classify traffic based 573 solely on DSCPs, but may perform finer grain traffic conditioning 574 similar to that performed by edge nodes. 576 So, for two arbitrary network endpoints, there can be no assurance 577 that the DSCP set at the source endpoint will be preserved and 578 presented at the destination endpoint. Rather, it is quite likely 579 that the DSCP will be set to zero (e.g., at the boundary of a network 580 operator that distrusts or does not use the DSCP field) or to a value 581 deemed suitable by an ingress classifier for whatever 5-tuple it 582 carries. DiffServ classifiers generally ignore embedded protocol 583 headers (e.g., for SCTP or RTP embedded in UDP, header-based 584 classification is unlikely to look beyond the outer UDP header). 586 In addition, remarking may remove application-level distinctions in 587 forwarding behavior - e.g., if multiple PHBs within an AF class are 588 used to distinguish different types of frames within a video RTP 589 stream, token-bucket-based remarkers operating in Color-Blind mode 590 (see [RFC2697] and [RFC2698] for examples) may remark solely based on 591 flow rate and burst behavior, removing the drop precedence 592 distinctions specified by the source. 594 Backbone and other carrier networks may employ a small number of 595 DSCPs (e.g., less than half a dozen) in order to manage a small 596 number of traffic aggregates; hosts that use a larger number of DSCPs 597 can expect to find that much of their intended differentiation is 598 removed by such networks. Better results may be achieved when DSCPs 599 are used to spread traffic among a smaller number of DiffServ-based 600 traffic subsets or aggregates, see [I-D.geib-tsvwg-diffserv-intercon] 601 for one proposal. This is of particular importance for MPLS-based 602 networks due to the limited size of the Traffic Class (TC) field in 603 an MPLS label [RFC5462] that is used to carry DiffServ information 604 and the use of that TC field for other purposes, e.g., ECN [RFC5129]. 605 For further discussion on use of DiffServ with MPLS, see [RFC3270] 606 and [RFC5127]. 608 3. RTP Multiplexing Background 610 Section 2 explains how source streams can be multiplexed over RTP 611 sessions, which can in turn be multiplexed over UDP with packets 612 generated by other transport protocols. This section provides 613 background on why this level of multiplexing is desirable. The 614 rationale in this section applies both to multiplexing of source 615 streams in RTP sessions and multiplexing of an RTP session with 616 traffic from other transport protocols via UDP encapsulation. 618 Multiplexing reduces the number of ports utilized for real-time and 619 related communication in an overall interaction. While a single 620 endpoint might have plenty of ports available for communication, this 621 traffic often traverses points in the network that are constrained on 622 the number of available ports or whose performance degrades as the 623 number of ports in use increases. A good example is a Network 624 Address Translator and Firewall (NAT/FW) device sitting at the 625 network edge. As the number of simultaneous protocol sessions 626 increases, so does the burden placed on these devices to provide port 627 mapping. 629 The STUN [RFC5389] / ICE [RFC5245] / TURN [RFC5766] protocol family 630 provides NAT/FW traversal and port mapping for protocols (e.g., those 631 in the RTCWEB protocol suite) via communication with a relay server. 632 These protocols were originally designed for use of UDP, however, 633 they have been extended to use TCP as a transport for situations in 634 which UDP does not work [RFC6062]. 636 When TCP is selected for NAT/FW traversal, a single PHB and DSCP 637 should be used for all traffic on that TCP connection for the reasons 638 discussed in Section 2.4 and Section 2.6 above. An additional reason 639 for this recommendation is that packetization for STUN/ICE/TURN 640 occurs before passing the resulting packets to TCP; TCP 641 resegmentation may result in a different packetization on the wire, 642 breaking any association between DSCPs and specific data to which 643 they are intended to apply. 645 Another reason for multiplexing is to help reduce the time required 646 to establish bi-directional communication. Since any two 647 communicating users might be situated behind different NAT/FW 648 devices, it is necessary to employ techniques like STUN/ICE/TURN in 649 order to get traffic to flow between the two devices 650 [I-D.ietf-rtcweb-transports]. Performing the tasks required of 651 STUN/ICE/TURN take time, especially when multiple protocol sessions 652 are involved. While tasks for different sessions can be performed in 653 parallel, it is nonetheless necessary for applications to wait for 654 all sessions to be opened before communication between two users can 655 begin. Reducing the number of STUN/ICE/TURN steps reduces the 656 likelihood of loss of a packet for one of these protocols; any such 657 loss adds delay to setting up a communication session. Further, 658 reducing the number of STUN/ICE/TURN tasks places a lower burden on 659 the STUN and TURN servers. 661 Multiplexing may reduce the complexity and resulting load on an 662 endpoint. A single instance of STUN/ICE/TURN is simpler to execute 663 and manage than multiple instances STUN/ICE/TURN operations happening 664 in parallel, as the latter require synchronization and create more 665 complex failure situations that have to be cleaned up by additional 666 code. 668 4. Guidelines 670 The only use of multiple standardized PHBs and DSCPs that prevents 671 network reordering among packets marked with different DSCPs is use 672 of PHBs within a single AF class. All other uses of multiple PHBs 673 and/or the class selector DSCPs allow network reordering of packets 674 that are marked with different DSCPs. Based on this and the 675 foregoing discussion, the following requirements apply to use of 676 DiffServ with real-time communications - applications and other 677 traffic sources: 679 o Should not use different PHBs and DSCPs that allow reordering 680 within a single RTP stream. If this is not done, significant 681 network reordering may overwhelm implementation assumptions about 682 reordering limits, e.g., jitter buffer size, causing poor user 683 experiences, see Section 2.5 above. When a common (coupled) 684 congestion controller is used across multiple RTP streams, this 685 recommendation against use of PHBs and DSCPs that allow reordering 686 applies across all of the RTP streams that are within the scope of 687 a single common (coupled) congestion controller. 689 o Should use a single PHB and DSCP for an RTCP session, primarily to 690 avoid RTCP reordering (and because there is no compelling reason 691 for use of different drop precedences). One of the PHBs and 692 associated DSCP used for the associated RTP traffic would be an 693 appropriate choice. 695 o Should use a single PHB and DSCP for all packets within a reliable 696 transport protocol session (e.g., TCP connection, SCTP 697 association) or DCCP connection. Receivers for such protocols 698 interpret reordering as indicating loss of some of the out-of- 699 order packets; see Section 2.4 and there is no operational 700 experience with multiple PHBs and DSCPs for SCTP or DCCP, see 701 Section 2.6. For SCTP, this requirement applies across the entire 702 SCTP association, and not just to individual streams within an 703 association because SCTP's reliable transmission functionality 704 operates on the overall association. 706 o May use different PHBs and DSCPs that cause reordering within a 707 single UDP (or UDP-Lite) 5-tuple, subject to the above 708 constraints. The service differentiation provided by such usage 709 is unreliable, as it may be removed or changed by DSCP remarking 710 at network boundaries as described in Section 2.7 above. 712 o Cannot rely on end-to-end preservation of DSCPs as network node 713 remarking can change DSCPs and remove drop precedence distinctions 714 see Section 2.7 above. For example, if a source uses drop 715 precedence distinctions within an AF class to identify different 716 types of video frames, using those DSCP values at the receiver to 717 identify frame type is inherently unreliable. 719 o Should limit use of the CS1 codepoint to traffic for which best 720 effort forwarding is acceptable, as network support for use of CS1 721 to select a "less than best effort" PHB is inconsistent. Further, 722 some networks may treat CS1 as providing "better than best effort" 723 forwarding behavior. 725 There is no requirement in this document for network operators to 726 differentiate traffic in any fashion. Networks may support all of 727 the PHBs discussed herein, classify EF and AFxx traffic identically, 728 or even remark all traffic to best effort at some ingress points. 729 Nonetheless, it is useful for network endpoints to provide finer 730 granularity DSCP marking on packets for the benefit of networks that 731 offer QoS service differentiation. A specific example is that 732 traffic originating from a browser may benefit from QoS service 733 differentiation in within-building and residential access networks, 734 even if the DSCP marking is subsequently removed or simplified. This 735 is because such networks and the boundaries between them are likely 736 traffic bottleneck locations (e.g., due to customer aggregation onto 737 common links and/or speed differences among links used by the same 738 traffic). 740 [Editor's note: rtcweb-transports draft is not aligned with the 741 above. The rtcweb WG and the draft author will bring it into line.] 743 5. Examples 745 For real-time communications, one might want to mark the audio 746 packets using EF and the video packets as AF41. However, in a video 747 conference receiving the audio packets ahead of the video is not 748 useful because lip sync is necessary between audio and video. It may 749 still be desirable to send audio with a PHB that provides better 750 service, because early arrival of audio helps assure smooth audio 751 rendering, which is often more important than fully faithful video 752 rendering. There are also limits, as some devices have difficulties 753 in synchronizing voice and video when packets that need to be 754 rendered together arrive at significantly different times. It makes 755 more sense to use different PHBs when the audio and video source 756 streams do not share a strict timing relationship. For example, 757 video content may be shared within a video conference via playback, 758 perhaps of an unedited video clip that is intended to become part of 759 a television advertisement. Such content sharing video does not need 760 precise synchronization with video conference audio, and could use a 761 different PHB, as content sharing video is more tolerant to jitter, 762 loss, and delay. 764 Within a layered video RTP stream, ordering of frame communication is 765 preferred, but importance of frame types varies, making use of PHBs 766 with different drop precedences appropriate. For example, I-frames 767 that contain an entire image are usually more important than P-frames 768 that contain only changes from the previous image because loss of a 769 P-frame (or part thereof) can be recovered (at the latest) via the 770 next I-frame, whereas loss of an I-frame (or part thereof) may cause 771 rendering problems for all of the P-frames that depend on the missing 772 I-frame. For this reason, it is appropriate to mark I-frame packets 773 with a PHB that has lower drop precedence than the PHB used for 774 P-frames, as long as the PHBs preserve ordering among frames (e.g., 775 are in an AF class) - AF41 for I-frames and AF43 for P-frames is one 776 possibility. Additional spatial and temporal layers beyond the base 777 video layer could also be marked with higher drop precedence than the 778 base video layer, as their loss reduces video quality, but does not 779 disrupt video rendering. 781 Additional RTP streams in a real-time communication interaction could 782 be marked with CS0 and carried as best effort traffic. One example 783 is real-time text transmitted as specified in RFC 4103 [RFC4103]. 784 Best effort forwarding suffices because such real-time text has loose 785 timing requirements; RFC 4103 recommends sending text in chunks every 786 300ms. Such text is technically real-time, but does not need a PHB 787 promising better service than best effort, in contrast to audio or 788 video. 790 6. IANA Considerations 792 This document includes no request to IANA. 794 7. Security Considerations 796 The security considerations for all of the technologies discussed in 797 this document apply; in particular see the security considerations 798 for RTP in [RFC3550] and DiffServ in [RFC2474] and[RFC2475]. 800 Multiplexing of multiple protocols onto a single UDP 5-tuple via 801 encapsulation has implications for network functionality that 802 monitors or inspects individual protocol flows, e.g., firewalls and 803 traffic monitoring systems. When implementations of such 804 functionality lack visibility into encapsulated traffic (likely for 805 many current implementations), it may be difficult or impossible to 806 apply network security policy and associated controls at a finer 807 granularity than the overall UDP 5-tuple. 809 Use of multiple PHBs and DSCPs that allow reordering within an 810 overall real-time communication interaction enlarges the set of 811 network forwarding resources used by that interaction, thereby 812 increasing exposure to resource depletion or failure, independent of 813 whether the underlying cause is benign or malicious. This represents 814 an increase in the effective attack surface of the interaction, and 815 is a consideration in selecting an appropriate degree of QoS 816 differentiation among the components of the real-time communication 817 interaction. 819 Use of multiple DSCPs to provide differentiated QoS service may 820 reveal information about the encrypted traffic to which different 821 service levels are provided. For example, DSCP-based identification 822 of RTP streams combined with packet frequency and packet size could 823 reveal the type or nature of the encrypted source streams. The IP 824 header used for forwarding has to be unencrypted for obvious reasons, 825 and the DSCP likewise has to be unencrypted in order to enable 826 different IP forwarding behaviors to be applied to different packets. 827 The nature of encrypted traffic components can be disguised via 828 encrypted dummy data padding and encrypted dummy packets, e.g., see 829 the discussion of traffic flow confidentiality in [RFC4303]. 830 Encrypted dummy packets could even be added in a fashion that an 831 observer of the overall encrypted traffic might mistake for another 832 encrypted RTP stream. 834 8. Acknowledgements 836 This document is the result of many conversations that have occurred 837 within the dart working group and multiple other working groups in 838 the RAI and Transport areas. Many thanks to Harald Alvestrand, Erin 839 Bournival, Brian Carpenter, Keith Drage, Gorry Fairhurst, Ruediger 840 Geib, Cullen Jennings, Jonathan Lennox, Karen Nielsen, Colin Perkins, 841 James Polk, Michael Welzl, Dan York and the dart WG participants for 842 their reviews and comments. 844 9. References 846 9.1. Normative References 848 [I-D.ietf-avtext-rtp-grouping-taxonomy] 849 Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, 850 "A Taxonomy of Grouping Semantics and Mechanisms for Real- 851 Time Transport Protocol (RTP) Sources", draft-ietf-avtext- 852 rtp-grouping-taxonomy-02 (work in progress), June 2014. 854 [I-D.petithuguenin-avtcore-rfc5764-mux-fixes] 855 Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme 856 Updates for Secure Real-time Transport Protocol (SRTP) 857 Extension for Datagram Transport Layer Security (DTLS)", 858 draft-petithuguenin-avtcore-rfc5764-mux-fixes-00 (work in 859 progress), July 2014. 861 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 862 August 1980. 864 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 865 793, September 1981. 867 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 868 "Definition of the Differentiated Services Field (DS 869 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 870 1998. 872 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 873 and W. Weiss, "An Architecture for Differentiated 874 Services", RFC 2475, December 1998. 876 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 877 "Assured Forwarding PHB Group", RFC 2597, June 1999. 879 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 880 J., Courtney, W., Davari, S., Firoiu, V., and D. 881 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 882 Behavior)", RFC 3246, March 2002. 884 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 885 Jacobson, "RTP: A Transport Protocol for Real-Time 886 Applications", STD 64, RFC 3550, July 2003. 888 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 889 Per-Domain Behavior (PDB) for Differentiated Services", 890 RFC 3662, December 2003. 892 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 893 G. Fairhurst, "The Lightweight User Datagram Protocol 894 (UDP-Lite)", RFC 3828, July 2004. 896 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 897 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 899 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 900 4960, September 2007. 902 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 903 for Application Designers", BCP 145, RFC 5405, November 904 2008. 906 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 907 Security (DTLS) Extension to Establish Keys for the Secure 908 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 910 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 911 Services Code Point (DSCP) for Capacity-Admitted Traffic", 912 RFC 5865, May 2010. 914 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 915 Control Transmission Protocol (SCTP) Packets for End-Host 916 to End-Host Communication", RFC 6951, May 2013. 918 9.2. Informative References 920 [H.222.0] ITU-T, "H.222.0 : Information technology - Generic coding 921 of moving pictures and associated audio information", June 922 2012. 924 [I-D.geib-tsvwg-diffserv-intercon] 925 Geib, R., "DiffServ interconnection classes and practice", 926 draft-geib-tsvwg-diffserv-intercon-06 (work in progress), 927 July 2014. 929 [I-D.ietf-avtcore-rtp-multi-stream-optimisation] 930 Lennox, J., Westerlund, M., Wu, W., and C. Perkins, 931 "Sending Multiple Media Streams in a Single RTP Session: 932 Grouping RTCP Reception Statistics and Other Feedback", 933 draft-ietf-avtcore-rtp-multi-stream-optimisation-03 (work 934 in progress), July 2014. 936 [I-D.ietf-mmusic-sdp-bundle-negotiation] 937 Holmberg, C., Alvestrand, H., and C. Jennings, 938 "Negotiating Media Multiplexing Using the Session 939 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 940 negotiation-07 (work in progress), April 2014. 942 [I-D.ietf-rmcat-cc-requirements] 943 Jesup, R., "Congestion Control Requirements For RMCAT", 944 draft-ietf-rmcat-cc-requirements-05 (work in progress), 945 July 2014. 947 [I-D.ietf-rtcweb-overview] 948 Alvestrand, H., "Overview: Real Time Protocols for 949 Browser-based Applications", draft-ietf-rtcweb-overview-10 950 (work in progress), June 2014. 952 [I-D.ietf-rtcweb-rtp-usage] 953 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 954 Communication (WebRTC): Media Transport and Use of RTP", 955 draft-ietf-rtcweb-rtp-usage-16 (work in progress), July 956 2014. 958 [I-D.ietf-rtcweb-transports] 959 Alvestrand, H., "Transports for RTCWEB", draft-ietf- 960 rtcweb-transports-05 (work in progress), June 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 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1021 Relays around NAT (TURN): Relay Extensions to Session 1022 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 1024 [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays 1025 around NAT (TURN) Extensions for TCP Allocations", RFC 1026 6062, November 2010. 1028 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1029 "IPv6 Flow Label Specification", RFC 6437, November 2011. 1031 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 1032 Yasevich, "Sockets API Extensions for the Stream Control 1033 Transmission Protocol (SCTP)", RFC 6458, December 2011. 1035 [W3C.WD-mediacapture-streams-20130903] 1036 Burnett, D., Bergkvist, A., Jennings, C., and A. 1037 Narayanan, "Media Capture and Streams", World Wide Web 1038 Consortium WD WD-mediacapture-streams-20130903, September 1039 2013, . 1042 Appendix A. Change History 1044 [To be removed before RFC publication.] 1046 Changes from draft-york-dart-dscp-rtp-00 to -01 1048 o Added examples (Section 5) 1050 o Reworked text on RTP session multiplexing, at most one RTP session 1051 can be used per UDP 5-tuple. 1053 o Initial terminology alignment with RTP grouping taxonomy draft. 1055 o Added Section 2.5 on real-time communication interaction w/ 1056 reordering based on text from Harald Alvestrand. 1058 o Strengthened warnings on loss of differentiation, but indicate 1059 that differentiation may still be useful from source to point of 1060 loss. 1062 o Added a few sentences on DiffServ and MPLS. 1064 o Added discussion of UDP-encapsulated protocols that are reordering 1065 sensitive. 1067 o Added initial security considerations. 1069 o Many editorial changes 1071 Changes from draft-york-dart-dscp-rtp-01 to -02 1073 o More terminology alignment with RTP grouping taxonomy draft: "RTP 1074 packet stream" -> "RTP stream" 1076 o Aligned terminology for less-than-best-effort with RFC 3662 - LE 1077 (Lower Effort) PHB and service 1079 o Minor reference updates 1081 Changes from draft-york-dart-dscp-rtp-02 to draft-ietf-dart-dscp- 1082 rtp-00 1084 o Reduce author list and convert to Informational - remove RFC 2119 1085 reference and keywords 1087 o Strengthen TCP and SCTP text. 1089 o Add section 2.6 on drop precedence. 1091 o Remove discussion of multiplexing multiple RTP sessions on a 1092 single UDP 5-tuple 1094 o Add discussions of RTCP,STUN/ICE/TURN and coupled congestion 1095 control 1097 o Many editorial changes. 1099 o Lots of additional references 1101 Changes from draft-ietf-dart-dscp-rtp-00 to draft-ietf-dart-dscp- 1102 rtp-01 1104 o Merge the two TCP/SCTP guideline bullets. 1106 o Add DCCP and UDP-Lite material, plus reference to RFC 5405 for UDP 1107 (and UDP-Lite) usage guidelines. 1109 o Add "attack surface" security consideration. 1111 o Many editorial changes. 1113 o More references, and moved some references to normative. 1115 Authors' Addresses 1117 David Black (editor) 1118 EMC 1119 176 South Street 1120 Hopkinton, MA 01748 1121 USA 1123 Phone: +1 508 293-7953 1124 Email: david.black@emc.com 1126 Paul Jones 1127 Cisco 1128 7025 Kit Creek Road 1129 Research Triangle Park, MA 27502 1130 USA 1132 Phone: +1 919 476 2048 1133 Email: paulej@packetizer.com