RFC 7295

Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication 🎀

Okay so, the title block first! 💅 This one is from the Internet Architecture Board (IAB), written by H. Tschofenig, L. Eggert, and Z. Sarker. It's published as RFC 7295 in July 2014, and it's Informational, which means it's a permanent record and not a standard. The ISSN is 2070-1721. It doesn't list anything it obsoletes or updates. 🦋

Abstract ✨

Okay bestie, so this doc is a recap of the IAB/IRTF Workshop on 'Congestion Control for Interactive Real-Time Communication', which happened in Vancouver, Canada, on July 28, 2012. 🍓 The big goal was to get people talking about congestion control mechanisms for interactive real-time communication, and the report sums up those discussions and lists recommendations for the IETF community. 💜

The views in here belong to the workshop participants. They don't necessarily match the views of the authors, the Internet Architecture Board (IAB), or the Internet Research Task Force (IRTF). Not the same thing, periodt! 🙈

Status of This Memo 🌸

This document is not an Internet Standards Track specification. It's published just for information. 🧚

It's a product of the Internet Architecture Board (IAB), and it holds info the IAB thought was worth keeping on the permanent record. It represents the consensus of the IAB. Documents the IAB approves for publication aren't candidates for any level of Internet Standard, see Section 2 of RFC 5741. 💅

For the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc7295. 🔥

Copyright Notice 🌈

Copyright (c) 2014 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) as they were in effect on the date of publication. Please read them carefully, because they describe your rights and restrictions for this document. 📜

---

Table of Contents 🦋

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Workshop Structure  . . . . . . . . . . . . . . . . . . . . .   5
  2.1.  History and Current Challenges  . . . . . . . . . . . . .   5
  2.2.  Simulations and Measurements  . . . . . . . . . . . . . .   8
  2.3.  Design Aspects of Problems and Solutions  . . . . . . . .   9
3.  Recommendations . . . . . . . . . . . . . . . . . . . . . . .  13
  3.1.  Changes to Network Infrastructure . . . . . . . . . . . .  14
  3.2.  Avoiding Self-Inflicted Queuing . . . . . . . . . . . . .  15
4.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  17
6.  Informative References  . . . . . . . . . . . . . . . . . . .  17
Appendix A.  Program Committee  . . . . . . . . . . . . . . . . .  22
Appendix B.  Workshop Material  . . . . . . . . . . . . . . . . .  22
Appendix C.  Accepted Position Papers . . . . . . . . . . . . . .  22
Appendix D.  Workshop Participants  . . . . . . . . . . . . . . .  24

1. Introduction 💖

Okay so the Internet Architecture Board (IAB) runs occasional workshops to think about long-term issues and strategies for the Internet, and to suggest where the Internet architecture should head next. ✨ This big-picture planning is a complement to the day-to-day engineering that IETF working groups do, under the leadership of the Internet Engineering Steering Group (IESG) and area directorates. 🧚

Any application that sends a lot of data over the Internet is expected to implement reasonable congestion control behavior. 👑 The goals for congestion control are already well understood and written down 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 it goes over the Real-Time Transport Protocol (RTP) on top of UDP, often on provisioned capacity and/or with only rudimentary congestion control mechanisms. 🙈 In 2004, the IAB raised concerns about possible congestion collapse because of rapid growth in real-time voice traffic that doesn't practice end-to-end congestion control [17]. That collapse didn't happen, but the worries about both congestion collapse and fairness are still valid. They matter even more now that bandwidth-hungry video apps are a thing. 💀

Then there's web-based real-time media communication, where RTP is used to and from web browsers to send audio, video, and data. It's being developed and is about to be widely deployed, and it will likely create a lot of new Internet traffic. 🌈 Because of how much traffic that's projected to be, and because it's more likely to use unprovisioned capacity, it's essential that it's sent with robust and effective congestion control mechanisms. 🔥

Designing congestion control that works well across a huge variety of traffic mixes and network paths with wildly different characteristics is not easy, bestie. 😭 A "circuit breaker" mechanism can prevent congestion collapse (see, for example, [3]). But media flows are supposed to coexist with a user's other ongoing sessions, so we need a congestion control mechanism that shares capacity fairly when TCP, UDP, and other protocol flows are all mixed together. 💅

There are a lot of extra complications. Here are some examples:

