Introduction and Scope
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 RFCs 2914 and 5405:
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.
- First, real-time interactive media sessions require low latencies, whereas streaming media can use large playout buffers.
- Second, RTCP feedback about an RTP session arrives much less frequently than, for example, TCP ACKs for a given TCP connection. This means that the RTP/RTCP control loop has a longer reaction time per se.
- Third, 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.
- Fourth, 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.
- Fifth, 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.
- Sixth, a congestion control scheme for interactive media needs to handle bundles of inter-related flows (audio, video, data), in a way that accommodates the preferences of the application in the event of congestion.
- Seventh, the desire to provide a congestion control mechanism that can be effectively implemented inside an application (e.g., a web server or browser) imposes additional restrictions.
The workshop organizers would like to foster a discussion on:
- What are appropriate congestion signals to use for interactive media and data?
- What existing congestion control algorithms are appropriate for interactive media and data? What properties would be desirable in new congestion control algorithms?
- Measurement and/or simulations of new congestion signals (e.g., delay-based) and their interaction with existing congestion control mechanisms.
- What are good available techniques for adjusting sending rates for interactive media and data? What are the limits of those techniques? What properties would be desirable in new techniques?
- What application-specific considerations have to be taken into account?
- How can we ensure that real-time communications are well-behaved with respect to other Internet applications while still providing good quality?
- What should the IETF and/or IRTF do?
The organizers seek position papers on any or all of these topics, as well as other topics related to congestion control for interactive realtime media.
The workshop will be structured as a series of working sessions punctuated by invited speakers who will present relevant background information or controversial ideas that help participants reach a deeper understanding of the subject. The main goal of the workshop is to foster discussion. As such, this is not a mini-conference where every author briefly talks about their paper. The organizing committee may ask submitters of particularly salient papers to present their ideas and experiences at the workshop. For each slot, there will be one or two invited speakers, followed by group work on the problem that’s identified, with a goal of reaching either a deeper understanding of the problem or some means of approaching it.
Participation at the workshop is free of charge. There is no requirement to either register with or attend the IETF-84 meeting that follows the workshop, but attendance is strongly encouraged, because further discussions about the outcomes of the workshop theme will take place there.
Note: Due to the highly interactive nature of the workshop we are unable to offer remote participation possibilities.
Position Paper Requirement
This is an invitation-only workshop.
Every prospective workshop participant must submit a position paper. The position paper reflects your views on a particular area of the workshop theme. We are interested in your opinion as an expert rather than your official company position. Keep your submission short and focused. If your expertise allows you to write about a range of topics, pick the one topic you think would bring the most value to the workshop. Authors of accepted papers will be invited to the workshop.
Papers up to 3 pages, formatted in HTML, PDF, or plain text (for example, as a submitted Internet-Draft) are ideal. Accepted position papers will be published.
We will provide a link for the paper submission tool in the next few days.
Position paper submission deadline: June 23, 2012
Notification to paper authors: June 30, 2012
Workshop date: July 28, 2012
Due to the close relationship to ongoing IRTF and IETF work, the IPR policies described in RFC 5378 and RFC 3979 apply, both to submitted position papers and to discussions at the workshop.
Paper submissions have to contain a name and an email address. We use this information to subscribe you to a mailing list for sharing workshop related information prior to the workshop (e.g., updates regarding the meeting venue, feedback on the position paper submissions). This specially created mailing list is only used for the duration of the workshop and will be deleted after the publication of the workshop report (which may take several months). You may at any time decide to unsubscribe from the mailing list (at your risk of missing information workshop related postings).
Your name will be listed in the meeting minutes and the workshop report. We will also publish all accepted position papers.
There will be an audio recording of the workshop discussion. This workshop recording will not be distributed to the workshop participants nor to the public; the purpose of the recording is to ensure that the workshop report and the meeting minutes accurately reflect the discussions.
The workshop will be held in Vancouver, Canada on Saturday, July 28th, 2012 prior to the IETF-84 meeting (see http://www.ietf.org/meeting/84/index.html). Additional details about the meeting venue will be provided to authors of accepted papers.
To sponsors: If you are interested to help us working towards better interactive media congestion control mechanisms on the Internet (such as by making a contribution towards catering costs and room rental), please contact us!
As members of the workshop committee we look forward to your input:
- Harald Alvestrand (Google, W3C Web RTC Working Group Co-Chair)
- Bernard Aboba (Microsoft, IAB Chair)
- Mary Barnes (Polycom, IAB Executive Director)
- Gonzalo Camarillo (Ericsson, IETF RAI Area Director)
- Spencer Dawkins (Huawei, IAB Member)
- Lars Eggert (NetApp, IRTF Chair)
- Randell Jesup (Mozilla)
- Cullen Jennings (Cisco, IETF RTC Web Working Group Co-Chair)
- Jon Peterson (Neustar, IAB Member)
- Robert Sparks (Tekelec, IETF RAI Area Director)
- Hannes Tschofenig (Nokia Siemens Networks, IAB Member)