Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication
draft-iab-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 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 December 25, 2016.

Copyright Notice

Copyright (c) 2013 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
• 2. Workshop Structure
• 2.1. History and Challenges
• 2.2. Simulations and Measurements
• 2.3. Challenges and Design Properties
• 3. Recommendations
• 3.1. Changes to Network Infrastructure
• 3.2. Avoiding Self-Inflicted Queuing
• 4. Acknowledgments
• 5. IANA Considerations
• 6. Security Considerations
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Appendix A. Program Committee
• Appendix B. Workshop Material
• Appendix C. Accepted Position Papers
• Appendix D. Workshop Participants
• Authors' Addresses

1. Introduction

Any application that sends significant amounts of data over the Internet is expected to implement reasonable congestion control behavior. The goals for congestion control are well understood and documented in RFC 2914 [2] and RFC 5405 [1]:

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 a "circuit breaker" mechanism (see, for example, [3]), 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. In an Real-time Transport Protocol (RTP) session feedback exchanged via the RTP Control Protocol (RTCP) typically arrives much less frequently than, for example, TCP ACKs for a given TCP connection. Theoretically, 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 [40].
5. Ramping up the transmission rate can be problematic. Simply increasing the output rate of the codec without knowing 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 Explicit Congestion Notification (ECN) [18]), and there are implicit indications of congestion (e.g., packet delay and loss). Care must be taken to account for each of these signals, particularly if various applications react on the same set of signals.
9. Large buffers are often used in network elements and end device operating systems to better support TCP-based applications. These buffers introduce additional communication delay, which harms the small delay budget available for interactive real-time applications.

The Internet Architecture Board (IAB) raised concerns regarding possibilities of a congestion collapse due to a rapid growth in real-time voice traffic that does not practice end-to-end congestion control in early 2004 [16]. This congestion collapse did not happen but the raised concerns are still valid and have gained more relevance when applied to more bandwidth-hungry video applications. Congestion collapse is, however, not the only concern as discussed in this workshop report.

2. Workshop Structure

The IETF has a long history in the work on congestion control mechanisms but with the ongoing standardization work on real-time interactive media communication on the Web new challenges emerged and existing work got revisited. To take a deeper look at the topic the participants contributed 32 papers as input to the one-day workshop.

The workshop started with a keynote speech of Mark Handley describing the history of the work on congestion control for real-time media followed with his views of the problems. A summary of the discussions and the identified issues are captured in the subsections below.

2.1. History and Challenges

The primary goal of congestion control is to avoid congestion collapse - to make the network work. The second important goal is to guarantee some sort of fairness so that all users get some service. Section 3 of RFC 2914 [2] discusses these two goals in detail and references earlier work, such as [19]. [19] informs about historic incidents, such as congestion collapse due to unnecessarily-retransmitted, undelivered, and fragmented packets.

Mark Handley argues that since 1988, the Internet has remained functional despite exponential growth, routers that are sometimes buggy or misconfigured, rapidly changing applications and usage patterns, and flash crowds. This is largely because most applications use TCP, and TCP implements end-to-end congestion control.

TCP's congestion control adapts the window to fit the capacity available in the network and accomplishes approximate fairness between two competing flows over a period of time. Mark indicates that the provided level of fairness is not necessarily what we want: The 1/round-trip-time relationship in TCP is not wonderful since it means that network operators can decide to lower packet loss by adding bigger buffers (which unfortunately leads to bufferbloat problems). The 1/sqrt(packet drop rate) relationship is also not necessarily desirable since TCP did not work particularly well for high-speed flows (which had been subject for a lot of TCP research).

TCP controls the congestion window in bytes. For bulk transfer, usually this results in controlling the number of 1500 byte packets per second sent. Real-time media is, however, different since it has its own time constraints. For audio we want to send one packet per 20ms and for video the ideal value would be 25 to 30 frames per second. We therefore want to avoid additional sending delay.

