Network Working Group H.T. Tschofenig
Internet-Draft L.E. Eggert
Intended status: Informational Z.S. Sarker
Expires: April 02, 2013 October 2012

Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication
draft-tschofenig-cc-workshop-report-00.txt

Abstract

This document provides a summary of the IAB/IRTF Workshop on 'Congestion Control for Interactive Real-Time Communication', which took place in Vancouver, Canada, on July 28, 2012. The main goal of the workshop was to foster a discussion on congestion control mechanisms for interactive real-time communication. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community. The views and positions in this report are those of the workshop participants and do not necessarily reflect the views and positions of the authors, the Internet Architecture Board (IAB) or the Internet Research Task Force (IRTF).

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 02, 2013.

Copyright Notice

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:/⁠/⁠trustee.ietf.org/⁠license-⁠info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

Any application that sends significant amounts of data over the Internet is expected to implement reasonable congestion control behavior. Although the specific mechanisms depend on the application or protocol, the motivations for congestion control are well understood and documented in RFC 2914 [RFC2914] and RFC 5405 [RFC5405]. The goals are:

  1. Preventing congestion collapse.
  2. Allowing multiple flows to share the network fairly.

The Internet has been used for interactive real-time communication for decades, most of which is being transmitted using RTP over UDP, often over provisioned capacity and/or using only rudimentary congestion control mechanisms.

The development and upcoming widespread deployment of web-based real-time media communication - where RTP is used to and from web browsers to transmit audio, video and data - will likely result in substantial new Internet traffic. Due to the projected volume of this traffic, as well as the fact that it is more likely to use unprovisioned capacity, it is essential that it is transmitted with robust and effective congestion control mechanisms.

Designing congestion control mechanisms that perform well under a wide variety of traffic mixes and over network paths with widely varying characteristics is not easy. Prevention of congestion collapse can be achieved through "circuit breaker" mechanisms, but for media flows that are supposed to coexist with a user's other ongoing communication sessions, a congestion control mechanism that shares capacity fairly in the presence of a mix of TCP, UDP and other protocol flows is needed.

Many additional complications arise. Here are some examples:

  1. Real-time interactive media sessions require low latencies, whereas streaming media can use large play-out buffers.
  2. RTCP feedback about an RTP session typically arrives much less frequently than, for example, TCP ACKs for a given TCP connection. The RTP/RTCP control loop can lead to a longer reaction time.
  3. Media codecs can usually only adjust their output rates in a much more coarse-grained fashion than, for example, TCP, and user experience suffers if encoding rates are switched too frequently. Codecs typically have a minimum sending rate as well.
  4. Some bits of an encoded media stream are more important than others. For example, losing or dropping an I-frame of a video stream is more problematic than dropping a P-frame.
  5. Ramping up the transmission rate can be problematic. Simply increasing the output rate of the codec without knowledge whether the network path can sustain transmission at the increased rate runs the danger of incurring a significant amount of packet loss that can cause playback artifacts.
  6. A congestion control scheme for interactive media needs to handle bundles of interrelated flows (audio, video, data), in a way that accommodates the preferences of the application in the event of congestion.
  7. The desire to provide a congestion control mechanism that can be efficiently implemented inside an application (e.g., a web server and a browser) imposes additional restrictions.
  8. There are explicit congestion signals (such as ECN), and there are indirect indications of congestion (such as packet delay and loss). However, congestion is not the only source of these indirect signals. Care must be taken to account for each of these signals, particularly if various applications react on the same signals.
  9. Network elements and end device operating systems often create buffers to better support TCP-based applications. These buffers introduce additional communication delay, which harms the small delay budget available for real-time applications.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect the views of the authors.

2. History and Current Status

The currently deployed RTP-based RTC systems use congestion control schemes that are ad hoc at best. As the Internet moves towards an RTCWeb standard for interoperable audio/video conferencing, it needs a standardized and most importantly effective mechanism for congestion control.

