idnits 2.17.1 draft-ietf-rmcat-cc-requirements-05.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-rtcweb-overview]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 4, 2014) is 3555 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5506' is defined on line 405, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-10 == Outdated reference: A later version (-13) exists of draft-ietf-rtcweb-data-channel-10 == Outdated reference: A later version (-05) exists of draft-welzl-rmcat-coupled-cc-03 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Jesup 3 Internet-Draft Mozilla 4 Intended status: Informational July 4, 2014 5 Expires: January 5, 2015 7 Congestion Control Requirements For RMCAT 8 draft-ietf-rmcat-cc-requirements-05 10 Abstract 12 Congestion control is needed for all data transported across the 13 Internet, in order to promote fair usage and prevent congestion 14 collapse. The requirements for interactive, point-to-point real time 15 multimedia, which needs low-delay, semi-reliable data delivery, are 16 different from the requirements for bulk transfer like FTP or bursty 17 transfers like Web pages. Due to an increasing amount of RTP-based 18 real-time media traffic on the Internet (e.g. with the introduction 19 of WebRTC[I-D.ietf-rtcweb-overview]), it is especially important to 20 ensure that this kind of traffic is congestion controlled. 22 This document describes a set of requirements that can be used to 23 evaluate other congestion control mechanisms in order to figure out 24 their fitness for this purpose, and in particular to provide a set of 25 possible requirements for realtime media congestion avoidance 26 technique. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 The terms are presented in many cases using lowercase for 34 readability. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on January 5, 2015. 53 Copyright Notice 55 Copyright (c) 2014 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 75 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 77 6.2. Informative References . . . . . . . . . . . . . . . . . 9 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 Most of today's TCP congestion control schemes were developed with a 83 focus on an use of the Internet for reliable bulk transfer of non- 84 time-critical data, such as transfer of large files. They have also 85 been used successfully to govern the reliable transfer of smaller 86 chunks of data in as short a time as possible, such as when fetching 87 Web pages. 89 These algorithms have also been used for transfer of media streams 90 that are viewed in a non-interactive manner, such as "streaming" 91 video, where having the data ready when the viewer wants it is 92 important, but the exact timing of the delivery is not. 94 When doing real time interactive media, the requirements are 95 different; one needs to provide the data continuously, within a very 96 limited time window (no more than 100s of milliseconds end-to-end 97 delay), the sources of data may be able to adapt the amount of data 98 that needs sending within fairly wide margins, and may tolerate some 99 amount of packet loss, but since the data is generated in real time, 100 sending "future" data is impossible, and since it's consumed in real 101 time, data delivered late is commonly useless. 103 While the requirements for RMCAT differ from the requirements for the 104 other flow types, these other flow types will be present in the 105 network. The RMCAT congestion control algorithm must work properly 106 when these other flow types are present as cross traffic on the 107 network. 109 One particular protocol portofolio being developed for this use case 110 is WebRTC [I-D.ietf-rtcweb-overview], where one envisions sending 111 multiple RTP-based flows between two peers, in conjunction with data 112 flows, all at the same time, without having special arrangements with 113 the intervening service providers. 115 Given that this use case is the focus of this document, use cases 116 involving noninteractive media such as video streaming, and use cases 117 using multicast/broadcast-type technologies, are out of scope. 119 The terminology defined in [I-D.ietf-rtcweb-overview] is used in this 120 memo. 122 2. Requirements 124 1. The congestion control algorithm must attempt to provide as-low- 125 as-possible-delay transit for real-time traffic while still 126 providing a useful amount of bandwidth. There may be lower 127 limits on the amount of bandwidth that is useful, but this is 128 largely application-specific and the application may be able to 129 modify or remove flows in order allow some useful flows to get 130 enough bandwidth. (Example: not enough bandwidth for low- 131 latency video+audio, but enough for audio-only.) 133 A. It should provide this as-low-as-possible-delay transit even 134 when faced with intermediate bottlenecks and competing 135 flows. Competing flows may limit what's possible to 136 achieve. 138 B. It should handle routing changes which may alter or remove 139 bottlenecks or change the bandwidth available, and react 140 quickly, especially if there is a reduction in available 141 bandwidth or increase in bottleneck delay. 143 C. It should handle interface changes (WLAN to 3G data, etc) 144 which may radically change the bandwidth available or 145 bottlenecks, and react quickly, especially if there is a 146 reduction in available bandwidth or increase in bottleneck 147 delay. It is assumed that an interface change can generate 148 a notification to the algorithm. 150 D. The offered load may be less than the available bandwidth at 151 any given moment, and may vary dramatically over time, 152 including dropping to no load and then resuming a high load, 153 such as in a mute operation. The reaction time between a 154 change in the bandwidth available from the algorithm and a 155 change in the offered load is variable, and may be different 156 when increasing versus decreasing. 158 E. The algorithm must not overreact to short-term bursts (such 159 as web-browsing) which can quickly saturate a local- 160 bottleneck router or link, but also clear quickly, and 161 should recover quickly when the burst ends. This is 162 inherently at odds with the need to react quickly-enough to 163 avoid queue buildup. 165 F. Similarly periodic bursty flows such as MPEG DASH 166 [MPEG_DASH] or proprietary media streaming algorithms may 167 compete in bursts with the algorithm, and may not be 168 adaptive within a burst. They are often layered on top of 169 TCP. The algorithm must avoid too much delay buildup during 170 those bursts, and quickly recover. Note that this competing 171 traffic may on a shared access link, or the traffic burst 172 may cause a shift in the location of the bottleneck for the 173 duration of the burst. 175 2. The algorithm must be fair to other flows, both realtime flows 176 (such as other instances of itself), and TCP flows, both long- 177 lived and bursts such as the traffic generated by a typical web 178 browsing session. Note that 'fair' is a rather hard-to-define 179 term. It should be fair with itself, giving roughly equal 180 bandwidth to multiple flows with similar RTTs, and if possible 181 to multiple flows with different RTTs. 183 A. Existing flows at a bottleneck must also be fair to new 184 flows to that bottleneck, and must allow new flows to ramp 185 up to a useful share of the bottleneck bandwidth quickly. 186 Note that relative RTTs may affect the rate new flows can 187 ramp up to a reasonable share. 189 3. The algorithm should not starve competing TCP flows, and should 190 as best as possible avoid starvation by TCP flows. 192 A. An algorithm may be more successful at avoiding starvation 193 from short-lived TCP than long-lived/saturating TCP flows. 195 B. In order to avoid starvation other goals may need to be 196 compromised (such as delay). 198 4. The algorithm should quickly adapt to initial network conditions 199 at the start of a flow. This should occur both if the initial 200 bandwidth is above or below the bottleneck bandwidth. 202 A. The startup adaptation may be faster than adaptation later 203 in a flow. It should allow for both slow-start operation 204 (adapt up) and history-based startup (start at a point 205 expected to be at or below channel bandwidth from historical 206 information, which may need to adapt down quickly if the 207 initial guess is wrong). Starting too low and/or adapting 208 up too slowly can cause a critical point in a personal 209 communication to be poor ("Hello!"). Starting over- 210 bandwidth causes other problems for user experience, so 211 there's a tension here. 213 B. Alternative methods to help startup like probing during 214 setup with dummy data may be useful in some applications; in 215 some cases there will be a considerable gap in time between 216 flow creation and the initial flow of data. 218 C. A flow may need to change adaptation rates due to network 219 conditions or changes in the provided flows (such as un- 220 muting or sending data after a gap). 222 5. It should be stable if the RTP streams are halted or 223 discontinuous (Voice Activity Detection/Discontinuous 224 Transmission). 226 A. After a resumption of RTP data it may adapt more quickly 227 (similar to the start of a flow), and previous bandwidth 228 estimates may need to be aged or thrown away. 230 6. The algorithm should where possible merge information across 231 multiple RTP streams between the same endpoints, whether or not 232 they're multiplexed on the same ports, in order to allow 233 congestion control of the set of streams together instead of as 234 multiple independent streams. This allows better overall 235 bandwidth management, faster response to changing conditions, 236 and fairer sharing of bandwidth with other network users. 237 Alternatively, it should work with an external bandwidth control 238 framework to coordinate bandwidth usage across a bottleneck, 239 such as draft-welzl-rmcat-coupled-cc 240 [I-D.welzl-rmcat-coupled-cc]. 242 A. If possible, it should also share information and adaptation 243 with other non-RTP flows between the same endpoints, such as 244 a WebRTC DataChannel[I-D.ietf-rtcweb-data-channel] 246 B. The most correlated bandwidth usage would be with other 247 flows on the same 5-tuple, but there may be use in 248 coordinating measurement and control of the local link(s). 250 C. Use of information about previous flows, especially on the 251 same 5-tuple, may be useful input to the algorithm, 252 especially to startup performance of a new flow. 254 D. When there are multiple streams across the same 5-tuple 255 coordinating their bandwidth use and congestion control, it 256 should be possible for the application to control the 257 relative split of available bandwidth. 259 7. The algorithm should not require any special support from 260 network elements (Explicit Congestion Notification (ECN) 261 [RFC3168], etc). As much as possible, it should leverage 262 available information about the incoming flow to provide 263 feedback to the sender. Examples of this information are the 264 ECN, packet arrival times, acknowledgments and feedback, packet 265 timestamps, and packet losses; all of these can provide 266 information about the state of the path and any bottlenecks. 268 A. Extra information could be added to the packets to provide 269 more detailed information on actual send times (as opposed 270 to sampling times), but should not be required. 272 B. When additional input signals such as ECN are available, 273 they should be utilized if possible. 275 8. Since the assumption here is a set of RTP streams, the 276 backchannel typically should be done via RTCP; one alternative 277 would be to include it instead in a reverse RTP channel using 278 header extensions. 280 A. In order to react sufficiently quickly when using RTCP for a 281 backchannel, an RTP profile such as RTP/AVPF [RFC4585] or 282 RTP/SAVPF [RFC5124] that allows sufficiently frequent 283 feedback must be used. 285 B. Note that in some cases, backchannel messages may be delayed 286 until the RTCP channel can be allocated enough bandwidth, 287 even under AVPF rules. This may also imply negotiating a 288 higher maximum percentage for RTCP data or allowing RMCAT 289 solutions to violate or modify the rules specified for AVPF. 291 C. Bandwidth for the feedback messages should be minimized 292 (such as via RFC 5506 [RFC5506]to allow RTCP without Sender 293 Reports/Receiver Reports) 295 D. Header extensions would avoid the RTCP timing rules issues, 296 and allow the application to allocate bandwidth as needed 297 for the congestion algorithm. 299 E. Backchannel data should be minimized to avoid taking too 300 much reverse-channel bandwidth (since this will often be 301 used in a bidirectional set of flows). In areas of 302 stability, backchannel data may be sent more infrequently so 303 long as algorithm stability and fairness are maintained. 304 When the channel is unstable or has not yet reached 305 equilibrium after a change, backchannel feedback may be more 306 frequent and use more reverse-channel bandwidth. This is an 307 area with considerable flexibility of design, and different 308 approaches to backchannel messages and frequency are 309 expected to be evaluated. 311 9. Flows managed by this algorithm and flows competing against at a 312 bottleneck may have different DSCP[RFC5865] markings depending 313 on the type of traffic, or may be subject to flow-based QoS. A 314 particular bottleneck or section of the network path may or may 315 not honor DSCP markings. The algorithm should attempt to 316 leverage DSCP markings when they're available. 318 A. In WebRTC, a division of packets into 4 classes is 319 envisioned in order of priority: faster-than-audio, audio, 320 video, best-effort, and bulk-transfer. Typically the flows 321 managed by this algorithm would be audio or video in that 322 heirarchy, and feedback flows would be faster-than-audio. 324 10. The algorithm should sense the unexpected lack of backchannel 325 information as a possible indication of a channel overuse 326 problem and react accordingly to avoid burst events causing a 327 congestion collapse. 329 11. The algorithm should be stable and low-delay when faced with 330 active queue management (AQM) algorithms. Also note that these 331 algorithms may apply across multiple queues in the bottleneck, 332 or to a single queue 334 3. IANA Considerations 336 This document makes no request of IANA. 338 Note to RFC Editor: this section may be removed on publication as an 339 RFC. 341 4. Security Considerations 343 An attacker with the ability to delete, delay or insert messages in 344 the flow can fake congestion signals, unless they are passed on a 345 tamper-proof path. Since some possible algorithms depend on the 346 timing of packet arrival, even a traditional protected channel does 347 not fully mitigate such attacks. 349 An attack that reduces bandwidth is not necessarily significant, 350 since an on-path attacker could break the connection by discarding 351 all packets. Attacks that increase the percieved available bandwidth 352 are concievable, and need to be evaluated. 354 Algorithm designers should consider the possibility of malicious on- 355 path attackers. 357 5. Acknowledgements 359 This document is the result of discussions in various fora of the 360 WebRTC effort, in particular on the rtp-congestion@alvestrand.no 361 mailing list. Many people contributed their thoughts to this. 363 6. References 365 6.1. Normative References 367 [I-D.ietf-rtcweb-overview] 368 Alvestrand, H., "Overview: Real Time Protocols for 369 Browser-based Applications", draft-ietf-rtcweb-overview-10 370 (work in progress), June 2014. 372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", BCP 14, RFC 2119, March 1997. 375 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 376 "Extended RTP Profile for Real-time Transport Control 377 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 378 2006. 380 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 381 Real-time Transport Control Protocol (RTCP)-Based Feedback 382 (RTP/SAVPF)", RFC 5124, February 2008. 384 6.2. Informative References 386 [I-D.ietf-rtcweb-data-channel] 387 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 388 Channels", draft-ietf-rtcweb-data-channel-10 (work in 389 progress), June 2014. 391 [I-D.welzl-rmcat-coupled-cc] 392 Welzl, M., Islam, S., and S. Gjessing, "Coupled congestion 393 control for RTP media", draft-welzl-rmcat-coupled-cc-03 394 (work in progress), May 2014. 396 [MPEG_DASH] 397 "Dynamic adaptive streaming over HTTP (DASH) -- Part 1: 398 Media presentation description and segment formats", April 399 2012. 401 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 402 of Explicit Congestion Notification (ECN) to IP", RFC 403 3168, September 2001. 405 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 406 Real-Time Transport Control Protocol (RTCP): Opportunities 407 and Consequences", RFC 5506, April 2009. 409 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 410 Services Code Point (DSCP) for Capacity-Admitted Traffic", 411 RFC 5865, May 2010. 413 Author's Address 415 Randell Jesup 416 Mozilla 417 USA 419 Email: randell-ietf@jesup.org