RFC 8083

Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions

📅 published March 2017, from ietf

RFC 8083: Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions 💖 (part 1 of 7)

okay bestie, first things first 🎀 this doc is RFC 8083, and it was written by C. Perkins (University of Glasgow) and V. Singh (callstats.io). It's a Standards Track document, so it's a real IETF standard, not just a suggestion 💅 It's dated March 2017, the ISSN is 2070-1721, and the header says it updates RFC 3550 🦋 That's the big RTP spec, so this one is adding to it. There's no obsoletes line in the header, so nothing gets replaced here ✨

Abstract ✨

okay so the Real-time Transport Protocol (RTP) is EVERYWHERE 📞 like telephony, video calls, and telepresence stuff. These apps usually run over best-effort UDP/IP networks, which means no guarantees 🥺 If nobody does congestion control, the network gets clogged, packets start disappearing, and the user's call goes full chaos 💀 Congestion control is basically the safety measure that stops RTP flows from hogging resources and keeps the whole network from overloading 🛡️ BUT (and this is the tea) even though there are a bunch of proprietary solutions, there's no standard algorithm for congestion control of interactive RTP flows yet 😭

This document doesn't propose a congestion control algorithm 🙅‍♀️ instead it defines a minimal set of RTP circuit breakers: the conditions where an RTP sender needs to stop sending media to protect the network from excessive congestion 🔌 The idea is that if there's no long-lived excessive congestion, RTP apps on best-effort IP networks should be totally fine and never trip these breakers 🌸 And if any Standards Track congestion control algorithm gets defined for RTP later, it has to stay inside the envelope these circuit breaker algorithms set, so it doesn't trigger them 🫶

Status of This Memo ✨

okay this part is the official paperwork, but it's still important 📜 This is an Internet Standards Track document 🔥

It's a product of the Internet Engineering Task Force (IETF) 🌈 It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) 👑 If you want more on Internet Standards, check out Section 2 of RFC 7841 🍓

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc8083 🧚

Copyright Notice ✨

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 stand on the publication date. Please read these carefully, bestie, because they explain your rights and restrictions for this doc 🙈 Any Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 💅

Table of Contents ✨

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
4.  RTP Circuit Breakers for Systems Using the RTP/AVP Profile  .   8
  4.1.  RTP/AVP Circuit Breaker #1: RTCP Timeout  . . . . . . . .  10
  4.2.  RTP/AVP Circuit Breaker #2: Media Timeout . . . . . . . .  11
  4.3.  RTP/AVP Circuit Breaker #3: Congestion  . . . . . . . . .  12
  4.4.  RTP/AVP Circuit Breaker #4: Media Usability . . . . . . .  16
  4.5.  Ceasing Transmission  . . . . . . . . . . . . . . . . . .  17
5.  RTP Circuit Breakers and the RTP/AVPF and RTP/SAVPF Profiles   18
6.  Impact of RTCP Extended Reports (XR)  . . . . . . . . . . . .  19
7.  Impact of Explicit Congestion Notification (ECN)  . . . . . .  19
8.  Impact of Bundled Media and Layered Coding  . . . . . . . . .  20
9.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
  10.1.  Normative References . . . . . . . . . . . . . . . . . .  21
  10.2.  Informative References . . . . . . . . . . . . . . . . .  22
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  25
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25

1. Introduction ✨

okay so the Real-time Transport Protocol (RTP) [RFC3550] is used a LOT in voice-over-IP, video teleconferencing, and telepresence systems 📞 Lots of these run over best-effort UDP/IP networks, and when congestion happens they can get packet loss and extra latency 😩 Designing good RTP congestion control algorithms is a hard problem, but it's super important 💕 The goal is to adjust RTP media transmission to match the available network capacity while still keeping the user experience good ✨ People have proposed a ton of congestion control and media adaptation algorithms, but right now there's no consensus on the correct approach, or even on whether one single standard algorithm is desirable 🤷‍♀️

This memo doesn't try to propose a new RTP congestion control algorithm 🙅‍♀️ Instead, it proposes a small set of RTP circuit breakers 🔌 These are mechanisms that terminate RTP flows in conditions where everyone generally agrees serious network congestion is happening 🚨 The RTP circuit breakers in this memo are a specific instance of the general class of network transport circuit breakers [RFC8084] 🦋 They're designed as a protection mechanism of last resort, to avoid persistent excessive congestion 🫡 And just like before, any Standards Track congestion control algorithms defined for RTP will need to operate within the envelope set by the RTP circuit breaker algorithms defined by this memo, so they don't trip the breaker 🌈

2. Background ✨

