idnits 2.17.1 draft-tschofenig-cc-workshop-report-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 (October 15, 2012) is 4210 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-avtcore-rtp-circuit-breakers' is defined on line 385, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5405 (Obsoleted by RFC 8085) == Outdated reference: A later version (-18) exists of draft-ietf-avtcore-rtp-circuit-breakers-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Tschofenig 3 Internet-Draft L. Eggert 4 Intended status: Informational Z. Sarker 5 Expires: April 18, 2013 October 15, 2012 7 Report from the IAB/IRTF Workshop on Congestion Control for Interactive 8 Real-Time Communication 9 draft-tschofenig-cc-workshop-report-00.txt 11 Abstract 13 This document provides a summary of the IAB/IRTF Workshop on 14 'Congestion Control for Interactive Real-Time Communication', which 15 took place in Vancouver, Canada, on July 28, 2012. The main goal of 16 the workshop was to foster a discussion on congestion control 17 mechanisms for interactive real-time communication. This report 18 summarizes the discussions and lists the conclusions and 19 recommendations to the Internet Engineering Task Force (IETF) 20 community. The views and positions in this report are those of the 21 workshop participants and do not necessarily reflect the views and 22 positions of the authors, the Internet Architecture Board (IAB) or 23 the Internet Research Task Force (IRTF). 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 18, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. History and Current Status . . . . . . . . . . . . . . . . . . 5 61 3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.1. Changes to Network Infrastructure . . . . . . . . . . . . 6 63 3.2. Avoiding Self-Inflicted Queuing . . . . . . . . . . . . . 7 64 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 70 Appendix A. Program Committee . . . . . . . . . . . . . . . . . . 14 71 Appendix B. Workshop Material . . . . . . . . . . . . . . . . . . 15 72 Appendix C. Accepted Position Papers . . . . . . . . . . . . . . 16 73 Appendix D. Workshop Participants . . . . . . . . . . . . . . . . 19 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 76 1. Introduction 78 Any application that sends significant amounts of data over the 79 Internet is expected to implement reasonable congestion control 80 behavior. Although the specific mechanisms depend on the application 81 or protocol, the motivations for congestion control are well 82 understood and documented in RFC 2914 [RFC2914] and RFC 5405 83 [RFC5405]. The goals are: 85 1. Preventing congestion collapse. 87 2. Allowing multiple flows to share the network fairly. 89 The Internet has been used for interactive real-time communication 90 for decades, most of which is being transmitted using RTP over UDP, 91 often over provisioned capacity and/or using only rudimentary 92 congestion control mechanisms. 94 The development and upcoming widespread deployment of web-based real- 95 time media communication - where RTP is used to and from web browsers 96 to transmit audio, video and data - will likely result in substantial 97 new Internet traffic. Due to the projected volume of this traffic, 98 as well as the fact that it is more likely to use unprovisioned 99 capacity, it is essential that it is transmitted with robust and 100 effective congestion control mechanisms. 102 Designing congestion control mechanisms that perform well under a 103 wide variety of traffic mixes and over network paths with widely 104 varying characteristics is not easy. Prevention of congestion 105 collapse can be achieved through "circuit breaker" mechanisms, but 106 for media flows that are supposed to coexist with a user's other 107 ongoing communication sessions, a congestion control mechanism that 108 shares capacity fairly in the presence of a mix of TCP, UDP and other 109 protocol flows is needed. 111 Many additional complications arise. Here are some examples: 113 1. Real-time interactive media sessions require low latencies, 114 whereas streaming media can use large play-out buffers. 116 2. RTCP feedback about an RTP session typically arrives much less 117 frequently than, for example, TCP ACKs for a given TCP 118 connection. The RTP/RTCP control loop can lead to a longer 119 reaction time. 121 3. Media codecs can usually only adjust their output rates in a much 122 more coarse-grained fashion than, for example, TCP, and user 123 experience suffers if encoding rates are switched too frequently. 125 Codecs typically have a minimum sending rate as well. 127 4. Some bits of an encoded media stream are more important than 128 others. For example, losing or dropping an I-frame of a video 129 stream is more problematic than dropping a P-frame. 131 5. Ramping up the transmission rate can be problematic. Simply 132 increasing the output rate of the codec without knowledge whether 133 the network path can sustain transmission at the increased rate 134 runs the danger of incurring a significant amount of packet loss 135 that can cause playback artifacts. 137 6. A congestion control scheme for interactive media needs to handle 138 bundles of interrelated flows (audio, video, data), in a way that 139 accommodates the preferences of the application in the event of 140 congestion. 142 7. The desire to provide a congestion control mechanism that can be 143 efficiently implemented inside an application (e.g., a web server 144 and a browser) imposes additional restrictions. 146 8. There are explicit congestion signals (such as ECN), and there 147 are indirect indications of congestion (such as packet delay and 148 loss). However, congestion is not the only source of these 149 indirect signals. Care must be taken to account for each of 150 these signals, particularly if various applications react on the 151 same signals. 153 9. Network elements and end device operating systems often create 154 buffers to better support TCP-based applications. These buffers 155 introduce additional communication delay, which harms the small 156 delay budget available for real-time applications. 158 Note that this document is a report on the proceedings of the 159 workshop. The views and positions documented in this report are 160 those of the workshop participants and do not necessarily reflect the 161 views of the authors. 163 2. History and Current Status 165 The currently deployed RTP-based RTC systems use congestion control 166 schemes that are ad hoc at best. As the Internet moves towards an 167 RTCWeb standard for interoperable audio/video conferencing, it needs 168 a standardized and most importantly effective mechanism for 169 congestion control. 171 The most immediate need is for a control mechanism that balances a 172 real-time flow fairly among other competing traffic. For instance, 173 under congested conditions, it would be inappropriate to use far more 174 bandwidth than flows from other applications are using, particularly 175 lasting gross over-utilization of the network. Simple "circuit 176 breaker" -style control mechanisms can prevent congestion collapse by 177 disabling a circuit that far exceeds a fair share and making the 178 circuit remain disabled for some time. But does not in any way 179 enable concurrent flows to share available network capacity sensibly. 181 Therefore, in addition to circuit breakers, more complete methods for 182 media congestion control are needed. The focus of the workshop was 183 on discussing ideas for these more complete congestion control 184 methods.Note that the primary focus of the workshop is RTCWeb-style 185 audio/video flows. The assumed underlying flows (in most attendees 186 minds) were digital audio/video data encapsulated in RTP over UDP 187 over IP. Most of the concepts presented at the workshop could be 188 used with different media types over different transports, but this 189 was the generally assumed baseline for discussions. 191 3. Recommendations 193 The participants suggested to explore two complementary solution 194 tracks, as described in the two sub-sections below. 196 3.1. Changes to Network Infrastructure 198 Like for all other traffic on the network, better data plane 199 infrastructure improves the perceived quality of the best-effort 200 service the Internet provides for RTCWeb flows. The IETF has already 201 developed several technologies that would be of immediate usefulness, 202 if they were deployed. The workshop participants expressed the hope 203 that due to the volume and importance of RTCWeb traffic, some of 204 these technologies might finally see widespread use. 206 The first and by far most important improvement is traffic 207 segregation, i.e., the ability to use different queues for different 208 traffic types. Specifically jitter/delay sensitive and throughput 209 maximizing protocols need to be in different queues. It is not 210 possible for a single queue/AQM to be optimal for both. 212 Explicit Congestion Notification (ECN) allows routers along the end- 213 to-end path to signal the onset of congestion and allows applications 214 to respond early, avoiding losses and keep queue sizes short and 215 therefore end-to-end delay low. ECN is implemented on some end 216 system stacks and routers, but frequently not enabled. 218 Different mechanisms have been developed to facilitate traffic 219 segregation. Differentiated services are one possibility in this 220 space if applications start to mark outgoing traffic appropriately 221 and routers would segregate traffic accordingly, browsers could more 222 directly control the relative importance of their various flows, and 223 avoid self-competition. Compared to ECN, however, DiffServ is far 224 more difficult to deploy meaningfully end-to-end, especially given 225 that DSCPs have no defined end-to-end meaning and packets can be re- 226 marked. Quality-of-service (QoS) signaling together with resource 227 reservation facilities would enable a fine-grained and flexible way 228 to indicate resource needs to network elements but it is also by far 229 the most heavyweight proposal, and unlikely to be viable in the 230 global Internet. 232 However, any change to network infrastructure will take time 233 particularly if the interest of the involved stakeholders is not 234 aligned (as it is the case for network operators and over-the-top 235 application providers). It is therefore imperative that RTCWeb 236 congestion control provides adequate improvement in the absence of 237 any of the aforementioned schemes. 239 3.2. Avoiding Self-Inflicted Queuing 241 This approach tries to ensure that the network does not get congested 242 by focusing on the traffic sent by a single host independent of any 243 changes to networks, as mentioned in the earlier chapter. A single 244 congestion manager within the end host or the browser could already 245 help to coordinate various congestion control activities and to 246 ensure a more coordinated approach between different applications, 247 and different flows. 249 The following activities were suggested during the workshop. 251 Reacting to all Congestion Signals: 253 To initiate the congestion control process it is important to 254 detect congestion in the communication path. Congestion in the 255 comminication can be detected using either an explicit mechanism 256 or an implicit mechanism. The explicit mechanism involves direct 257 congestion signaling usually from the congested network node, such 258 as ECN. The ECN bits are set in the IP header by the network node 259 before it starts to drop the packets and gives end hosts to react 260 to the congestion. In case of implicite mechanism, a particular 261 characteristics or event in the network traffic can be inferred as 262 a congestion signal. For example, packet loss events or observed 263 delay increase or jitter in the communication path can be taken as 264 an implicit congestion signals. These measurements can also be 265 made available in a variety of different protocols, such as RTCP 266 reports or transport protocols. Communication endpoints can 267 trigger congestion control on the event of these phenomena. It is 268 also possible to correlate these events to detect congestion in 269 the communication path. The implicit and explicit signals can 270 come in any sequence and at any time during the ongoing media 271 session. It is recommended to react to all the possible implicit 272 congestion signals, ideally from all applications at the end host, 273 to avoid self- inflicted queues. 275 Delay- and Loss-based Algorithms: 277 The main goal of designing a congestion control algorithm for 278 real-time conversational media is to achieve low latency. An 279 explicit signaling based congestion control algorithm perhaps is 280 the best fit for this purpose as the network nodes are directly 281 involved in the process. However, in case of absence of ECN 282 support in the end-to-end communication path delay based 283 algorithms are needed where the increased delay in the 284 communication path is taken into account as implicit congestion 285 signal. While it is difficult to design algorithms based on delay 286 since many wireless networks show a wide delay variation even in a 287 non-congested network. The workshop participants recommended that 288 more research should be done to better understand non-congestion 289 related delay variation in the network. General consensus among 290 the workshop participants was that when latency-based techniques 291 were competing against loss-based techniques, the loss-based 292 techniques got all the bandwidth. 294 Algorithm Evaluation: 296 The Internet consists of heterogeneous networks, which also 297 includes misconfigured, and unmanaged network nodes. Bandwidth 298 and latency varies a lot. Not only this, different services 299 deployed using RTP/UDP have different requirements in terms of 300 media quality. A congestion control algorithm needs to perform 301 well not only in simulators but also in today's Internet. To 302 achieve this it is recommended to test the algorithms with real- 303 world loss and delay figures to be sure that the desired audio/ 304 video rates are attainable using the proposed algorithms for the 305 desired services. 307 Media Characteristics in Focus: 309 Interactive real-time voice and video data is inherently variable. 310 Usually the content of the media and service requirements dictate 311 the media coding. The codec may be bursty and not all frames are 312 equally important (e.g., I-frames are more important than 313 P-frames). Thus, codecs have limited room for adaptation. 314 Congestion control for audio and video codecs is therefore 315 different to congestion control applied for bulk transfers. The 316 latter are allows buffering of media irrespective to their content 317 and more fine-grained control for a congestion control algorithm. 318 In the workshop these limitations were brought up and the workshop 319 participants recommended that a congestion controller needs to be 320 aware of these constraints. However, further investigation is 321 needed to decide what information needs to be exchanged between a 322 codec and the congestion manager. 324 Startup Behaviour: 326 The startup media quality is very important for real-time 327 interactive application and for user-perceived application 328 performance. The startup behavior of these is also different to 329 other traffic. By nature the real-time interactive communication 330 applications want to provide a smooth user experience and maintain 331 best media quality to ease the interaction. While it may be 332 desirable from a user experience point of view to immediately 333 start streaming video with high-definition quality and audio of a 334 wideband codec this will have impacts on the bandwidth of the 335 already ongoing flows. As such, it would be ideal to start slow 336 enough to avoid excessive congestion to other flows but fast 337 enough to offer a good user experience. The sweetspot, however, 338 yet has to be found. 340 In addition, there were some discussions on how to make RTCWeb-style 341 flows fair to other RTCWeb-style flows, other TCP based flows, LEDBAT 342 flows, and other flows. This is a much more difficult problem than 343 simply making RTCWeb flows avoid congestion. Changing the way TCP is 344 used in browsers or other HTTP-based applications would already help, 345 for example, by avoid opening too many concurrent TCP connections, 346 and improved interworking with video streaming and file sharing 347 software. The work on HTTP 2.0 with SPDY is already the step in the 348 right direction since SPDY makes makes use of a more aggressive form 349 of multiplexing instead of opening a larger number of TCP 350 connections. 352 4. Acknowledgments 354 We would like to thank the participants and the paper authors of the 355 position papers for their input. 357 Additionally, we would like to thank the following persons for their 358 review comments: Michael Welzl, John Leslie, Mirja Kuehlewind, Matt 359 Mathis, Mary Barnes 361 5. IANA Considerations 363 This memo includes no request to IANA. 365 6. Security Considerations 367 While two position papers focused on security congestion control 368 security itself was not on the agenda of the workshop. As such, 369 nothing beyond the material contained in those position papers can be 370 reported. 372 7. References 374 7.1. Normative References 376 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 377 RFC 2914, September 2000. 379 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 380 for Application Designers", BCP 145, RFC 5405, 381 November 2008. 383 7.2. Informative References 385 [I-D.ietf-avtcore-rtp-circuit-breakers] 386 Perkins, C. and V. Singh, "RTP Congestion Control: Circuit 387 Breakers for Unicast Sessions", 388 draft-ietf-avtcore-rtp-circuit-breakers-00 (work in 389 progress), October 2012. 391 Appendix A. Program Committee 393 This workshop was organized by Harald Alvestrand, Bernard Aboba, Mary 394 Barnes, Gonzalo Camarillo, Spencer Dawkins, Lars Eggert, Matthew 395 Ford, Randell Jesup, Cullen Jennings, Jon Peterson, Robert Sparks, 396 and Hannes Tschofenig. 398 Appendix B. Workshop Material 400 o Main Workshop Page: 401 http://www.iab.org/activities/workshops/cc-workshop/ 403 o Position Papers: 404 http://www.iab.org/activities/workshops/cc-workshop/papers/ 406 o Slides: 407 http://www.iab.org/activities/workshops/cc-workshop/slides/ 409 Appendix C. Accepted Position Papers 411 1. "One control to rule them all" by Michael Welzl 413 2. "Congestion Avoidance Through Deterministic" by Pier Luca 414 Montessoro, Riccardo Bernardini, Franco Blanchini, Daniele 415 Casagrande, Mirko Loghi, and Stefan Wieser 417 3. "Congestion Control in Real Time Media - Context" by Harald 418 Alvestrand 420 4. "Improving the Interactive Real-Time Video Communication with 421 Network Provided Congestion Notification" by ANM Zaheduzzaman 422 Sarker, Ingemar Johansson 424 5. "Multiparty Requirements in Congestion Control for Real-Time 425 Interactive Media" by Magnus Westerlund 427 6. "On Fairness, Delay and Signaling of Different Approaches to 428 Real-time Congestion Control" by Stefan Holmer 430 7. "RTP Congestion Control and RTCWeb Application Feedback" by Ted 431 Hardie 433 8. "Issues with Using Packet Delays and Inter-arrival Times for 434 Inference of Internet Congestion" by Wesley M. Eddy 436 9. "Impact of TCP on Interactive Real-Time Communication" by Ilpo 437 Jarvinen, Binoy Chemmagate, Laila Daniel, Aaron Yi Ding, Markku 438 Kojo, and Markus Isomaki 440 10. "Security Concerns For RTCWeb Congestion Control" by Dan York 442 11. "Vendors Considered Harmfull" by Cullen Jennings, Suhas 443 Nandakumar, and Hein Phan 445 12. "Network-Assisted Dynamic Adaptation" by Xiaoqing Zhu and Rong 446 Pan 448 13. "Congestion Control for Interactive Real-Time Applications" by 449 Sanjeev Mehrotra, and Jin Li 451 14. "There is No Magic Transport Wand" by John Leslie 453 15. "Towards Adaptive Congestion Management for Interactive Real- 454 Time Communications" by Dirk Kutscher, and Miriam Kuehlewind 456 16. "Enlarge the pre-congestion spectrum usage?" by Xavier Marjou, 457 and Emile Stephan 459 17. "Congestion control for users who don't have first-class 460 internet access" by Maire Reavy 462 18. "Realtime Congestion Challenges" by Randell Jesup 464 19. "Congestion Control for Interactive Media: Control Loops & APIs" 465 by Varun Singh, Joerg Ott, and Colin Perkins 467 20. "Some Notes on Threat Modelling Congestion Management" by Eric 468 Rescorla 470 21. "Timely Detection of Lost Packets" by Ali C. Begen 472 22. "Congestion Control Considerations for Data Channels" by Michael 473 Tuexen 475 23. "Position paper on CC for Interactive RT" by Matt Mathis 477 24. "Overall Considerations for Congestion Control" by M. Zanaty, B. 478 VerSteeg, B. Christensen, D. Benham, A. Romanow 480 25. "Fairness Considerations for Congestion Control" by Mo Zanaty 482 26. "Media is not Data: The Meaning of Fairness for Competing 483 Multimedia Flows" by Timothy B. Terriberry 485 27. "Thoughts on Real-Time Congestion Control" by Murari Sridharan 487 28. "Congestion Control for Interactive Real-Time Flows on Today's 488 Internet" by Keith Winstein, Anirudh Sivaraman, and Hari 489 Balakrishnan 491 29. "Congestion Control Principles for CoAP" by Carsten Bormann, 492 Klaus Hartke 494 30. "Erasure Coding and Congestion Control for Interactive Real-Time 495 Communication" by Pierre-Ugo Tournoux, Tuan Tran Thai, Emmanuel 496 Lochin, Jerome Lacan, Vincent Roca 498 31. "Video Conferencing Specific Considerations for RTP Congestion 499 Control" by Stephen Botzko and Mary Barnes 501 32. "The Internet is Broken, and How to Fix It" by Jim Gettys 502 33. "Deployment Considerations for Congestion Control in Real-Time 503 Interactive Media Systems" by Jari Arkko 505 Appendix D. Workshop Participants 507 We would like to thank the following workshop participants for 508 attending the workshop: 510 o Mat Ford 512 o Bernard Aboba 514 o Alissa Cooper 516 o Mary Barnes 518 o Lars Eggert 520 o Harald Alvestrand 522 o Gonzalo Camarillo 524 o Robert Sparks 526 o Cullen Jennings 528 o Dirk Kutscher 530 o Carsten Bormann 532 o Michael Welzl 534 o Magnus Westerlund 536 o Colin Perkins 538 o Murari Sridharan 540 o Klaus Hartke 542 o Pier Luca Montessoro 544 o Xavier Marjou 546 o Vincent Roca 548 o Wes Eddy 550 o Ali C. Begen 551 o Mo Zanaty 553 o Jin Li 555 o Dave Thaler 557 o Bob Briscoe 559 o Barry Leiba 561 o Jari Arkko 563 o Stewart Bryant 565 o Martin Stiemerling 567 o Russ Housley 569 o Marc Blanchet 571 o Zaheduzzaman Sarker 573 o Xiaoqing Zhu 575 o Randell Jesup 577 o Eric Rescorla 579 o Suhas Nandakumar 581 o Hannes Tschofenig 583 o Bill VerSteeg 585 o Sean Turner 587 o Keith Winstein 589 o Jon Peterson 591 o Maire Reavy 593 o Michael Tuexen 595 o Stefan Holmer 597 o Joerg Ott 598 o Timothy Terriberry 600 o Benoit Claise 602 o Ted Hardie 604 o Stephen Botzko 606 o Matt Mathis 608 o David Benham 610 o Jim Gettys 612 o Spencer Dawkins 614 o Sanjeev Mehrotra 616 o Adrian Farrel 618 o Greg White 620 o Markku Kojo 622 We also had remote participants, namely 624 o Emmanuel Lochin 626 o Mark Handley 628 o Anirudh Sivaraman 630 o John Leslie 632 o Varun Singh 634 Authors' Addresses 636 Hannes Tschofenig 637 Linnoitustie 6 638 Espoo, 02600 639 Finland 641 Phone: +358 (50) 4871445 642 Email: Hannes.Tschofenig@gmx.net 643 URI: http://www.tschofenig.priv.at 645 Lars Eggert 646 Sonnenallee 1 647 Kirchheim, 85551 648 Germany 650 Phone: +49 151 12055791 651 Email: lars@netapp.com 652 URI: http://eggert.org/ 654 Zaheduzzaman Sarker 655 Lulea, SE-971 28 656 Sweden 658 Phone: +46 10 717 37 43 659 Email: zaheduzzaman.sarker@ericsson.com