idnits 2.17.1 draft-york-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 (June 6, 2014) is 3611 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 542, but no explicit reference was found in the text == 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 -- Obsolete informational reference (is this intentional?): RFC 3662 (Obsoleted by RFC 8622) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DiffServ Applied to Real-time Transports D. York, Ed. 3 Internet-Draft Internet Society 4 Intended status: Standards Track D. Black, Ed. 5 Expires: December 8, 2014 EMC 6 C. Jennings 7 P. Jones 8 Cisco 9 June 6, 2014 11 Differentiated Services (DiffServ) and Real-time Communication 12 draft-york-dart-dscp-rtp-00 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 flow may cause 23 transport protocol interactions (e.g., due to 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 December 8, 2014. 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. Differentiated Services (DiffServ) . . . . . . . . . . . 4 67 2.2. Diffserv PHBs (Per-Hop Behaviors) . . . . . . . . . . . . 6 68 2.3. DiffServ and Transport Protocols . . . . . . . . . . . . 7 69 2.4. Traffic Classifiers and DSCP Remarking . . . . . . . . . 8 70 3. RTP Multiplexing Background . . . . . . . . . . . . . . . . . 9 71 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 10 72 5. RTCWEB Examples . . . . . . . . . . . . . . . . . . . . . . . 10 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 78 9.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Introduction 83 This document describes the interactions between Differentiated 84 Services (DiffServ) network quality of service (QoS) functionality 85 [RFC2475] and real-time network communication, including 86 communication based on the Real-time Transport Protocol (RTP) 87 [RFC3550]. DiffServ is based on network nodes applying different 88 forwarding treatments to packets whose IP headers are marked with 89 different DiffServ Code Points (DSCPs)[RFC2474]. As a result use of 90 different DSCPs within a single traffic stream may cause transport 91 protocol interactions (e.g., due to reordering). In addition, DSCP 92 markings may be changed or removed between the traffic's source and 93 destination. This document covers the implications of these DiffServ 94 aspects for real-time network communication, including RTCWEB traffic 95 [I-D.ietf-rtcweb-overview]. 97 1.1. Requirements Language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [RFC2119]. 103 2. Background 105 Real-time communications enables communication in real-time over an 106 IP network using communication modalities, such as voice, video, 107 text, content sharing, etc. It is possible to utilize any one or 108 more modalities in parallel in order to provide for a richer 109 communication experience. 111 A simple example of real-time communications is a voice call placed 112 over the Internet wherein an audio flow is transmitted in each 113 direction between two users. A more complex example is an immersive 114 videoconferencing system that has multiple video screens, multiple 115 cameras, multiple microphones, and some means of sharing content. 116 For such complex systems, there may be multiple media flows that may 117 be transmitted via a single IP address and port or via multiple IP 118 addresses and ports. 120 The most common protocol used for real time media is the Real-Time 121 Transport Protocol (RTP)[RFC3550]. RTP defines the mechanism by 122 which real-time data is transmitted between hosts on the Internet. 123 With most applications, a single media type (e.g., audio) is 124 transmitted within a single RTP session. However, it is possible to 125 transmit multiple, distinct media flows over the same RTP session as 126 individual RTP packet streams. This is referred to as RTP 127 multiplexing. 129 For the purposes of this draft, the term "media flow" refers to a 130 sequence of packets that is transmitted as a single RTP packet 131 stream. 133 Other transport protocols may also be used to transmit real-time data 134 or near-real-time data. For example, SCTP might be utilized to carry 135 application sharing or whiteboarding information as part of an 136 overall interaction that includes real time media flows. These 137 additional transport protocols can be multiplexed with one or more 138 RTP sessions via UDP encapsulation, thereby using a single pair of 139 UDP ports. The RTCWEB protocol suite [I-D.ietf-rtcweb-transports] 140 employs two layers of multiplexing: 142 1. Individual media flows are carried in individual RTP packet 143 streams that can multiplexed into a single RTP session (for 144 RTCWEB,an individual media flow is a MediaStreamTrack, and a 145 MediaStream may contain multiple MediaStreamTracks 146 [W3C.WD-mediacapture-streams-20130903]); and 148 2. One or more RTP session(s) multiplexed could be multiplexed with 149 other transport protocols via UDP encapsulation over a common 150 pair of UDP ports. The resulting unidirectional UDP flow is 151 uniquely identified by a 5-tuple, i.e., a combination of two IP 152 addresses (source and destination), two UDP ports (source and 153 destination), and the use of the UDP protocol. 155 For more information on use of RTP in RTCWEB, see . 156 [I-D.ietf-rtcweb-rtp-usage]. 158 The number of media and other transport flows in an overall real-time 159 interaction can be surprisingly large. In addition to a voice flow 160 and a video flow, there could be separate media flows for each of the 161 cameras or microphones on a videoconferencing system. For each of 162 those video flows, and especially for layered video codecs, there 163 might be flows that carry spatial and temporal data separately from 164 the base layer. There might also be a separate flow that provides 165 protection to a media flow, using techniques such as Forward Error 166 Correction or redundancy. Still another example is simulcast 167 transmission, where a video flow can be transmitted at high 168 resolution and low resolution at the same time. In this case, a 169 media processing function might choose to send one or both flows 170 downstream to a receiver based on bandwidth availability or who the 171 active speaker is in a multipoint conference. Lastly, a transmitter 172 might send a the same media content concurrently as two media flows 173 using different encodings (e.g., VP8 in parallel with H.264) to allow 174 a media processing function to select a media encoding that best 175 matches the capabilities of the receiver. 177 2.1. Differentiated Services (DiffServ) 179 The DiffServ architecture is intended to enable scalable service 180 discrimination in the Internet without requiring per-flow state and 181 signaling at every network node. The services may be end-to-end or 182 within a network; they include both those that can satisfy 183 quantitative performance requirements (e.g., peak bandwidth) and 184 those based on relative performance (e.g., "class" differentiation). 185 Services can be constructed by a combination of well-defined building 186 blocks deployed in network nodes that: 188 o classify traffic and setting bits in an IP header field at network 189 boundaries or hosts, 191 o use those bits to determine how packets are forwarded by the nodes 192 inside the network, and 194 o condition the marked packets (e.g., meter, mark, shape, police) at 195 network boundaries in accordance with the requirements or rules of 196 each service. 198 A network node that supports DiffServ includes a classifier that 199 selects packets based on the value of the DS field in IP headers, 200 along with buffer management and packet scheduling mechanisms capable 201 of delivering the specific packet forwarding treatment indicated by 202 the DS field value. Setting of the DS field and fine-grain 203 conditioning of marked packets need only be performed at network 204 boundaries; internal network nodes operate on traffic aggregates that 205 share a DS field value, or in some cases, a small set of related 206 values. 208 The DiffServ architecture[RFC2475] maintains distinctions among: 210 o the service provided to a traffic aggregate, 212 o the conditioning functions and per-hop behaviors (PHBs) used to 213 realize services, 215 o the DS field value (DS codepoint, or DSCP) used to mark packets to 216 select a per-hop behavior, and 218 o the particular implementation mechanisms that realize a per-hop 219 behavior. 221 This document focuses on PHBs and the usage of DSCPs to obtain those 222 behaviors. In a network node's forwarding path, the DSCP in a field 223 in the IP packet header is mapped to a particular forwarding 224 treatment, or per-hop behavior (PHB) that specifies the forwarding 225 treatment. 227 A per-hop behavior (PHB) is a description of the externally 228 observable forwarding behavior of a network node for network traffic 229 marked with a DSCP that selects that PHB. In this context, 230 "forwarding behavior" is a general - for example, if only one DSCP is 231 used for all traffic on a link, the observable forwarding behavior 232 (e.g., loss, delay, jitter) will often depend only on the relative 233 loading of the link. To obtain useful behavioral 234 differentiation,multiple traffic subsets are marked with different 235 DSCPs for different PHBs for which node resources such as buffer 236 space and bandwidth are allocated. PHBs provide the framework for a 237 DiffServ network node to allocates resources to traffic subsets, with 238 network-scope differentiated services constructed on top of this 239 basic hop-by-hop (per-node) resource allocation mechanism. 241 The codepoints (DCSPs) may be chosen from a set of mandatory values 242 (the class selector codepoints), or may be chosen from a set of 243 recommended values defined in PHB specifications, or may be values 244 may have purely local meaning to the network. 246 The mandatory DSCPs are the class selector code points as specified 247 in [RFC2474]. The class selector codepoints (CS0-CS7) extend the 248 deprecated concept of IP Precedence in the IPv4 header; three bits 249 are added, so that the class selector DSCPs are of the form 'xxx000'. 250 The all-zero DSCP ('00000') designates a Default PHB that provides 251 best-effort forwarding behavior and the remaining class selector code 252 points were originally specified to provide relatively better per- 253 hop-forwarding behavior in increasing numerical order, but: 255 o There is no requirement that any two adjacent class selector 256 codepoints select different PHBs; adjacent class selector 257 codepoints may use the same pool of resources on each network node 258 in some networks. 260 o CS1 ('001000') was subsequently recommended for "less than best 261 effort" service when such a service is offered by a network 262 [RFC3662]. Not all networks offer such a service. 264 Applications and traffic sources in general cannot rely upon 265 different class selector codepoints providing differentiated services 266 or upon the presence of a "less than best effort" service that is 267 selected by the CS1 DSCP. 269 2.2. Diffserv PHBs (Per-Hop Behaviors) 271 Although Differentiated Services is a general architecture that may 272 be used to implement a variety of services, three fundamental 273 forwarding behaviors (PHBs) have been defined and characterized for 274 general use. These are: 276 1. Default Forwarding (DF) for elastic traffic [RFC2474]. The 277 Default PHB is always selected by the all-zero DSCP. 279 2. Assured Forwarding (AF) [RFC2597] to provide differentiated 280 service to elastic traffic. Each instance of the AF behavior 281 consists of three PHBs that differ only in drop precedence, e.g., 282 AF11, AF12 and AF13; such a set of three AF PHBs is referred to 283 as an AF class, e.g., AF1x. There are four defined AF classes, 284 AF1x through AF4x. 286 3. Expedited Forwarding (EF) [RFC3246]intended for inelastic 287 traffic. Beyond the basic EF PHB, the VOICE-ADMIT PHB [RFC5865] 288 is an admission controlled variant of the EF PHB. 290 2.3. DiffServ and Transport Protocols 292 [Editor's note: This section and the recommendations in Section 4 are 293 centered on TCP, UDP, and SCTP. They could use generalization to 294 include other transport protocols - DCCP is a likely one to include, 295 although it is not necessary to include every known transport 296 protocol.] 298 Transport protocols provide data communication behaviors beyond those 299 possible at the IP layer. An important example is that TCP provides 300 reliable in-order delivery of a data stream with congestion control. 301 SCTP provides additional properties such as preservation of message 302 boundaries, and the ability to avoid head-of-line blocking that may 303 occur with TCP. In contrast, UDP is a basic unreliable datagram 304 protocol whose primary functionality is port-based multiplexing and 305 demultiplexing on top of IP. 307 Transport protocols that provide reliable delivery (e.g., TCP, SCTP) 308 are sensitive to network reordering of traffic. When a protocol that 309 provides reliable delivery receives a packet other than the next 310 expected packet for an ordered connection or stream, it usually 311 assumes that the expected packet has been lost and respond with a 312 retransmission request for that packet. In addition, congestion 313 control functionality in transport protocols usually infers 314 congestion when packets are lost, creating an additional sensitivity 315 to significant reordering - such reordering may be (mis-)interpreted 316 as indicating congestion-caused packet loss, causing a reduction in 317 transmission rate. This remains true even when ECN [RFC3168] is in 318 use, as receivers continue to treat missing packets as potential 319 indications of congestion because extreme congestion conditions may 320 cause ECN-capable network nodes to drop packets and ECN traffic may 321 transit network nodes that do not support ECN. Congestion control is 322 an important aspect of the Internet architecture, see [RFC2914] for 323 further discussion. 325 In general, marking traffic with different DSCPs results in different 326 PHBs being applied at network nodes, making reordering possible due 327 to use of different pools of forwarding resources for each PHB. The 328 primary exception is that reordering is prohibited within each AF 329 class (e.g., AF1x), as the three PHBs in an AF class differ solely in 330 drop precedence. Reordering within a PHB or AF class may occur for 331 other transient reasons (e.g., route flap). 333 UDP is the primary transport protocol that is not sensitive to 334 reordering in the network, because it does not provide reliable 335 delivery or congestion control. 337 2.4. Traffic Classifiers and DSCP Remarking 339 DSCP markings are not end-to-end in general. Each network is free to 340 make its own decisions about what PHBs to use and which DSCP 341 corresponds to each PHB. While every PHB specification includes a 342 recommended DSCP, and RFC 4594 [RFC4594] recommends their end-to-end 343 usage, there is no requirement that every network support any PHBs or 344 use any DSCPs, with the exception of the requirements for the class 345 selector codepoints in RFC 2474 [RFC2474]. When DiffServ is used, 346 the edge or boundary nodes of a network are responsible for ensuring 347 that all traffic entering that network conforms to that network's 348 policies for DSCP and PHB usage, and such nodes remark traffic 349 (change the DSCP marking as part of traffic conditioning) 350 accordingly. As a result, DSCP remarking is possible at any network 351 boundary, including the first network node that traffic sent by a 352 host encounters. Remarking is also possible within a network, e.g., 353 for traffic shaping. 355 DSCP remarking is part of traffic conditioning; the traffic 356 conditioning functionality applied to packets at a network node is 357 determined by a traffic classifier [RFC2475]. BA (Behavioral 358 Aggregate) traffic classifiers are usually used by network nodes 359 within a DiffServ network; they classify traffic based solely on 360 DSCPs. MF (Multi-Field) classifiers are usually used by network 361 nodes at the edges of a DiffServ network, but may also be used for 362 finer grain traffic conditioning within a DiffServ network; they 363 classify based on selected header fields, but typical implementations 364 do not look beyond the traffic's 5-tuple in the IP and transport 365 protocol headers. As a result, when multiple DSCPs are used for 366 network traffic that shares a 5-tuple, remarking at a network 367 boundary (or within a network) may result in all of the traffic being 368 forwarded with a single DSCP, removing any differentiation within the 369 5-tuple beyond the point at which this remarking occurs. 371 In addition, remarking may remove application-level distinctions in 372 forwarding behavior - e.g., if multiple PHBs within an AF class are 373 used to distinguish different types of frames within a video flow, 374 token-bucket-based remarkers operating in Color-Blind mode (see 375 [RFC2697] and [RFC2698] for examples) may remark solely based on flow 376 rate and burst behavior, removing the drop precedence distinctions 377 specified by the source. 379 Backbone and other carrier networks may employ a small number of 380 DSCPs (e.g., less than half a dozen) in order to manage a small 381 number of traffic aggregates; hosts that use a larger number of DSCPs 382 may find that much of the intended differentiation is removed by such 383 networks. 385 3. RTP Multiplexing Background 387 Section2 explains how media flows can be multiplexed over RTP 388 sessions which can in turn be multiplexed over UDP with other RTP 389 sessions as well as flows generated by other transport protocols. 390 This section provides background on why this level of media flow 391 multiplexing is desirable. The rationale in this section applies 392 both to multiplexing of media flows in RTP sessions and multiplexing 393 of one or more RTP sessions with traffic from other transport 394 protocols via UDP encapsulation. 396 Multiplexing reduces the number of ports utilized for real-time and 397 related communication in an overall interaction. While a single 398 endpoint might have plenty of ports available for communication, 399 these media flows are often traverse points in the network that are 400 constrained on the number of available ports. A good example is a 401 NAT/FW device sitting at the network edge. As the number of 402 simultaneous protocol sessions increases, so does the burden placed 403 on these devices in order to provide port mapping. 405 Another reason for multiplexing is to help reduce the time required 406 to establish bi-directional traffic flows. Since any two 407 communicating users might be situated behind different NAT/FW 408 devices, it is necessary to employ techniques like STUN/ICE/TURN in 409 order to get traffic to flow between the two devices 410 [I-D.ietf-rtcweb-transports]. Performing the tasks required of 411 STUN/ICE/TURN take time and requiring an endpoint to perform these 412 tasks for several flows can increase the time required. While tasks 413 for different flows can be performed in parallel, it is nonetheless 414 necessary for applications to wait for all flows to be opened before 415 communication between to users can begin. Reducing the number of 416 STUN/ICE/TURN steps reduces the probability of losing a packet and 417 introducing delay in setting up a communication session. Further, 418 reducing the number of STUN/ICE/TURN tasks means that there is a 419 lower burden placed on the STUN and TURN servers. 421 Multiplexing may reduce the complexity and resulting load on an 422 endpoint. A single instance of STUN/ICE/TURN is simpler to execute 423 and manage than multiple instances STUN/ICE/TURN operations happening 424 in parallel, as the latter require synchronization and create more 425 complex failure situations that have to be cleaned up by additional 426 code. 428 4. Recommendations 430 The only use of multiple standardized PHBs and DSCPs that does not 431 allow network reordering among packets marked with different DSCPs is 432 the use of PHBs from a single AF class. All other uses of multiple 433 PHBs and/or the class selector DSCPs allow network reordering of 434 packets that are marked with different DSCPs. 436 [Editor's note: The following are preliminary and subject to change. 437 Please keep in mind that this is a -00 draft] Summary - Applications 438 and other traffic sources: 440 o SHOULD NOT use different PHBs and DSCPs that may cause reordering 441 within a single media flow. If this is not done, significant 442 network reordering may overwhelm implementation assumptions about 443 limits on reordering (e.g., available buffering) resulting in poor 444 user experiences and the like. 446 o SHOULD NOT use different PHBs and DSCPs that may cause reordering 447 within an ordered session for a reliable transport protocol (e.g., 448 TCP, SCTP) , Receivers for such protocols interpret reordering as 449 indicating loss of out-of-order packets causing undesired 450 retransmission requests, and will infer congestion from 451 significant reordering, causing throughput reduction. 453 o MAY use different PHBs and DSCPs that cause reordering within a 454 single UDP 5-tuple, subject to the above constraints. The service 455 differentiation provided by such usage is unreliable, as it may be 456 removed at network boundaries for the reasons described in 457 Section 2.4 above. 459 o SHOULD NOT rely on end-to-end preservation of DSCPs or of drop 460 precedence distinctions within an AF class (e.g., different DCSPs 461 applied to different types of video frames), as network node 462 remarking can change DSCPs and remove drop precedence distinctions 463 see Section 2.4 above. 465 o SHOULD use the CS1 codepoint only for traffic that is acceptable 466 to forward as best effort traffic, as network support for use of 467 CS1 to select a "less than best effort" PHB is inconsistent. 468 Further, some networks may treat CS1 as providing "better than 469 best effort" forwarding behavior. 471 5. RTCWEB Examples 473 [Editor's Note: This section will provide examples of DiffServ/DSCP 474 application to RTCWEB and related limitations.] 476 6. Acknowledgements 478 This document is the result of many conversations that have occurred 479 within multiple RAI and TRANSPORT area working groups. Thanks for 480 review and input from James Polk. 482 7. IANA Considerations 484 This document includes no request to IANA. 486 8. Security Considerations 488 [Editor's Note: There are security considerations, start by pointing 489 to security considerations in the relevant references. Multiplexing 490 multiple transport protocols onto a single UDP 5-tuple has firewall 491 configuration and traffic inspection/monitoring implications.] 493 9. References 495 9.1. Normative References 497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 498 Requirement Levels", BCP 14, RFC 2119, March 1997. 500 9.2. Informative References 502 [I-D.ietf-rtcweb-overview] 503 Alvestrand, H., "Overview: Real Time Protocols for Brower- 504 based Applications", draft-ietf-rtcweb-overview-09 (work 505 in progress), February 2014. 507 [I-D.ietf-rtcweb-rtp-usage] 508 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 509 Communication (WebRTC): Media Transport and Use of RTP", 510 draft-ietf-rtcweb-rtp-usage-15 (work in progress), May 511 2014. 513 [I-D.ietf-rtcweb-transports] 514 Alvestrand, H., "Transports for RTCWEB", draft-ietf- 515 rtcweb-transports-04 (work in progress), April 2014. 517 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 518 "Definition of the Differentiated Services Field (DS 519 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 520 1998. 522 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 523 and W. Weiss, "An Architecture for Differentiated 524 Services", RFC 2475, December 1998. 526 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 527 "Assured Forwarding PHB Group", RFC 2597, June 1999. 529 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 530 Marker", RFC 2697, September 1999. 532 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 533 Marker", RFC 2698, September 1999. 535 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 536 2914, September 2000. 538 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 539 of Explicit Congestion Notification (ECN) to IP", RFC 540 3168, September 2001. 542 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 543 J., Courtney, W., Davari, S., Firoiu, V., and D. 544 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 545 Behavior)", RFC 3246, March 2002. 547 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 548 Jacobson, "RTP: A Transport Protocol for Real-Time 549 Applications", STD 64, RFC 3550, July 2003. 551 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 552 Per-Domain Behavior (PDB) for Differentiated Services", 553 RFC 3662, December 2003. 555 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 556 Guidelines for DiffServ Service Classes", RFC 4594, August 557 2006. 559 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 560 Services Code Point (DSCP) for Capacity-Admitted Traffic", 561 RFC 5865, May 2010. 563 [W3C.WD-mediacapture-streams-20130903] 564 Burnett, D., Bergkvist, A., Jennings, C., and A. 565 Narayanan, "Media Capture and Streams", World Wide Web 566 Consortium WD WD-mediacapture-streams-20130903, September 567 2013, . 570 Authors' Addresses 572 Dan York (editor) 573 Internet Society 574 Keene, N.H. 575 USA 577 Phone: +1-802-735-1624 578 Email: dyork@lodestar2.com 580 David Black (editor) 581 EMC 582 176 South Street 583 Hopkinton, MA 01748 584 USA 586 Phone: +1 508 293-7953 587 Email: david.black@emc.com 589 Cullen Jennings 590 Cisco 591 170 West Tasman Drive 592 MS: SJC-21/2 593 San Jose, CA 95134 594 USA 596 Phone: +1 408 421-9990 597 Email: fluffy@cisco.com 599 Paul Jones 600 Cisco