idnits 2.17.1 draft-york-dart-dscp-rtp-02.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 (July 4, 2014) is 3583 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-08) exists of draft-geib-tsvwg-diffserv-intercon-05 == Outdated reference: A later version (-08) exists of draft-ietf-avtext-rtp-grouping-taxonomy-02 == 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-15 == 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 -- Obsolete informational reference (is this intentional?): RFC 3662 (Obsoleted by RFC 8622) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DiffServ Applied to Real-time Transports D. York 3 Internet-Draft Internet Society 4 Intended status: Standards Track D. Black, Ed. 5 Expires: January 5, 2015 EMC 6 C. Jennings 7 P. Jones 8 Cisco 9 July 4, 2014 11 Differentiated Services (DiffServ) and Real-time Communication 12 draft-york-dart-dscp-rtp-02 14 Abstract 16 This document describes the interaction between Differentiated 17 Services (DiffServ) network quality of service (QoS) functionality 18 and real-time network communication, including communication based on 19 the Real-time Transport Protocol (RTP). DiffServ is based on network 20 nodes applying different forwarding treatments to packets whose IP 21 headers are marked with different DiffServ Code Points (DSCPs). As a 22 result, use of different DSCPs within a single traffic stream may 23 cause transport protocol interactions (e.g., reordering). In 24 addition, DSCP markings may be changed or removed between the traffic 25 source and destination. This document covers the implications of 26 these DiffServ aspects for real-time network communication, including 27 RTCWEB. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 5, 2015. 46 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 65 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.1. RTP Background . . . . . . . . . . . . . . . . . . . . . 3 67 2.2. Differentiated Services (DiffServ) Background . . . . . . 5 68 2.3. Diffserv PHBs (Per-Hop Behaviors) . . . . . . . . . . . . 7 69 2.4. DiffServ, Reordering and Transport Protocols . . . . . . 8 70 2.5. DiffServ, Reordering and Real-Time Communication . . . . 9 71 2.6. Traffic Classifiers and DSCP Remarking . . . . . . . . . 10 72 3. RTP Multiplexing Background . . . . . . . . . . . . . . . . . 11 73 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 12 74 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 80 9.2. Informative References . . . . . . . . . . . . . . . . . 16 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 83 1. Introduction 85 This document describes the interactions between Differentiated 86 Services (DiffServ) network quality of service (QoS) functionality 87 [RFC2475] and real-time network communication, including 88 communication based on the Real-time Transport Protocol (RTP) 89 [RFC3550]. DiffServ is based on network nodes applying different 90 forwarding treatments to packets whose IP headers are marked with 91 different DiffServ Code Points (DSCPs)[RFC2474]. As a result use of 92 different DSCPs within a single traffic stream may cause transport 93 protocol interactions (e.g., reordering). In addition, DSCP markings 94 may be changed or removed between the traffic's source and 95 destination. This document covers the implications of these DiffServ 96 aspects for real-time network communication, including RTCWEB traffic 97 [I-D.ietf-rtcweb-overview]. 99 1.1. Requirements Language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 2. Background 107 Real-time communications enables communication in real-time over an 108 IP network using voice, video, text, content sharing, etc. It is 109 possible to use one or more of these modalities in parallel in order 110 to provide a richer communication experience. 112 A simple example of real-time communications is a voice call placed 113 over the Internet wherein an audio stream is transmitted in each 114 direction between two users. A more complex example is an immersive 115 videoconferencing system that has multiple video screens, multiple 116 cameras, multiple microphones, and some means of sharing content. 117 For such complex systems, there may be multiple media streams that 118 may be transmitted via a single IP address and port or via multiple 119 IP addresses and ports. 121 2.1. RTP Background 123 The most common protocol used for real time media is the Real-Time 124 Transport Protocol (RTP) [RFC3550]. RTP defines a common 125 encapsulation format and handling rules for real-time data 126 transmitted over the Internet. Unfortunately, RTP terminology usage 127 has been inconsistent. For example, this document on RTP grouping 128 terminology [I-D.ietf-avtext-rtp-grouping-taxonomy] observes that: 130 RFC 3550 [RFC3550] uses the terms media stream, audio stream, 131 video stream and streams of (RTP) packets interchangeably. 133 Terminology in this document is based on that RTP grouping 134 terminology document with the following terms being of particular 135 importance (see that terminology document for full definitions): 137 Source Stream: A reference clock synchronized, time progressing, 138 digital media stream. 140 RTP Stream: A stream of RTP packets containing media data, which may 141 be source data or redundant data. The RTP Packet Stream is 142 identified by an RTP synchronization source (SSRC) belonging to a 143 particular RTP session. 145 Media encoding and packetization of a source stream results in a 146 source RTP stream plus zero or more redundancy RTP streams that 147 provide resilience against loss of packets from the source RTP stream 148 [I-D.ietf-avtext-rtp-grouping-taxonomy]. Redundancy information may 149 also be carried in the same RTP stream as the encoded source stream, 150 e.g., see Section 7.2 of [RFC5109]. With most applications, a single 151 media type (e.g., audio) is transmitted within a single RTP session. 152 However, it is possible to transmit multiple, distinct source streams 153 over the same RTP session as one or more individual RTP streams. 154 This is referred to as RTP multiplexing. 156 The number of source streams and RTP streams in an overall real-time 157 interaction can be surprisingly large. In addition to a voice source 158 stream and a video source stream, there could be separate source 159 streams for each of the cameras or microphones on a videoconferencing 160 system. As noted above, there might also be separate redundancy RTP 161 streams that provide protection to a source RTP stream, using 162 techniques such as Forward Error Correction. Another example is 163 simulcast transmission, where a video source stream can be 164 transmitted at high resolution and low resolution RTP streams at the 165 same time. In this case, a media processing function might choose to 166 send one or both RTP streams onward to a receiver based on bandwidth 167 availability or who the active speaker is in a multipoint conference. 168 Lastly, a transmitter might send a the same media content 169 concurrently as two RTP streams using different encodings (e.g., VP8 170 in parallel with H.264) to allow a media processing function to 171 select a media encoding that best matches the capabilities of the 172 receiver. 174 Other transport protocols may also be used to transmit real-time data 175 or near-real-time data. For example, SCTP can be utilized to carry 176 application sharing or whiteboarding information as part of an 177 overall interaction that includes real time media. These additional 178 transport protocols can be multiplexed with an RTP session via UDP 179 encapsulation, thereby using a single pair of UDP ports. 181 The RTCWEB protocol suite [I-D.ietf-rtcweb-transports] employs two 182 layers of multiplexing: 184 1. Individual source streams are carried in one or more individual 185 RTP streams that can be multiplexed into a single RTP session as 186 described in [RFC3550]; and 188 2. An RTP session could be multiplexed with other protocols via UDP 189 encapsulation over a common pair of UDP ports as described in 191 [RFC5764] and [I-D.petithuguenin-avtcore-rfc5764-mux-fixes]. The 192 resulting unidirectional UDP packet flow is identified by a 193 5-tuple, i.e., a combination of two IP addresses (source and 194 destination), two UDP ports (source and destination), and the use 195 of the UDP protocol. 197 For RTCWEB,an individual source stream is a MediaStreamTrack, and a 198 MediaStream contains one or more MediaStreamTracks 199 [W3C.WD-mediacapture-streams-20130903]. A MediaStreamTrack is 200 transmitted as a source RTP stream plus zero or more redundancy RTP 201 streams, so a MediaStream that consists of one MediaStreamTrack is 202 transmitted as a single source RTP stream plus zero or more 203 redundancy RTP streams. 205 For more information on use of RTP in RTCWEB, see 206 [I-D.ietf-rtcweb-rtp-usage]. 208 [I-D.westerlund-avtcore-transport-multiplexing] proposes to allow 209 multiple RTP sessions to be multiplexed over a single UDP 5-tuple; 210 the future of that expired proposal is uncertain. 212 For IPv6, addition of the flow label [RFC6437] to 5-tuples results in 213 6-tuples, but in practice, use of a flow label is unlikely to result 214 in a finer-grain traffic subset than the corresponding 5-tuple (e.g., 215 the flow label is likely to represent the combination of two ports 216 with use of the UDP protocol). For that reason, discussion in this 217 draft focuses on UDP 5-tuples. 219 [Editor's Note: Multiple RTP sessions cannot be multiplexed on the 220 same UDP 5-tuple, but what about multiple DTLS sessions for RTP? RFC 221 5764 appears to allow multiple DTLS sessions.] 223 [Editor's Note: Should RTCP multiplexing w/RTP be mentioned here, as 224 described in RFC 5761?] 226 2.2. Differentiated Services (DiffServ) Background 228 The DiffServ architecture is intended to enable scalable service 229 discrimination in the Internet without requiring each network node to 230 store per-flow state and participate in per-flow signaling. The 231 services may be end-to-end or within a network; they include both 232 those that can satisfy quantitative performance requirements (e.g., 233 peak bandwidth) and those based on relative performance (e.g., 234 "class" differentiation). Services can be constructed by a 235 combination of well-defined building blocks deployed in network nodes 236 that: 238 o classify traffic and set bits in an IP header field at network 239 boundaries or hosts, 241 o use those bits to determine how packets are forwarded by the nodes 242 inside the network, and 244 o condition the marked packets (e.g., meter, mark, shape, police) at 245 network boundaries in accordance with the requirements or rules of 246 each service. 248 A network node that supports DiffServ includes a classifier that 249 selects packets based on the value of the DS field in IP headers, 250 along with buffer management and packet scheduling mechanisms capable 251 of delivering the specific packet forwarding treatment indicated by 252 the DS field value. Setting of the DS field and fine-grain 253 conditioning of marked packets need only be performed at network 254 boundaries; internal network nodes operate on traffic aggregates that 255 share a DS field value, or in some cases, a small set of related 256 values. 258 The DiffServ architecture[RFC2475] maintains distinctions among: 260 o the QoS service provided to a traffic aggregate, 262 o the conditioning functions and per-hop behaviors (PHBs) used to 263 realize services, 265 o the DS field value (DS codepoint, or DSCP) in the IP header used 266 to mark packets to select a per-hop behavior, and 268 o the particular implementation mechanisms that realize a per-hop 269 behavior. 271 This document focuses on PHBs and the usage of DSCPs to obtain those 272 behaviors. In a network node's forwarding path, the DSCP is used to 273 map a packet to a particular forwarding treatment, or per-hop 274 behavior (PHB) that specifies the forwarding treatment. 276 A per-hop behavior (PHB) is a description of the externally 277 observable forwarding behavior of a network node for network traffic 278 marked with a DSCP that selects that PHB. In this context, 279 "forwarding behavior" is a general concept - for example, if only one 280 DSCP is used for all traffic on a link, the observable forwarding 281 behavior (e.g., loss, delay, jitter) will often depend only on the 282 relative loading of the link. To obtain useful behavioral 283 differentiation,multiple traffic subsets are marked with different 284 DSCPs for different PHBs for which node resources such as buffer 285 space and bandwidth are allocated. PHBs provide the framework for a 286 DiffServ network node to allocate resources to traffic subsets, with 287 network-scope differentiated services constructed on top of this 288 basic hop-by-hop (per-node) resource allocation mechanism. 290 The codepoints (DSCPs) may be chosen from a small set of fixed values 291 (the class selector codepoints), or from a set of recommended values 292 defined in PHB specifications, or from values that have purely local 293 meanings to a specific network that supports DiffServ; in general, 294 packets may be forwarded across multiple such networks between source 295 and destination. 297 The mandatory DSCPs are the class selector code points as specified 298 in [RFC2474]. The class selector codepoints (CS0-CS7) extend the 299 deprecated concept of IP Precedence in the IPv4 header; three bits 300 are added, so that the class selector DSCPs are of the form 'xxx000'. 301 The all-zero DSCP ('000000' or CS0) designates a Default PHB that 302 provides best-effort forwarding behavior and the remaining class 303 selector code points were originally specified to provide relatively 304 better per-hop-forwarding behavior in increasing numerical order, 305 but: 307 o There is no requirement that any two adjacent class selector 308 codepoints select different PHBs; adjacent class selector 309 codepoints may use the same pool of resources on each network node 310 in some networks. 312 o CS1 ('001000') was subsequently recommended for a Lower Effort 313 (LE) PHB and service when such a service is offered by a network 314 [RFC3662]. An LE service forwards traffic with "lower" priority 315 than best effort and can be "starved" by best effort and other 316 "higher" priority traffic. Not all networks offer an LE service. 317 See [RFC3662] for further discussion of the LE PHB and service. 319 Applications and traffic sources cannot rely upon different class 320 selector codepoints providing differentiated services or upon the 321 presence of an LE service that is selected by the CS1 DSCP. There is 322 no effective way for a network endpoint to determine whether the CS1 323 DSCP selects an LE service on a specific network, let alone end-to- 324 end. Packets marked with the CS1 DSCP may be forwarded with best 325 effort service or another "higher" priority service, see [RFC2474]. 327 2.3. Diffserv PHBs (Per-Hop Behaviors) 329 Although Differentiated Services is a general architecture that may 330 be used to implement a variety of services, three fundamental 331 forwarding behaviors (PHBs) have been defined and characterized for 332 general use. These are: 334 1. Default Forwarding (DF) for elastic traffic [RFC2474]. The 335 Default PHB is always selected by the all-zero DSCP. 337 2. Assured Forwarding (AF) [RFC2597] to provide differentiated 338 service to elastic traffic. Each instance of the AF behavior 339 consists of three PHBs that differ only in drop precedence, e.g., 340 AF11, AF12 and AF13; such a set of three AF PHBs is referred to 341 as an AF class, e.g., AF1x. There are four defined AF classes, 342 AF1x through AF4x, with higher numbered classes expected to 343 receive better forwarding treatment than lower numbered classes. 345 3. Expedited Forwarding (EF) [RFC3246] intended for inelastic 346 traffic. Beyond the basic EF PHB, the VOICE-ADMIT PHB [RFC5865] 347 is an admission controlled variant of the EF PHB. 349 2.4. DiffServ, Reordering and Transport Protocols 351 [Editor's note: This section and the recommendations in Section 4 are 352 centered on TCP, UDP, and SCTP. They could use generalization to 353 include other transport protocols - DCCP is a likely one to include, 354 although it is not necessary to include every known transport 355 protocol.] 357 Transport protocols provide data communication behaviors beyond those 358 possible at the IP layer. An important example is that TCP provides 359 reliable in-order delivery of data with congestion control. SCTP 360 provides additional properties such as preservation of message 361 boundaries, and the ability to avoid head-of-line blocking that may 362 occur with TCP. In contrast, UDP is a basic unreliable datagram 363 protocol that provides port-based multiplexing and demultiplexing on 364 top of IP. 366 Transport protocols that provide reliable delivery (e.g., TCP, SCTP) 367 are sensitive to network reordering of traffic. When a protocol that 368 provides reliable delivery receives a packet other than the next 369 expected packet for an ordered connection or stream, it usually 370 assumes that the expected packet has been lost and respond with a 371 retransmission request for that packet. In addition, congestion 372 control functionality in transport protocols usually infers 373 congestion when packets are lost, creating an additional sensitivity 374 to significant reordering - such reordering may be (mis-)interpreted 375 as indicating congestion-caused packet loss, causing a reduction in 376 transmission rate. This remains true even when ECN [RFC3168] is in 377 use, as ECN receivers are required to treat missing packets as 378 potential indications of congestion. This requirement is based on 379 two factors: 381 o Severe congestion may cause ECN-capable network nodes to drop 382 packets, and 384 o ECN traffic may be forwarded by network nodes that do not support 385 ECN and hence use packet drops to indicate congestion. 387 Congestion control is an important aspect of the Internet 388 architecture, see [RFC2914] for further discussion. 390 In general, marking packets with different DSCPs results in different 391 PHBs being applied at network nodes, making reordering possible due 392 to use of different pools of forwarding resources for each PHB. The 393 primary exception is that reordering is prohibited within each AF 394 class (e.g., AF1x), as the three PHBs in an AF class differ solely in 395 drop precedence. Reordering within a PHB or AF class may occur for 396 other transient reasons (e.g., route flap or ECMP rebalancing). 398 UDP is the primary transport protocol that is not sensitive to 399 reordering in the network, because it does not provide reliable 400 delivery or congestion control. On the other hand, when UDP is used 401 to encapsulate other protocols (e.g., as is the case for RTCWEB, see 402 Section 2.1), the reordering considerations for the encapsulated 403 protocols apply. For RTCWEB example in particular, every 404 encapsulated protocol (i.e., RTP, SCTP and TCP) is sensitive to 405 reordering as further discussed in this document. 407 2.5. DiffServ, Reordering and Real-Time Communication 409 Real-time communications are also sensitive to network reordering of 410 packets. Such reordering may lead to spurious NACK generation and 411 unneeded retransmission, as is the case for reliable delivery 412 protocols (see Section Section 2.4). The degree of sensitivity 413 depends on protocol or stream timers, in contrast to reliable 414 delivery protocols that usually react to all reordering. 416 Receiver jitter buffers have important roles in the effect of 417 reordering on real time communications: 419 o Minor packet reordering that is contained within a jitter buffer 420 usually has no effect on rendering of the received RTP stream. 422 o Packet reordering that exceeds the capacity of a jitter buffer can 423 cause user-perceptible quality problems (e.g., glitches, noise) 424 for delay sensitive communication, such as interactive 425 conversations. Interactive real-time communication 426 implementations often choose to discard data that is sufficiently 427 late to prevent it from being rendered in source stream order, 428 making retransmission counterproductive. For this reason, 429 implementations of interactive real-time communication often do 430 not use retransmission. 432 o In contrast, replay of recorded media can typically uses 433 significantly larger jitter buffers than can be tolerated for 434 interactive conversations, with the result that replay is more 435 tolerant to reordering than interactive conversations. The size 436 of the jitter buffer imposes an upper bound on replay tolerance to 437 reordering, but does enable retransmission to be used when the 438 jitter buffer is significantly larger than the amount of data that 439 will arrive during the round-trip latency for retransmission. 441 Network packet reordering caused by use of different DSCPs has no 442 effective upper bound, and can exceed the size of any reasonable 443 jitter buffer - in practice, the size of jitter buffers for replay is 444 limited by external factors such as the amount of time that a human 445 is willing to wait for replay to start. 447 2.6. Traffic Classifiers and DSCP Remarking 449 DSCP markings are not end-to-end in general. Each network can make 450 its own decisions about what PHBs to use and which DSCP maps to each 451 PHB. While every PHB specification includes a recommended DSCP, and 452 RFC 4594 [RFC4594] recommends their end-to-end usage, there is no 453 requirement that every network support any PHBs or use any DSCPs, 454 with the exception of the class selector codepoint requirements in 455 RFC 2474 [RFC2474]. When DiffServ is used, the edge or boundary 456 nodes of a network are responsible for ensuring that all traffic 457 entering that network conforms to that network's policies for DSCP 458 and PHB usage, and such nodes remark traffic (change the DSCP marking 459 as part of traffic conditioning) accordingly. As a result, DSCP 460 remarking is possible at any network boundary, including the first 461 network node that traffic sent by a host encounters. Remarking is 462 also possible within a network, e.g., for traffic shaping. 464 DSCP remarking is part of traffic conditioning; the traffic 465 conditioning functionality applied to packets at a network node is 466 determined by a traffic classifier [RFC2475]. Edge nodes of a 467 DiffServ network classify traffic based on selected packet header 468 fields; typical implementations do not look beyond the traffic's 469 5-tuple in the IP and transport protocol headers. As a result, when 470 multiple DSCPs are used for traffic that shares a 5-tuple, remarking 471 at a network boundary may result in all of the traffic being 472 forwarded with a single DSCP, thereby removing any differentiation 473 within the 5-tuple downstream of the remarking location. Network 474 nodes within a DiffServ network generally classify traffic based 475 solely on DSCPs, but may perform finer grain traffic conditioning 476 similar to that performed by edge nodes. 478 So, for two arbitrary network endpoints, there can be no assurance 479 that the DSCP set at the source endpoint will be preserved and 480 presented at the destination endpoint. On the contrary, it is quite 481 likely that the DSCP will be set to zero (e.g., at the boundary of a 482 network operator that distrusts or does not use the DSCP field) or to 483 a value deemed suitable by an ingress (MF) classifier for whatever 484 5-tuple it carries. DiffServ classifiers generally ignore embedded 485 protocol headers (e.g., for SCTP or RTP embedded in UDP, 486 classification will be only on the outer UDP header). 488 In addition, remarking may remove application-level distinctions in 489 forwarding behavior - e.g., if multiple PHBs within an AF class are 490 used to distinguish different types of frames within a video RTP 491 stream, token-bucket-based remarkers operating in Color-Blind mode 492 (see [RFC2697] and [RFC2698] for examples) may remark solely based on 493 flow rate and burst behavior, removing the drop precedence 494 distinctions specified by the source. 496 Backbone and other carrier networks may employ a small number of 497 DSCPs (e.g., less than half a dozen) in order to manage a small 498 number of traffic aggregates; hosts that use a larger number of DSCPs 499 can expect to find that much of their intended differentiation is 500 removed by such networks. Better results may be achieved when DSCPs 501 are used to spread traffic among a smaller number of DiffServ-based 502 traffic subsets or aggregates, see [I-D.geib-tsvwg-diffserv-intercon] 503 for one proposal. This is of particular importance for MPLS-based 504 networks due to the limited size of the Traffic Class (TC) field in 505 an MPLS label [RFC5462] that is used to carry DiffServ information 506 and the use of that TC field for other purposes, e.g., ECN [RFC5129]. 507 For further discussion on use of DiffServ with MPLS, see [RFC3270] 508 and [RFC5127]. 510 3. RTP Multiplexing Background 512 Section 2 explains how source streams can be multiplexed over RTP 513 sessions which can in turn be multiplexed over UDP with packets 514 generated by other transport protocols. This section provides 515 background on why this level of multiplexing is desirable. The 516 rationale in this section applies both to multiplexing of source 517 streams in RTP sessions and multiplexing of an RTP session with 518 traffic from other transport protocols via UDP encapsulation. 520 Multiplexing reduces the number of ports utilized for real-time and 521 related communication in an overall interaction. While a single 522 endpoint might have plenty of ports available for communication, this 523 traffic often traverses points in the network that are constrained on 524 the number of available ports. A good example is a NAT/FW device 525 sitting at the network edge. As the number of simultaneous protocol 526 sessions increases, so does the burden placed on these devices in 527 order to provide port mapping. 529 Another reason for multiplexing is to help reduce the time required 530 to establish bi-directional communication. Since any two 531 communicating users might be situated behind different NAT/FW 532 devices, it is necessary to employ techniques like STUN/ICE/TURN in 533 order to get traffic to flow between the two devices 534 [I-D.ietf-rtcweb-transports]. Performing the tasks required of 535 STUN/ICE/TURN take time and requiring an endpoint to perform these 536 tasks for multiple protocol sessions can increase the time required. 537 While tasks for different sessions can be performed in parallel, it 538 is nonetheless necessary for applications to wait for all sessions to 539 be opened before communication between to users can begin. Reducing 540 the number of STUN/ICE/TURN steps reduces the probability of losing a 541 packet and introducing delay in setting up a communication session. 542 Further, reducing the number of STUN/ICE/TURN tasks means that there 543 is a lower burden placed on the STUN and TURN servers. 545 Multiplexing may reduce the complexity and resulting load on an 546 endpoint. A single instance of STUN/ICE/TURN is simpler to execute 547 and manage than multiple instances STUN/ICE/TURN operations happening 548 in parallel, as the latter require synchronization and create more 549 complex failure situations that have to be cleaned up by additional 550 code. 552 4. Recommendations 554 The only standardized use of multiple PHBs and DSCPs that avoids 555 network reordering among packets marked with different DSCPs is use 556 of PHBs within a single AF class. All other uses of multiple PHBs 557 and/or the class selector DSCPs allow network reordering of packets 558 that are marked with different DSCPs. Based on this and the 559 foregoing discussion, the following requirements apply to use of 560 DiffServ with real-time communications - applications and other 561 traffic sources: 563 o SHOULD NOT use different PHBs and DSCPs that may cause reordering 564 within a single RTP stream. If this is not done, significant 565 network reordering may overwhelm implementation assumptions about 566 limits on reordering, e.g., jitter buffer size, causing poor user 567 experiences, see Section Section 2.5 above. 569 o SHOULD NOT use different PHBs and DSCPs that may cause reordering 570 within an ordered session for a reliable transport protocol (e.g., 571 TCP, SCTP). Receivers for such protocols interpret reordering as 572 indicating loss of out-of-order packets causing undesired 573 retransmission requests, and will infer congestion from 574 significant reordering, causing throughput reduction. This 575 requirement applies to both unencapsulated and encapsulated (e.g., 576 via UDP) uses of reliable transport protocols. 578 o MAY use different PHBs and DSCPs that cause reordering within a 579 single UDP 5-tuple, subject to the above constraints. The service 580 differentiation provided by such usage is unreliable, as it may be 581 removed at network boundaries for the reasons described in 582 Section 2.6 above. 584 o MUST NOT rely on end-to-end preservation of DSCPs as network node 585 remarking can change DSCPs and remove drop precedence distinctions 586 see Section 2.6 above. For example, if a source uses drop 587 precedence distinctions within an AF class to identify different 588 types of video frames, using those DSCP values at the receiver to 589 identify frame type is inherently unreliable. 591 o SHOULD use the CS1 codepoint only for traffic that is acceptable 592 to forward as best effort traffic, as network support for use of 593 CS1 to select a "less than best effort" PHB is inconsistent. 594 Further, some networks may treat CS1 as providing "better than 595 best effort" forwarding behavior. 597 There is no requirement in this document for network operators to 598 differentiate traffic in any fashion. Networks may support all of 599 the PHBs discussed herein, classify EF and AFxx traffic identically, 600 or even remark all traffic to best effort at some ingress points. 601 Nonetheless, it is useful for network endpoints to provide finer 602 granularity DSCP marking on packets for the benefit of networks that 603 offer QoS service differentiation. A specific example is that 604 traffic originating from a browser may benefit from QoS service 605 differentiation in within-building and residential access networks, 606 even if the DSCP marking is subsequently removed or simplified. This 607 is because such networks and the boundaries between them are likely 608 traffic bottleneck locations (e.g., due to customer aggregation onto 609 common links and/or speed differences among links used by the same 610 traffic). 612 5. Examples 614 For real-time communications, one might want to mark the audio 615 packets using EF and the video packets as AF41. However, in a video 616 conference receiving the audio packets ahead of the video is not 617 useful because lip sync is necessary between audio and video. It may 618 still be desirable to send audio with a PHB that provides better 619 service, because early arrival of audio helps assure smooth audio 620 rendering, which is often more important than fully faithful video 621 rendering. There are also limits, as some devices have difficulties 622 in synchronizing voice and video when packets that need to be 623 rendered together arrive at significantly different times. It makes 624 more sense to use different PHBs when the audio and video source 625 streams do not share a strict timing relationship. For example, 626 video content may be shared within a video conference via playback, 627 perhaps of an unedited video clip that is intended to become part of 628 a television advertisement. Such content sharing video does not need 629 precise synchronization with video conference audio, and could use a 630 different PHB, as content sharing video is more tolerant to jitter, 631 loss, and delay. 633 Within a layered video RTP stream, ordering of frame communication is 634 preferred, but importance of frame types varies, making use of PHBs 635 with different drop precedences appropriate. For example, I-frames 636 that contain an entire image are usually more important than P-frames 637 that contain only changes from the previous image because loss of a 638 P-frame (or part thereof) can be recovered (at the latest) via the 639 next I-frame, whereas loss of an I-frame (or part thereof) may cause 640 rendering problems for all of the P-frames that depend on the 641 I-frame. For this reason, it is appropriate to mark I-frame packets 642 with a PHB that has lower drop precedence than the PHB used for 643 P-frames, as long as the PHBs preserve ordering among frames (e.g., 644 are in an AF class) - AF41 for I-frames and AF43 for P-frames is one 645 possibility. Additional spatial and temporal layers beyond the base 646 video layer could also be marked with higher drop precedence than the 647 base video layer, as their loss reduces video quality, but does not 648 disrupt video rendering. 650 Additional RTP streams in a real-time communication interaction could 651 be marked with CS0 and carried as best effort traffic. One example 652 is real-time text transmitted as specified in RFC 4103[RFC4103]; best 653 effort forwarding suffices when redundancy encoding is used (as 654 required by RFC 4103). Best effort forwarding suffices because such 655 real-time text has loose timing requirements; RFC 4103 recommends 656 sending text in chunks every 300ms. Such text is technically real- 657 time, but does not need a PHB promising better service than best 658 effort, in contrast to audio or video. 660 6. IANA Considerations 662 This document includes no request to IANA. 664 7. Security Considerations 666 The security considerations for all of the technologies discussed in 667 this document apply; in particular see the security considerations 668 for RTP in [RFC3550] and DiffServ in [RFC2474] and [RFC2475]. 670 Multiplexing of multiple protocols onto a single UDP 5-tuple via 671 encapsulation has implications for network functionality that is 672 based on monitoring or inspection of individual protocol flows, e.g., 673 firewalls and traffic monitoring systems. When implementations of 674 such functionality lack visibility into encapsulated traffic (likely 675 for many current implementations), it may be difficult or impossible 676 to apply network security policy and controls at a finer grain than 677 the overall UDP 5-tuple. 679 Use of multiple DSCPs to provide differentiated QoS service may 680 reveal information about the encrypted traffic to which different 681 service levels are provided. For example, DSCP-based identification 682 of RTP streams combined with packet frequency and packet size could 683 reveal the type or nature of the encrypted source streams. The IP 684 header used for forwarding has to be unencrypted for obvious reasons, 685 and the DSCP likewise has to be unencrypted in order to enable 686 different IP forwarding behaviors to be applied to different packets. 687 The nature of encrypted traffic components can be disguised via 688 encrypted dummy data padding and encrypted dummy packets, e.g., see 689 the discussion of traffic flow confidentiality in [RFC4303]. 690 Encrypted dummy packets could even be added in a fashion that an 691 observer of the overall encrypted traffic might mistake for another 692 encrypted RTP stream. 694 8. Acknowledgements 696 This document is the result of many conversations that have occurred 697 within multiple working groups in the RAI and Transport areas. Many 698 thanks to Harald Alvestrand, Erin Bournival, Brian Carpenter, 699 Ruediger Geib and James Polk for their reviews and input. 701 9. References 703 9.1. Normative References 705 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 706 Requirement Levels", BCP 14, RFC 2119, March 1997. 708 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 709 "Definition of the Differentiated Services Field (DS 710 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 711 1998. 713 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 714 "Assured Forwarding PHB Group", RFC 2597, June 1999. 716 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 717 J., Courtney, W., Davari, S., Firoiu, V., and D. 718 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 719 Behavior)", RFC 3246, March 2002. 721 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 722 Jacobson, "RTP: A Transport Protocol for Real-Time 723 Applications", STD 64, RFC 3550, July 2003. 725 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 726 Services Code Point (DSCP) for Capacity-Admitted Traffic", 727 RFC 5865, May 2010. 729 9.2. Informative References 731 [I-D.geib-tsvwg-diffserv-intercon] 732 Geib, R., "DiffServ interconnection classes and practice", 733 draft-geib-tsvwg-diffserv-intercon-05 (work in progress), 734 February 2014. 736 [I-D.ietf-avtext-rtp-grouping-taxonomy] 737 Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, 738 "A Taxonomy of Grouping Semantics and Mechanisms for Real- 739 Time Transport Protocol (RTP) Sources", draft-ietf-avtext- 740 rtp-grouping-taxonomy-02 (work in progress), June 2014. 742 [I-D.ietf-rtcweb-overview] 743 Alvestrand, H., "Overview: Real Time Protocols for 744 Browser-based Applications", draft-ietf-rtcweb-overview-10 745 (work in progress), June 2014. 747 [I-D.ietf-rtcweb-rtp-usage] 748 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 749 Communication (WebRTC): Media Transport and Use of RTP", 750 draft-ietf-rtcweb-rtp-usage-15 (work in progress), May 751 2014. 753 [I-D.ietf-rtcweb-transports] 754 Alvestrand, H., "Transports for RTCWEB", draft-ietf- 755 rtcweb-transports-05 (work in progress), June 2014. 757 [I-D.petithuguenin-avtcore-rfc5764-mux-fixes] 758 Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme 759 Updates for Secure Real-time Transport Protocol (SRTP) 760 Extension for Datagram Transport Layer Security (DTLS)", 761 draft-petithuguenin-avtcore-rfc5764-mux-fixes-00 (work in 762 progress), July 2014. 764 [I-D.westerlund-avtcore-transport-multiplexing] 765 Westerlund, M. and C. Perkins, "Multiplexing Multiple RTP 766 Sessions onto a Single Lower-Layer Transport", draft- 767 westerlund-avtcore-transport-multiplexing-07 (work in 768 progress), October 2013. 770 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 771 and W. Weiss, "An Architecture for Differentiated 772 Services", RFC 2475, December 1998. 774 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 775 Marker", RFC 2697, September 1999. 777 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 778 Marker", RFC 2698, September 1999. 780 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 781 2914, September 2000. 783 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 784 of Explicit Congestion Notification (ECN) to IP", RFC 785 3168, September 2001. 787 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 788 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 789 Protocol Label Switching (MPLS) Support of Differentiated 790 Services", RFC 3270, May 2002. 792 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 793 Per-Domain Behavior (PDB) for Differentiated Services", 794 RFC 3662, December 2003. 796 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 797 Conversation", RFC 4103, June 2005. 799 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 800 4303, December 2005. 802 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 803 Guidelines for DiffServ Service Classes", RFC 4594, August 804 2006. 806 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 807 Correction", RFC 5109, December 2007. 809 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 810 Diffserv Service Classes", RFC 5127, February 2008. 812 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 813 Marking in MPLS", RFC 5129, January 2008. 815 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 816 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 817 Class" Field", RFC 5462, February 2009. 819 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 820 Security (DTLS) Extension to Establish Keys for the Secure 821 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 823 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 824 "IPv6 Flow Label Specification", RFC 6437, November 2011. 826 [W3C.WD-mediacapture-streams-20130903] 827 Burnett, D., Bergkvist, A., Jennings, C., and A. 828 Narayanan, "Media Capture and Streams", World Wide Web 829 Consortium WD WD-mediacapture-streams-20130903, September 830 2013, . 833 Appendix A. Change History 835 [To be removed before RFC publication.] 837 Changes from draft-york-dart-dscp-rtp-00 to -01 839 o Added examples (Section 5) 841 o Reworked text on RTP session multiplexing, at most one RTP session 842 can be used per UDP 5-tuple. 844 o Initial terminology alignment with RTP grouping taxonomy draft. 846 o Added Section 2.5 on real-time communication interaction w/ 847 reordering based on text from Harald Alvestrand. 849 o Strengthened warnings on loss of differentiation, but indicate 850 that differentiation may still be useful from source to point of 851 loss. 853 o Added a few sentences on DiffServ and MPLS. 855 o Added discussion of UDP-encapsulated protocols that are reordering 856 sensitive. 858 o Added initial security considerations. 860 o Many editorial changes 862 Changes from draft-york-dart-dscp-rtp-01 to -02 864 o More terminology alignment with RTP grouping taxonomy draft: "RTP 865 packet stream" -> "RTP stream" 867 o Aligned terminology for less-than-best-effort with RFC 3662 - LE 868 (Lower Effort) PHB and service 870 o Minor reference updates 872 Authors' Addresses 874 Dan York 875 Internet Society 876 Keene, N.H. 877 USA 879 Phone: +1-802-735-1624 880 Email: dyork@lodestar2.com 882 David Black (editor) 883 EMC 884 176 South Street 885 Hopkinton, MA 01748 886 USA 888 Phone: +1 508 293-7953 889 Email: david.black@emc.com 891 Cullen Jennings 892 Cisco 893 170 West Tasman Drive 894 MS: SJC-21/2 895 San Jose, CA 95134 896 USA 898 Phone: +1 408 421-9990 899 Email: fluffy@cisco.com 900 Paul Jones 901 Cisco 902 7025 Kit Creek Road 903 Research Triangle Park, MA 27502 904 USA 906 Phone: +1 919 476 2048 907 Email: paulej@packetizer.com