okay bestie, let's talk about unicast RTP congestion control 🦋 the problem is adapting an audio/visual flow, wrapped in an RTP transport session, going from one sender to one receiver. The goal is to never use more capacity than the network path actually has free 💅 and to keep the adaptation gentle, so the user doesn't get wrecked by packet loss or wild rate changes 🫶 Multicast is OUT of scope for this memo 🙈 (sorry, I mean it's not covered here). Multicast needs different solutions because the capacity estimator for a whole group of receivers is different from the one for a single receiver, and multicast has to think about fairness across groups of receivers, which just doesn't apply to unicast flows.

So where does unicast congestion control actually live in the protocol stack? There are two options 🎀

Option one is to run the RTP traffic over a congestion-controlled transport protocol (like TCP) and then adjust the media encoding to match whatever the transport's congestion control algorithm says. This is safe for the network ✨ but it can be suboptimal for media quality unless the transport is built for real-time media flows. This class of apps is not discussed further in this memo, because the underlying transport already guarantees their network safety 🌸

Option two is to run RTP over a non-congestion-controlled transport (like UDP) and do the rate adaptation at the application layer, based on RTCP feedback 🧚 When the app is well designed and network-aware, the media quality adaptation can be super effective 👑 BUT (big but 💀) there's a real risk of causing persistent congestion in the network if the app doesn't adapt its sending rate in a timely and effective way. This is the class this memo is about, so this is our main character 🍓

Congestion control basically works by watching how a media flow gets delivered and changing how it's sent when the network path looks congested 🌈 There are three ways congestion can get detected:

A receiver can infer that congestion is starting by noticing an increase in one-way delay, caused by queues building up inside the network 🌸
If Explicit Congestion Notification (ECN) [RFC3168] is supported, the network can signal congestion by marking packets with ECN Congestion Experienced (CE) marks. This could potentially get a boost from things like Congestion Exposure (ConEx) [RFC7713] or other future protocol extensions for network signaling of congestion ✨
In the extreme case, congestion causes packet loss, which the receiver can spot by seeing a gap in the received RTP sequence numbers 😭

Once congestion onset is observed, the receiver has to send feedback so the sender knows the transmission rate needs to drop 🔥 How the sender actually reduces its rate depends heavily on the media codec being used, and that's outside the scope of this memo 💅

Now, there are a few ways a receiver can send feedback to a media sender within the RTP framework, and they're all kinda different vibes 🦋

The base RTP spec [RFC3550] defines RTCP Receiver Report (RR) packets for reception quality feedback, and Sender Report (SR) packets for info about the media transmission. SR packets carry data that lets a receiver reconstruct media timing, plus a count of the total octets and packets sent 🎀 RR packets report the fraction of packets lost in the last reporting interval, the cumulative number of packets lost, the highest sequence number received, and the inter-arrival jitter. RR packets also carry timing info that lets the sender estimate the network Round-Trip Time (RTT) to the receivers ⏱️ RTCP reports get sent periodically, and the interval is determined by the number of Synchronization Sources (SSRCs) used in the session and a configured session bandwidth estimate (the number of SSRCs) used is usually two in a unicast session, one for each participant, but can be greater if the participants send multiple media streams). The interval between reports from each receiver is on the order of a few seconds on average 🌷 Even though it varies with session bandwidth, it gets randomized so reports from multiple receivers don't sync up and clump together 🫧 The interval can be less than a second in a high-bandwidth session. RR packets let a receiver report ongoing network congestion to the sender, but if a receiver spots the onset of congestion partway through a reporting interval, the base RTP spec has zero provision for sending the RR early, so the receiver just has to wait for the next scheduled interval 😤
RTCP Extended Reports (XR) [RFC3611] let you report more complex and sophisticated reception quality metrics, but they do NOT change the RTCP timing rules 🙃 The XR reports that could be interesting for congestion control are the extended packet loss, discard, and burst metrics [RFC3611] [RFC7002] [RFC7097] [RFC7003] [RFC6958], plus the extended delay metrics [RFC6843] [RFC6798]. Other RTCP Extended Reports might be helpful for congestion control in the future too 🌟
Rapid feedback about congestion events can be achieved using the Extended RTP Profile for RTCP-Based Feedback (RTP/AVPF) [RFC4585] (or its secure variant, RTP/SAVPF [RFC5124]) instead of the RTP/AVP profile [RFC3551] ⚡ This modifies the RTCP timing rules so RTCP reports can be sent early, and in some cases immediately, as long as the RTCP transmission rate stays within its bandwidth allocation. It also defines transport-layer feedback messages, including Negative Acknowledgements (NACKs), which can report on specific congestion events 🎯 RTP Codec Control Messages [RFC5104] extend the RTP/AVPF profile with extra feedback messages that can influence how rate adaptation happens, but they don't change how fast feedback can be sent 💅 Using the RTP/AVPF profile depends on signaling 🧚
Finally, ECN for RTP over UDP [RFC6679] can provide feedback on the number of packets that received an ECN-CE mark 🦋 This RTCP extension builds on the RTP/AVPF profile to allow rapid congestion feedback when ECN is supported 💜

On top of all those feedback mechanisms, the sender can include an RTP header extension in each packet to record packet transmission times [RFC5450] ⏰ Accurate transmission timestamps are super helpful for estimating queuing delays, which gives an early heads-up that congestion is starting 🌈

Put it all together and receivers can give feedback to senders when congestion events happen, with different levels of timeliness and accuracy 👑 The big distinction is between systems that only use the basic RTCP mechanisms (no RTP/AVPF rapid feedback) and systems that use the RTP/AVPF extensions to respond to congestion way faster 🔥 iykyk, and now you do too 💖

3. Terminology ✨

okay so first things first, bestie: the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in RFC 2119 [RFC2119] 💅. That reading only applies when they're written in ALL CAPS. Mixed-case or lower-case uses don't carry any special meaning in this memo 🙈

Now the RTP circuit breaker is defined using a bunch of variables, so let's go through them 🧚

Td is the deterministic RTCP reporting interval, as defined in Section 6.3.1 of [RFC3550] 🎀
Tdr is the sender's estimate of that deterministic RTCP reporting interval (Td), and it's calculated by a receiver of the data the sender is sending. Honestly, Tdr isn't known at the sender, but the sender can estimate it by running the algorithm in Section 6.2 of [RFC3550]. It uses the average RTCP packet size seen at the sender, the number of members reported in the receiver's SR/RR report blocks, and whether the receiver is sending SR or RR packets 📊 Tdr gets recalculated every time a new RTCP SR/RR report comes in, but the media timeout circuit breaker (see Section 4.2) only gets reconsidered when Tdr goes up 📈
Tr is the network round-trip time. The sender calculates it using the algorithm in Section 6.4.1 of [RFC3550], and then it gets smoothed with an exponentially weighted moving average like this:

Tr = (0.8 * Tr) + (0.2 * Tr_new)

Here Tr_new is the latest RTT estimate from an RTCP report. The weight is picked so that old estimates decay over k intervals, which is so cute and so intentional 🌸