As an example, in case of video, to relieve congestion one has to reduce the number of packets-per-second transmission rate rather than transmitting smaller packets since at higher bitrates on WiFi the time it takes to send a packet is almost negligible compared to the time that is spent with MAC layer operations. Reducing the packet size makes little difference to the available capacity. For a serial line it does not matter how big the packets are.

From a network point of view the goals of congestion control therefore are:

1. Avoid congestion collapse
2. Avoid starvation of TCP flows
3. Avoid starvation of real-time flows. Specifically, in the case where TCP and real-time flows share the same FIFO queue.

From an application point of view the goals of congestion control are different, namely:

1. Robust behavior. One wants to have a good throughput when the network is working well and it still works when the network is working poorly.
2. Predictable behavior. This matters from a usability point of view since variable media quality is bad for users.
3. Low latency. With large buffers along the end-to-end path the latency will increase when interactive real-time flows compete with TCP flows since TCP will fill up the buffers and the increased buffering leads to additional delays for the delivery of the interactive real-time media.

Attempts for providing congestion control for interactive real-time media were already done much earlier in the IETF, for example, with the work on TCP-Friendly Rate Control (TFRC) [11]. It illustrates the challenges quite well. TFRC tries to accomplish the same throughput as TCP, but with smoother transmission rate. It measures the loss and the round-trip time but follows a similar model as TCP to determine the sending rate.

In a link with low statistical multiplexing TCP can lead to bad oscillations. The sending rate hits the maximum rate of a bottleneck link, a lot of loss occurs, and then the sending rate peaks again. For very small buffers the result is acceptable but bigger buffers lead to oscillations. The result is bad for networks and for applications. To deal with large buffers on these links a short-term rate adaptation based on round-trip time (RTT) information is utilized in TRFC but this requires good short-term RTT measurements.

TRFC works pretty well in theory. TFRC assumes the network is in charge of the codec and that the codec can produce data at the demanded rate. Modern video codecs inherently produce variable-bitrate video streams based on the content being encoded, and it is hard to produce data at exactly the desired bitrate without excessive buffering or ugly quality changes.

What if we put the codec in charge instead of the network? The network tells the codec the mean rate but it does not worry about what happens in short time scales and the codec matches the mean rate and does not worry whether it is over or under the rate for a relatively short time scale. This again leads to the low statistical multiplexing problem and leads to oscillations.

Known congestion control mechanisms work well if they can respond quickly enough to changes if they do not bump into the low statistical multiplexing problem.

To avoid the low statistical multiplexing problem techniques for inferring linkspeed are needed and the work from Van Jacobson's pathchar [37] (and successors) serve as valuable input. The idea is to send short packet trains, to measure timing accurately, and to infer the linkspeed from the relative delay. If we know the linkspeed, we can avoid exceeding it. Congestion control can give us an approximate rate, but we must not exceed linkspeed. This is a hybrid between codec being in charge (most of the time), and network being in charge. These work well for some links, but not for others. Wireless links where speed can change in less than a single RTT because of fading, bitrate adaption, etc. cause problems. We would like to have the codec and the network to be in charge. However, they cannot be both in charge at the same time.

Mark indicated that he is not entirely sure whether RTCP is suitable for congestion control. "RTCP gives feedback, but it cannot send it often enough to avoid bumping into linkspeed." he says. Circuit breakers [3] on the other hand do not help to give good performance on an uncongested path. With circuit breakers the sender measures the loss rate and RTT, and runs with a loose "cap".

As a conclusion, Mark Handley claims that we know how to do good congestion control, but only if congestion control is in charge, and that's not acceptable for real-time applications. We only know how to do good congestion control if we change packet/sec rate and not packet size.

2.2. Simulations and Measurements

This second part of the workshop was focused on the presentation and the discussion of data gathered from simulations and real-world measurements.