The most immediate need is for a control mechanism that balances a real-time flow fairly among other competing traffic. For instance, under congested conditions, it would be inappropriate to use far more bandwidth than flows from other applications are using, particularly lasting gross over-utilization of the network. Simple "circuit breaker" -style control mechanisms can prevent congestion collapse by disabling a circuit that far exceeds a fair share and making the circuit remain disabled for some time. But does not in any way enable concurrent flows to share available network capacity sensibly.

Therefore, in addition to circuit breakers, more complete methods for media congestion control are needed. The focus of the workshop was on discussing ideas for these more complete congestion control methods.Note that the primary focus of the workshop is RTCWeb-style audio/video flows. The assumed underlying flows (in most attendees minds) were digital audio/video data encapsulated in RTP over UDP over IP. Most of the concepts presented at the workshop could be used with different media types over different transports, but this was the generally assumed baseline for discussions.

3. Recommendations

The participants suggested to explore two complementary solution tracks, as described in the two sub-sections below.

3.1. Changes to Network Infrastructure

Like for all other traffic on the network, better data plane infrastructure improves the perceived quality of the best-effort service the Internet provides for RTCWeb flows. The IETF has already developed several technologies that would be of immediate usefulness, if they were deployed. The workshop participants expressed the hope that due to the volume and importance of RTCWeb traffic, some of these technologies might finally see widespread use.

The first and by far most important improvement is traffic segregation, i.e., the ability to use different queues for different traffic types. Specifically jitter/delay sensitive and throughput maximizing protocols need to be in different queues. It is not possible for a single queue/AQM to be optimal for both.

Explicit Congestion Notification (ECN) allows routers along the end-to-end path to signal the onset of congestion and allows applications to respond early, avoiding losses and keep queue sizes short and therefore end-to-end delay low. ECN is implemented on some end system stacks and routers, but frequently not enabled.

Different mechanisms have been developed to facilitate traffic segregation. Differentiated services are one possibility in this space if applications start to mark outgoing traffic appropriately and routers would segregate traffic accordingly, browsers could more directly control the relative importance of their various flows, and avoid self-competition. Compared to ECN, however, DiffServ is far more difficult to deploy meaningfully end-to-end, especially given that DSCPs have no defined end-to-end meaning and packets can be re-marked. Quality-of-service (QoS) signaling together with resource reservation facilities would enable a fine-grained and flexible way to indicate resource needs to network elements but it is also by far the most heavyweight proposal, and unlikely to be viable in the global Internet.

However, any change to network infrastructure will take time particularly if the interest of the involved stakeholders is not aligned (as it is the case for network operators and over-the-top application providers). It is therefore imperative that RTCWeb congestion control provides adequate improvement in the absence of any of the aforementioned schemes.

3.2. Avoiding Self-Inflicted Queuing

This approach tries to ensure that the network does not get congested by focusing on the traffic sent by a single host independent of any changes to networks, as mentioned in the earlier chapter. A single congestion manager within the end host or the browser could already help to coordinate various congestion control activities and to ensure a more coordinated approach between different applications, and different flows.

The following activities were suggested during the workshop.

Reacting to all Congestion Signals:


To initiate the congestion control process it is important to detect congestion in the communication path. Congestion in the comminication can be detected using either an explicit mechanism or an implicit mechanism. The explicit mechanism involves direct congestion signaling usually from the congested network node, such as ECN. The ECN bits are set in the IP header by the network node before it starts to drop the packets and gives end hosts to react to the congestion. In case of implicite mechanism, a particular characteristics or event in the network traffic can be inferred as a congestion signal. For example, packet loss events or observed delay increase or jitter in the communication path can be taken as an implicit congestion signals. These measurements can also be made available in a variety of different protocols, such as RTCP reports or transport protocols. Communication endpoints can trigger congestion control on the event of these phenomena. It is also possible to correlate these events to detect congestion in the communication path. The implicit and explicit signals can come in any sequence and at any time during the ongoing media session. It is recommended to react to all the possible implicit congestion signals, ideally from all applications at the end host, to avoid self- inflicted queues.
Delay- and Loss-based Algorithms:


