idnits 2.17.1 draft-jesup-rtp-congestion-reqs-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 (March 4, 2012) is 4435 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5506' is defined on line 277, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-00 Summary: 0 errors (**), 0 flaws (~~), 3 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 H. Alvestrand 5 Expires: September 5, 2012 Google 6 March 4, 2012 8 Congestion Control Requirements For Real Time Media 9 draft-jesup-rtp-congestion-reqs-00 11 Abstract 13 Congestion control is needed for all data transported across the 14 Internet, in order to promote fair usage and prevent congestion 15 collapse. The requirements for interactive, point-to-point real time 16 multimedia, which needs by low-delay, semi-reliable data delivery, 17 are different from the requirements for bulk transfer like FTP or 18 bursty transfers like Web pages, and the TCP algorithms are not 19 suitable for this traffic. 21 This document attempts to describe a set of requirements that can be 22 used to evaluate other congestion control mechanisms in order to 23 figure out their fitness for this purpose. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 5, 2012. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 68 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 71 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 The traditional TCP congestion control requirements were developed in 77 order to promote efficient use of the Internet for reliable bulk 78 transfer of non-time-critical data, such as transfer of large files. 79 They have also been used successfully to govern the reliable transfer 80 of smaller chunks of data in "as fast as possible" mode, such as when 81 fetching Web pages. 83 These algorithms have also been used for transfer of media streams 84 that are viewed in a non-interactive manner, such as "streaming" 85 video, where having the data ready when the viewer wants it is 86 important, but the exact timing of the delivery is not. 88 When doing real time interactive media, the requirements are 89 different; one needs to provide the data continuously, within a very 90 limited time window (no more than 100s of milliseconds end-to-end 91 delay), the sources of data may be able to adapt the amount of data 92 that needs sending within fairly wide margins, and may tolerate some 93 amount of packet loss, but since the data is generated in real time, 94 sending "future" data is impossible, and since it's consumed in real 95 time, data delivered late is useless. 97 One particular protocol portofolio being developed for this use case 98 is WebRTC [I-D.ietf-rtcweb-overview], where one envisions sending 99 multiple RTP-based flows between two peers, in conjunction with data 100 flows, all at the same time, without having special arrangements with 101 the intervening service providers. 103 Given that this use case is the focus of this document, use cases 104 involving noninteractive media such as YouTube-like video streaming, 105 and use cases using multicast/broadcast-type technologies, are out of 106 scope. 108 The terminology defined in [I-D.ietf-rtcweb-overview] is used in this 109 memo. 111 2. Requirements 113 1. The congestion control algorithm must attempt to provide low- 114 delay transit for real-time traffic, even when faced with 115 intermediate bottlenecks and competing flows. 117 A. It should also deal well with routing changes and interface 118 changes (WiFi to 3G data, etc) which may radically change 119 the bandwidth available. 121 2. The algorithm must be fair to other flows, both realtime flows 122 (such as other instances of itself), and TCP flows, both long- 123 lived and bursts such as the traffic generated by a typical web 124 browsing session. Note that 'fair' is a rather hard-to-define 125 term. 127 A. The algorithm must not overreact to short-term bursts (such 128 as web-browsing) which can quickly saturate a local- 129 bottleneck router or link, but also clear quickly, and 130 should recover quickly when the burst ends. 132 3. The algorithm should merge information across multiple RTP 133 streams between the same endpoints, whether or not they're 134 multiplexed on the same ports, in order to allow congestion 135 control of the set of streams together instead of as multiple 136 independent streams. This allows better overall bandwidth 137 management, faster response to changing conditions, and fairer 138 sharing of bandwidth with other network users. 140 A. If possible, it should also share information and adaptation 141 with other non-RTP flows between the same endpoints, such as 142 a WebRTC data channel 144 4. The algorithm should not require any special support from 145 network elements (ECN, etc). As much as possible, it should 146 leverage existing information about the incoming flows to 147 provide feedback to the sender. Examples of this information 148 are the packet arrival times, packet timestamps, packet sizes, 149 packet losses. Extra information could be added to the packets 150 to provide more detailed information on actual send times (as 151 opposed to sampling times), but should not be required. 153 A. When signals such as ECN are available, it is good if they 154 can be utilized. 156 5. Since the assumption here is a set of RTP streams, the 157 backchannel typically should be done via RTCP; the alternative 158 would be to include it in a reverse RTP channel using header 159 extensions. 161 A. In order to react sufficiently quickly, the AVPF/SAVPF RTP 162 profile[RFC4585] must be used 164 B. Note that in some cases, backchannel messages may be delayed 165 until the RTCP channel can be allocated enough bandwidth, 166 even under AVPF rules. This may also imply allowing a 167 higher maximum percentage for RTCP data. 169 C. Note that RTCP is of course unreliable 171 D. Bandwidth for the feedback messages should be minimized 172 (such as via RFC 5506 [RFC5506]to allow RTCP without SR/RR) 174 E. Header extensions would avoid the RTCP timing rules issues, 175 and allow the application to allocate bandwidth as needed 176 for the congestion algorithm. 178 F. Backchannel data should be minimized to avoid taking too 179 much reverse-channel bandwidth (since this will often be 180 used in a bidirectional set of flows). In areas of 181 stability, backchannel data may be sent more infrequently so 182 long as algorithm stability and fairness are maintained. 183 When the channel is unstable or has not yet reached 184 equilibrium after a change, backchannel feedback may be more 185 frequent and use more reverse-channel bandwidth. 187 6. It should attempt to avoid bandwidth 'collapse' when facing a 188 long-lived saturating TCP flow or flows. (I.e. a classic delay- 189 sensitive algorithm will reduce bandwidth to keep delay down 190 until the TCP flow has all the bandwidth). See the Cx-TCP 191 algorithm discussed in a recent Transactions On Networking 192 [cx-tcp] for an example of a delay-sensitive congestion-control 193 algorithm that transitions to a loss-based mode when competing 194 with TCP flows - at the cost of increased delay. 196 7. The algorithm should be stable and low-delay when faced with 197 active queue management (AQM) in the channel. 199 8. The algorithm should quickly adapt to initial network conditions 200 at the start of a flow; the adaptation may be faster than 201 adaptation later in a flow. This should occur both if the 202 initial bandwidth is above or below the bottleneck bandwidth. 204 A. it should allow for both slow-start operation (adapt up) and 205 history-based startup (start at a point expected to be at or 206 below channel bandwidth from historical information, which 207 may need to adapt down quickly if the initial guess is 208 wrong). Starting too low and/or adapting up too slowly can 209 cause a critical point in a personal communication to be 210 poor ("Hello!"). 212 9. Where possible, the algorithm should leverage and piggyback on 213 other RTCP communications, such as SR/RR, rctp-fb PLI, RPSI, SLI 214 or application-specific NACK messages (such as for loss 215 information). 217 10. It should be evaluated in how it works both with backbone-router 218 bottlenecks, (asymmetric) local-loop bottlenecks, and local-lan 219 (WiFi/etc) bottlenecks. 221 11. The algorithm should sense the unexpected lack of backchannel 222 information as a possible indication of a channel overuse 223 problem and react accordingly to avoid burst events causing a 224 congestion collapse. 226 12. It should be stable if the RTP streams are halted or 227 discontinuous (VAD/DTX); after a resumption of RTP data it may 228 adapt more quickly (similar to the start of a flow). 230 3. IANA Considerations 232 This document makes no request of IANA. 234 Note to RFC Editor: this section may be removed on publication as an 235 RFC. 237 4. Security Considerations 239 An attacker with the ability to delete, delay or insert messages in 240 the flow can fake congestion signals, unless they are passed on a 241 tamper-proof path. Since some possible algorithms depend on the 242 timing of packet arrival, even a traditional protected channel does 243 not fully mitigate such attacks. 245 An attack that reduces bandwidth is not necessarily significant, 246 since an on-path attacker could break the connection by discarding 247 all packets. Attacks that increase the percieved available bandwidth 248 are concievable, and need to be evaluated. 250 Algorithm designers SHOULD consider the possibility of malicious on- 251 path attackers. 253 5. Acknowledgements 255 This document is the result of discussions in various fora of the 256 WebRTC effort, in particular on the rtp-congestion@alvestrand.no 257 mailing list. Many people contributed their thoughts to this. 259 6. References 260 6.1. Normative References 262 [I-D.ietf-rtcweb-overview] 263 Alvestrand, H., "Overview: Real Time Protocols for Brower- 264 based Applications", draft-ietf-rtcweb-overview-00 (work 265 in progress), June 2011. 267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 268 Requirement Levels", BCP 14, RFC 2119, March 1997. 270 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 271 "Extended RTP Profile for Real-time Transport Control 272 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 273 July 2006. 275 6.2. Informative References 277 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 278 Real-Time Transport Control Protocol (RTCP): Opportunities 279 and Consequences", RFC 5506, April 2009. 281 [cx-tcp] Budzisz, L., Stanojevic, R., Schlote, A., Baker, F., and 282 R. Shorten, "On the Fair Coexistence of Loss- and Delay- 283 Based TCP", December 2011. 285 Authors' Addresses 287 Randell Jesup 288 Mozilla 289 USA 291 Email: randell-ietf@jesup.org 293 Harald Alvestrand 294 Google 295 Kungsbron 2 296 Stockholm 11122 297 Sweden 299 Email: harald@alvestrand.no