Keith Winstein started the discussion with his presentation of measurements performed in cellular operator networks in the US [22]. The measurements indicate that the analyzed cellular networks showed varying RTT with transient latency spikes to hundreds of ms, link speed that varies by a factor of 10 in a short time scale, and buffers that do not drop packets until they contain 5 - 10 seconds of data at bottleneck link speed.

Zaheduzzaman Sarker [21] presented results from real-time video communication in an LTE simulator utilizing ECN-based packet marking and adaptation using implicit methods like packet loss and delay. ECN marking provides ways for the network to explicitly signal congestion hence distributes the cost of congestion well and helps achieving lower latency. However, although RFC 3168 [18] was finalized in 2001 the deployment of ECN is still lacking as investigated by Bauer, et al. [25]. A few participants noted that they believe that the deployment of LTE networks will also increase the deployment of ECN.

Mo Zahaty [20] discussed TFRC [11] and TFRC with weighted fairness (MulTFRC) [4], which tunes TFRC to consider multiple flows, and showed the impact of RTT and loss rates on the type of video quality that can be achieved under those conditions. TFRC requires frequent feedback, which RTCP does not provide even when considering the extended RTP profile for RTCP-based feedback (RFC 4585 [5]). Mo argued that application-specified weighted fairness is important but while MulTFRC provides better performance than TFRC it is not clear whether the added complexity over an n-times-TFRC approach is indeed worth the effort.

Markku Kojo shared analysis results of how real-time audio is affected by competing TCP flows. In the experiments shown in Figure 2 of [27] a real-time interactive audio stream had to compete against one TCP flow, and, as a comparison, against six TCP flows. With one concurrent TCP flow voice is impacted on startup and six TCP flows destroy quality of call. Two types of losses were analyzed, namely losses that result from a packet being dropped in the network (e.g., due to congestion or link errors) and losses that result from the delayed arrival of the packet (due to buffering) when the audio packet misses the deadline for the codec to decode and play the transmitted content. Consequently, even a moderate number of TCP flows typically used by browsers to retrieve content on Web pages in parallel causes irreparable harm for audio transfers. The size of the initial window also impacts interactive real-time communication since a larger TCP initial window size (e.g., IW(10) with ten segments, as proposed in [17], instead of three) leads to a bigger burst of packets because of the initial window transmission. Note that the study in [24] does not necessarily lead to the same conclusion. It claims that that the increased initial window size leads to no impact or only modest impact for buffering in the majority of cases.

Cullen Jennings [28] presented measurement results showing interactions between RTP and TCP flows for several widely deployed video communication products, i.e., Apple Facetime, Google Hangout, Cisco Movi, and Microsoft Skype. While all tested products implemented some form of congestion control none of the applications did additive increase and multiplicative decrease (AIMD). In general, it was observable that video adapts more slowly than AIMD to changes in available bandwidth, because most codecs cannot make small increases in sending rates when available bandwidth increases, and do not make large decreases in sending rates when available bandwidth decreases, in order to improve the user's experience.

Stefan Holmer [41] investigated the difference between loss-based and delay-based congestion control algorithms. The suitability of loss-based congestion control schemes for interactive real-time communication systems heavily depends on buffer sizes and the deployment of active queue management mechanisms. If most routers are using tail-drop queuing, then loss-based congestion control cannot fulfill the requirements of interactive real-time applications since those flows will effectively increase the bitrate until a loss event is identified, which only happens when the bottleneck queue is full.

2.3. Challenges and Design Properties

During the remaining part of the workshop the participants discussed challenges and identified design properties. The discussions in this session started with a presentation by Jim Gettys about problems related to bufferbloat [32][36]. Bufferbloat is "a phenomenon in a packet-switched computer network whereby excess buffering of packets inside the network causes high latency and jitter, as well as reducing the overall network throughput." [39]. A certain amount of buffering is helpful to improve the efficiency. Not dropping packets in the event of congestion leads to increasing delays for interactive real-time communication.