The main goal of designing a congestion control algorithm for real-time conversational media is to achieve low latency. An explicit signaling based congestion control algorithm perhaps is the best fit for this purpose as the network nodes are directly involved in the process. However, in case of absence of ECN support in the end-to-end communication path delay based algorithms are needed where the increased delay in the communication path is taken into account as implicit congestion signal. While it is difficult to design algorithms based on delay since many wireless networks show a wide delay variation even in a non-congested network. The workshop participants recommended that more research should be done to better understand non-congestion related delay variation in the network. General consensus among the workshop participants was that when latency-based techniques were competing against loss-based techniques, the loss-based techniques got all the bandwidth.
Algorithm Evaluation:


The Internet consists of heterogeneous networks, which also includes misconfigured, and unmanaged network nodes. Bandwidth and latency varies a lot. Not only this, different services deployed using RTP/UDP have different requirements in terms of media quality. A congestion control algorithm needs to perform well not only in simulators but also in today's Internet. To achieve this it is recommended to test the algorithms with real-world loss and delay figures to be sure that the desired audio/video rates are attainable using the proposed algorithms for the desired services.
Media Characteristics in Focus:


Interactive real-time voice and video data is inherently variable. Usually the content of the media and service requirements dictate the media coding. The codec may be bursty and not all frames are equally important (e.g., I-frames are more important than P-frames). Thus, codecs have limited room for adaptation. Congestion control for audio and video codecs is therefore different to congestion control applied for bulk transfers. The latter are allows buffering of media irrespective to their content and more fine-grained control for a congestion control algorithm. In the workshop these limitations were brought up and the workshop participants recommended that a congestion controller needs to be aware of these constraints. However, further investigation is needed to decide what information needs to be exchanged between a codec and the congestion manager.
Startup Behaviour:


The startup media quality is very important for real-time interactive application and for user-perceived application performance. The startup behavior of these is also different to other traffic. By nature the real-time interactive communication applications want to provide a smooth user experience and maintain best media quality to ease the interaction. While it may be desirable from a user experience point of view to immediately start streaming video with high-definition quality and audio of a wideband codec this will have impacts on the bandwidth of the already ongoing flows. As such, it would be ideal to start slow enough to avoid excessive congestion to other flows but fast enough to offer a good user experience. The sweetspot, however, yet has to be found.

In addition, there were some discussions on how to make RTCWeb-style flows fair to other RTCWeb-style flows, other TCP based flows, LEDBAT flows, and other flows. This is a much more difficult problem than simply making RTCWeb flows avoid congestion. Changing the way TCP is used in browsers or other HTTP-based applications would already help, for example, by avoid opening too many concurrent TCP connections, and improved interworking with video streaming and file sharing software. The work on HTTP 2.0 with SPDY is already the step in the right direction since SPDY makes makes use of a more aggressive form of multiplexing instead of opening a larger number of TCP connections.

4. Acknowledgments

We would like to thank the participants and the paper authors of the position papers for their input.

Additionally, we would like to thank the following persons for their review comments: Michael Welzl, John Leslie, Mirja Kuehlewind, Matt Mathis, Mary Barnes

5. IANA Considerations

This memo includes no request to IANA.

6. Security Considerations

While two position papers focused on security congestion control security itself was not on the agenda of the workshop. As such, nothing beyond the material contained in those position papers can be reported.

7. References

7.1. Normative References