k is the non-reporting threshold (see Section 4.2) 🦋
Tf is the media framing interval at the sender. For apps sending at a constant frame rate, Tf is just the inter-frame interval ⏱️ For apps that switch between a small set of possible frame rates (like when they're sending speech with comfort noise, so the comfort noise frames go out less often than the speech frames), Tf gets set to the longest of the inter-frame intervals across those different frame rates 🎶 For apps that send periodic frames but change their frame rate on the fly, Tf is set to the largest inter-frame interval used in the last 10 seconds 🕙 For apps that send less than one frame every 10 seconds, or that don't have any concept of periodic frames at all (think text conversation [RFC4103], or pointer events [RFC2862]), Tf is set to the time interval since the previous frame every time a frame gets sent 💜
G is the frame group size, meaning the number of frames that get coded together based on a particular sending rate setting. If the sender's codec can change its rate on each frame, then G = 1. Otherwise, G is set to the number of frames before the codec can adjust to the new rate ✨ For codecs that have the concept of a Group of Pictures (GOP), G is likely the GOP length 🎞️
T_rr_interval is the minimal interval between RTCP reports, as defined in Section 3.4 of [RFC4585]. It only means something for implementations of the RTP/AVPF profile [RFC4585] or the RTP/SAVPF profile [RFC5124] 🧁
X is the estimated throughput a TCP connection would get over a path, in bytes per second 🏃‍♀️
s is the size of the RTP packets being sent, in bytes. If the RTP packets vary in size, then the average size over the packets comprising the last 4 * G frames MUST be used. This is meant to be comparable to the four loss intervals used in [RFC5348] 📦
p is the loss event rate, between 0.0 and 1.0, that a TCP connection would see over a particular path. When it's used in the RTP congestion circuit breaker, it gets approximated as described in Section 4.3 💅
t_RTO is the retransmission timeout value a TCP connection would use over a particular path, in seconds. This MUST be approximated using t_RTO = 4 * Tr when it's used as part of the RTP congestion circuit breaker 🫶
b is the number of packets acknowledged by a single TCP acknowledgement. Following [RFC5348], it is RECOMMENDED that the value b = 1 is used as part of the RTP congestion circuit breaker 🌈

4. RTP Circuit Breakers for Systems Using the RTP/AVP Profile ✨

The feedback mechanisms defined in [RFC3550] and available under the RTP/AVP profile [RFC3551] are the bare minimum you can assume for a baseline circuit breaker mechanism that works for all unicast applications of RTP 🎀 So, for an RTP circuit breaker to be useful, it has to be able to notice that an RTP flow is causing excessive congestion using only basic RTCP features. It can't rely on RTCP XR feedback or the RTP/AVPF profile for rapid RTCP reports 🙌

RTCP is a fundamental part of the RTP protocol, and the mechanisms in this document rely on RTCP being implemented 🧠 Implementations that claim to support RTP but don't implement RTCP will be unable to use the circuit breaker mechanisms described in this memo 💀 Those implementations SHOULD NOT be used on networks that might be subject to congestion, unless equivalent mechanisms are defined using some non-RTCP feedback channel to report congestion and signal circuit breaker conditions 🚫

The RTCP timeout circuit breaker (Section 4.1) will trigger if an implementation of this memo tries to interwork with an endpoint that doesn't support RTCP 🙈 Implementations that sometimes need to interwork with endpoints that don't support RTCP need to disable the RTP circuit breakers if they don't receive some confirmation via signaling that the remote endpoint implements RTCP. (The presence of a Session Description Protocol (SDP) a=rtcp: attribute in an answer might be such an indication 🍓) The RTP circuit breaker SHOULD NOT be disabled on networks that might be subject to congestion, unless equivalent mechanisms are defined using some non-RTCP feedback channel to report congestion and signal circuit breaker conditions [RFC8084] 🛑

Three potential congestion signals are available from the basic RTCP SR/RR packets, and they're reported for each SSRC in the RTP session 👀

The sender can estimate the network round-trip time once per RTCP reporting interval, based on the contents and timing of RTCP SR and RR packets ⏳
Receivers report a jitter estimate (the statistical variance of the RTP data packet inter-arrival time) calculated over the RTCP reporting interval. Because of how the jitter calculation works (Section 6.4.4. of [RFC3550]), jitter is only meaningful for RTP flows that send a single data packet for each RTP timestamp value (so, audio flows, or video flows where each packet holds one video frame) 🎵
Receivers report the fraction of RTP data packets lost during the RTCP reporting interval, plus the cumulative number of RTP packets lost over the entire RTP session 📉

These congestion signals limit the possible circuit breakers, since they give only limited visibility into what the network is doing 😭

RTT estimates are widely used in congestion control algorithms, either as a proxy for queuing delay measures in delay-based congestion control or to determine connection timeouts 🫧 But RTT estimates derived from RTCP SR and RR packets sent according to the RTP/AVP timing rules are too infrequent to be useful for congestion control. They also don't give enough information to tell a delay change caused by routing updates apart from queuing delay caused by congestion 🗺️ So, we can't use the RTT estimate alone as an RTP circuit breaker 🙅‍♀️

Increased jitter can be a signal of transient network congestion. But in the highly aggregated form reported in RTCP RR packets, it doesn't offer enough information to estimate the extent or persistence of congestion 🌊 Jitter reports are a useful early warning of potential network congestion, but they're not a strong enough signal to be used as a circuit breaker ⚠️

The remaining congestion signals are the packet loss fraction and the cumulative number of packets lost. If they're considered carefully, and over an appropriate time frame to tell transient problems apart from long-term issues [RFC8084], they can be effective indicators that persistent, excessive congestion is happening in networks where packet loss is mainly due to queue overflows 📦 Loss caused by non-congestive packet corruption can distort the result in some networks, though 🫠 TCP congestion control [RFC5681] intentionally tries to fill the router queues and uses the resulting packet loss as congestion feedback. So an RTP flow competing with TCP traffic will expect to see a non-zero packet loss fraction, plus some variation in queuing latency, during normal operation when it shares a path with other flows. That needs to be accounted for when figuring out the circuit breaker threshold [RFC8084] 🧮 This TCP behavior is reflected in the congestion circuit breaker below, and it will affect the design of any RTP congestion control protocol 🎀

Two packet loss regimes can be observed. First, RTCP RR packets show a non-zero packet loss fraction while the extended highest sequence number received keeps incrementing 📈 Second, RR packets show a loss fraction of zero, but the extended highest sequence number received doesn't increment, even though the sender has been transmitting RTP data packets 📉 The first one matches the TCP congestion avoidance state and means there's a congested path that's still delivering data. The second one matches a TCP timeout and is most likely due to a path failure 💔 There's also a third condition: data is being sent but no RTCP feedback comes back at all, which matches a failure of the reverse path 🙃 We derive circuit breaker conditions for these loss regimes in the following 🦋

4.1. RTP/AVP Circuit Breaker #1: RTCP Timeout ⏰

okay so an RTCP timeout can happen when RTP data packets are going out but no RTCP reports are coming back from the receiver 😭. That's either because the receiver stopped sending RTCP reports, or because the return path is broken and the reports can't get delivered. Either way, it's not safe to keep sending, because the sender has no idea whether it's causing congestion 💀.

An RTP sender that hasn't received any RTCP SR or RTCP RR packets reporting on the SSRC it's using, for a time period of at least three times its deterministic RTCP reporting interval, Td (where Td is calculated without the randomization factor and using the fixed minimum interval of Tmin=5 seconds), SHOULD cease transmission (see Section 4.5). The reasoning behind this timeout comes from Section 6.2 of [RFC3550] ("so that implementations which do not use the reduced value for transmitting RTCP packets are not timed out by other participants prematurely"). It was then updated by Section 6.1.4 of [RFC8108] to account for the use of the RTP/AVPF profile [RFC4585] or the RTP/SAVPF profile [RFC5124]. Iconic glow-up 🌸✨

To reduce the risk of a premature timeout, implementations SHOULD NOT configure the RTCP bandwidth such that Td is larger than 5 seconds. Similarly, implementations that use the RTP/AVPF profile [RFC4585] or the RTP/SAVPF profile [RFC5124] SHOULD NOT configure T_rr_interval to values larger than 4 seconds (the reduced limit for T_rr_interval follows Section 6.1.3 of [RFC8108]). Don't let your timers get too chonky 🎀

The choice of three RTCP reporting intervals as the timeout is made following Section 6.3.5 of RFC 3550 [RFC3550]. This says that participants in an RTP session will time out and remove an RTP sender from the list of active RTP senders if no RTP data packets have been received from that sender within the last two RTCP reporting intervals. So using a timeout of three RTCP reporting intervals is big enough that the other participants will have timed out the sender if a network problem stops its data packets from reaching the receivers, even if some RTCP packets get lost too 🦋

If a sender is transmitting a large number of RTP media streams, so the corresponding RTCP SR or RR packets are too large to fit into the network MTU, the receiver will generate RTCP SR or RR packets in a round-robin manner. In this case, the sender SHOULD treat receipt of an RTCP SR or RR packet for any SSRC it sent on the same 5-tuple of source and destination IP address, port, and protocol as a sign that the receiver and return path are working. That keeps the RTCP timeout circuit breaker from triggering 🫶

4.2. RTP/AVP Circuit Breaker #2: Media Timeout 🎬

If RTP data packets are being sent but the RTCP SR or RR packets reporting on that SSRC show a non-increasing extended highest sequence number received, that's a sign the RTP data packets aren't reaching the receiver 👀. This could be a short-term blip affecting just a few packets, maybe from a slow-to-open firewall or a transient connectivity hiccup. But if it keeps going, it's a sign of a more ongoing and significant problem (a "media timeout") 😬

The time needed to declare a media timeout depends on the parameters Tdr, Tr, Tf, and the non-reporting threshold k. The value of k is chosen so that when Tdr is large compared to Tr and Tf, receiving at least k RTCP reports with a non-increasing extended highest sequence number received gives reasonable assurance that the forward path has failed, and that the RTP data packets weren't just lost by chance. The RECOMMENDED value for k is 5 reports 🌈

When Tdr < Tf, RTP data packets are being sent at a rate of less than one per RTCP reporting interval of the receiver. So the extended highest sequence number received can be expected to be non-increasing for some receiver RTCP reporting intervals. Similarly, when Tdr < Tr, some receiver RTCP reporting intervals might pass before the RTP data packets arrive at the receiver, which also leads to reports where the extended highest sequence number received is non-increasing. Both issues mean the media timeout interval has to be scaled relative to the threshold, k 🧮

The media timeout RTP circuit breaker goes like this. When sending starts, calculate MEDIA_TIMEOUT using:

MEDIA_TIMEOUT = ceil(k * max(Tf, Tr, Tdr) / Tdr)

When a sender receives an RTCP packet showing that the media it has been sending was received, it cancels the media timeout circuit breaker. If it's still sending, then it MUST calculate a new value for MEDIA_TIMEOUT and set a new media timeout circuit breaker. Reset energy, but make it make sense 💅

If a sender receives an RTCP packet indicating that its media was not received, it MUST calculate a new value for MEDIA_TIMEOUT. If the new value is larger than the previous one, it replaces MEDIA_TIMEOUT with the new value, which extends the media timeout circuit breaker. Otherwise, it keeps the original value of MEDIA_TIMEOUT. This process is known as reconsidering the media timeout circuit breaker 🔁

If MEDIA_TIMEOUT consecutive RTCP packets are received indicating that the media being sent was not received, and the media timeout circuit breaker hasn't been canceled, then the media timeout circuit breaker triggers. When it triggers, the sender SHOULD cease transmission (see Section 4.5). Don't skip this one, bestie 🚨

When stopping sending an RTP stream, a sender MUST cancel the corresponding media timeout circuit breaker. No loose ends, periodt 💖

4.3. RTP/AVP Circuit Breaker #3: Congestion ✨

okay bestie, this is the congestion one and it's giving drama 🌊💅 Picture this: you're sending RTP data packets, and the RTCP SR or RR packets show a non-zero packet loss fraction while the extended highest sequence number received keeps going up 📈. ngl that means the packets ARE reaching the receiver ✅, but some congestion is happening anyway 😬. The RTP/AVP profile [RFC3551] lays down the law on this:

If best-effort service is being used, RTP receivers SHOULD monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path and experiencing the same network conditions would achieve an average throughput, measured on a reasonable timescale, that is not less than [the throughput] the RTP flow is achieving. This condition can be satisfied by implementing congestion control mechanisms to adapt the transmission rate (or the number of layers subscribed for a layered multicast session), or by arranging for a receiver to leave the session if the loss rate is unacceptably high. The comparison to TCP cannot be specified exactly, but is intended as an "order-of-magnitude" comparison in timescale and throughput. The timescale on which TCP throughput is measured is the round- trip time of the connection. In essence, this requirement states that it is not acceptable to deploy an application (using RTP or any other transport protocol) on the best-effort Internet which consumes bandwidth arbitrarily and does not compete fairly with TCP within an order of magnitude.

The "order of magnitude" phrase basically means within a factor of ten, give or take 🍓. So to make this work, you have to estimate how much throughput a bulk TCP connection would get over the same path 🧠. For a long-lived TCP Reno connection, it's been shown that the TCP throughput, X, in bytes per second, can be estimated like this [Padhye]:

                              s
  X = -------------------------------------------------------------
      Tr*sqrt(2*b*p/3)+(t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p*p)))