1. Real-time interactive media sessions need low latencies, whereas streaming media can use large play-out buffers. 🦋
2. In an RTP session, feedback sent over the RTP Control Protocol (RTCP) typically arrives much less often than, for example, TCP ACKs for a given TCP connection. In theory, 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 way than TCP can, and user experience suffers if encoding rates switch too often. Codecs also typically have a minimum sending rate. 🌸
4. Some bits of an encoded media stream matter more 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 codec's output rate without knowing whether the network path can sustain the higher rate risks a significant amount of packet loss, which can cause playback artifacts. 💀
6. A congestion control scheme for interactive media needs to handle bundles of interrelated flows (audio, video, and data) in a way that respects the application's preferences when congestion happens. 👑
7. Wanting congestion control that can be implemented efficiently inside an application adds more restrictions. For example, a web browser can't take into account the protocol interactions of a software download happening in another application. 🧚
8. There are explicit congestion signals (such as Explicit Congestion Notification (ECN) [19]), 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 to 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 add communication delay, which harms the small delay budget that interactive real-time applications have. 🙈

2. Workshop Structure 🎀

The IETF has a long history of work on congestion control mechanisms. 💜 With ongoing standardization work on real-time interactive media communication on the web, new challenges have popped up, and they've refocused engineering attention on congestion control. 🌈 To take a deeper look at congestion control in light of all this real-time traffic growth, workshop participants were invited to submit position papers. Those papers were then used to organize the agenda into three main parts. First was a keynote from Mark Handley about the history of congestion control for real-time media and his views on current problems. Next came a presentation of simulations and data showing current problems and solutions. Last was a discussion of desirable solution properties and the challenges of deploying solutions. 🦋

2.1. History and Current Challenges ✨

okay bestie, gather around 🫶 Mark Handley argued that since 1988, the Internet has stayed functional even with exponential growth 📈, routers that are sometimes buggy or misconfigured 🙈, applications and usage patterns that change super fast 💨, and flash crowds 🌊. The big reason? Most apps use TCP, and TCP does end-to-end congestion control, which is literally the MVP here 👑.

TCP's congestion control adjusts the window to fit the capacity the network has available 🦋, and it gets approximate fairness between two competing flows over time ⚖️. Mark pointed out that this fairness isn't necessarily what we want 🤔. The 1/round-trip-time relationship in TCP is not ideal, because it means network operators can lower packet loss by adding bigger buffers 📦. That unfortunately leads to bufferbloat problems 💀 (see [31] and [39]). The 1/sqrt(packet drop rate) relationship isn't necessarily desirable either, since TCP initially did not work particularly well for high-speed flows 🏎️, which had been the subject of a lot of TCP research 📚.

TCP controls the congestion window in bytes 🍓. For bulk transfer, this usually works out to controlling the number of 1500-byte packets sent per second 📨. Real-time media is different because it has its own time constraints ⏰. For audio, you want to send one packet per 20 ms 🎶, and for video, the ideal is 25 to 30 frames per second 🎬. So you really want to avoid extra sending delay 🙅‍♀️.

As an example, for video, to relieve congestion you have to reduce the number of packets-per-second transmission rate, rather than sending smaller packets 💅. Why? At higher bitrates on WiFi, the time it takes to send a packet is almost negligible compared to the time spent on Media Access Control (MAC) layer operations 📡. Shrinking the packet size barely changes the available capacity 🤷‍♀️. And for a serial line, it doesn't matter how big the packets are 🧚.

From a network point of view, the goals of congestion control 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 good throughput when the network is working well and passable performance when the network is working poorly 🌈.
2. Predictable behavior 🔮. This matters for usability, since variable media creates a bad user experience 😩.
3. Low latency ⚡. With large buffers along the end-to-end path, latency increases when interactive real-time flows compete with TCP flows 🐌. This results in TCP filling up the buffers, and increased buffering leads to additional delays for delivering the interactive real-time media 😭.

Attempts to provide congestion control for interactive real-time media have been made in the IETF before, for example with the work on TCP Friendly Rate Control (TFRC) [12] 💜. TFRC illustrates the challenges really well ✨. It tries to accomplish the same throughput as TCP, but with a 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 😵‍💫. That's 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 used 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 🎯. But modern video codecs inherently produce variable-bitrate video streams based on the content being encoded, and it's hard to produce data at exactly the desired bitrate without excessive buffering or ugly quality changes 😬.

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

