idnits 2.17.1 draft-ietf-dart-dscp-rtp-00.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 31, 2014) is 3558 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5245' is defined on line 949, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-petithuguenin-avtcore-rfc5764-mux-fixes-00 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 3662 (Obsoleted by RFC 8622) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-08) exists of draft-geib-tsvwg-diffserv-intercon-06 == Outdated reference: A later version (-12) exists of draft-ietf-avtcore-rtp-multi-stream-optimisation-03 == Outdated reference: A later version (-08) exists of draft-ietf-avtext-rtp-grouping-taxonomy-02 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-07 == Outdated reference: A later version (-09) exists of draft-ietf-rmcat-cc-requirements-05 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-10 == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-rtp-usage-15 == Outdated reference: A later version (-17) exists of draft-ietf-rtcweb-transports-05 == Outdated reference: A later version (-05) exists of draft-welzl-rmcat-coupled-cc-03 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) Summary: 3 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DiffServ Applied to Real-time Transports D. Black, Ed. 3 Internet-Draft EMC 4 Intended status: Informational P. Jones 5 Expires: February 1, 2015 Cisco 6 July 31, 2014 8 Differentiated Services (DiffServ) and Real-time Communication 9 draft-ietf-dart-dscp-rtp-00 11 Abstract 13 This document describes the interaction between Differentiated 14 Services (DiffServ) network quality of service (QoS) functionality 15 and real-time network communication, including communication based on 16 the Real-time Transport Protocol (RTP). DiffServ is based on network 17 nodes applying different forwarding treatments to packets whose IP 18 headers are marked with different DiffServ Code Points (DSCPs). As a 19 result, use of different DSCPs within a single traffic stream may 20 cause transport protocol interactions (e.g., reordering). In 21 addition, DSCP markings may be changed or removed between the traffic 22 source and destination. This document covers the implications of 23 these DiffServ aspects for real-time network communication, including 24 RTCWEB. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 1, 2015. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. RTP Background . . . . . . . . . . . . . . . . . . . . . 3 63 2.2. Differentiated Services (DiffServ) Background . . . . . . 5 64 2.3. Diffserv PHBs (Per-Hop Behaviors) . . . . . . . . . . . . 7 65 2.4. DiffServ, Reordering and Transport Protocols . . . . . . 8 66 2.5. DiffServ, Reordering and Real-Time Communication . . . . 9 67 2.6. Drop Precedence . . . . . . . . . . . . . . . . . . . . . 10 68 2.7. Traffic Classifiers and DSCP Remarking . . . . . . . . . 11 69 3. RTP Multiplexing Background . . . . . . . . . . . . . . . . . 13 70 4. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 77 9.2. Informative References . . . . . . . . . . . . . . . . . 19 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 80 1. Introduction 82 This document describes the interactions between Differentiated 83 Services (DiffServ) network quality of service (QoS) functionality 84 [RFC2475] and real-time network communication, including 85 communication based on the Real-time Transport Protocol (RTP) 86 [RFC3550]. DiffServ is based on network nodes applying different 87 forwarding treatments to packets whose IP headers are marked with 88 different DiffServ Code Points (DSCPs)[RFC2474]. As a result use of 89 different DSCPs within a single traffic stream may cause transport 90 protocol interactions (e.g., reordering). In addition, DSCP markings 91 may be changed or removed between the traffic's source and 92 destination. This document covers the implications of these DiffServ 93 aspects for real-time network communication, including RTCWEB traffic 94 [I-D.ietf-rtcweb-overview]. 96 2. Background 98 [Editor's Note: Current section structure draft skips around topics 99 somewhat. The editor suggestsrestructuring to put real-time/RTP 100 material first (new section 2, consisting of current sections 2, 2.1 101 and 3), then DiffServ Background (new section 3, consisting of 102 current sections 2.2, 2.3, 2.6 and 2.7, followed by discussion of 103 interactions (new section 4, consisting of current sections 2.4, 2.5 104 and 5) and guidelines (current section 4, renumbered to new section 105 5).] 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 as 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 For the RTCWEB protocol suite [I-D.ietf-rtcweb-transports], an 175 individual source stream is a MediaStreamTrack, and a MediaStream 176 contains one or more MediaStreamTracks 177 [W3C.WD-mediacapture-streams-20130903]. A MediaStreamTrack is 178 transmitted as a source RTP stream plus zero or more redundancy RTP 179 streams, so a MediaStream that consists of one MediaStreamTrack is 180 transmitted as a single source RTP stream plus zero or more 181 redundancy RTP streams. For more information on use of RTP in 182 RTCWEB, see [I-D.ietf-rtcweb-rtp-usage]. 184 Other transport protocols may also be used to transmit real-time data 185 or near-real-time data. For example, SCTP [RFC4960] can be utilized 186 to carry application sharing or whiteboarding information as part of 187 an overall interaction that includes real time media. These 188 additional transport protocols can be multiplexed with an RTP session 189 via UDP encapsulation, thereby using a single pair of UDP ports. 191 The RTCWEB protocol suite encompasses a number of forms of 192 multiplexing: 194 1. Individual source streams are carried in one or more individual 195 RTP streams that can be multiplexed into a single RTP session as 196 described in [RFC3550]; 198 2. RTCP (see [RFC3550]) may be multplexed with the RTP session as 199 described in [RFC5761]; 201 3. An RTP session could be multiplexed with other protocols via UDP 202 encapsulation over a common pair of UDP ports as described in 203 [RFC5764] as updated by 204 [I-D.petithuguenin-avtcore-rfc5764-mux-fixes]; and 206 4. The data may be further encapsulated via STUN [RFC5389] and TURN 207 [RFC5766] for NAT (Network Address Translator) traversal. 209 The resulting unidirectional UDP packet flow is identified by a 210 5-tuple, i.e., a combination of two IP addresses (source and 211 destination), two UDP ports (source and destination), and the use of 212 the UDP protocol. SDP bundle negotiation restrictions 213 [I-D.ietf-mmusic-sdp-bundle-negotiation] limit RTCWEB to using at 214 most a single DTLS session per UDP 5-tuple. In contrast, multple 215 SCTP associations can be mulitplexed over a single UDP 5-tuple 216 [RFC6951]. 218 For IPv6, addition of the flow label [RFC6437] to 5-tuples results in 219 6-tuples, but in practice, use of a flow label is unlikely to result 220 in a finer-grain traffic subset than the corresponding 5-tuple (e.g., 221 the flow label is likely to represent the combination of two ports 222 with use of the UDP protocol). For that reason, discussion in this 223 draft focuses on UDP 5-tuples. 225 2.2. Differentiated Services (DiffServ) Background 227 The DiffServ architecture is intended to enable scalable service 228 discrimination in the Internet without requiring each network node to 229 store per-flow state and participate in per-flow signaling. The 230 services may be end-to-end or within a network; they include both 231 those that can satisfy quantitative performance requirements (e.g., 232 peak bandwidth) and those based on relative performance (e.g., 233 "class" differentiation). Services can be constructed by a 234 combination of well-defined building blocks deployed in network nodes 235 that: 237 o classify traffic and set bits in an IP header field at network 238 boundaries or hosts, 240 o use those bits to determine how packets are forwarded by the nodes 241 inside the network, and 243 o condition the marked packets (e.g., meter, mark, shape, police) at 244 network boundaries in accordance with the requirements or rules of 245 each service. 247 A network node that supports DiffServ includes a classifier that 248 selects packets based on the value of the DS field in IP headers, 249 along with buffer management and packet scheduling mechanisms capable 250 of delivering the specific packet forwarding treatment indicated by 251 the DS field value. Setting of the DS field and fine-grain 252 conditioning of marked packets need only be performed at network 253 boundaries; internal network nodes operate on traffic aggregates that 254 share a DS field value, or in some cases, a small set of related 255 values. 257 The DiffServ architecture[RFC2475] maintains distinctions among: 259 o the QoS service provided to a traffic aggregate, 261 o the conditioning functions and per-hop behaviors (PHBs) used to 262 realize services, 264 o the DS field value (DS codepoint, or DSCP) in the IP header used 265 to mark packets to select a per-hop behavior, and 267 o the particular implementation mechanisms that realize a per-hop 268 behavior. 270 This document focuses on PHBs and the usage of DSCPs to obtain those 271 behaviors. In a network node's forwarding path, the DSCP is used to 272 map a packet to a particular forwarding treatment, or per-hop 273 behavior (PHB) that specifies the forwarding treatment. 275 A per-hop behavior (PHB) is a description of the externally 276 observable forwarding behavior of a network node for network traffic 277 marked with a DSCP that selects that PHB. In this context, 278 "forwarding behavior" is a general concept - for example, if only one 279 DSCP is used for all traffic on a link, the observable forwarding 280 behavior (e.g., loss, delay, jitter) will often depend only on the 281 relative loading of the link. To obtain useful behavioral 282 differentiation, multiple traffic subsets are marked with different 283 DSCPs for different PHBs for which node resources such as buffer 284 space and bandwidth are allocated. PHBs provide the framework for a 285 DiffServ network node to allocate resources to traffic subsets, with 286 network-scope differentiated services constructed on top of this 287 basic hop-by-hop (per-node) resource allocation mechanism. 289 The codepoints (DSCPs) may be chosen from a small set of fixed values 290 (the class selector codepoints), or from a set of recommended values 291 defined in PHB specifications, or from values that have purely local 292 meanings to a specific network that supports DiffServ; in general, 293 packets may be forwarded across multiple such networks between source 294 and destination. 296 The mandatory DSCPs are the class selector code points as specified 297 in [RFC2474]. The class selector codepoints (CS0-CS7) extend the 298 deprecated concept of IP Precedence in the IPv4 header; three bits 299 are added, so that the class selector DSCPs are of the form 'xxx000'. 300 The all-zero DSCP ('000000' or CS0) designates a Default PHB that 301 provides best-effort forwarding behavior and the remaining class 302 selector code points are intended to provide relatively better per- 303 hop-forwarding behavior in increasing numerical order, but: 305 o There is no requirement that any two adjacent class selector 306 codepoints select different PHBs; adjacent class selector 307 codepoints may use the same pool of resources on each network node 308 in some networks. This generalizes to ranges of class selector 309 codepoints, but with limits - for example CS6 and CS7 are often 310 used for network control (e.g., routing) traffic [RFC4594] and 311 hence are likely to provide better forwarding behavior under 312 network load in order to prioritize network recovery from 313 disruptions. 315 o CS1 ('001000') was subsequently designated as the recommended 316 codepoint for the Lower Effort (LE) PHB [RFC3662]. An LE service 317 forwards traffic with "lower" priority than best effort and can be 318 "starved" by best effort and other "higher" priority traffic. Not 319 all networks offer an LE service. See [RFC3662] for further 320 discussion of the LE PHB and service. 322 Applications and traffic sources cannot rely upon different class 323 selector codepoints providing differentiated services or upon the 324 presence of an LE service that is selected by the CS1 DSCP. There is 325 no effective way for a network endpoint to determine whether the CS1 326 DSCP selects an LE service on a specific network, let alone end-to- 327 end. Packets marked with the CS1 DSCP may be forwarded with best 328 effort service or another "higher" priority service, see [RFC2474]. 330 2.3. Diffserv PHBs (Per-Hop Behaviors) 332 Although Differentiated Services is a general architecture that may 333 be used to implement a variety of services, three fundamental 334 forwarding behaviors (PHBs) have been defined and characterized for 335 general use. These are: 337 1. Default Forwarding (DF) for elastic traffic [RFC2474]. The 338 Default PHB is always selected by the all-zero DSCP. 340 2. Assured Forwarding (AF) [RFC2597] to provide differentiated 341 service to elastic traffic. Each instance of the AF behavior 342 consists of three PHBs that differ only in drop precedence, e.g., 343 AF11, AF12 and AF13; such a set of three AF PHBs is referred to 344 as an AF class, e.g., AF1x. There are four defined AF classes, 345 AF1x through AF4x, with higher numbered classes intended to 346 receive better forwarding treatment than lower numbered classes. 348 3. Expedited Forwarding (EF) [RFC3246] intended for inelastic 349 traffic. Beyond the basic EF PHB, the VOICE-ADMIT PHB [RFC5865] 350 is an admission controlled variant of the EF PHB. 352 2.4. DiffServ, Reordering and Transport Protocols 354 [Editor's note: Add a sentence or two on DCCP - it is not necessary 355 to include every known transport protocol.] 357 Transport protocols provide data communication behaviors beyond those 358 possible at the IP layer. An important example is that TCP [RFC0793] 359 provides reliable in-order delivery of data with congestion control. 360 SCTP [RFC4960] provides additional properties such as preservation of 361 message boundaries, and the ability to avoid head-of-line blocking 362 that may occur with TCP. In contrast, UDP [RFC0768] is a basic 363 unreliable datagram protocol that provides port-based multiplexing 364 and demultiplexing on 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, the protocol usually assumes that the expected 370 packet has been lost and respond with a retransmission request for 371 that packet. In addition, congestion control functionality in 372 transport protocols usually infers congestion when packets are lost, 373 creating an additional sensitivity to significant reordering - such 374 reordering may be (mis-)interpreted as indicating congestion-caused 375 packet loss, causing a reduction in transmission rate. This remains 376 true even when ECN [RFC3168] is in use, as ECN receivers are required 377 to treat missing packets as potential indications of congestion. 378 This requirement is based on two factors: 380 o Severe congestion may cause ECN-capable network nodes to drop 381 packets, and 383 o ECN traffic may be forwarded by network nodes that do not support 384 ECN and hence use packet drops to indicate congestion. 386 Congestion control is an important aspect of the Internet 387 architecture, see [RFC2914] for further discussion. 389 In general, marking packets with different DSCPs results in different 390 PHBs being applied at network nodes, making reordering possible due 391 to use of different pools of forwarding resources for each PHB. The 392 primary exception is that reordering is prohibited within each AF 393 class (e.g., AF1x), as the three PHBs in an AF class differ solely in 394 drop precedence. Reordering within a PHB or AF class may occur for 395 other transient reasons (e.g., route flap or ECMP rebalancing). 397 Reordering also affects other forms of congestion control, such as 398 techniques for RTP congestion control that were under development 399 when this document was published, see 400 [I-D.ietf-rmcat-cc-requirements] for requirements. These techniques 401 prefer use of a common (coupled) congestion controller for RTP 402 streams between the same endpoints in order to reduce packet loss and 403 delay by reducing competition for resources at any shared bottleneck. 405 Shared bottlenecks can be detected via correlations of measured 406 metrics such as one-way delay. An alternative approach assumes that 407 the set of packets on a single 5-tuple marked with DSCPs that do not 408 allow reordering will utilize a common network path and common 409 forwarding resources at each network node. Under that assumption, 410 any bottleneck encountered by such packets is shared among all of 411 them, making it safe to use a common (coupled) congestion controller, 412 see [I-D.welzl-rmcat-coupled-cc]. This is not a safe assumption when 413 the packets involved are marked with DSCP values that allow 414 reordering because a bottleneck may not be shared among all such 415 packets (e.g., if the DSCPs result in use of different queues at a 416 network node, only one of which is a bottleneck). 418 UDP is the primary transport protocol that is not sensitive to 419 reordering in the network, because it does not provide reliable 420 delivery or congestion control. On the other hand, when UDP is used 421 to encapsulate other protocols (e.g., as is the case for RTCWEB, see 422 Section 2.1), the reordering considerations for the encapsulated 423 protocols apply. For the specific usage of UDP by RTCWEB, every 424 encapsulated protocol (i.e., RTP, SCTP and TCP) is sensitive to 425 reordering as further discussed in this document. 427 2.5. DiffServ, Reordering and Real-Time Communication 429 Real-time communications are also sensitive to network reordering of 430 packets. Such reordering may lead to spurious NACK generation and 431 unneeded retransmission, as is the case for reliable delivery 432 protocols (see Section 2.4). The degree of sensitivity depends on 433 protocol or stream timers, in contrast to reliable delivery protocols 434 that usually react to all reordering. 436 Receiver jitter buffers have important roles in the effect of 437 reordering on real time communications: 439 o Minor packet reordering that is contained within a jitter buffer 440 usually has no effect on rendering of the received RTP stream. 442 o Packet reordering that exceeds the capacity of a jitter buffer can 443 cause user-perceptible quality problems (e.g., glitches, noise) 444 for delay sensitive communication, such as interactive 445 conversations. Interactive real-time communication 446 implementations often discard data that is sufficiently late that 447 it cannot be rendered in source stream order, making 448 retransmission counterproductive. For this reason, 449 implementations of interactive real-time communication often do 450 not use retransmission. 452 o In contrast, replay of recorded media can tolerate signficantly 453 longer delays than interactive conversations, so replay is likely 454 to use larger jitter buffers than interactive conversations. 455 These larger jitter buffers increase the tolerance of replay to 456 reordering by comparison to interactive conversations. The size 457 of the jitter buffer imposes an upper bound on replay tolerance to 458 reordering, but does enable retransmission to be used when the 459 jitter buffer is significantly larger than the amount of data that 460 can be expected to arrive during the round-trip latency for 461 retransmission. 463 Network packet reordering caused by use of different DSCPs has no 464 effective upper bound, and can exceed the size of any reasonable 465 jitter buffer - in practice, the size of jitter buffers for replay is 466 limited by external factors such as the amount of time that a human 467 is willing to wait for replay to start. 469 2.6. Drop Precedence 471 Each DiffServ AF class consists of three PHBs that differ solely in 472 drop precedence (e.g., AF3x consists of AF31, AF32 and AF33). 473 Reordering is prohibited among packets on the same 5-tuple that use 474 PHBs within a single AF class; further, these packets can be expected 475 to draw upon the same forwarding resources on network nodes (e.g., 476 use the same router queue) and hence use of multple drop precedences 477 within an AF class is not expected to impact latency. 479 When PHBs within a single AF class are mixed for a protocol session, 480 the resulting drop likelihood is a mix of the drop likelihoods of the 481 PHBs involved. The primary effect of multiple drop precedences is to 482 influence decisions on what to drop with the goal that less important 483 packets are dropped in preference to more important packets. 485 There are situations in which drop precedences should not be mixed. 486 A simple example is that there is little value in mixing drop 487 precedences iwthin a TCP connection, because TCP's ordered delivery 488 behavior results in any drop requiring the receiver to wait for the 489 dropped packet to be retransmitted. Any resulting delay depends on 490 the RTT and not the packe that was dropped. Hence a single PHB and 491 DSCP should be used for all packets in a TCP connection. 493 SCTP [RFC4960] differs from TCP in a number of ways, including the 494 ability to deliver messages in an order that differs from the order 495 in which they were sent and support for unreliable streams. However, 496 SCTP performs congestion control and retransmission across the entire 497 association, and not on a per-stream basis. Although there may be 498 advantages to using multiple drop precedence across SCTP streams or 499 within an SCTP stream that does not use reliable ordered delivery, 500 there is no practical operational experience in doing so (e.g., the 501 SCTP sockets API [RFC6458] does not support use of more than one DSCP 502 for an SCTP association). As a consequence, the impacts on SCTP 503 protocol and implementation behavior are unknown and difficult to 504 predict. Hence a single PHB and DSCP should be used for all packets 505 in an SCTP association, independent of the number or nature of 506 streams in that association. 508 RTCP multi-stream reporting optimizations for an RTP session 509 [I-D.ietf-avtcore-rtp-multi-stream-optimisation] assume that the RTP 510 streams involved experience the same packet loss behavior. This 511 mechanism is highly inappropriate if the RTP streams involved use 512 different PHBs, even if those PHBs differ solely in drop precedence. 514 2.7. Traffic Classifiers and DSCP Remarking 516 DSCP markings are not end-to-end in general. Each network can make 517 its own decisions about what PHBs to use and which DSCP maps to each 518 PHB. While every PHB specification includes a recommended DSCP, and 519 RFC 4594 [RFC4594] recommends their end-to-end usage, there is no 520 requirement that every network support any PHBs or use any specific 521 DSCPs, with the exception of the class selector codepoint 522 requirements in RFC 2474 [RFC2474]. When DiffServ is used, the edge 523 or boundary nodes of a network are responsible for ensuring that all 524 traffic entering that network conforms to that network's policies for 525 DSCP and PHB usage, and such nodes remark traffic (change the DSCP 526 marking as part of traffic conditioning) accordingly. As a result, 527 DSCP remarking is possible at any network boundary, including the 528 first network node that traffic sent by a host encounters. Remarking 529 is also possible within a network, e.g., for traffic shaping. 531 DSCP remarking is part of traffic conditioning; the traffic 532 conditioning functionality applied to packets at a network node is 533 determined by a traffic classifier [RFC2475]. Edge nodes of a 534 DiffServ network classify traffic based on selected packet header 535 fields; typical implementations do not look beyond the traffic's 536 5-tuple in the IP and transport protocol headers. As a result, when 537 multiple DSCPs are used for traffic that shares a 5-tuple, remarking 538 at a network boundary may result in all of the traffic being 539 forwarded with a single DSCP, thereby removing any differentiation 540 within the 5-tuple downstream of the remarking location. Network 541 nodes within a DiffServ network generally classify traffic based 542 solely on DSCPs, but may perform finer grain traffic conditioning 543 similar to that performed by edge nodes. 545 So, for two arbitrary network endpoints, there can be no assurance 546 that the DSCP set at the source endpoint will be preserved and 547 presented at the destination endpoint. Rather, it is quite likely 548 that the DSCP will be set to zero (e.g., at the boundary of a network 549 operator that distrusts or does not use the DSCP field) or to a value 550 deemed suitable by an ingress classifier for whatever 5-tuple it 551 carries. DiffServ classifiers generally ignore embedded protocol 552 headers (e.g., for SCTP or RTP embedded in UDP, header-based 553 classification is unlikely to look beyond the outer UDP header). 555 In addition, remarking may remove application-level distinctions in 556 forwarding behavior - e.g., if multiple PHBs within an AF class are 557 used to distinguish different types of frames within a video RTP 558 stream, token-bucket-based remarkers operating in Color-Blind mode 559 (see [RFC2697] and [RFC2698] for examples) may remark solely based on 560 flow rate and burst behavior, removing the drop precedence 561 distinctions specified by the source. 563 Backbone and other carrier networks may employ a small number of 564 DSCPs (e.g., less than half a dozen) in order to manage a small 565 number of traffic aggregates; hosts that use a larger number of DSCPs 566 can expect to find that much of their intended differentiation is 567 removed by such networks. Better results may be achieved when DSCPs 568 are used to spread traffic among a smaller number of DiffServ-based 569 traffic subsets or aggregates, see [I-D.geib-tsvwg-diffserv-intercon] 570 for one proposal. This is of particular importance for MPLS-based 571 networks due to the limited size of the Traffic Class (TC) field in 572 an MPLS label [RFC5462] that is used to carry DiffServ information 573 and the use of that TC field for other purposes, e.g., ECN [RFC5129]. 574 For further discussion on use of DiffServ with MPLS, see [RFC3270] 575 and [RFC5127]. 577 3. RTP Multiplexing Background 579 Section 2 explains how source streams can be multiplexed over RTP 580 sessions which can in turn be multiplexed over UDP with packets 581 generated by other transport protocols. This section provides 582 background on why this level of multiplexing is desirable. The 583 rationale in this section applies both to multiplexing of source 584 streams in RTP sessions and multiplexing of an RTP session with 585 traffic from other transport protocols via UDP encapsulation. 587 Multiplexing reduces the number of ports utilized for real-time and 588 related communication in an overall interaction. While a single 589 endpoint might have plenty of ports available for communication, this 590 traffic often traverses points in the network that are constrained on 591 the number of available ports. A good example is a Network Address 592 Translator and Firewall (NAT/FW) device sitting at the network edge. 593 As the number of simultaneous protocol sessions increases, so does 594 the burden placed on these devices in order to provide port mapping. 596 The STUN [RFC5389]/ICE [RFC5245]/TURN [RFC5766]protocol family 597 provides NAT/FW traversal and port mapping for protocols (e.g., those 598 in the RTCWEB protocol suite) via communication with a relay server. 599 These protocols were originally designed for use of UDP, however, 600 they have been extended to use TCP as a transport for situations in 601 which UDP does not work [RFC6062]. 603 When TCP is selected for NAT/FW traversal, a single PHB and DSCP 604 should be used for all traffic on that TCP connection for the reasons 605 discussed in Section 2.4 and Section 2.6 above. An additional reason 606 for this recommendation is that packetization for STUN/ICE/TURN 607 occurs before passing the resulting packets to TCP; TCP 608 resegmentation may result in a different packetization on the wire, 609 breaking any association between DSCPs and specific data to which 610 they are intended to apply. 612 Another reason for multiplexing is to help reduce the time required 613 to establish bi-directional communication. Since any two 614 communicating users might be situated behind different NAT/FW 615 devices, it is necessary to employ techniques like STUN/ICE/TURN in 616 order to get traffic to flow between the two devices 617 [I-D.ietf-rtcweb-transports]. Performing the tasks required of 618 STUN/ICE/TURN take time, especially when multiple protocol sessions 619 are involved. While tasks for different sessions can be performed in 620 parallel, it is nonetheless necessary for applications to wait for 621 all sessions to be opened before communication between to users can 622 begin. Reducing the number of STUN/ICE/TURN steps reduces the 623 likelihood of loss of a packet for one of these protocols; any such 624 loss adds delay to setting up a communication session. Further, 625 reducing the number of STUN/ICE/TURN tasks places a lower burden on 626 the STUN and TURN servers. 628 Multiplexing may reduce the complexity and resulting load on an 629 endpoint. A single instance of STUN/ICE/TURN is simpler to execute 630 and manage than multiple instances STUN/ICE/TURN operations happening 631 in parallel, as the latter require synchronization and create more 632 complex failure situations that have to be cleaned up by additional 633 code. 635 4. Guidelines 637 The only use of multiple standardized PHBs and DSCPs that prevents 638 network reordering among packets marked with different DSCPs is use 639 of PHBs within a single AF class. All other uses of multiple PHBs 640 and/or the class selector DSCPs allow network reordering of packets 641 that are marked with different DSCPs. Based on this and the 642 foregoing discussion, the following requirements apply to use of 643 DiffServ with real-time communications - applications and other 644 traffic sources: 646 o Should not use different PHBs and DSCPs that allow reordering 647 within a single RTP stream. If this is not done, significant 648 network reordering may overwhelm implementation assumptions about 649 limits on reordering, e.g., jitter buffer size, causing poor user 650 experiences, see Section 2.5 above. When a common (coupled) 651 congestion controller is used across multiple RTP streams, this 652 recommendation against use of PHBs and DSCPs that allow reordering 653 applies across all of the RTP streams that are within the scope of 654 a single common (coupled) congestion controller. 656 o Should use a single PHB and DSCP for an RTCP session, primarily to 657 avoid reordering for RTCP (and because there is no compelling 658 reason for use of different drop precedences. One of the PHBs and 659 associated DSCP used for the associated RTP traffic would be an 660 appropriate choice. 662 o Should not use different PHBs and DSCPs that allow reordering 663 within a reliable transport protocol session (e.g., TCP 664 connection, SCTP association). Receivers for such protocols 665 interpret reordering as indicating loss of some of the out-of- 666 order packets; see Section 2.4. For SCTP, this requirement 667 applies across the entire SCTP association, and not just to 668 individual streams within an association because SCTP's reliable 669 transmission functionality operates on the overall association. 671 o Should use a a single PHB and DSCP for all packets in a single TCP 672 connection, and likewise for a single STP association. See 673 Section 2.6. 675 o May use different PHBs and DSCPs that cause reordering within a 676 single UDP 5-tuple, subject to the above constraints. The service 677 differentiation provided by such usage is unreliable, as it may be 678 removed at network boundaries for the reasons described in 679 Section 2.7 above. 681 o Cannot rely on end-to-end preservation of DSCPs as network node 682 remarking can change DSCPs and remove drop precedence distinctions 683 see Section 2.7 above. For example, if a source uses drop 684 precedence distinctions within an AF class to identify different 685 types of video frames, using those DSCP values at the receiver to 686 identify frame type is inherently unreliable. 688 o Should limit use of the CS1 codepoint to traffic for which best 689 effor forwarding is acceptable, as network support for use of CS1 690 to select a "less than best effort" PHB is inconsistent. Further, 691 some networks may treat CS1 as providing "better than best effort" 692 forwarding behavior. 694 There is no requirement in this document for network operators to 695 differentiate traffic in any fashion. Networks may support all of 696 the PHBs discussed herein, classify EF and AFxx traffic identically, 697 or even remark all traffic to best effort at some ingress points. 698 Nonetheless, it is useful for network endpoints to provide finer 699 granularity DSCP marking on packets for the benefit of networks that 700 offer QoS service differentiation. A specific example is that 701 traffic originating from a browser may benefit from QoS service 702 differentiation in within-building and residential access networks, 703 even if the DSCP marking is subsequently removed or simplified. This 704 is because such networks and the boundaries between them are likely 705 traffic bottleneck locations (e.g., due to customer aggregation onto 706 common links and/or speed differences among links used by the same 707 traffic). 709 [Editor's note: rtcweb-transports draft is not aligned with the 710 above. The rtcweb WG and the draft author will bring it into line.] 712 5. Examples 714 For real-time communications, one might want to mark the audio 715 packets using EF and the video packets as AF41. However, in a video 716 conference receiving the audio packets ahead of the video is not 717 useful because lip sync is necessary between audio and video. It may 718 still be desirable to send audio with a PHB that provides better 719 service, because early arrival of audio helps assure smooth audio 720 rendering, which is often more important than fully faithful video 721 rendering. There are also limits, as some devices have difficulties 722 in synchronizing voice and video when packets that need to be 723 rendered together arrive at significantly different times. It makes 724 more sense to use different PHBs when the audio and video source 725 streams do not share a strict timing relationship. For example, 726 video content may be shared within a video conference via playback, 727 perhaps of an unedited video clip that is intended to become part of 728 a television advertisement. Such content sharing video does not need 729 precise synchronization with video conference audio, and could use a 730 different PHB, as content sharing video is more tolerant to jitter, 731 loss, and delay. 733 Within a layered video RTP stream, ordering of frame communication is 734 preferred, but importance of frame types varies, making use of PHBs 735 with different drop precedences appropriate. For example, I-frames 736 that contain an entire image are usually more important than P-frames 737 that contain only changes from the previous image because loss of a 738 P-frame (or part thereof) can be recovered (at the latest) via the 739 next I-frame, whereas loss of an I-frame (or part thereof) may cause 740 rendering problems for all of the P-frames that depend on the missing 741 I-frame. For this reason, it is appropriate to mark I-frame packets 742 with a PHB that has lower drop precedence than the PHB used for 743 P-frames, as long as the PHBs preserve ordering among frames (e.g., 744 are in an AF class) - AF41 for I-frames and AF43 for P-frames is one 745 possibility. Additional spatial and temporal layers beyond the base 746 video layer could also be marked with higher drop precedence than the 747 base video layer, as their loss reduces video quality, but does not 748 disrupt video rendering. 750 Additional RTP streams in a real-time communication interaction could 751 be marked with CS0 and carried as best effort traffic. One example 752 is real-time text transmitted as specified in RFC 4103 [RFC4103]. 753 Best effort forwarding suffices because such real-time text has loose 754 timing requirements; RFC 4103 recommends sending text in chunks every 755 300ms. Such text is technically real-time, but does not need a PHB 756 promising better service than best effort, in contrast to audio or 757 video. 759 6. IANA Considerations 761 This document includes no request to IANA. 763 7. Security Considerations 765 The security considerations for all of the technologies discussed in 766 this document apply; in particular see the security considerations 767 for RTP in [RFC3550] and DiffServ in [RFC2474] and [RFC2475]. 769 Multiplexing of multiple protocols onto a single UDP 5-tuple via 770 encapsulation has implications for network functionality that 771 monitors or inspects individual protocol flows, e.g., firewalls and 772 traffic monitoring systems. When implementations of such 773 functionality lack visibility into encapsulated traffic (likely for 774 many current implementations), it may be difficult or impossible to 775 apply network security policy and associated controls at a finer 776 granularity than the overall UDP 5-tuple. 778 Use of multiple DSCPs to provide differentiated QoS service may 779 reveal information about the encrypted traffic to which different 780 service levels are provided. For example, DSCP-based identification 781 of RTP streams combined with packet frequency and packet size could 782 reveal the type or nature of the encrypted source streams. The IP 783 header used for forwarding has to be unencrypted for obvious reasons, 784 and the DSCP likewise has to be unencrypted in order to enable 785 different IP forwarding behaviors to be applied to different packets. 786 The nature of encrypted traffic components can be disguised via 787 encrypted dummy data padding and encrypted dummy packets, e.g., see 788 the discussion of traffic flow confidentiality in [RFC4303]. 789 Encrypted dummy packets could even be added in a fashion that an 790 observer of the overall encrypted traffic might mistake for another 791 encrypted RTP stream. 793 8. Acknowledgements 795 This document is the result of many conversations that have occurred 796 within the dart working group and multiple other working groups in 797 the RAI and Transport areas. Many thanks to Harald Alvestrand, Erin 798 Bournival, Brian Carpenter, Keith Drage, Ruediger Geib, Cullen 799 Jennings, Jonathan Lennox, Karen Nielsen, Colin Perkins, James Polk, 800 Michael Welzl, Dan York and DART WG participants for their reviews 801 and comments. 803 [Editor's Note: Check which references should be Normative.] 805 9. References 806 9.1. Normative References 808 [I-D.petithuguenin-avtcore-rfc5764-mux-fixes] 809 Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme 810 Updates for Secure Real-time Transport Protocol (SRTP) 811 Extension for Datagram Transport Layer Security (DTLS)", 812 draft-petithuguenin-avtcore-rfc5764-mux-fixes-00 (work in 813 progress), July 2014. 815 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 816 August 1980. 818 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 819 793, September 1981. 821 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 822 "Definition of the Differentiated Services Field (DS 823 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 824 1998. 826 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 827 "Assured Forwarding PHB Group", RFC 2597, June 1999. 829 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 830 J., Courtney, W., Davari, S., Firoiu, V., and D. 831 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 832 Behavior)", RFC 3246, March 2002. 834 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 835 Jacobson, "RTP: A Transport Protocol for Real-Time 836 Applications", STD 64, RFC 3550, July 2003. 838 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 839 Per-Domain Behavior (PDB) for Differentiated Services", 840 RFC 3662, December 2003. 842 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 843 4960, September 2007. 845 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 846 Security (DTLS) Extension to Establish Keys for the Secure 847 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 849 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 850 Services Code Point (DSCP) for Capacity-Admitted Traffic", 851 RFC 5865, May 2010. 853 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 854 Control Transmission Protocol (SCTP) Packets for End-Host 855 to End-Host Communication", RFC 6951, May 2013. 857 9.2. Informative References 859 [I-D.geib-tsvwg-diffserv-intercon] 860 Geib, R., "DiffServ interconnection classes and practice", 861 draft-geib-tsvwg-diffserv-intercon-06 (work in progress), 862 July 2014. 864 [I-D.ietf-avtcore-rtp-multi-stream-optimisation] 865 Lennox, J., Westerlund, M., Wu, W., and C. Perkins, 866 "Sending Multiple Media Streams in a Single RTP Session: 867 Grouping RTCP Reception Statistics and Other Feedback", 868 draft-ietf-avtcore-rtp-multi-stream-optimisation-03 (work 869 in progress), July 2014. 871 [I-D.ietf-avtext-rtp-grouping-taxonomy] 872 Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, 873 "A Taxonomy of Grouping Semantics and Mechanisms for Real- 874 Time Transport Protocol (RTP) Sources", draft-ietf-avtext- 875 rtp-grouping-taxonomy-02 (work in progress), June 2014. 877 [I-D.ietf-mmusic-sdp-bundle-negotiation] 878 Holmberg, C., Alvestrand, H., and C. Jennings, 879 "Negotiating Media Multiplexing Using the Session 880 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 881 negotiation-07 (work in progress), April 2014. 883 [I-D.ietf-rmcat-cc-requirements] 884 Jesup, R., "Congestion Control Requirements For RMCAT", 885 draft-ietf-rmcat-cc-requirements-05 (work in progress), 886 July 2014. 888 [I-D.ietf-rtcweb-overview] 889 Alvestrand, H., "Overview: Real Time Protocols for 890 Browser-based Applications", draft-ietf-rtcweb-overview-10 891 (work in progress), June 2014. 893 [I-D.ietf-rtcweb-rtp-usage] 894 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 895 Communication (WebRTC): Media Transport and Use of RTP", 896 draft-ietf-rtcweb-rtp-usage-15 (work in progress), May 897 2014. 899 [I-D.ietf-rtcweb-transports] 900 Alvestrand, H., "Transports for RTCWEB", draft-ietf- 901 rtcweb-transports-05 (work in progress), June 2014. 903 [I-D.welzl-rmcat-coupled-cc] 904 Welzl, M., Islam, S., and S. Gjessing, "Coupled congestion 905 control for RTP media", draft-welzl-rmcat-coupled-cc-03 906 (work in progress), May 2014. 908 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 909 and W. Weiss, "An Architecture for Differentiated 910 Services", RFC 2475, December 1998. 912 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 913 Marker", RFC 2697, September 1999. 915 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 916 Marker", RFC 2698, September 1999. 918 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 919 2914, September 2000. 921 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 922 of Explicit Congestion Notification (ECN) to IP", RFC 923 3168, September 2001. 925 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 926 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 927 Protocol Label Switching (MPLS) Support of Differentiated 928 Services", RFC 3270, May 2002. 930 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 931 Conversation", RFC 4103, June 2005. 933 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 934 4303, December 2005. 936 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 937 Guidelines for DiffServ Service Classes", RFC 4594, August 938 2006. 940 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 941 Correction", RFC 5109, December 2007. 943 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 944 Diffserv Service Classes", RFC 5127, February 2008. 946 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 947 Marking in MPLS", RFC 5129, January 2008. 949 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 950 (ICE): A Protocol for Network Address Translator (NAT) 951 Traversal for Offer/Answer Protocols", RFC 5245, April 952 2010. 954 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 955 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 956 October 2008. 958 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 959 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 960 Class" Field", RFC 5462, February 2009. 962 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 963 Control Packets on a Single Port", RFC 5761, April 2010. 965 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 966 Relays around NAT (TURN): Relay Extensions to Session 967 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 969 [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays 970 around NAT (TURN) Extensions for TCP Allocations", RFC 971 6062, November 2010. 973 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 974 "IPv6 Flow Label Specification", RFC 6437, November 2011. 976 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 977 Yasevich, "Sockets API Extensions for the Stream Control 978 Transmission Protocol (SCTP)", RFC 6458, December 2011. 980 [W3C.WD-mediacapture-streams-20130903] 981 Burnett, D., Bergkvist, A., Jennings, C., and A. 982 Narayanan, "Media Capture and Streams", World Wide Web 983 Consortium WD WD-mediacapture-streams-20130903, September 984 2013, . 987 Appendix A. Change History 989 [To be removed before RFC publication.] 991 Changes from draft-york-dart-dscp-rtp-00 to -01 993 o Added examples (Section 5) 994 o Reworked text on RTP session multiplexing, at most one RTP session 995 can be used per UDP 5-tuple. 997 o Initial terminology alignment with RTP grouping taxonomy draft. 999 o Added Section 2.5 on real-time communication interaction w/ 1000 reordering based on text from Harald Alvestrand. 1002 o Strengthened warnings on loss of differentiation, but indicate 1003 that differentiation may still be useful from source to point of 1004 loss. 1006 o Added a few sentences on DiffServ and MPLS. 1008 o Added discussion of UDP-encapsulated protocols that are reordering 1009 sensitive. 1011 o Added initial security considerations. 1013 o Many editorial changes 1015 Changes from draft-york-dart-dscp-rtp-01 to -02 1017 o More terminology alignment with RTP grouping taxonomy draft: "RTP 1018 packet stream" -> "RTP stream" 1020 o Aligned terminology for less-than-best-effort with RFC 3662 - LE 1021 (Lower Effort) PHB and service 1023 o Minor reference updates 1025 Changes from draft-york-dart-dscp-rtp-02 to draft-ietf-dart-dscp- 1026 rtp-00 1028 o Reduce author list and convert to Informational - remove RFC 2119 1029 reference and keywords 1031 o Strengthen TCP and SCTP text. 1033 o Add section 2.6 on drop precedence. 1035 o Remove discussion of multiplexing multiple RTP sessions on a 1036 single UDP 5-tuple 1038 o Add discussions of RTCP,STUN/ICE/TURN and coupled congestion 1039 control 1041 o Many editorial changes. 1043 o Lots of additional references 1045 Authors' Addresses 1047 David Black (editor) 1048 EMC 1049 176 South Street 1050 Hopkinton, MA 01748 1051 USA 1053 Phone: +1 508 293-7953 1054 Email: david.black@emc.com 1056 Paul Jones 1057 Cisco 1058 7025 Kit Creek Road 1059 Research Triangle Park, MA 27502 1060 USA 1062 Phone: +1 919 476 2048 1063 Email: paulej@packetizer.com