This is the same TCP throughput estimate that [RFC5348] uses 🎀. When packet loss is low, the second term on the denominator is small, so the formula can be approximated pretty accurately like this [Mathis]:

            s
  X = ----------------
      Tr*sqrt(2*b*p/3)

It is RECOMMENDED that this simplified throughput equation be used, since the drop in accuracy is small and it's way easier to calculate than the full one 💖. Measurements have shown that the simplified TCP throughput equation works well as an RTP circuit breaker for multimedia flows sent to hosts on residential networks using Asymmetric Digital Subscriber Line (ADSL) and cable modem links [Singh] 🏠. The data also shows that the full TCP throughput equation tends to be more sensitive to packet loss and triggers the RTP circuit breaker earlier than the simplified one 👀. Implementations that want that extra sensitivity MAY use the full TCP throughput equation in the RTP circuit breaker 🔥. Early measurements in LTE networks showed that the extra sensitivity helps in that environment, since the full equation gave a more balanced circuit breaker response than the simplified one [Sarker] 📶. Other networks might act similarly, though 🌸.

No matter which TCP throughput equation you pick, two parameters need to be estimated and reported to the sender so it can calculate the throughput: the round-trip time, Tr, and the loss event rate, p (the sender already knows the packet size, s) 🧚. The round-trip time can be estimated from RTCP SR and RR packets. That happens too infrequently for super accurate stats, but it's the best you can do with the standard RTCP mechanisms 🙈.