Packets may get buffered at various places along the end-to-end path including in the operating system/device drivers, customer premise equipment (such as cable modem and DSL routers), base stations, and routers. While the understanding of too large buffers has improved over the last few years the participants were still concerned that many equipment manufactures and network operators do not yet acknowledge the existence of the problem. This lack of understanding is caused by the strong focus on throughput network performance measurements that do not take latency into account. For example, only recently the Federal Communications Commission (FCC) has added latency tests to their test suites [REF missing].

Active queue management (AQM) aims to prevent queues from growing too large. This is accomplished by the monitoring queue length and by informing the sender by dropping or marking packets to lower their transmission rate. Random Early Detection (RED) [9] is one such AQM algorithm but it has not been widely deployed in routers largely because of challenges to configure it correctly [33]. According to [23], RED does not work with the default settings as it is "too gentle to handle fast changes due to TCP slow start when the aggregate traffic is limited". There may also be a lack of incentives to deploy AQM algorithms. Participants speculated about the time it takes to update network equipment (to support AQM algorithms) considering the different replacement cycles of these devices. Measurement tools that allow an end user to determine the performance of their network, including latency, is seen as a promising approach to motivate network operators to upgrade their equipment and to make use of AQM algorithms. Measurement tools would allow users to determine how bad your network performs and to complain to your ISP and thereby creating a market force. As to what the right performance measurement metrics are it was noted that the intent of the IETF IP Performance Metrics (IPPM) working group [34] was to develop such metrics to qualify networks it may have started too early. There are, however, recent attempts to re-visit the measurement work and an effort by the FCC has gotten a lot of attention recently, see [7].

Matt Mathis argued that the traffic of throughput-maximizing and delay-minimizing applications need to be in separate queues, i.e. that segregated queuing is applied. Requiring segregated queues assumes you are sharing the network with other greedy traffic. Others agreed with him. Quality of Service signaling is a way to deploy segregated queuing but there are several simpler alternatives, such as Stochastic Fair Queuing [38]. The Controlled Delay (CoDel) AQM algorithm [6] can also be used in combination with stochastic fair queuing. Note that queue segregation is not necessary for every router to segregate and using it at the edge of a network where bottleneck links are is already sufficient.

It was noted that current interactive voice usage over the Internet works most of the time satisfactory. In typical networks, the reason voice works is because networks are underloaded. As long as there is idle capacity and the queue is empty when your packets arrive, traffic does not be separated into distinct queues. Further explanations were offered why many networks work surprisingly well: LEDBAT [8] is used for the download of software updates, voice traffic contributes only a small percentage of the overall Internet traffic, and "human protocols" (e.g., parents asking their kids to get off the network during the time of a conference call).

Cullen Jennings raised a concern that not providing a solid congestion control mechanism for interactive video, as it was done with interactive voice, could have substantial impact due to the potential uptake in deployment triggered by the work on RTCWeb. He phrased it as "I'm worried about the approach that says 'Let us do the minimal' and that is what we did with voice -- nothing. If we do the same with video, we're going to be in trouble. In the class of space where voice is currently working, that's where I'm worried about video failing." Ted Hardie countered by saying that RTCWeb is trying to replace existing proprietary technologies. It may ramp up the amount of use we are expecting, but it is not doing much that was not being done by Adobe Flash or Skype. RTCWeb is not a totally novel context of Internet usage. Magnus Westerlund concluded that RTCWeb might be driver for the moment, but we are not only talking about Web browsers.

Furthermore, Ted noted that applications will not produce media streams that grow to 10Mbps because their sending rate is auto-rate-limited by the production of the video. He suggested to ask ourselves if we are trying to get TCP to be friendly to media streams, which are already rate-limited or are we asking media streams that are already rate-limited to be TCP friendly? He then quoted Andrew McGregor: "It's really not good to be TCP-friendly because it's not going to return the favor." If the desired properties we want are no starvation, fairness, and effective goodput for the offered loads, is the only thing we're willing to consider changes in RTP control or are we willing to consider changes in TCP congestion control?