Known congestion control mechanisms work well if they can respond quickly enough to changes, and if they don't bump into the low statistical multiplexing problem 🙌.

To avoid the low statistical multiplexing problem, we need techniques for inferring link speed 🔍. The work from Van Jacobson's pathchar [37] (and successors) is valuable input 💎. The idea is to send short packet trains, measure timing accurately, and infer the link speed from the relative delay 🚂. If we know the link speed, we can avoid exceeding it 🛑. Congestion control can give us an approximate rate, but we must not exceed link speed 🚧. This is a hybrid between the codec being in charge (most of the time) and the network being in charge 🤝. It works 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 both be in charge 👯. However, they both cannot be in charge at the same time 🙃.

Mark 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 link speed ⏳. Circuit breakers [3], on the other hand, don't help give good performance on an uncongested path 🙅‍♀️. With circuit breakers, the sender measures the loss rate and RTT, and runs with a loose "cap" 🧢.

In conclusion, Mark Handley claimed 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 the packet/sec rate and not the packet size 💅✨.

2.2. Simulations and Measurements 🔬

This second part of the workshop was all about presenting and discussing data from simulations and real-world measurements 📊.

Keith Winstein kicked things off with his presentation of measurements from cellular operator networks in the US [22] 📱. The measurements showed that the analyzed cellular networks had varying RTT, with transient latency spikes up to hundreds of milliseconds ⚡. Link speed varied by a factor of 10 on a short time scale 🎢, and buffers didn't drop packets until they held 5-10 seconds of data at bottleneck link speed 😱.

Zaheduzzaman Sarker [21] presented results from real-time video communication in a Long Term Evolution (LTE) simulator 🛰️. It used ECN-based packet marking, and adaptation using implicit methods like packet loss and delay 🎀. ECN marking gives the network a way to explicitly signal congestion, so it distributes the cost of congestion well and helps achieve lower latency 🫧. However, although RFC 3168 [19] was finalized in 2001, ECN deployment is still lacking, as investigated by Bauer, et al. [25] 😩. A few participants said they believe LTE deployments will also boost ECN deployment, with the recent work on ECN for RTP over UDP [11] 🌟.

Mo Zahaty [20] discussed TFRC [12] and TFRC with weighted fairness (MulTFRC) [4], which tunes TFRC to consider multiple flows 🧩. Mo showed how RTT and loss rates affect the video quality that can be achieved under those conditions 🎞️. TFRC needs frequent feedback, which RTCP doesn't provide, even with the extended RTP profile for RTCP-based feedback (RFC 4585 [5]) 🙅‍♀️. Mo argued that application-specified weighted fairness is important, but while MulTFRC performs better than TFRC, it's not clear whether the extra complexity over an n-times-TFRC approach is actually worth the effort 🤔.

Markku Kojo shared analysis results on 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, for comparison, against six TCP flows 🆚. With one concurrent TCP flow, voice is impacted at startup, and six TCP flows destroy the quality of the call 📞💥. Markku analyzed two types of losses: losses from a packet being dropped in the network (e.g., due to congestion or link errors) 🕳️, and losses from a packet arriving late (due to buffering) when the audio packet misses the deadline for the codec to decode and play the content ⏰. So even a moderate number of TCP flows, which browsers typically use to fetch content on web pages in parallel, causes irreparable harm to audio transfers 😭. The initial window (IW) size also affects interactive real-time communication 🪟. A larger TCP IW (e.g., IW10 with ten segments, as proposed in [18], instead of three) leads to a bigger burst of packets because of the initial window transmission 💥. Note that the study in [24] doesn't necessarily reach the same conclusion 🧐. It claims that a larger initial window size has no impact, or only a modest impact, on buffering in the majority of cases 🫤.

Cullen Jennings [28] presented measurements showing interactions between RTP and TCP flows for several widely deployed video communication products: Apple FaceTime, Google Hangout, Cisco Movi, and Microsoft Skype 📹. All the tested products implemented some form of congestion control, but none of them did additive increase and multiplicative decrease (AIMD) 🙅‍♀️. Generally, video was observed to adapt more slowly than AIMD to changes in available bandwidth 🐢. That's because most codecs can't make small increases in sending rate when available bandwidth goes up, and don't make large decreases when it goes down, in order to improve the user's experience 🥹✨.