Report blocks in RTCP SR or RR packets contain the packet loss fraction, not the loss event rate, so p can't be reported directly 😭. (TCP usually treats the loss of multiple packets within a single RTT as one loss event, but RTCP RR packets only report the overall fraction of packets lost and don't say when the losses happened.) Using the loss fraction instead of the loss event rate can overestimate the loss. We believe that overestimate won't be significant, since we only care about an order of magnitude comparison. (Section 3.2.1 of [Floyd] shows the difference is small for steady-state conditions and random loss, but using the loss fraction is more conservative when the loss is bursty 💜.)

Here's the congestion circuit breaker, step by step ⭐. When a sender that's transmitting at least one RTP packet every max(Tdr, Tr) seconds receives an RTCP SR or RR packet containing a report block for an SSRC it's using, the sender MUST record the value of the fraction lost field from that report block, plus the time since the last report block was received for that SSRC 📝. If more than CB_INTERVAL (see below) report blocks have been received for that SSRC, the sender MUST calculate the average fraction lost over the last CB_INTERVAL reporting intervals. Then it estimates the TCP throughput that would be achieved over the path, using the chosen TCP throughput equation along with the measured round-trip time Tr, the loss event rate p (approximated by the average fraction lost, as described below), and the packet size s 🧮. The estimated TCP throughput, X, gets compared with the actual sending rate of the RTP stream. If the actual sending rate is more than 10 * X, the congestion circuit breaker is triggered 🚨.

The average fraction lost is calculated from the sum, over the last CB_INTERVAL reporting intervals, of the fraction lost in each reporting interval multiplied by the duration of that interval. That sum is then divided by the total duration of the last CB_INTERVAL reporting intervals ✨. The CB_INTERVAL parameter is set to:

   CB_INTERVAL =
      ceil(3*min(max(10*G*Tf, 10*Tr, 3*Tdr), max(15, 3*Td))/(3*Tdr))

The parameters that feed into CB_INTERVAL are picked so the congestion control algorithm has time to react to congestion 🕰️. They give at least three RTCP reports, ten round trip times, and ten groups of frames to adjust the rate and bring the congestion down to a reasonable level 💪. It's expected that a responsive congestion control algorithm will start responding with the next group of frames after it gets an indication of congestion, so CB_INTERVAL ought to be a much longer interval than the congestion response 👑.

If the RTP/AVPF profile [RFC4585] or the RTP/SAVPF profile [RFC5124] is used, and the T_rr_interval parameter is used to reduce how often regular RTCP reports go out, then the value of Tdr in the expression above for CB_INTERVAL MUST be replaced by max(T_rr_interval, Tdr) 🔄.

The CB_INTERVAL parameter gets calculated when you join the session, and recalculated every time an RTCP packet comes in, after checking whether the media timeout circuit breaker or the congestion circuit breaker has been triggered ⏱️.

To make sure you respond quickly to persistent congestion, implementations SHOULD NOT configure the RTCP bandwidth so that Tdr is larger than 5 seconds 🏃‍♀️. Similarly, implementations that use the RTP/AVPF profile [RFC4585] or the RTP/SAVPF profile [RFC5124] SHOULD NOT configure T_rr_interval to values larger than 4 seconds. (The reduced limit for T_rr_interval follows Section 6.1.3 of [RFC8108] 📚.)

The reason for enforcing a minimum sending rate, below which the congestion circuit breaker won't trigger, is to avoid spurious triggers when the number of packets sent per RTCP reporting interval is small. In that case the fraction lost samples are full of measurement artifacts 🙈. The rule of at least one packet every max(Tdr, Tr) seconds comes from the one packet per RTT minimum sending rate of TCP [RFC8085], adapted for RTP, where the RTCP reporting interval is decoupled from the network RTT 🦋.

When the congestion circuit breaker is triggered, the sender SHOULD cease transmission (see Section 4.5) 🛑. But if the sender can drop its sending rate by a factor of (approximately) ten, it MAY first reduce its rate by that factor, or some larger amount, to see if that fixes the congestion 🤞. If the rate gets reduced this way and the congestion circuit breaker triggers again after the next CB_INTERVAL RTCP reporting intervals, the sender MUST then cease transmission 😤. An example of this would be a video conferencing system that backs off to sending audio only before fully dropping the call 🎧. If that reduction fixes the congestion, the sender MAY gradually increase its sending rate after a reasonable amount of time has passed, as long as it's careful not to make the problem come back. ("Reasonable" is intentionally not defined here, since it depends on the application, the media codec, and the congestion control algorithm 💅.)

The RTCP reporting interval of the media sender doesn't affect how quickly the congestion circuit breaker can trigger 🙌. The timing is based on the RTCP reporting interval of the receiver that generates the SR/RR packets the loss rate and RTT estimate come from. (RTCP requires all participants in a session to have similar reporting intervals, or else the participant timeout rules in [RFC3550] won't work, so the receiver's interval is probably similar to the sender's 🫶.) If the incoming RTCP SR or RR packets use a reduced minimum RTCP reporting interval (as specified in Section 6.2 of RFC 3550 [RFC3550] or the RTP/AVPF profile [RFC4585]), then that reduced interval is used when deciding whether the circuit breaker triggers 🌈.