[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.

7.2. Informative References

[I-D.ietf-avtcore-rtp-circuit-breakers] Perkins, C and V Singh, "RTP Congestion Control: Circuit Breakers for Unicast Sessions", Internet-Draft draft-ietf-avtcore-rtp-circuit-breakers-00, October 2012.

Appendix A. Program Committee

This workshop was organized by Harald Alvestrand, Bernard Aboba, Mary Barnes, Gonzalo Camarillo, Spencer Dawkins, Lars Eggert, Matthew Ford, Randell Jesup, Cullen Jennings, Jon Peterson, Robert Sparks, and Hannes Tschofenig.

Appendix B. Workshop Material

Appendix C. Accepted Position Papers

  1. "One control to rule them all" by Michael Welzl
  2. "Congestion Avoidance Through Deterministic" by Pier Luca Montessoro, Riccardo Bernardini, Franco Blanchini, Daniele Casagrande, Mirko Loghi, and Stefan Wieser
  3. "Congestion Control in Real Time Media - Context" by Harald Alvestrand
  4. "Improving the Interactive Real-Time Video Communication with Network Provided Congestion Notification" by ANM Zaheduzzaman Sarker, Ingemar Johansson
  5. "Multiparty Requirements in Congestion Control for Real-Time Interactive Media" by Magnus Westerlund
  6. "On Fairness, Delay and Signaling of Different Approaches to Real-time Congestion Control" by Stefan Holmer
  7. "RTP Congestion Control and RTCWeb Application Feedback" by Ted Hardie
  8. "Issues with Using Packet Delays and Inter-arrival Times for Inference of Internet Congestion" by Wesley M. Eddy
  9. "Impact of TCP on Interactive Real-Time Communication" by Ilpo Jarvinen, Binoy Chemmagate, Laila Daniel, Aaron Yi Ding, Markku Kojo, and Markus Isomaki
  10. "Security Concerns For RTCWeb Congestion Control" by Dan York
  11. "Vendors Considered Harmfull" by Cullen Jennings, Suhas Nandakumar, and Hein Phan
  12. "Network-Assisted Dynamic Adaptation" by Xiaoqing Zhu and Rong Pan
  13. "Congestion Control for Interactive Real-Time Applications" by Sanjeev Mehrotra, and Jin Li
  14. "There is No Magic Transport Wand" by John Leslie
  15. "Towards Adaptive Congestion Management for Interactive Real-Time Communications" by Dirk Kutscher, and Miriam Kuehlewind
  16. "Enlarge the pre-congestion spectrum usage?" by Xavier Marjou, and Emile Stephan
  17. "Congestion control for users who don't have first-class internet access" by Maire Reavy
  18. "Realtime Congestion Challenges" by Randell Jesup
  19. "Congestion Control for Interactive Media: Control Loops & APIs" by Varun Singh, Joerg Ott, and Colin Perkins
  20. "Some Notes on Threat Modelling Congestion Management" by Eric Rescorla
  21. "Timely Detection of Lost Packets" by Ali C. Begen
  22. "Congestion Control Considerations for Data Channels" by Michael Tuexen
  23. "Position paper on CC for Interactive RT" by Matt Mathis
  24. "Overall Considerations for Congestion Control" by M. Zanaty, B. VerSteeg, B. Christensen, D. Benham, A. Romanow
  25. "Fairness Considerations for Congestion Control" by Mo Zanaty
  26. "Media is not Data: The Meaning of Fairness for Competing Multimedia Flows" by Timothy B. Terriberry
  27. "Thoughts on Real-Time Congestion Control" by Murari Sridharan
  28. "Congestion Control for Interactive Real-Time Flows on Today's Internet" by Keith Winstein, Anirudh Sivaraman, and Hari Balakrishnan
  29. "Congestion Control Principles for CoAP" by Carsten Bormann, Klaus Hartke
  30. "Erasure Coding and Congestion Control for Interactive Real-Time Communication" by Pierre-Ugo Tournoux, Tuan Tran Thai, Emmanuel Lochin, Jerome Lacan, Vincent Roca
  31. "Video Conferencing Specific Considerations for RTP Congestion Control" by Stephen Botzko and Mary Barnes
  32. "The Internet is Broken, and How to Fix It" by Jim Gettys
  33. "Deployment Considerations for Congestion Control in Real-Time Interactive Media Systems" by Jari Arkko

Appendix D. Workshop Participants

We would like to thank the following workshop participants for attending the workshop:

We also had remote participants, namely

Authors' Addresses

Hannes Tschofenig Linnoitustie 6 Espoo, 02600 Finland Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at
Lars Eggert Sonnenallee 1 Kirchheim, 85551 Germany Phone: +49 151 12055791 EMail: lars@netapp.com URI: http://eggert.org/
Zaheduzzaman Sarker Lulea, SE-971 28 Sweden Phone: +46 10 717 37 43 EMail: zaheduzzaman.sarker@ericsson.com