Stefan Holmer [43] investigated the difference between loss-based and delay-based congestion control algorithms 🧪. Whether loss-based schemes suit interactive real-time communication systems depends heavily on buffer sizes and on whether active queue management mechanisms are deployed 🪣. If most routers use tail-drop queuing, then loss-based congestion control can't meet the requirements of interactive real-time applications 🚫. Those flows keep increasing the bitrate until a loss event is identified, and that only happens when the bottleneck queue is full 🌊💔.

2.3. Design Aspects of Problems and Solutions ✨

okay bestie, this part is where the workshop got into the design side of things, so buckle up 🎀 the discussion kicked off with Jim Gettys talking about bufferbloat [31][36] 💀. Bufferbloat is "a phenomenon in packet-switched networks, in which excess buffering of packets causes high latency and packet delay variation (also known as jitter), as well as reducing the overall network throughput" [39]. Like, a little buffering is actually helpful for efficiency 🦋 but if you never drop packets when things get congested, the delays just keep piling up for interactive real-time stuff. Not it 😭

Packets can get stuck in buffers all over the end-to-end path 🌸: in the operating system and device drivers, in customer premise equipment (think cable modems and DSL routers), in base stations, and in routers. Participants said that people understand "too large buffers" way better than they did a few years ago, but they were still worried that a lot of equipment manufacturers and network operators just don't acknowledge the problem exists 🙈. Why? Because the focus has been on throughput measurements that totally ignore latency 💅. For example, the Federal Communications Commission (FCC) only recently added latency tests to their test suites [41]. Finally, periodt 👑

Active queue management (AQM) is all about keeping queues from getting too huge ✨. It works by watching the queue length and telling the sender to slow down, either by dropping or marking packets 🫶. Random Early Detection (RED) [9] is one AQM algorithm, but it hasn't been widely deployed in routers, mostly because it's hard to configure correctly [32] 😭. According to [23], RED doesn't work with the default settings because it is "too "gentle" to handle fast changes due to TCP slow start, when the aggregate traffic is limited." Like, it's giving underpowered 💀. There may also be a lack of incentive to deploy AQM algorithms 🥲, and people speculated about how long it takes to update network equipment to support them, since different devices get replaced on different cycles 🍓.

The workshop's AQM discussion led to a Birds of a Feather ("BoF") meeting on "Active Queue Management and Packet Scheduling" at IETF 87 (July 28 - August 5, 2013, Berlin, Germany) 🌈. A few weeks later the AQM WG [35] got chartered, and it's now working on AQM and network infrastructure improvements to deal with bufferbloat and related issues 💜.

Measurement tools are seen as a promising way to get network operators to upgrade their equipment and use AQM algorithms 🔥. The idea is that if an end user can measure how badly their network performs, including latency, they can complain to their ISP, and that creates a market force 💖. As for which performance metrics are the right ones, someone noted that the IETF IP Performance Metrics (IPPM) working group [33] was meant to develop exactly those metrics for qualifying networks 🧚. That work may have started before its time, but there have been recent attempts to revisit the measurement work, and an effort by the FCC has gotten a lot of attention lately (see [7] and [42]) ⭐.

Matt Mathis and others argued that the traffic from throughput-maximizing applications and from delay-minimizing applications needs to sit in separate queues (segregated queuing) 🎀. Requiring segregated queues assumes you're sharing the network with other greedy traffic 👀. Quality-of-Service (QoS) signaling is one way to deploy segregated queuing, but there are simpler alternatives, like Stochastic Fair Queuing [38] ✨. The Controlled Delay (CoDel) AQM algorithm [6] can also be combined with stochastic fair queuing 🦋. Also, queue segregation doesn't have to happen on every router: using it at the edge of a network, where the bottleneck links are, is already sufficient 💅.

People noted that interactive voice over the Internet mostly works satisfactorily today 🫶. In typical networks, voice works because the networks are underloaded. As long as there's idle capacity and the queue is empty when packets arrive, traffic doesn't need to be split into separate queues 🌸. Other reasons many networks work surprisingly well: Low Extra Delay Background Transport (LEDBAT) [8] is used for downloading software updates, voice contributes only a small slice of overall Internet traffic, and users rely on "human protocols" (like parents asking their kids to get off the network during a conference call) 💀🫶.