If more media streams can fit in a single RTCP SR or RR packet, or if a complete RTCP SR or RR packet is bigger than the network MTU, the receiver reports on a subset of sources in each reporting interval. The subsets are chosen round-robin across multiple intervals, so every source eventually gets reported [RFC3550] 🔁. When generating these round-robin RTCP reports, priority SHOULD be given to sources with high packet loss rates, so senders know about the network congestion they're causing (this is an update to [RFC3550]) 🥹💖.

4.4. RTP/AVP Circuit Breaker #4: Media Usability 🎀

okay so RTP apps are usually pretty chill about some packet loss 🦋 how much they can handle depends on the app, the codec, and how much error correction and packet loss concealment is running. but there's a ceiling on how much loss can be fixed, and past that point the media is just unusable 💀 same deal with latency. apps have an upper bound on the capture-to-play-out delay they can tolerate. that bound depends on the app, but typical numbers range from a few hundred milliseconds for voice telephony and interactive conferencing up to several seconds for some video-on-demand systems ✨

Last but not least, the final circuit breaker 🔥 RTP senders SHOULD keep an eye on the reported packet loss and delay to figure out whether the media is still good for what it's meant to do. if the loss and/or latency gets bad enough that the media is unusable AND stays that way for a significant time, the application SHOULD stop sending 🛑 receivers SHOULD also watch the quality of what they're getting, and if it's unusable for a significant stretch, they SHOULD terminate the session 📞 this memo deliberately doesn't set a number for the loss rate or latency that makes media unusable, because it's super app-dependent 🙈 the same goes for "significant time," which is app-dependent too, but probably seconds or tens of seconds ⏱️

Sending media that's so lossy or laggy that the receiver can't use it is a waste of resources and does nothing for the user 😭 it's also super likely to congest the network and mess with other apps 🌪️ so the congestion circuit breaker will almost certainly kick in and stop flows where the media would be unusable from high loss or latency 🙌 but in pathological cases where the congestion circuit breaker doesn't stop the flow, we want to stop the app from sending pointless traffic that could disrupt everyone else. that's the whole job of the media usability circuit breaker: protecting the network in those situations 🫶

4.5. Ceasing Transmission 🛑

What "cease transmission" means depends on the app 🤷‍♀️ it could mean stopping one RTP flow, or stopping a bunch of bundled RTP flows together. the idea is that the app stops sending RTP data packets on a particular 5-tuple (transport protocol, source and destination ports, source and destination IP addresses) until the network problem that tripped the RTP circuit breaker has cleared up 🌸 RTP flows halted by the circuit breaker SHOULD NOT be restarted automatically unless the sender has learned that the congestion has dissipated or can reasonably be expected to have dissipated. what counts as that expectation is app-dependent 💅 for example, a competing flow finishing and freeing up some capacity, or, on a mobile device, the device moving to a new location so a restarted flow would take a different path. ideally a human user is part of the decision to restart, since they'll eventually give up if the flows keep tripping the breaker 🙋‍♀️ that helps stop automatic redial systems from congesting the network 📞

It's recognized that the RTP implementation in some systems can't tell whether a flow setup request came from a human or from a scripted higher-level component of the system 🤖 those implementations MUST rate limit attempts to restart a flow on the same 5-tuple as the flow that triggered the circuit breaker, so that the reaction to a triggered circuit breaker lasts for at least the triggering interval [RFC8084].

The RTP circuit breaker only triggers, and ceases transmission, for media flows subject to long-term persistent congestion 📉 those flows are likely to have poor quality and usability for some time before the breaker trips 😬 implementations can watch the RTCP Receiver Report blocks coming back for their media flows, and might find it helpful to show a user interface cue that problems are happening before the circuit breaker triggers 👀

5. RTP Circuit Breakers and the RTP/AVPF and RTP/SAVPF Profiles ✈️

Use of the Extended RTP Profile for RTCP-based Feedback (RTP/AVPF) [RFC4585] lets receivers send early RTCP reports in some cases, to tell the sender about particular events in the media stream 📨 there are several use cases for early RTCP reports, including giving rapid feedback to a sender about the onset of congestion. the RTP/SAVPF Profile [RFC5124] is a secure variant of RTP/AVPF, and it's treated the same way in the context of the RTP circuit breaker 🔐 these feedback profiles are often used with non-compound RTCP reports [RFC5506] to cut down on reporting overhead 📉

Getting rapid feedback about congestion events could let congestion control algorithms be more responsive and adapt media transmission better to the limits of the network 🏃‍♀️ lots of RTP congestion control algorithms are expected to adopt RTP/AVPF or RTP/SAVPF for this reason, and define new transport-layer feedback reports that suit their needs. since those reports aren't defined yet and are probably very specific to each algorithm, they can't be part of the generic RTP circuit breaker 🙅‍♀️

Reduced-size RTCP reports sent under the RTP/AVPF early feedback rules that don't contain an RTCP SR or RR packet MUST be ignored by the congestion circuit breaker (they don't have the information the congestion circuit breaker algorithm needs), but they MUST be counted as received packets for the RTCP timeout circuit breaker. Reduced-size RTCP reports sent under the early feedback rules that DO contain RTCP SR or RR packets MUST be processed by the congestion circuit breaker as if they were sent as regular RTCP reports, and counted towards the circuit breaker conditions specified in Section 4 of this memo. this can make the RTP circuit breaker trigger earlier than it would if the RTP/AVPF profile wasn't used 😬

When using ECN with RTP (see Section 7), early RTCP feedback packets can contain ECN feedback reports 🌈 the count of ECN-CE-marked packets in those ECN feedback reports gets counted towards the number of lost packets reported, if the ECN Feedback Report is sent in a compound RTCP packet along with an RTCP SR/RR report packet. reports of ECN-CE packets sent as reduced-size RTCP ECN feedback packets without an RTCP SR/RR packet MUST be ignored. 🙈

These rules are meant to allow low-overhead RTP/AVPF feedback for generic NACK messages without tripping the RTP circuit breaker 💖 this should make that feedback suitable for RTP congestion control algorithms that need to quickly report loss events in between regular RTCP reports. the reaction to reduced-size RTCP SR/RR packets is to let those algorithms send feedback that can trigger the circuit breaker when they want it to 🔥

The RTP/AVPF and RTP/SAVPF profiles include the T_rr_interval parameter, which can be used to adjust the regular RTCP reporting interval. using T_rr_interval changes how the RTP circuit breaker behaves, as described in Section 4 ⏰

6. Impact of RTCP Extended Reports (XR) 📊