This led to a discussion whether the development of a congestion control algorithm for interactive real-time applications provides any value if network equipment suffers from bufferbloat. Is there something that can be done today to help interactive real-time media or do we have to wait to get the network updated first? Replacing home routers and updating routers with modern AQM algorithms was seen as a longer-term effort. Also, the time scale for changing TCP's congestion control is on the time scale as deploying ECN [18]. Colin Perkins noted that while we cannot change TCP quickly, but the way TCP is being used is changing quickly and we can impact the way TCP is used. When TCP is used for file transfer it will send data as fast as it can but when TCP is used for WebSockets, the dynamics are different. WebSockets and SPDY are clearly changing the behavior of TCP. Also, Netflix-style video streaming applications are huge users of TCP and those applications can change rather quickly. Matt Mathis added that real-time videoconferencing almost always produces video streams at a lower bitrate than downloading equivalent-sized stored video using best-effort file-sharing will produce.

Bill Ver Steeg suggested to consider three different deployment environments, namely

1. Flows competing with flows from the host ("self-inflicted queuing delay")
2. Flows competing with flows in the same sub-network (e.g. home network)
3. Flows competing with flows from other networks (e.g., traffic from different households that utilize the same DSL provider)

The narrowest problem domain that makes sense is to avoid self-inflicted queuing delay. Michael Welzl indicated that this requires an information exchange (called flow-state exchange) inside a browser (at the level of the same host or even beyond, as described in [29]) to synchronize congestion control of different audio, video, and data flows. Although it would provide great benefits if one could share information about a bottleneck with all the flows sharing that bottleneck but this is considered challenging even within a single host. John Leslie [30] also noted: "We're acting as if we believe congestion will magically be solved by a new transport algorithm. It won't." Instead, an interaction between the network layer, transport layer, and the application layer is needed whereby the application layer is the only practical place to balance what piece(s) to constrain to lower bandwidths. All flows relating to a user session should have a common congestion controller. For many applications, audio is much more critical than video. In those cases the video may back off, but the audio transmission remains unchanged.

Mo Zanaty pointed to the importance of the media start-up behavior, which is an area where the exchange of real-time interactive media is different from a TCP-based file transfer. The instantaneous experience in the first part of a video call is highly determinative of people's perception of the call quality. Vendors are using vague heuristics, for example, data from the last call to figure out what to do on the next call. Lars Eggert highlighted that the start-up behavior of an application affects ongoing performance of other flows if, for example, an application blast at line rate at the beginning of a video stream. You need to start slow enough to not cause congestion to others. Randell Jesup argued that for an interactive real-time video application, you really need to have most of your bandwidth right away. Colin Perkins agreed and added that on startup you need good quality video quickly, but how quickly? For a phone call one needs to be able to say "Hello!" pretty quickly, but for video it may not be necessary to see the other person very quickly. Those requirements are likely going to be different from audio to video and maybe even vary between different applications. Various protocol exchanges take place before media is exchanged between endpoints (such as STUN packets [12] as part of the ICE [14] or a DTLS security handshake [13]) and may be used to the advantage to obtain a couple simple measurements.

The group agreed that it is feasible to design a congestion control algorithm that work on mostly idle networks. In the view of the participants upgrades of the network infrastructure can happen in parallel. This view was later confirmed at the RTP Media Congestion Avoidance Techniques (RMCAT) Birds of a Feather ("BoF") meeting at IETF#84 (July 29 - August 3, 2012, Vancouver, BC, Canada) that led to the formation of the RMCAT working group [35].

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 protocols would benefit from being in different queues from throughput maximizing protocols. It is not possible for a single queue/AQM to be optimal for both.