Cullen Jennings raised a concern: voice might work without a congestion control mechanism, but the potentially huge uptake of interactive video spurred on by Real-Time Communications on the Web (RTCWEB) could cause way bigger problems 😭. In the space where voice works today, video may fail 🥲. Ted Hardie pushed back, saying RTCWEB is trying to replace existing proprietary technologies 💅. It may ramp up the amount of usage we expect, but it isn't doing much that wasn't already being done by Adobe Flash or Skype ✨. RTCWEB isn't a totally novel context of Internet usage 🦋. Magnus Westerlund added that RTCWEB might be the driver for the moment, but web browsers aren't the only consumers of this kind of congestion control algorithm 🌈.

Ted Hardie also noted that applications won't produce media streams that grow to 10 Mbps, because their sending rate is automatically rate limited by the production of the video 🍓. He suggested we ask ourselves whether we're trying to make TCP friendly to media streams that are already rate limited, or whether we're asking already rate limited media streams to be TCP friendly 🤔. To quote Andrew McGregor: "It's really not good to be TCP friendly because it's not going to return the favor." 💀 If the properties we want are no starvation, fairness, and effective goodput for the offered loads, are we only willing to consider changes in RTP control, or are we also willing to consider changes in TCP congestion control? 👑 That led to a discussion about whether developing a congestion control algorithm for interactive real-time applications is worth anything if network equipment still suffers from bufferbloat 🙈. Is there something we can do today to help interactive real-time media, or do we have to wait for the network to get 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 about the same as the time scale for deploying ECN [19] 🫧. Colin Perkins noted that we can't change TCP quickly, but the way TCP is used is changing quickly, and we can influence how TCP gets used 🦋. When TCP carries a file transfer, it sends data as fast as it can, but when TCP is used for WebSockets, the dynamics are different 💖. WebSockets and SPDY are clearly changing how TCP behaves 🔥. Netflix-style video streaming applications are also huge TCP users, and those applications can change pretty 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 🌸.

Bill Ver Steeg suggested considering three different deployment environments 🧚:

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

The narrowest problem domain that makes sense is avoiding 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 across audio, video, and data flows 🫶. Sharing information about a bottleneck with all the flows that share it would be amazing, but it's 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, the network layer, transport layer, and application layer need to interact, and the application layer is the only practical place to balance which 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 way more critical than video, so in those cases the video may back off while the audio stays unchanged 🎶.

Mo Zanaty pointed out how important media start-up behavior is, and that's where real-time interactive media differs from a TCP-based file transfer 🌈. The instant experience in the first part of a video call heavily shapes people's perception of call quality 💜. Vendors use vague heuristics, like data from the last call, to decide what to do on the next call 🤷‍♀️. Lars Eggert highlighted that an application's start-up behavior affects the ongoing performance of other flows if, say, an application blasts at line rate at the start of a video stream 🔥. You need to start slow enough not to cause congestion for others 🛑. Randell Jesup argued that for an interactive real-time video application, you really need most of your bandwidth right away 💖. Colin Perkins agreed and added that at startup you need good video quality quickly, but maybe not as quickly as voice 🦋. The requirements will likely differ between audio and video, and might even vary between applications 🌸. Various protocol exchanges happen before media is exchanged between endpoints (like Session Traversal Utilities for NAT (STUN) packets [13] as part of Interactive Connectivity Establishment (ICE) [15], or a Datagram Transport Layer Security (DTLS) handshake [14]), and they may be used to get simple start-up measurements 📏.

The group agreed that it's feasible to design a congestion control algorithm that works on mostly idle networks 🎀. In the participants' view, upgrades to the network infrastructure can happen in parallel 🚀. This view was later confirmed at the RTP Media Congestion Avoidance Techniques (RMCAT) BoF meeting at IETF 84 (July 29 - August 3, 2012, Vancouver, BC, Canada), which led to the formation of the RMCAT working group [34] 🌈✨

3. Recommendations 💖