RTCP Extended Report (XR) blocks provide additional reception quality metrics, but they don't change the RTCP timing rules ⏰ some of the RTCP XR blocks give info that could be useful for congestion control, and others give non-congestion-related metrics. with the exception of RTCP XR ECN Summary Reports (see Section 7), the presence of RTCP XR blocks in a compound RTCP packet doesn't affect the RTP circuit breaker algorithm. for consistency and ease of implementation, only the receiver report blocks contained in RTCP SR packets, RTCP RR packets, or RTCP XR ECN Summary Report packets are used by the RTP circuit breaker algorithm 💜

7. Impact of Explicit Congestion Notification (ECN) 🌈

Using ECN for RTP flows doesn't affect the RTCP timeout circuit breaker (Section 4.1) or the media timeout circuit breaker (Section 4.2), since both of those are connectivity checks that simply check whether any packets are being received 🔌

At the time of writing, there's no consensus on how receiving ECN feedback will affect the congestion circuit breaker (Section 4.3), or even whether the congestion circuit breaker ought to take ECN feedback into account 🤔 a future replacement of this memo is expected to give implementers guidance ✨

For the media usability circuit breaker (Section 4.4), ECN-CE-marked packets do arrive at the receiver, and if they arrive in time, they get decoded and rendered as normal 🎶 so receiving them shouldn't affect the usability of the media, and RTCP feedback reporting their receipt isn't expected to change how the media usability circuit breaker operates 💅

8. Impact of Bundled Media and Layered Coding 🧅

The RTP circuit breaker operates on a per-RTP-session basis. An RTP sender that participates in several RTP sessions MUST treat each RTP session independently with regards to the RTP circuit breaker 🔒

An RTP sender can generate several media streams within a single RTP session, with each stream using a different SSRC 🎬 this can happen when bundled media is in use, when using simulcast, or when using layered media coding. by default, each SSRC is treated independently by the RTP circuit breaker. however, the sender MAY choose to treat the flows (or a subset of them) as a group, so that a circuit breaker trigger for one flow applies to the group as a whole. depending on which RTP circuit breaker was triggered, that either causes the entire group to cease transmission or causes the group's sending rate to drop by a factor of ten 🪜 grouping flows like this is expected to be especially useful for layered flows sent using multiple SSRCs, since the layered flow can react as a whole, ceasing transmission on the enhancement layers first to reduce sending rate if necessary, rather than treating each layer on its own 🧚

Care needs to be taken if the different media streams sent on a single transport-layer flow use different Differentiated Services Code Point (DSCP) values [RFC7657] [WebRTC-QoS], since congestion could be experienced differently depending on the DSCP marking ⚠️

Accordingly, RTP media streams with different DSCP values SHOULD NOT be considered as a group when evaluating the RTP circuit breaker conditions 💜

9. Security Considerations 🔒✨

okay bestie, this is the serious part 🫶 but it's still giving main character energy because security is literally where the drama lives. The security considerations of [RFC3550] apply.

If the RTP/AVPF profile is used to provide rapid RTCP feedback, the security considerations of [RFC4585] apply. If ECN feedback for RTP over UDP/IP is used, the security considerations of [RFC6679] apply.

If non-authenticated RTCP reports are used, an on-path attacker can trivially generate fake RTCP packets that indicate high packet loss rates. 😭 That means they can cause the circuit breaker to trigger and disrupt an RTP session. It's somewhat harder for an off-path attacker, because they'd first have to guess the randomly chosen RTP SSRC value and the RTP sequence number. This attack can be avoided if RTCP packets are authenticated, and authentication options are discussed in [RFC7201]. 🔐

Timely operation of the RTP circuit breaker depends on the choice of RTCP reporting interval. If the receiver has a reporting interval that is overly long, the circuit breaker gets less responsive. In the limit, the RTP circuit breaker can be disabled for all practical purposes by configuring an RTCP reporting interval that lasts many minutes. 💀 This issue isn't specific to the circuit breaker, though. Long RTCP reporting intervals also stop reception quality reports, feedback messages, codec control messages, and so on from being used. Implementations are expected to impose an upper limit on the RTCP reporting interval they are willing to negotiate (based on the session bandwidth and RTCP bandwidth fraction) when using the RTP circuit breaker, as discussed in Section 4.3. 🦋

10. References 📚

10.1. Normative References 💜

The references below are listed in full, exactly as written.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <http://www.rfc-editor.org/info/rfc3550>.

   [RFC3551]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
              Video Conferences with Minimal Control", STD 65, RFC 3551,
              DOI 10.17487/RFC3551, July 2003,
              <http://www.rfc-editor.org/info/rfc3551>.

   [RFC3611]  Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
              "RTP Control Protocol Extended Reports (RTCP XR)",
              RFC 3611, DOI 10.17487/RFC3611, November 2003,
              <http://www.rfc-editor.org/info/rfc3611>.

   [RFC4585]  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,
              DOI 10.17487/RFC4585, July 2006,
              <http://www.rfc-editor.org/info/rfc4585>.

   [RFC5348]  Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
              Friendly Rate Control (TFRC): Protocol Specification",
              RFC 5348, DOI 10.17487/RFC5348, September 2008,
              <http://www.rfc-editor.org/info/rfc5348>.

   [RFC6679]  Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
              and K. Carlberg, "Explicit Congestion Notification (ECN)
              for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August
              2012, <http://www.rfc-editor.org/info/rfc6679>.