Furthermore, 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. The participants expressed the importance to increase the deployment of ECN, even if used initially only in closed environments likes data centers (as with Data Center TCP (DCTCP) [26].

Different mechanisms have been developed to facilitate traffic segregation. Differentiated Services [10] 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, as mentioned in Section 2.3 QoS signaling is not the only way to accomplish traffic segregation. Further investigations regarding stochastic fair queuing and new AQM algorithms is seen as desirable.

In any case, network infrastructure updates will take time particularly if the interest of the involved stakeholders is not aligned (as is often the case for network operators). 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 suffer from congestion collapse and that one data flow from a single host does not harm another data stream from the same host. 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 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. In case of implicit mechanism, packet loss events or observed delay increase is used as an indication for congestion. These measurements can also be made available in a variety of different protocols, such as RTCP reports or transport protocols. It is recommended for applications to take all available congestion signals into account and to couple the congestion control algorithm, the codec and the application so that better information exchange between these components is possible since there are constraints on how quickly a codec can adapt to a specific sending rate.

Delay- and Loss-based Algorithms:

The main goal of designing a congestion control algorithm for real-time conversational media is to achieve low latency. Although explicit congestion signals provide the most reliable way for applications to react. However, due to the lack of ECN deployment delay based algorithms are needed. Since there is large delay variation in wireless networks (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 latency-based congestion control algorithms are needed due to the lack of loss indications caused by large buffers but 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 the deployed Internet. To achieve this it is recommended to test the algorithms with real-world loss and delay figures to ensure 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 to 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.

Some workshop participants also recommended to change the way TCP is used in browsers and other HTTP-based applications. For example, by not opening too many concurrent TCP connections, and by improving the interaction with other non-real-time applications (such as video streaming and file sharing) additional improvements can be made. The work on HTTP 2.0 with SPDY [15] is already the step in the right direction since SPDY makes use of a more aggressive form of multiplexing instead of opening a larger number of TCP connections.

Finally, it was noted that ongoing IETF standardization activities should be supported with deployment tests, not just simulations, to verify the effectiveness of developed congestion control algorithms.

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, Spencer Dawkins, Alissa Cooper

5. IANA Considerations

This memo includes no request to IANA.

6. Security Considerations

Two position papers focused on security but these papers were not discussed during the workshop. As such, nothing beyond the material contained in those position papers can be reported.

7. References

7.1. Normative References

7.2. Informative References

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

• Main Workshop Page: http://www.iab.org/activities/workshops/cc-workshop/
• Position Papers: http://www.iab.org/activities/workshops/cc-workshop/papers/
• Slides: http://www.iab.org/activities/workshops/cc-workshop/slides/

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:

• Mat Ford
• Bernard Aboba
• Alissa Cooper
• Mary Barnes
• Lars Eggert
• Harald Alvestrand
• Gonzalo Camarillo
• Robert Sparks
• Cullen Jennings
• Dirk Kutscher
• Carsten Bormann
• Michael Welzl
• Magnus Westerlund
• Colin Perkins
• Murari Sridharan
• Klaus Hartke
• Pier Luca Montessoro
• Xavier Marjou
• Vincent Roca
• Wes Eddy
• Ali C. Begen
• Mo Zanaty
• Jin Li
• Dave Thaler
• Bob Briscoe
• Barry Leiba
• Jari Arkko
• Stewart Bryant
• Martin Stiemerling
• Russ Housley
• Marc Blanchet
• Zaheduzzaman Sarker
• Xiaoqing Zhu
• Randell Jesup
• Eric Rescorla
• Suhas Nandakumar
• Hannes Tschofenig
• Bill VerSteeg
• Sean Turner
• Keith Winstein
• Jon Peterson
• Maire Reavy
• Michael Tuexen
• Stefan Holmer
• Joerg Ott
• Timothy Terriberry
• Benoit Claise
• Ted Hardie
• Stephen Botzko
• Matt Mathis
• David Benham
• Jim Gettys
• Spencer Dawkins
• Sanjeev Mehrotra
• Adrian Farrel
• Greg White
• Markku Kojo

We also had remote participants, namely

• Emmanuel Lochin
• Mark Handley
• Anirudh Sivaraman
• John Leslie
• Varun Singh

Authors' Addresses