okay so the group landed on two main solution tracks 🛣️: changes to network infrastructure, and algorithms that avoid self-inflicted queuing. We'll get into both below. A third approach some participants suggested was changing how TCP gets used in browsers and other HTTP-based apps 🌐. For example, not opening too many concurrent TCP connections, and being nicer to other non-real-time apps (like video streaming and file sharing) can unlock more improvements ✨. Also, the work on HTTP 2.0 with SPDY [16] is already a step in the right direction, because SPDY uses a more aggressive form of multiplexing instead of opening a pile of TCP connections 🧚

3.1. Changes to Network Infrastructure

bestie, the same rule applies to RTCWEB traffic as to everything else on the network 🌸: better data plane infrastructure makes the best-effort service the Internet offers look and feel better for RTCWEB flows 💅. The IETF has already built several technologies that would be immediately useful if people actually deployed them. The participants were hopeful that, because RTCWEB traffic is so high-volume and so important, some of these might finally get widespread use 🙏

The first and by far most important upgrade is traffic segregation 👑: being able to put different traffic types in different queues. Jitter- and delay-sensitive protocols would really benefit from sitting in different queues from the throughput-maximizing ones. A single queue or AQM simply can't be optimal for both, so this isn't a nice-to-have, it's a need 😭

ECN is also huge 🔥. It lets routers along the end-to-end path signal that congestion is starting, so apps can react early, avoid losses, keep queues short, and keep end-to-end delay low 🦋. It's implemented on some end system stacks and routers, but it's frequently not turned on, which is a whole mood 💀. The participants stressed how important it is to get ECN deployed more, even if it's only in closed environments at first, like data centers (as with Data Center TCP (DCTCP) [26]) 🌈

There are different mechanisms for traffic segregation. Differentiated Services [10] is one option 🎀. If apps mark their outgoing traffic appropriately and routers segregate traffic accordingly, browsers could more directly control the relative importance of their various flows and avoid competing with themselves 🙈. Compared to ECN, though, DiffServ is way harder to deploy meaningfully end to end 😩. The reason is that Differentiated Services Code Points (DSCPs) have no defined end-to-end meaning, and packets can be re-marked along the way.

QoS signaling together with resource reservation would give a fine-grained, flexible way to tell network elements what resources you need 🧁. But it's also by far the most heavyweight proposal, and it's unlikely to be viable on the global Internet. As mentioned in Section 2.3, QoS signaling isn't the only way to get traffic segregation, though ✨. Further investigation into stochastic fair queuing and new AQM algorithms is seen as desirable 🔍.

In any case, network infrastructure updates will take time 🐢, especially when the stakeholders' interests aren't lined up (which is often the case for network operators dealing with over-the-top real-time traffic). So it is, therefore, imperative that RTCWEB congestion control delivers adequate improvement even when none of the aforementioned schemes are available 🫶

3.2. Avoiding Self-Inflicted Queuing

this approach is all about making sure the network doesn't suffer congestion collapse 🌊, and that one data flow from a single host doesn't hurt another data flow from that same host 🫣. A single congestion manager inside the end host or the browser could help coordinate the different congestion control activities, so everything stays more organized across apps and flows 💜

The following design and testing aspects were considered relevant to this approach 📋:

Reacting to All Congestion Signals

okay so first things first, you have to detect congestion in the communication path before you can start the congestion control process 🔎. Congestion can be detected with an explicit mechanism or an implicit one. An explicit mechanism is direct congestion signaling, usually from the congested network node, like ECN 📣. An implicit mechanism uses packet-loss events or observed delay increases as the hint 👀. These measurements can also be made available in a variety of protocols, like 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 they can exchange better information 🤝. That matters because 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 get low latency ⚡. Explicit congestion signals are the most reliable way for apps to react 💯, but since ECN isn't deployed much yet, delay-based algorithms are needed 😤. There's also big delay variation in wireless networks, even when they aren't congested 📶, so the workshop participants recommended more research to better understand non-congestion-related delay variation in the network 🧐. General consensus among the participants was that latency-based congestion control algorithms are needed because large buffers mean you don't get loss indications 🫧. Just know that loss-based techniques still dominate latency-based ones when the two are competing for bandwidth 🥊

Algorithm Evaluation

the Internet is a messy place 🌪️. It's made of heterogeneous networks, including misconfigured and unmanaged network nodes, and bandwidth and latency vary a lot 📉📈. Different services deployed using RTP/UDP have different requirements for media quality 🎥. So a congestion control algorithm needs to perform well not only in simulators, but also in the deployed Internet 🌍. To get there, it is recommended to test algorithms with real-world loss and delay figures, so you can make sure the desired audio and video rates are attainable for the services you care about 💖