10.2. Informative References 🌸

   [Floyd]    Floyd, S., Handley, M., Padhye, J., and J. Widmer,
              "Equation-Based Congestion Control for Unicast
              Applications", ACM SIGCOMM Computer Communication
              Review, Volume 30, Issue 4, pages 43-56,
              DOI 10.1145/347059.347397, August 2000.

   [Mathis]   Mathis, M., Semke, J., Mahdavi, J., and T. Ott, "The
              Macroscopic Behavior of the TCP Congestion Avoidance
              Algorithm", ACM SIGCOMM Computer Communication
              Review, Volume 27, Issue 3, pages 67-82,
              DOI 10.1145/263932.264023, July 1997.

   [Padhye]   Padhye, J., Firoiu, V., Towsley, D., and J. Kurose,
              "Modeling TCP Throughput: A Simple Model and its Empirical
              Validation", ACM SIGCOMM Computer Communication
              Review Volume 30, Issue 4, pages 303-314,
              DOI 10.1145/285237.285291, August 1998.

   [RFC2862]  Civanlar, M. and G. Cash, "RTP Payload Format for Real-
              Time Pointers", RFC 2862, DOI 10.17487/RFC2862, June 2000,
              <http://www.rfc-editor.org/info/rfc2862>.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, DOI 10.17487/RFC3168, September 2001,
              <http://www.rfc-editor.org/info/rfc3168>.

   [RFC4103]  Hellstrom, G. and P. Jones, "RTP Payload for Text
              Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005,
              <http://www.rfc-editor.org/info/rfc4103>.

   [RFC5104]  Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
              "Codec Control Messages in the RTP Audio-Visual Profile
              with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
              February 2008, <http://www.rfc-editor.org/info/rfc5104>.

   [RFC5124]  Ott, J. and E. Carrara, "Extended Secure RTP Profile for
              Real-time Transport Control Protocol (RTCP)-Based Feedback
              (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
              2008, <http://www.rfc-editor.org/info/rfc5124>.

   [RFC5450]  Singer, D. and H. Desineni, "Transmission Time Offsets in
              RTP Streams", RFC 5450, DOI 10.17487/RFC5450, March 2009,
              <http://www.rfc-editor.org/info/rfc5450>.

   [RFC5506]  Johansson, I. and M. Westerlund, "Support for Reduced-Size
              Real-Time Transport Control Protocol (RTCP): Opportunities
              and Consequences", RFC 5506, DOI 10.17487/RFC5506, April
              2009, <http://www.rfc-editor.org/info/rfc5506>.

   [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
              Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
              <http://www.rfc-editor.org/info/rfc5681>.

   [RFC6798]  Clark, A. and Q. Wu, "RTP Control Protocol (RTCP) Extended
              Report (XR) Block for Packet Delay Variation Metric
              Reporting", RFC 6798, DOI 10.17487/RFC6798, November 2012,
              <http://www.rfc-editor.org/info/rfc6798>.

   [RFC6843]  Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol
              (RTCP) Extended Report (XR) Block for Delay Metric
              Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013,
              <http://www.rfc-editor.org/info/rfc6843>.

   [RFC6958]  Clark, A., Zhang, S., Zhao, J., and Q. Wu, Ed., "RTP
              Control Protocol (RTCP) Extended Report (XR) Block for
              Burst/Gap Loss Metric Reporting", RFC 6958,
              DOI 10.17487/RFC6958, May 2013,
              <http://www.rfc-editor.org/info/rfc6958>.

   [RFC7002]  Clark, A., Zorn, G., and Q. Wu, "RTP Control Protocol
              (RTCP) Extended Report (XR) Block for Discard Count Metric
              Reporting", RFC 7002, DOI 10.17487/RFC7002, September
              2013, <http://www.rfc-editor.org/info/rfc7002>.

   [RFC7003]  Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control
              Protocol (RTCP) Extended Report (XR) Block for Burst/Gap
              Discard Metric Reporting", RFC 7003, DOI 10.17487/RFC7003,
              September 2013, <http://www.rfc-editor.org/info/rfc7003>.

   [RFC7097]  Ott, J., Singh, V., Ed., and I. Curcio, "RTP Control
              Protocol (RTCP) Extended Report (XR) for RLE of Discarded
              Packets", RFC 7097, DOI 10.17487/RFC7097, January 2014,
              <http://www.rfc-editor.org/info/rfc7097>.

   [RFC7201]  Westerlund, M. and C. Perkins, "Options for Securing RTP
              Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
              <http://www.rfc-editor.org/info/rfc7201>.

   [RFC7657]  Black, D., Ed. and P. Jones, "Differentiated Services
              (Diffserv) and Real-Time Communication", RFC 7657,
              DOI 10.17487/RFC7657, November 2015,
              <http://www.rfc-editor.org/info/rfc7657>.

   [RFC7713]  Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx)
              Concepts, Abstract Mechanism, and Requirements", RFC 7713,
              DOI 10.17487/RFC7713, December 2015,
              <http://www.rfc-editor.org/info/rfc7713>.

   [RFC8084]  Fairhurst, G., "Network Transport Circuit Breakers",
              BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017,
              <http://www.rfc-editor.org/info/rfc8084>.

   [RFC8085]  Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
              Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
              March 2017, <http://www.rfc-editor.org/info/rfc8085>.

   [RFC8108]  Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
              "Sending Multiple RTP Streams in a Single RTP Session",
              RFC 8108, DOI 10.17487/RFC8108, March 2017,
              <http://www.rfc-editor.org/info/rfc8108>.

   [Sarker]   Sarker, Z., Singh, V., and C. Perkins, "An Evaluation of
              RTP Circuit Breaker Performance on LTE Networks",
              Proceedings of the IEEE INFOCOM Workshop on Communication
              and Networking Techniques for Contemporary Video,
              DOI 10.1109/INFCOMW.2014.6849240, April 2014.

   [Singh]    Singh, V., McQuistin, S., Ellis, M., and C. Perkins,
              "Circuit Breakers for Multimedia Congestion Control",
              Proceedings of the 2013 20th International Packet Video
              Workshop (PV), DOI 10.1109/PV.2013.6691439, December 2013.

   [WebRTC-QoS]
              Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP
              Packet Markings for WebRTC QoS", Work in Progress,
              draft-ietf-tsvwg-rtcweb-qos-18, August 2016.

Acknowledgements 🫶

The authors would like to thank Bernard Aboba, Harald Alvestrand, Ben Campbell, Alissa Cooper, Spencer Dawkins, Gorry Fairhurst, Stephen Farrell, Nazila Fough, Kevin Gross, Cullen Jennings, Randell Jesup, Mirja Kuehlewind, Jonathan Lennox, Matt Mathis, Stephen McQuistin, Simon Perreault, Eric Rescorla, Abheek Saha, Meral Shirazipour, Fabio Verdicchio, and Magnus Westerlund for their valuable feedback. 💖 Iconic group project energy, honestly. 👑

Authors' Addresses 🎀

   Colin Perkins
   University of Glasgow
   School of Computing Science
   Glasgow  G12 8QQ
   United Kingdom

   Email: csp@csperkins.org


   Varun Singh
   CALLSTATS I/O Oy
   Runeberginkatu 4c A 4
   Helsinki  00100
   Finland

   Email: varun@callstats.io
   URI:   https://www.callstats.io/about

📦 where this page comes from

ietf: rfc8083 2017-03
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms