idnits 2.17.1 draft-york-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 == Line 69 has weird spacing: '...rdering and T...' -- The document date (July 3, 2014) is 3585 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) == Unused Reference: 'RFC3246' is defined on line 715, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3662 (Obsoleted by RFC 8622) == 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-01 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-09 == 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-04 == Outdated reference: A later version (-02) exists of draft-petithuguenin-avtcore-rfc5764-mux-fixes-00 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). 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 4, 2015 EMC 6 C. Jennings 7 P. Jones 8 Cisco 9 July 3, 2014 11 Differentiated Services (DiffServ) and Real-time Communication 12 draft-york-dart-dscp-rtp-01 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 4, 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 Packet Stream: A stream of RTP packets containing media data, 141 which may be source data or redundant data. The RTP Packet Stream 142 is identified by an RTP synchronization source (SSRC) belonging to 143 a particular RTP session. 145 Media encoding and packetization of a source stream results in a 146 source RTP packet stream plus zero or more redundancy RTP packet 147 streams that provide resilience against loss of packets from the 148 source RTP packet stream [I-D.ietf-avtext-rtp-grouping-taxonomy]. 149 Redundancy information may also be carried in the same RTP packet 150 stream as the encoded source stream, e.g., see Section 7.2 of 151 [RFC5109]. With most applications, a single media type (e.g., audio) 152 is transmitted within a single RTP session. However, it is possible 153 to transmit multiple, distinct source streams over the same RTP 154 session as one or more individual RTP packet streams. This is 155 referred to as RTP multiplexing. 157 The number of source streams and RTP packet streams in an overall 158 real-time interaction can be surprisingly large. In addition to a 159 voice source stream and a video source stream, there could be 160 separate source streams for each of the cameras or microphones on a 161 videoconferencing system. As noted above, there might also be 162 separate redundancy RTP packet streams that provide protection to a 163 source RTP packet stream, using techniques such as Forward Error 164 Correction. Another example is simulcast transmission, where a video 165 source stream can be transmitted at high resolution and low 166 resolution RTP packet streams at the same time. In this case, a 167 media processing function might choose to send one or both RTP packet 168 streams onward to a receiver based on bandwidth availability or who 169 the active speaker is in a multipoint conference. Lastly, a 170 transmitter might send a the same media content concurrently as two 171 RTP packet streams using different encodings (e.g., VP8 in parallel 172 with H.264) to allow a media processing function to select a media 173 encoding that best matches the capabilities of the receiver. 175 Other transport protocols may also be used to transmit real-time data 176 or near-real-time data. For example, SCTP can be utilized to carry 177 application sharing or whiteboarding information as part of an 178 overall interaction that includes real time media. These additional 179 transport protocols can be multiplexed with an RTP session via UDP 180 encapsulation, thereby using a single pair of UDP ports. 182 The RTCWEB protocol suite [I-D.ietf-rtcweb-transports] employs two 183 layers of multiplexing: 185 1. Individual source streams are carried in one or more individual 186 RTP packet streams that can be multiplexed into a single RTP 187 session as described in [RFC3550]; and 189 2. An RTP session could be multiplexed with other protocols via UDP 190 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 packet stream plus zero or more 201 redundancy RTP packet streams, so a MediaStream that consists of one 202 MediaStreamTrack is transmitted as a single source RTP packet stream 203 plus zero or more redundancy RTP packet 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 "less than best 313 effort" service when such a service is offered by a network 314 [RFC3662]. Not all networks offer such a service. 316 Applications and traffic sources cannot rely upon different class 317 selector codepoints providing differentiated services or upon the 318 presence of a "less than best effort" service that is selected by the 319 CS1 DSCP, and there is no effective way for a network endpoint to 320 determine whether the CS1 DSCP selects such a service on a specific 321 network, let alone end-to-end. Packets marked with the CS1 DSCP may 322 be carried as best effort or even "better than best effort", see 323 [RFC2474]. 325 2.3. Diffserv PHBs (Per-Hop Behaviors) 327 Although Differentiated Services is a general architecture that may 328 be used to implement a variety of services, three fundamental 329 forwarding behaviors (PHBs) have been defined and characterized for 330 general use. These are: 332 1. Default Forwarding (DF) for elastic traffic [RFC2474]. The 333 Default PHB is always selected by the all-zero DSCP. 335 2. Assured Forwarding (AF) [RFC2597] to provide differentiated 336 service to elastic traffic. Each instance of the AF behavior 337 consists of three PHBs that differ only in drop precedence, e.g., 338 AF11, AF12 and AF13; such a set of three AF PHBs is referred to 339 as an AF class, e.g., AF1x. There are four defined AF classes, 340 AF1x through AF4x, with higher numbered classes expected to 341 receive better forwarding treatment than lower numbered classes. 343 3. Expedited Forwarding (EF) [RFC3246]intended for inelastic 344 traffic. Beyond the basic EF PHB, the VOICE-ADMIT PHB [RFC5865] 345 is an admission controlled variant of the EF PHB. 347 2.4. DiffServ, Reordering and Transport Protocols 349 [Editor's note: This section and the recommendations in Section 4 are 350 centered on TCP, UDP, and SCTP. They could use generalization to 351 include other transport protocols - DCCP is a likely one to include, 352 although it is not necessary to include every known transport 353 protocol.] 355 Transport protocols provide data communication behaviors beyond those 356 possible at the IP layer. An important example is that TCP provides 357 reliable in-order delivery of data with congestion control. SCTP 358 provides additional properties such as preservation of message 359 boundaries, and the ability to avoid head-of-line blocking that may 360 occur with TCP. In contrast, UDP is a basic unreliable datagram 361 protocol that provides port-based multiplexing and demultiplexing on 362 top of IP. 364 Transport protocols that provide reliable delivery (e.g., TCP, SCTP) 365 are sensitive to network reordering of traffic. When a protocol that 366 provides reliable delivery receives a packet other than the next 367 expected packet for an ordered connection or stream, it usually 368 assumes that the expected packet has been lost and respond with a 369 retransmission request for that packet. In addition, congestion 370 control functionality in transport protocols usually infers 371 congestion when packets are lost, creating an additional sensitivity 372 to significant reordering - such reordering may be (mis-)interpreted 373 as indicating congestion-caused packet loss, causing a reduction in 374 transmission rate. This remains true even when ECN [RFC3168] is in 375 use, as ECN receivers are required to treat missing packets as 376 potential indications of congestion. This requirement is based on 377 two factors: 379 o Severe congestion may cause ECN-capable network nodes to drop 380 packets, and 382 o ECN traffic may be forwarded by network nodes that do not support 383 ECN and hence use packet drops to indicate congestion. 385 Congestion control is an important aspect of the Internet 386 architecture, see [RFC2914] for further discussion. 388 In general, marking packets with different DSCPs results in different 389 PHBs being applied at network nodes, making reordering possible due 390 to use of different pools of forwarding resources for each PHB. The 391 primary exception is that reordering is prohibited within each AF 392 class (e.g., AF1x), as the three PHBs in an AF class differ solely in 393 drop precedence. Reordering within a PHB or AF class may occur for 394 other transient reasons (e.g., route flap or ECMP rebalancing). 396 UDP is the primary transport protocol that is not sensitive to 397 reordering in the network, because it does not provide reliable 398 delivery or congestion control. On the other hand, when UDP is used 399 to encapsulate other protocols (e.g., as is the case for RTCWEB, see 400 Section 2.1), the reordering considerations for the encapsulated 401 protocols apply. For RTCWEB example in particular, every 402 encapsulated protocol (i.e., RTP, SCTP and TCP) is sensitive to 403 reordering as further discussed in this document. 405 2.5. DiffServ, Reordering and Real-Time Communication 407 Real-time communications are also sensitive to network reordering of 408 packets. Such reordering may lead to spurious NACK generation and 409 unneeded retransmission, as is the case for reliable delivery 410 protocols (see Section Section 2.4). The degree of sensitivity 411 depends on protocol or stream timers, in contrast to reliable 412 delivery protocols that usually react to all reordering. 414 Receiver jitter buffers have important roles in the effect of 415 reordering on real time communications: 417 o Minor packet reordering that is contained within a jitter buffer 418 usually has no effect on rendering of the received RTP packet 419 stream. 421 o Packet reordering that exceeds the capacity of a jitter buffer can 422 cause user-perceptible quality problems (e.g., glitches, noise) 423 for delay sensitive communication, such as interactive 424 conversations. Interactive real-time communication 425 implementations often choose to discard data that is sufficiently 426 late to prevent it from being rendered in source stream order, 427 making retransmission counterproductive. For this reason, 428 implementations of interactive real-time communication often do 429 not use retransmission. 431 o In contrast, replay of recorded media can typically uses 432 significantly larger jitter buffers than can be tolerated for 433 interactive conversations, with the result that replay is more 434 tolerant to reordering than interactive conversations. The size 435 of the jitter buffer imposes an upper bound on replay tolerance to 436 reordering, but does enable retransmission to be used when the 437 jitter buffer is significantly larger than the amount of data that 438 will arrive during the round-trip latency for retransmission. 440 Network packet reordering caused by use of different DSCPs has no 441 effective upper bound, and can exceed the size of any reasonable 442 jitter buffer - in practice, the size of jitter buffers for replay is 443 limited by external factors such as the amount of time that a human 444 is willing to wait for replay to start. 446 2.6. Traffic Classifiers and DSCP Remarking 448 DSCP markings are not end-to-end in general. Each network can make 449 its own decisions about what PHBs to use and which DSCP maps to each 450 PHB. While every PHB specification includes a recommended DSCP, and 451 RFC 4594 [RFC4594] recommends their end-to-end usage, there is no 452 requirement that every network support any PHBs or use any DSCPs, 453 with the exception of the class selector codepoint requirements in 454 RFC 2474 [RFC2474]. When DiffServ is used, the edge or boundary 455 nodes of a network are responsible for ensuring that all traffic 456 entering that network conforms to that network's policies for DSCP 457 and PHB usage, and such nodes remark traffic (change the DSCP marking 458 as part of traffic conditioning) accordingly. As a result, DSCP 459 remarking is possible at any network boundary, including the first 460 network node that traffic sent by a host encounters. Remarking is 461 also possible within a network, e.g., for traffic shaping. 463 DSCP remarking is part of traffic conditioning; the traffic 464 conditioning functionality applied to packets at a network node is 465 determined by a traffic classifier [RFC2475]. Edge nodes of a 466 DiffServ network classify traffic based on selected packet header 467 fields; typical implementations do not look beyond the traffic's 468 5-tuple in the IP and transport protocol headers. As a result, when 469 multiple DSCPs are used for traffic that shares a 5-tuple, remarking 470 at a network boundary may result in all of the traffic being 471 forwarded with a single DSCP, thereby removing any differentiation 472 within the 5-tuple downstream of the remarking location. Network 473 nodes within a DiffServ network generally classify traffic based 474 solely on DSCPs, but may perform finer grain traffic conditioning 475 similar to that performed by edge nodes. 477 So, for two arbitrary network endpoints, there can be no assurance 478 that the DSCP set at the source endpoint will be preserved and 479 presented at the destination endpoint. On the contrary, it is quite 480 likely that the DSCP will be set to zero (e.g., at the boundary of a 481 network operator that distrusts or does not use the DSCP field) or to 482 a value deemed suitable by an ingress (MF) classifier for whatever 483 5-tuple it carries. DiffServ classifiers generally ignore embedded 484 protocol headers (e.g., for SCTP or RTP embedded in UDP, 485 classification will be only on the outer UDP header). 487 In addition, remarking may remove application-level distinctions in 488 forwarding behavior - e.g., if multiple PHBs within an AF class are 489 used to distinguish different types of frames within a video RTP 490 packet stream, token-bucket-based remarkers operating in Color-Blind 491 mode (see [RFC2697] and [RFC2698] for examples) may remark solely 492 based on flow rate and burst behavior, removing the drop precedence 493 distinctions specified by the source. 495 Backbone and other carrier networks may employ a small number of 496 DSCPs (e.g., less than half a dozen) in order to manage a small 497 number of traffic aggregates; hosts that use a larger number of DSCPs 498 can expect to find that much of their intended differentiation is 499 removed by such networks. Better results may be achieved when DSCPs 500 are used to spread traffic among a smaller number of DiffServ-based 501 traffic subsets or aggregates, see [I-D.geib-tsvwg-diffserv-intercon] 502 for one proposal. This is of particular importance for MPLS-based 503 networks due to the limited size of the Traffic Class (TC) field in 504 an MPLS label [RFC5462] that is used to carry DiffServ information 505 and the use of that TC field for other purposes, e.g., ECN [RFC5129]. 506 For further discussion on use of DiffServ with MPLS, see [RFC3270] 507 and [RFC5127]. 509 3. RTP Multiplexing Background 511 Section 2 explains how source streams can be multiplexed over RTP 512 sessions which can in turn be multiplexed over UDP with packets 513 generated by other transport protocols. This section provides 514 background on why this level of multiplexing is desirable. The 515 rationale in this section applies both to multiplexing of source 516 streams in RTP sessions and multiplexing of an RTP session with 517 traffic from other transport protocols via UDP encapsulation. 519 Multiplexing reduces the number of ports utilized for real-time and 520 related communication in an overall interaction. While a single 521 endpoint might have plenty of ports available for communication, this 522 traffic often traverses points in the network that are constrained on 523 the number of available ports. A good example is a NAT/FW device 524 sitting at the network edge. As the number of simultaneous protocol 525 sessions increases, so does the burden placed on these devices in 526 order to provide port mapping. 528 Another reason for multiplexing is to help reduce the time required 529 to establish bi-directional communication. Since any two 530 communicating users might be situated behind different NAT/FW 531 devices, it is necessary to employ techniques like STUN/ICE/TURN in 532 order to get traffic to flow between the two devices 533 [I-D.ietf-rtcweb-transports]. Performing the tasks required of 534 STUN/ICE/TURN take time and requiring an endpoint to perform these 535 tasks for multiple protocol sessions can increase the time required. 536 While tasks for different sessions can be performed in parallel, it 537 is nonetheless necessary for applications to wait for all sessions to 538 be opened before communication between to users can begin. Reducing 539 the number of STUN/ICE/TURN steps reduces the probability of losing a 540 packet and introducing delay in setting up a communication session. 541 Further, reducing the number of STUN/ICE/TURN tasks means that there 542 is a lower burden placed on the STUN and TURN servers. 544 Multiplexing may reduce the complexity and resulting load on an 545 endpoint. A single instance of STUN/ICE/TURN is simpler to execute 546 and manage than multiple instances STUN/ICE/TURN operations happening 547 in parallel, as the latter require synchronization and create more 548 complex failure situations that have to be cleaned up by additional 549 code. 551 4. Recommendations 553 The only standardized use of multiple PHBs and DSCPs that avoids 554 network reordering among packets marked with different DSCPs is use 555 of PHBs within a single AF class. All other uses of multiple PHBs 556 and/or the class selector DSCPs allow network reordering of packets 557 that are marked with different DSCPs. Based on this and the 558 foregoing discussion, the following requirements apply to use of 559 DiffServ with real-time communications - applications and other 560 traffic sources: 562 o SHOULD NOT use different PHBs and DSCPs that may cause reordering 563 within a single RTP packet stream. If this is not done, 564 significant network reordering may overwhelm implementation 565 assumptions about limits on reordering, e.g., jitter buffer size, 566 causing poor user experiences, see Section Section 2.5 above. 568 o SHOULD NOT use different PHBs and DSCPs that may cause reordering 569 within an ordered session for a reliable transport protocol (e.g., 570 TCP, SCTP). Receivers for such protocols interpret reordering as 571 indicating loss of out-of-order packets causing undesired 572 retransmission requests, and will infer congestion from 573 significant reordering, causing throughput reduction. This 574 requirement applies to both unencapsulated and encapsulated (e.g., 575 via UDP) uses of reliable transport protocols. 577 o MAY use different PHBs and DSCPs that cause reordering within a 578 single UDP 5-tuple, subject to the above constraints. The service 579 differentiation provided by such usage is unreliable, as it may be 580 removed at network boundaries for the reasons described in 581 Section 2.6 above. 583 o MUST NOT rely on end-to-end preservation of DSCPs as network node 584 remarking can change DSCPs and remove drop precedence distinctions 585 see Section 2.6 above. For example, if a source uses drop 586 precedence distinctions within an AF class to identify different 587 types of video frames, using those DSCP values at the receiver to 588 identify frame type is inherently unreliable. 590 o SHOULD use the CS1 codepoint only for traffic that is acceptable 591 to forward as best effort traffic, as network support for use of 592 CS1 to select a "less than best effort" PHB is inconsistent. 593 Further, some networks may treat CS1 as providing "better than 594 best effort" forwarding behavior. 596 There is no requirement in this document for network operators to 597 differentiate traffic in any fashion. Networks may support all of 598 the PHBs discussed herein, classify EF and AFxx traffic identically, 599 or even remark all traffic to best effort at some ingress points. 600 Nonetheless, it is useful for network endpoints to provide finer 601 granularity DSCP marking on packets for the benefit of networks that 602 offer QoS service differentiation. A specific example is that 603 traffic originating from a browser may benefit from QoS service 604 differentiation in within-building and residential access networks, 605 even if the DSCP marking is subsequently removed or simplified. This 606 is because such networks and the boundaries between them are likely 607 traffic bottleneck locations (e.g., due to customer aggregation onto 608 common links and/or speed differences among links used by the same 609 traffic). 611 5. Examples 613 For real-time communications, one might want to mark the audio 614 packets using EF and the video packets as AF41. However, in a video 615 conference receiving the audio packets ahead of the video is not 616 useful because lip sync is necessary between audio and video. It may 617 still be desirable to send audio with a PHB that provides better 618 service, because early arrival of audio helps assure smooth audio 619 rendering, which is often more important than fully faithful video 620 rendering. There are also limits, as some devices have difficulties 621 in synchronizing voice and video when packets that need to be 622 rendered together arrive at significantly different times. It makes 623 more sense to use different PHBs when the audio and video source 624 streams do not share a strict timing relationship. For example, 625 video content may be shared within a video conference via playback, 626 perhaps of an unedited video clip that is intended to become part of 627 a television advertisement. Such content sharing video does not need 628 precise synchronization with video conference audio, and could use a 629 different PHB, as content sharing video is more tolerant to jitter, 630 loss, and delay. 632 Within a layered video RTP packet stream, ordering of frame 633 communication is preferred, but importance of frame types varies, 634 making use of PHBs with different drop precedences appropriate. For 635 example, I-frames that contain an entire image are usually more 636 important than P-frames that contain only changes from the previous 637 image because loss of a P-frame (or part thereof) can be recovered 638 (at the latest) via the next I-frame, whereas loss of an I-frame (or 639 part thereof) may cause rendering problems for all of the P-frames 640 that depend on the I-frame. For this reason, it is appropriate to 641 mark I-frame packets with a PHB that has lower drop precedence than 642 the PHB used for P-frames, as long as the PHBs preserve ordering 643 among frames (e.g., are in an AF class) - AF41 for I-frames and AF43 644 for P-frames is one possibility. Additional spatial and temporal 645 layers beyond the base video layer could also be marked with higher 646 drop precedence than the base video layer, as their loss reduces 647 video quality, but does not disrupt video rendering. 649 Additional RTP packet streams in a real-time communication 650 interaction could be marked with CS0 and carried as best effort 651 traffic. One example is real-time text transmitted as specified in 652 RFC 4103[RFC4103]; best effort forwarding suffices when redundancy 653 encoding is used (as required by RFC 4103). Best effort forwarding 654 suffices because such real-time text has loose timing requirements; 655 RFC 4103 recommends sending text in chunks every 300ms. Such text is 656 technically real-time, but does not need a PHB promising better 657 service than best effort, in contrast to audio or video. 659 6. IANA Considerations 661 This document includes no request to IANA. 663 7. Security Considerations 665 The security considerations for all of the technologies discussed in 666 this document apply; in particular see the security considerations 667 for RTP in [RFC3550] and DiffServ in [RFC2474] and [RFC2475]. 669 Multiplexing of multiple protocols onto a single UDP 5-tuple via 670 encapsulation has implications for network functionality that is 671 based on monitoring or inspection of individual protocol flows, e.g., 672 firewalls and traffic monitoring systems. When implementations of 673 such functionality lack visibility into encapsulated traffic (likely 674 for many current implementations), it may be difficult or impossible 675 to apply network security policy and controls at a finer grain than 676 the overall UDP 5-tuple. 678 Use of multiple DSCPs to provide differentiated QoS service may 679 reveal information about the encrypted traffic to which different 680 service levels are provided. For example, DSCP-based identification 681 of RTP packet streams combined with packet frequency and packet size 682 could reveal the type or nature of the encrypted source streams. The 683 IP header used for forwarding has to be unencrypted for obvious 684 reasons, and the DSCP likewise has to be unencrypted in order to 685 enable different IP forwarding behaviors to be applied to different 686 packets. The nature of encrypted traffic components can be disguised 687 via encrypted dummy data padding and encrypted dummy packets, e.g., 688 see the discussion of traffic flow confidentiality in [RFC4303]. 689 Encrypted dummy packets could even be added in a fashion that an 690 observer of the overall encrypted traffic might mistake for another 691 encrypted RTP packet stream. 693 8. Acknowledgements 695 This document is the result of many conversations that have occurred 696 within multiple working groups in the RAI and Transport areas. Many 697 thanks to Harald Alvestrand, Erin Bournival, Brian Carpenter, 698 Ruediger Geib and James Polk for their reviews and input. 700 9. References 702 9.1. Normative References 704 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 705 Requirement Levels", BCP 14, RFC 2119, March 1997. 707 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 708 "Definition of the Differentiated Services Field (DS 709 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 710 1998. 712 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 713 "Assured Forwarding PHB Group", RFC 2597, June 1999. 715 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 716 J., Courtney, W., Davari, S., Firoiu, V., and D. 717 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 718 Behavior)", RFC 3246, March 2002. 720 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 721 Jacobson, "RTP: A Transport Protocol for Real-Time 722 Applications", STD 64, RFC 3550, July 2003. 724 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 725 Per-Domain Behavior (PDB) for Differentiated Services", 726 RFC 3662, December 2003. 728 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 729 Services Code Point (DSCP) for Capacity-Admitted Traffic", 730 RFC 5865, May 2010. 732 9.2. Informative References 734 [I-D.geib-tsvwg-diffserv-intercon] 735 Geib, R., "DiffServ interconnection classes and practice", 736 draft-geib-tsvwg-diffserv-intercon-05 (work in progress), 737 February 2014. 739 [I-D.ietf-avtext-rtp-grouping-taxonomy] 740 Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, 741 "A Taxonomy of Grouping Semantics and Mechanisms for Real- 742 Time Transport Protocol (RTP) Sources", draft-ietf-avtext- 743 rtp-grouping-taxonomy-01 (work in progress), February 744 2014. 746 [I-D.ietf-rtcweb-overview] 747 Alvestrand, H., "Overview: Real Time Protocols for Brower- 748 based Applications", draft-ietf-rtcweb-overview-09 (work 749 in progress), February 2014. 751 [I-D.ietf-rtcweb-rtp-usage] 752 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 753 Communication (WebRTC): Media Transport and Use of RTP", 754 draft-ietf-rtcweb-rtp-usage-15 (work in progress), May 755 2014. 757 [I-D.ietf-rtcweb-transports] 758 Alvestrand, H., "Transports for RTCWEB", draft-ietf- 759 rtcweb-transports-04 (work in progress), April 2014. 761 [I-D.petithuguenin-avtcore-rfc5764-mux-fixes] 762 Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme 763 Updates for Secure Real-time Transport Protocol (SRTP) 764 Extension for Datagram Transport Layer Security (DTLS)", 765 draft-petithuguenin-avtcore-rfc5764-mux-fixes-00 (work in 766 progress), July 2014. 768 [I-D.westerlund-avtcore-transport-multiplexing] 769 Westerlund, M. and C. Perkins, "Multiplexing Multiple RTP 770 Sessions onto a Single Lower-Layer Transport", draft- 771 westerlund-avtcore-transport-multiplexing-07 (work in 772 progress), October 2013. 774 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 775 and W. Weiss, "An Architecture for Differentiated 776 Services", RFC 2475, December 1998. 778 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 779 Marker", RFC 2697, September 1999. 781 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 782 Marker", RFC 2698, September 1999. 784 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 785 2914, September 2000. 787 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 788 of Explicit Congestion Notification (ECN) to IP", RFC 789 3168, September 2001. 791 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 792 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 793 Protocol Label Switching (MPLS) Support of Differentiated 794 Services", RFC 3270, May 2002. 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 Authors' Addresses 864 Dan York 865 Internet Society 866 Keene, N.H. 867 USA 869 Phone: +1-802-735-1624 870 Email: dyork@lodestar2.com 872 David Black (editor) 873 EMC 874 176 South Street 875 Hopkinton, MA 01748 876 USA 878 Phone: +1 508 293-7953 879 Email: david.black@emc.com 881 Cullen Jennings 882 Cisco 883 170 West Tasman Drive 884 MS: SJC-21/2 885 San Jose, CA 95134 886 USA 888 Phone: +1 408 421-9990 889 Email: fluffy@cisco.com 891 Paul Jones 892 Cisco 893 7025 Kit Creek Road 894 Research Triangle Park, MA 27502 895 USA 897 Phone: +1 919 476 2048 898 Email: paulej@cisco.com