Media Characteristics

interactive real-time voice and video data are inherently variable 🎢. The content and service requirements usually decide the media coding 🧩. The codec may be bursty, and not every frame is equally important (I-frames are more important than P-frames, for example) 🖼️. That means codecs have limited room to adapt 🙃. So congestion control for audio and video codecs is different from congestion control for bulk file transfers, where buffering isn't a problem and the transmission rate can be changed to any rate the algorithm likes 📦. In the workshop, these limitations came up, and the participants recommended that a congestion controller needs to be aware of these constraints 🧠. Further investigation is still needed to decide what information needs to be exchanged between a codec and the congestion manager 🔬

Start-up Behavior

the start-up media quality is super important for real-time interactive apps and for how users perceive performance 😍. The start-up behavior is also different from other traffic 🚀. Real-time interactive communication apps want to give a smooth user experience and keep the best media quality possible to make the interaction easy 💫. Sure, it might be tempting to immediately stream high-definition video and wideband audio, but that would impact the bandwidth of flows that are already going 😬. So ideally you start slow enough to avoid causing excessive congestion to other flows, but fast enough to offer a good user experience 🎯. The sweet spot, however, has yet to be found 🥺

---

4. Security Considerations 🔐

this one's serious, bestie 🫡. Two position papers focused on security, but those papers were not discussed during the workshop. As such, nothing beyond the material contained in those position papers can be reported 📄.

5. Acknowledgments 🫶

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

We also want to thank the following people for their review comments 🌷: Michael Welzl, John Leslie, Mirja Kuehlewind, Matt Mathis, Mary Barnes, Spencer Dawkins, Dave Thaler, and Alissa Cooper 👑.

6. Informative References ✨

okay bestie, this is the reading list 📚🫶 every paper, RFC, and working draft the workshop leaned on, all in one place so you can go down a rabbit hole whenever you want 🐇

[1] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.

[2] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.

[3] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", Work in Progress, February 2014.

[4] Welzl, M., Damjanovic, D., and S. Gjessing, "MulTFRC: TFRC with weighted fairness", Work in Progress, July 2010.

[5] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.

[6] Nichols, K. and V. Jacobson, "Controlled Delay Active Queue Management", Work in Progress, March 2014.

[7] Schulzrinne, H., Johnston, W., and J. Miller, "Large-Scale Measurement of Broadband Performance: Use Cases, Architecture and Protocol Requirements", Work in Progress, September 2012.

[8] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, December 2012.

[9] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.

[10] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.

[11] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, August 2012.

[12] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008.

[13] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.

[14] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.

[15] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.

[16] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer Protocol version 2", Work in Progress, June 2014.

[17] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet", RFC 3714, March 2004.

[18] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, "Increasing TCP's Initial Window", RFC 6928, April 2013.

[19] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.

[20] Zanaty, M., "Fairness Considerations for Congestion Control for Interactive Real-Time Communication (IRTC)", IAB/ RTF Workshop on Congestion Control for Interactive Real-Time Communication, July 2012.

[21] Sarker, Z. and I. Johansson, "Improving the Interactive Real-Time Video Communication with Network Provided Congestion Notification", IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 2012.

[22] Winstein, K., Sivaraman, A., and H. Balakrishnan, "Congestion Control for Interactive Real-Time Flows on Today's Internet", IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 2012.

[23] Jarvinen, I., Ding, A., Nyrhinen, A., and M. Kojo, "Harsh RED: Improving RED for Limited Aggregate Traffic", In Proceedings of the 26th IEEE International Conference on Advanced Information Networking and Applications (AINA 2012), March 2012.

[24] Allman, M., "Comments on Bufferbloat", In ACM SIGCOMM Computer Communication Review, Volume 43, Issue 1, pp. 30-37, January 2013, http://dl.acm.org/citation.cfm?doid=2427036.2427041.

[25] Bauer, S., Beverly, R., and A. Berger, "Measuring the state of ECN readiness in servers, clients,and routers", In Proceedings of the 2011 ACM SIGCOMM conference on Internet measurement conference (IMC '11), New York, NY, USA, pp. 171-180, February 2011, http://dl.acm.org/citation.cfm?doid=2068816.2068833.

[26] Bauer, S., Greenberg, A., Maltz, D., Padhye, J., Patel, P., Prabhakar, B., Sengupta, S., and M. Sridharan, "Data center TCP (DCTCP)", In Proceedings of the ACM SIGCOMM 2010 conference (SIGCOMM '10), New York, NY, USA, pp. 63-74, August 2010, http://dl.acm.org/citation.cfm?doid=1851182.1851192.

[27] Jarvinen, I., Chemmagate, B., Daniel, L., Ding, A., Kojo, M., and M. Isomaki, "Impact of TCP on Interactive Real- Time Communication", IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 2012.

[28] Jennings, C., Nandakumar, S., and H. Phan, "Vendors Considered Harmfull", IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 2012.

[29] Welzl, M., "One control to rule them all", IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 2012.

[30] Leslie, J., "There is No Magic Transport Wand", IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 2012.

[31] Gettys, J. and J. Gettys, "Bufferbloat: Dark Buffers in the Internet", IEEE Internet Computing, Volume 15, Issue 3, pp. 95-96, May/June 2011.

[32] Feng, W., Shin, K., Kandlur, D., and D. Saha, "The BLUE active queue management algorithms", In IEEE/ACM Transactions on Networking, Volume 10, Issue 4, pp. 513-528, August 2002.

[33] IETF, "IP Performance Metrics (ippm) Working Group", January 2012, http://datatracker.ietf.org/wg/ippm/charter/.

[34] IETF, "RTP Media Congestion Avoidance Techniques (rmcat) Working Group", January 2012, http://datatracker.ietf.org/wg/rmcat/charter/.

[35] IETF, "Active Queue Management and Packet Scheduling (aqm) Working Group", September 2013, http://datatracker.ietf.org/wg/aqm/charter/.

[36] Gettys, J. and K. Nichols, "Bufferbloat: Dark Buffers in the Internet", Communications of the ACM, Vol. 55, No. 1, pp. 57-65, January 2012, http://cacm.acm.org/magazines/2012/1/144810-bufferbloat/.

[37] Jacobson, V., "pathchar - a tool to infer characteristics of Internet paths", Presented at the Mathematical Sciences Research Institute, April 1997, ftp://ftp.ee.lbl.gov/pathchar/msri-talk.pdf.

[38] McKenney, P., "Stochastic Fairness Queuing", In IEEE INFOCOM'90 Proceedings, Volume 2, pp. 733-740, June 1990.

[39] Wikipedia, "Bufferbloat", May 2014, http://en.wikipedia.org/w/index.php?title=Bufferbloat&oldid=608805474.

[40] Wikipedia, "Video compression picture types", March 2014, http://en.wikipedia.org/w/index.php?title=Video_compression_picture_types&oldid=602183340.

[41] FCC, "Methodology - Measuring Broadband America July Report 2012", July 2012, http://www.fcc.gov/measuring-broadband-america/2012/methodology-july-report-2012.

[42] IETF, "lmap -- Large Scale Measurement of Access network Performance Mailing List", 2012, https://www.ietf.org/mailman/listinfo/lmap.

[43] Holmer, S., "On Fairness, Delay and Signaling of Different Approaches to Real-time Congestion Control", IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 2012.

---

Appendix A. Program Committee 👑

this workshop was run by a squad of legends: 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. the main characters of this whole story 🎀

Appendix B. Workshop Material 🦋

if you want to dig into the actual workshop stuff, here's where it lives:

• 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 ✨

okay bestie, this is the big lineup 🎀 these are the position papers the workshop accepted, so basically everyone who showed up with a hot take on real-time congestion control 💅

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 and 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 Mo Zanaty, Bill VerSteeg, Bent Christensen, David Benham, and Allyn 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 and Klaus Hartke
30. "Erasure Coding and Congestion Control for Interactive Real-Time Communication" by Pierre-Ugo Tournoux, Tuan Tran Thai, Emmanuel Lochin, Jerome Lacan, and 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 need to thank these workshop participants for showing up and being part of the squad 🫶 the group chat was OBSESSED

• 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 🦋

and finally, where to find the people who wrote this 💖 here are the authors' details, copied exactly as they appear

Hannes Tschofenig
Hall, Tirol  6060
Austria

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