RFC 9392

📄 RFC 9392: Sending RTCP Feedback for Congestion Control in Interactive Multimedia Conferences 🎀

Okay bestie, this is RFC 9392 ✨. It's from the IETF (Internet Engineering Task Force) and it was written by C. Perkins at the University of Glasgow 🌸. It's marked Informational, which means it's published for information and isn't a Standards Track spec 💅. It came out in April 2023 and has ISSN 2070-1721 🦋. The title block doesn't list anything it obsoletes or updates, so it doesn't replace or change any older RFC 🙈. The title is "Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences" 💖.

Abstract ✨

Okay so this memo talks about how often congestion control feedback can be sent using RTCP 🎀. It also asks whether RTCP is actually a good fit for doing congestion control for unicast multimedia apps 💅. Spoiler: it's a whole discussion, iykyk 🫶.

Status of This Memo 🌈

This document is not an Internet Standards Track specification 🙈. It's published for informational purposes, so it's giving "read this and learn" energy 📚.

This document is a product of the Internet Engineering Task Force (IETF) 💜. It represents the consensus of the IETF community ✨. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG) 👑. Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841 💀.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9392 🍓.

Copyright Notice 🔥

Copyright (c) 2023 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document 📜. Please review these documents carefully, as they describe your rights and restrictions with respect to this document 💅. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License ⚠️.

Table of Contents 🧚

1.  Introduction
  1.1.  Terminology
2.  Considerations for RTCP Feedback
3.  What Feedback is Achievable with RTCP?
  3.1.  Scenario 1: Voice Telephony
  3.2.  Scenario 2: Point-to-Point Video Conference
4.  Discussion and Conclusions
5.  Security Considerations
6.  IANA Considerations
7.  Normative References
8.  Informative References
Acknowledgements
Author's Address

---

1. Introduction 💖

Video conferencing has gotten so big since WebRTC systems [RFC8825] showed up 📹✨. To keep the network stable with all that traffic, WebRTC systems need some form of congestion control for their RTP-based media traffic [RFC2914] [RFC8083] [RFC8085] [RFC8834] 🛡️. That lets them adapt and adjust the media they send so it matches whatever network capacity is available right now 🦋. Honestly, this adaptation is also a huge deal for user experience 🥹, because the sender can match the media to the capacity instead of making the receiver deal with uncontrolled packet loss once the available capacity is exceeded 😭.

To build this kind of congestion control, we need to know what sort of congestion feedback can be provided within the RTP framework [RFC3550] and the RTP Control Protocol (RTCP) 🧠. From there, we can figure out whether that's enough for congestion control or whether some form of RTP extension is needed 🔍.

As this memo will show, if we want to use RTCP in something close to its current form for congestion feedback, the multimedia congestion control algorithm needs to be designed to work with detailed feedback sent every few frames, rather than per-frame acknowledgement, so it matches the constraints of RTCP 💅🔥.

This memo considers unicast congestion feedback that can be sent using RTCP under the RTP/SAVPF profile [RFC5124] (the secure version of the RTP/AVPF profile [RFC4585]) 🔐. This profile was picked because it's the basis for media transport in WebRTC [RFC8834] systems 🌸. Nothing in this memo is specific to the secure version of the profile or to WebRTC, though 🙌. It's also assumed that the congestion control feedback mechanism described in [RFC8888] and the common RTCP extensions for efficient feedback [RFC5506] [RFC8108] [RFC8861] [RFC8872] are being used 🧚.

1.1. Terminology 🎀

• Nr: number of frames between feedback reports
• Nrs: number of reduced-size RTCP packets send for every compound RTCP packet
• Na: number of audio packets per report
• Nv: number of video packets per reports
• Sc: size of a compound RTCP packet
• Srs: size of a reduced-size RTCP packet
• Tf: duration of a media frame in seconds
• Rf: frame rate 1/Tf

2. Considerations for RTCP Feedback 🍓

Okay so there are a few questions you have to answer when you're giving RTCP feedback for congestion control 🤔. They include:

• How often is feedback needed?
• How much overhead is acceptable?
• How much and what data does each report contain?

But the key question is this: how often does the receiver need to send feedback about the reception quality it's experiencing, and therefore about the congestion state of the network? 👑

Widely used transport protocols, like TCP, send acknowledgements super often 💨. For example, a TCP receiver sends an acknowledgement at least once every 0.5 seconds, or when new data equal to twice the maximum segment size has arrived [RFC9293] 🕒. That's relatively low overhead when traffic goes both ways and the acknowledgements can ride along on return path data packets 🚗. It can also be fine, with reasonable overhead, to send separate acknowledgement packets when they're much smaller than the data packets 🌈.

Frequent acknowledgements can turn into a problem, though 😬. That happens when there's no return traffic to piggyback feedback on, or when feedback and data are sent separately and the feedback is about the same size as the data it's acknowledging 📦. This can happen with some kinds of media traffic, especially Voice over IP (VoIP) flows, and then the overhead gets high when you're using a transport protocol that sends frequent feedback 📞. Approaches like in-network filtering of acknowledgements, which have been proposed to cut acknowledgement overhead on highly asymmetric links (e.g., as mentioned in [RFC3449]), can also reduce feedback frequency and overhead for multimedia traffic 🪄. But this so-called "stretch-ACK" behavior is nonstandard and not guaranteed 🙈.

So when you're implementing congestion control for RTP-based multimedia traffic, it might make sense to give the option of sending congestion feedback less often than TCP does 💅. For example, it might be possible to send a feedback packet once per video frame, every few frames, or once per network round-trip time (RTT) 🎞️. That could still give feedback often enough for the congestion control loop to be stable and responsive, while keeping the overhead reasonable when the feedback can't be piggybacked onto returning data 🫶. And here's the big thing: RTCP can send much more detailed feedback than simple acknowledgements 🤯. For example, if it were useful, it could be possible to use an RTCP extended report (XR) packet [RFC3611] to send feedback once per RTT 🔁. That feedback could include a bitmap of lost and received packets, with reception times, over that RTT 🗺️. As long as feedback is sent often enough that the control loop is stable and the sender is kept informed when data leaves the network (to provide an equivalent to acknowledgement (ACK) clocking in TCP), it's not necessary to report on every packet at the instant it's received ⏱️. Honestly, it's unlikely that a video codec can react instantly to a rate change, so there's little point in giving feedback more often than the codec can adapt 🧠. This suggests that an RTP receiver needs to be configured to provide feedback at a rate that matches how fast the sender adapts 🎯. In the best case, that matches the media frame rate, but it might often be slower 🐢.

Reducing feedback frequency compared to TCP will cut feedback overhead, but it will also make multimedia flows adapt to congestion more slowly than TCP does, which raises concerns about inter-flow fairness ⚖️. Similar concerns are noted in [RFC5348], so the congestion control algorithm described there aims for "reasonable" fairness and a sending rate that is "generally within a factor of two" of what TCP would achieve under the same conditions 📏. It's worth noting, though, that TCP shows inter-flow unfairness when flows with different round-trip times compete 🏎️, and stretch acknowledgements caused by in-network traffic manipulation are not uncommon and also raise fairness concerns 😤. Implementations need to balance potential unfairness against feedback overhead ⚖️✨.

Generating and processing feedback uses up resources at the sender and receiver 💻. The feedback packets also cost forwarding resources, contribute to link utilization, and can affect the timing of other traffic on the network 🚦. This can hit performance on some network types that are affected by the rate, timing, and size of feedback packets, as well as the overall volume of feedback bytes 📉.

We still have to figure out how much overhead from congestion control feedback is acceptable 🤷‍♀️. RTCP feedback is sent in separate packets from the RTP data, and that costs some extra header overhead compared to protocols that piggyback feedback on return path data packets 🧾. The RTP standards have long said that a 5% overhead for RTCP traffic is generally acceptable 📊. Is that still the case for congestion control feedback? 🤨 Is there a desire for more responsive feedback and congestion control, possibly with higher overhead? 🚀 Or is lower overhead wanted, accepting that this might reduce how responsive the congestion control algorithm is? 🐌

Finally, the details of how much and what data goes in each report will affect the frequency and/or overhead of feedback 🧩. There's a fundamental trade-off here: the more often feedback packets are sent, the less data can be included in each packet if you want to keep the overhead constant 🍰. So does congestion control need a high rate of simple feedback (like TCP acknowledgements), or is it fine to send more complex feedback less often? 🤔 Is it useful for congestion control to get frequent feedback, maybe for more accurate round-trip time estimates, or for robustness in case feedback packets are lost, even if the media sending rate can't quickly change? 🛟 Or is low-rate feedback, which gives slowly responsive changes to the sending rate, acceptable? 🐢 Different combinations of congestion control algorithm and media codec might need different trade-offs, and the right trade-off for interactive, self-paced, real-time multimedia traffic might not be the same as the one for TCP congestion control 💜.

3. What Feedback is Achievable with RTCP? 🦋

Okay, this part shows how the RTCP congestion control feedback report [RFC8888] can be used in different scenarios, and what the overheads of that approach look like 📊✨.

3.1. Scenario 1: Voice Telephony 📞

okay so point-to-point voice calls are literally the simplest case for congestion control 💖 because there's only ONE media stream to keep an eye on. the catch is that the feedback has to be super lightweight so the overhead doesn't get out of hand 😭

picture a two-party VoIP call running RTP over UDP/IP 🎀. the audio is made by a rate-adaptive speech codec like Opus, and it's packed into RTP packets in frames that last Tf seconds each (Tf = 0.020 s in lots of cases, but up to 0.060 s is totally normal too 🌸). the congestion control algorithm wants feedback every Nr frames, which means every Nr * Tf seconds, so it can do its job properly ✨. both people on the call send speech or comfort noise often enough that they still count as senders when RTCP works out its reporting interval 🫶.

RTCP feedback can come in full (compound) packets or in reduced-size RTCP packets [RFC5506] 🦋. a compound RTCP packet gets sent once for every Nrs reduced-size RTCP packets.

Compound RTCP packets hold a Sender Report (SR) packet, a Source Description (SDES) packet, and an RTP Congestion Control Feedback (CCFB) packet [RFC8888] 💅. reduced-size packets only carry the CCFB packet. since each participant only sends one RTP media stream, the RTCP report aggregation extensions [RFC8108] and the reporting group optimization [RFC8861] aren't used here, bestie 🙈.

Inside each compound RTCP packet, the SR packet has a sender information block (28 octets) and a single reception report block (24 octets), which adds up to 52 octets total 🍓. a minimal SDES packet has a header (4 octets), one chunk with a synchronization source (SSRC) (4 octets), and a CNAME item. if the recommendations for choosing the CNAME [RFC7022] are followed, the CNAME item is a 2-octet header, 16 octets of data, and 2 octets of padding, so the whole SDES packet comes to 28 octets 🌈. the CCFB packets have an RTCP header and SSRC (8 octets), a report timestamp (4 octets), the other party's SSRC, beginning and ending sequence numbers (8 octets), and 2 * Nr octets of reports, for a total of 20 + (2 * Nr) octets ✨. the compound Secure RTCP (SRTCP) packet adds a 4-octet trailer, followed by an 80-bit (10-octet) authentication tag if HMAC-SHA1 authentication is used 🔐. with IPv4 and no IP options, the UDP/IP header is 28 octets. so the total compound RTCP packet size is Sc = 142 + (2 * Nr) octets 🧚.

the reduced-size RTCP packets are just the CCFB packet, the SRTCP trailer and authentication tag, and a UDP/IP header. those come out to Srs = 62 + (2 * Nr) octets 💜.

the RTCP reporting interval calculation (Sections 6.2 and 6.3 of [RFC3550] and [RFC4585]) for a two-party session where both people are senders boils down to this 🤓:

Trtcp = n * Srtcp / Brtcp

where Srtcp = (Sc + Nrs * Srs) / (1 + Nrs) is the average RTCP packet size in octets, Brtcp is the bandwidth given to RTCP in octets per second, and n is the number of participants in the RTP session (here, n = 2) 💕.

so to make sure an RTCP report with congestion control feedback goes out after every Nr frames of audio, the RTCP reporting interval has to be Trtcp = Nr * Tf. plugging that in gives Nr * Tf = n * Srtcp / Brtcp. solving for the RTCP bandwidth (Brtcp) and expanding the Srtcp definition gives us 🎯:

Brtcp = (n * (Sc + Nrs * Srs)) / (Nr * Tf * (1 + Nrs))

say every report is a compound RTCP packet (Nrs = 0), the frame duration is Tf = 20 ms, and an RTCP report goes out for every second frame (that's 25 RTCP reports per second). then the RTCP feedback bandwidth is Brtcp = 57 kbps 😳. making the frames longer or sending reports less often drops the RTCP bandwidth, as Table 1 shows 🦋.

+==============+=============+================+
| Tf (seconds) | Nr (frames) | rtcp_bw (kbps) |
+==============+=============+================+
| 0.020        | 2           | 57.0           |
+--------------+-------------+----------------+
| 0.020        | 4           | 29.3           |
+--------------+-------------+----------------+
| 0.020        | 8           | 15.4           |
+--------------+-------------+----------------+
| 0.020        | 16          | 8.5            |
+--------------+-------------+----------------+
| 0.060        | 2           | 19.0           |
+--------------+-------------+----------------+
| 0.060        | 4           | 9.8            |
+--------------+-------------+----------------+
| 0.060        | 8           | 5.1            |
+--------------+-------------+----------------+
| 0.060        | 16          | 2.8            |
+--------------+-------------+----------------+

    Table 1: RTCP Bandwidth Needed for VoIP
        Feedback (Compound Reports Only)

the last row of Table 1 (60 ms frames, reporting every 16 frames) sends RTCP reports once per second, so the RTCP bandwidth overhead is 2.8 kbps 🌸.

you can cut the overhead even more by sending some reports as reduced-size RTCP packets [RFC5506] ✨. for example, if we alternate compound and reduced-size packets (so Nrs = 1), the math gives the numbers in Table 2 👑.

+==============+=============+================+
| Tf (seconds) | Nr (frames) | rtcp_bw (kbps) |
+==============+=============+================+
| 0.020        | 2           | 41.4           |
+--------------+-------------+----------------+
| 0.020        | 4           | 21.5           |
+--------------+-------------+----------------+
| 0.020        | 8           | 11.5           |
+--------------+-------------+----------------+
| 0.020        | 16          | 6.5            |
+--------------+-------------+----------------+
| 0.060        | 2           | 13.8           |
+--------------+-------------+----------------+
| 0.060        | 4           | 7.2            |
+--------------+-------------+----------------+
| 0.060        | 8           | 3.8            |
+--------------+-------------+----------------+
| 0.060        | 16          | 2.2            |
+--------------+-------------+----------------+

   Table 2: Required RTCP Bandwidth for VoIP
  Feedback (Alternating Compound and Reduced-
                 Size Reports)

for 60 ms frames with reports every 16 frames (once per second), the RTCP bandwidth drops all the way to 2.2 kbps 🥹. you can repeat this for other mixes of compound and reduced-size packets, feedback frequencies, and frame durations whenever you need to ✨.

   |  Note: To achieve the RTCP transmission intervals above, the
   |  RTP/SAVPF profile with T_rr_interval=0 is used, since even when
   |  using the reduced minimal transmission interval, the RTP/SAVP
   |  profile would only allow sending RTCP at most every 0.11 s
   |  (every third frame of video).  Using RTP/SAVPF with
   |  T_rr_interval=0, however, enables full utilization of the
   |  configured 5% RTCP bandwidth fraction.

⚠️ the RTP/SAVPF profile with T_rr_interval=0 is what gets you those RTCP intervals. plain RTP/SAVP would only let RTCP go out at most every 0.11 s even with the reduced minimal transmission interval, and that's way too slow for this 🙈.

using IPv6 adds 20 octets per packet, because the IPv6 header is bigger than the IPv4 one (assuming no IP options in either case) 🧚. that makes compound packets Sc = 162 + (2 * Nr) octets and reduced-size packets Srs = 82 + (2 * Nr). rerunning the Table 1 calculations with these sizes gives Table 3. and yep, the overhead jumps a lot with IPv6 💀.

+==============+=============+================+
| Tf (seconds) | Nr (frames) | rtcp_bw (kbps) |
+==============+=============+================+
| 0.020        | 2           | 64.8           |
+--------------+-------------+----------------+
| 0.020        | 4           | 33.2           |
+--------------+-------------+----------------+
| 0.020        | 8           | 17.4           |
+--------------+-------------+----------------+
| 0.020        | 16          | 9.5            |
+--------------+-------------+----------------+
| 0.060        | 2           | 21.6           |
+--------------+-------------+----------------+
| 0.060        | 4           | 11.1           |
+--------------+-------------+----------------+
| 0.060        | 8           | 5.8            |
+--------------+-------------+----------------+
| 0.060        | 16          | 3.2            |
+--------------+-------------+----------------+

    Table 3: RTCP Bandwidth Needed for VoIP
  Feedback (Compound Reports Only) Using IPv6

doing the Table 2 calculations again with IPv6 gives Table 4. the overhead still goes up with IPv6 when you mix compound and reduced-size reports, but it's less dramatic than with compound reports only 🫶.

+==============+=============+================+
| Tf (seconds) | Nr (frames) | rtcp_bw (kbps) |
+==============+=============+================+
| 0.020        | 2           | 49.2           |
+--------------+-------------+----------------+
| 0.020        | 4           | 25.4           |
+--------------+-------------+----------------+
| 0.020        | 8           | 13.5           |
+--------------+-------------+----------------+
| 0.020        | 16          | 7.5            |
+--------------+-------------+----------------+
| 0.060        | 2           | 16.4           |
+--------------+-------------+----------------+
| 0.060        | 4           | 8.5            |
+--------------+-------------+----------------+
| 0.060        | 8           | 4.5            |
+--------------+-------------+----------------+
| 0.060        | 16          | 2.5            |
+--------------+-------------+----------------+

   Table 4: Required RTCP Bandwidth for VoIP
  Feedback (Alternating Compound and Reduced-
            Size Reports) Using IPv6

---

3.2. Scenario 2: Point-to-Point Video Conference 🎥

okay picture a point-to-point video call between two end systems 🌈. this one has four RTP flows going at the same time (two audio and two video), and all four are active basically the whole time 💖. the audio flows will probably use voice activity detection and comfort noise to lower the packet rate during silence, but that doesn't mean they stop transmitting 🫶.

okay so picture all four flows riding in one single RTP session 🎀, each one with its own SSRC 🦋. The RTCP reports from the co-located audio and video SSRCs at each end point get aggregated [RFC8108] ✨, the optimizations in [RFC8861] get switched on 💅, and RTCP congestion control feedback gets sent too [RFC8888] 🔥.

As in Section 3.1 🌸, when all members are senders, the RTCP reporting interval calculation in Sections 6.2 and 6.3 [RFC3550] and in [RFC4585] collapses down to this super clean formula 😭:

   Trtcp = n * Srtcp / Brtcp

where n is the number of members in the session, Srtcp is the average RTCP packet size in octets, and Brtcp is the RTCP bandwidth in octets per second 🧚.

The average RTCP packet size (Srtcp) depends on a few things, bestie 💜: how much feedback goes in each RTCP packet, how many members are in the session, how much source description (RTCP SDES) info gets sent, and how much congestion control feedback rides along in each packet.

Okay so the baseline is that each RTCP packet is a compound RTCP packet 🍓. It holds an aggregate of a compound RTCP packet generated by the video SSRC and another one generated by the audio SSRC. When the RTCP reporting group extensions are used, one of these SSRCs becomes a reporting SSRC 👑, and the other SSRC delegates its reports to it. And no reduced-size RTCP packets are sent in this baseline 🙈.

The aggregated compound RTCP packet from the non-reporting SSRC has an RTCP SR packet, an RTCP SDES packet, and an RTCP Reporting Group Reporting Sources (RGRS) packet 💅. The RTCP SR packet has the 28-octet UDP/IP header (assuming IPv4 with no options) plus sender information, but no report blocks, since the reporting got delegated away 🫶. The RTCP SDES packet is a header (4 octets), the originating SSRC (4 octets), a CNAME chunk, a terminating chunk, and any padding ✨. If the CNAME follows [RFC7022] and [RFC8834], the CNAME chunk is 18 octets, then one octet of padding and one terminating null octet line it up to a 32-bit boundary ([RFC3550], Section 6.5), so the SDES packet ends up at 28 octets 🌈. The RTCP RGRS packet is 12 octets 🦋. Add it all up and you get 28 + 28 + 12 = 68 octets. Iconic math 💖.

The aggregated compound RTCP packet from the reporting SSRC has an RTCP SR packet, an RTCP SDES packet, and an RTCP congestion control feedback packet 🔥. The RTCP SR packet has two report blocks, one for each of the remote SSRCs. The report for the other local SSRC is suppressed by the reporting group extension, so that's 28 + (2 * 24) = 76 octets total 👑. The RTCP SDES packet is a header (4 octets), originating SSRC (4 octets), a CNAME chunk, a Reporting Group (RGRP) chunk, a terminating chunk, and any padding 🎀. If the CNAME follows [RFC7022] and [RFC8834], it's 18 octets. The RGRP chunk is also 18 octets, the terminating chunk is 1 octet, and 3 octets of padding are needed, for a total of 48 octets 🧚. The RTCP congestion control feedback (CCFB) report is an 8-octet RTCP header and SSRC, a 4-octet report timestamp, and then for each of the remote audio and video SSRCs, an 8-octet report header, 2 octets per packet reported upon, and padding to a 4-octet boundary if it's needed 💜. So that's 8 + 4 + 8 + (2 * Nv) + 8 + (2 * Na), where Nv is the number of video packets per report and Na is the number of audio packets per report 😭.

The complete compound RTCP packet has the RTCP packets from both the reporting and non-reporting SSRCs, an SRTCP trailer and authentication tag, and a UDP/IPv4 header 🌸. The size of this RTCP packet works out to 262 + (2 * Nv) + (2 * Na) octets. Since the aggregate RTCP packet has reports from two SSRCs, the RTCP packet size gets halved before use [RFC8108] ✨. So the size of the RTCP packets is:

   Srtcp = (262 + (2 * Nv) + (2 * Na)) / 2

Now the big question, bestie 👀: how many RTP packets does the RTCP XR congestion control feedback packet, included in these compound RTCP packets, actually report on? In other words, what are Nv and Na? That depends on the RTCP reporting interval (Trtcp), the video bit rate and frame rate (Rf), the audio bit rate and framing interval, and whether the receiver chooses to send congestion control feedback in each RTCP packet it sends 🦋.

To keep the math simple 🧮, let's assume we want one RTCP report for each frame of video received (so Trtcp = 1 / Rf) and we want a congestion control feedback packet in each report 💅. Also assume the video has a constant bit rate and frame rate, and each frame of video has to fit into a 1500-octet MTU 🔥. The audio takes negligible bandwidth 🫶, and the audio framing interval can be varied within reasonable bounds, so that a whole number of audio frames line up with video frame boundaries ✨.

Table 5 shows the resulting values of Nv and Na (the number of video and audio packets covered by each congestion control feedback report) for a range of data rates and video frame rates, assuming congestion control feedback is sent once per video frame 🌈. The table also shows the result of inverting the RTCP reporting interval calculation to find the corresponding RTCP bandwidth (Brtcp) 🧚. The RTCP bandwidth is given in kbps and as a fraction of the data rate 💖.

   +===========+==========+=============+=============+===============+
   | Data Rate |  Video   |    Video    |    Audio    | Required RTCP |
   |   (kbps)  |  Frame   | Packets per | Packets per |   Bandwidth:  |
   |           | Rate: Rf |  Report: Nv |  Report: Na |  Brtcp (kbps) |
   +===========+==========+=============+=============+===============+
   | 100       | 8        | 1           | 6           | 34.5 (34%)    |
   +-----------+----------+-------------+-------------+---------------+
   | 200       | 16       | 1           | 3           | 67.5 (33%)    |
   +-----------+----------+-------------+-------------+---------------+
   | 350       | 30       | 1           | 2           | 125.6 (35%)   |
   +-----------+----------+-------------+-------------+---------------+
   | 700       | 30       | 2           | 2           | 126.6 (18%)   |
   +-----------+----------+-------------+-------------+---------------+
   | 700       | 60       | 1           | 1           | 249.4 (35%)   |
   +-----------+----------+-------------+-------------+---------------+
   | 1024      | 30       | 3           | 2           | 127.5 (12%)   |
   +-----------+----------+-------------+-------------+---------------+
   | 1400      | 60       | 2           | 1           | 251.2 (17%)   |
   +-----------+----------+-------------+-------------+---------------+
   | 2048      | 30       | 6           | 2           | 130.3 ( 6%)   |
   +-----------+----------+-------------+-------------+---------------+
   | 2048      | 60       | 3           | 1           | 253.1 (12%)   |
   +-----------+----------+-------------+-------------+---------------+
   | 4096      | 30       | 12          | 2           | 135.9 ( 3%)   |
   +-----------+----------+-------------+-------------+---------------+
   | 4096      | 60       | 6           | 1           | 258.8 ( 6%)   |
   +-----------+----------+-------------+-------------+---------------+

        Table 5: Required RTCP Bandwidth, Reporting on Every Frame

Use of reduced-size RTCP [RFC5506] would let the SR and SDES packets get left out of some reports 🦋. These reduced-size RTCP packets would contain an RTCP RGRS packet from the non-reporting SSRC, plus an RTCP SDES RGRP packet and a congestion control feedback packet from the reporting SSRC 🌸. That comes to 12 + 28 + 12 + 8 + (2 * Nv) + 8 + (2 * Na) octets, plus the SRTCP trailer and authentication tag and a UDP/IP header 💜. So the size of the reduced-size packets is (110 + (2 * Nv) + (2 * Na)) / 2 octets. If you repeat the analysis above but alternate compound and reduced-size reports, you get the results in Table 6 ✨.

   +===========+==========+=============+=============+===============+
   | Data Rate |  Video   |    Video    |    Audio    | Required RTCP |
   |   (kbps)  |  Frame   | Packets per | Packets per |   Bandwidth:  |
   |           | Rate: Rf |  Report: Nv |  Report: Na |  Brtcp (kbps) |
   +===========+==========+=============+=============+===============+
   | 100       | 8        | 1           | 6           | 25.0 (25%)    |
   +-----------+----------+-------------+-------------+---------------+
   | 200       | 16       | 1           | 3           | 48.5 (24%)    |
   +-----------+----------+-------------+-------------+---------------+
   | 350       | 30       | 1           | 2           | 90.0 (25%)    |
   +-----------+----------+-------------+-------------+---------------+
   | 700       | 30       | 2           | 2           | 90.9 (12%)    |
   +-----------+----------+-------------+-------------+---------------+
   | 700       | 60       | 1           | 1           | 178.1 (25%)   |
   +-----------+----------+-------------+-------------+---------------+
   | 1024      | 30       | 3           | 2           | 91.9 ( 8%)    |
   +-----------+----------+-------------+-------------+---------------+
   | 1400      | 60       | 2           | 1           | 180.0 (12%)   |
   +-----------+----------+-------------+-------------+---------------+
   | 2048      | 30       | 6           | 2           | 94.7 ( 4%)    |
   +-----------+----------+-------------+-------------+---------------+
   | 2048      | 60       | 3           | 1           | 181.9 ( 8%)   |
   +-----------+----------+-------------+-------------+---------------+
   | 4096      | 30       | 12          | 2           | 100.3 ( 2%)   |
   +-----------+----------+-------------+-------------+---------------+
   | 4096      | 60       | 6           | 1           | 187.5 ( 4%)   |
   +-----------+----------+-------------+-------------+---------------+

     Table 6: Required RTCP Bandwidth, Reporting on Every Frame, with
                           Reduced-Size Reports

The use of reduced-size RTCP gives a noticeable drop in the needed RTCP bandwidth 📉, and it can be combined with reporting every few frames instead of every single frame 🌟. Overall it's clear that RTCP overhead can be reasonable across the whole range of data and frame rates, as long as RTCP is configured carefully 🫶💅.

As discussed in Section 3.1 🎀, the reporting overhead goes up if IPv6 is used, because the IPv6 header is bigger 🧚. Table 7 shows the overhead in this case, compared to Table 6 💖. And as you can see, the increase in overhead from IPv6 gets way less significant as the data rate goes up 😭✨.

   +===========+==========+=============+=============+===============+
   | Data Rate |  Video   |    Video    |    Audio    | Required RTCP |
   |   (kbps)  |  Frame   | Packets per | Packets per |   Bandwidth:  |
   |           | Rate: Rf |  Report: Nv |  Report: Na |  Brtcp (kbps) |
   +===========+==========+=============+=============+===============+
   | 100       | 8        | 1           | 6           | 27.5 (27%)    |
   +-----------+----------+-------------+-------------+---------------+
   | 200       | 16       | 1           | 3           | 53.5 (26%)    |
   +-----------+----------+-------------+-------------+---------------+
   | 350       | 30       | 1           | 2           | 99.4 (28%)    |
   +-----------+----------+-------------+-------------+---------------+
   | 700       | 30       | 2           | 2           | 100.3 (14%)   |
   +-----------+----------+-------------+-------------+---------------+
   | 700       | 60       | 1           | 1           | 196.9 (28%)   |
   +-----------+----------+-------------+-------------+---------------+
   | 1024      | 30       | 3           | 2           | 101.2 ( 9%)   |
   +-----------+----------+-------------+-------------+---------------+
   | 1400      | 60       | 2           | 1           | 198.8 (14%)   |
   +-----------+----------+-------------+-------------+---------------+
   | 2048      | 30       | 6           | 2           | 104.1 ( 5%)   |
   +-----------+----------+-------------+-------------+---------------+
   | 2048      | 60       | 3           | 1           | 200.6 ( 9%)   |
   +-----------+----------+-------------+-------------+---------------+
   | 4096      | 30       | 12          | 2           | 109.7 ( 2%)   |
   +-----------+----------+-------------+-------------+---------------+
   | 4096      | 60       | 6           | 1           | 206.2 ( 5%)   |
   +-----------+----------+-------------+-------------+---------------+

     Table 7: Required RTCP Bandwidth, Reporting on Every Frame, with
                     Reduced-Size Reports, Using IPv6

4. Discussion and Conclusions 💅

okay so, real talk: practical systems are almost always sending some non-media traffic on the same path as the media 🫶 Think STUN / TURN packets that keep NAT bindings alive [RFC8445], or WebRTC data channel packets [RFC8831], and so on. That stuff needs congestion control too, but how you actually get it is out of scope for this memo 🎀

RTCP, as it's currently specced, cannot send per-packet congestion feedback with reasonable overhead. ngl, that's a bummer 😭

BUT. RTCP can send congestion feedback on each frame of video, as long as the session bandwidth is more than a couple of megabits per second ✨ The exact rate depends on how many participants there are, the RTCP bandwidth fraction, which RTCP extensions are turned on, and how much detail you need. For lower-rate sessions, reporting on every frame gets expensive 💸 but you can bring it down to something reasonable by reporting once every N frames (say, every second frame), or by sending reduced-size RTCP reports in between the regular ones. The improved compression of newer video codecs makes the reporting overhead worse for a given video quality, although higher-quality video over time sort of balances that out 🌈

If you want to use RTCP in something close to its current form for congestion feedback in WebRTC, the multimedia congestion control algorithm needs to be designed to work with feedback sent every few frames, since that fits inside RTCP's limits 🦋 The feedback is way more detailed than a simple acknowledgement, though. It gives you a loss bitmap, relative arrival time, and received Explicit Congestion Notification (ECN) marks for each packet sent 🔥 That's what makes congestion control that's effective (just slower to respond) possible. There's guidance on providing effective congestion control in Section 3.1 of [RFC8085] 📖

The format in [RFC8888] seems sufficient for congestion control feedback needs. There's not much point optimizing it further 🙈 The main overhead comes from the UDP/IP headers and the other RTCP packets bundled in compound packets. You can lower that by using the extensions in [RFC5506] and by sending reports less often. Header compression [RFC2508] [RFC3545] [RFC5795] can help too 🍓

Last thing: more study is needed to make sure this analysis applies to other media topologies [RFC7667] and to sessions with different data rates and membership sizes 🧚

5. Security Considerations 🚨

Okay, this part is serious bestie 😭 An attacker that can modify or spoof RTCP congestion control feedback packets can manipulate how the sender behaves and cause a denial of service. That can be prevented with authentication and integrity protection of RTCP packets, for example using the secure RTP profile [RFC3711] [RFC5124], or other means discussed in [RFC7201] 🔒💜

6. IANA Considerations 🎀

This document has no IANA actions. Nothing to register here, we're good 💖

7. Normative References 📚

[RFC2914]  Floyd, S., "Congestion Control Principles", BCP 41,
           RFC 2914, DOI 10.17487/RFC2914, September 2000,
           <https://www.rfc-editor.org/info/rfc2914>.

[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, <https://www.rfc-editor.org/info/rfc3550>.

[RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
           Norrman, "The Secure Real-time Transport Protocol (SRTP)",
           RFC 3711, DOI 10.17487/RFC3711, March 2004,
           <https://www.rfc-editor.org/info/rfc3711>.

[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,
           <https://www.rfc-editor.org/info/rfc4585>.

[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, <https://www.rfc-editor.org/info/rfc5124>.

[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, <https://www.rfc-editor.org/info/rfc5506>.

[RFC7022]  Begen, A., Perkins, C., Wing, D., and E. Rescorla,
           "Guidelines for Choosing RTP Control Protocol (RTCP)
           Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022,
           September 2013, <https://www.rfc-editor.org/info/rfc7022>.

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

[RFC8083]  Perkins, C. and V. Singh, "Multimedia Congestion Control:
           Circuit Breakers for Unicast RTP Sessions", RFC 8083,
           DOI 10.17487/RFC8083, March 2017,
           <https://www.rfc-editor.org/info/rfc8083>.

[RFC8085]  Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
           Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
           March 2017, <https://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,
           <https://www.rfc-editor.org/info/rfc8108>.

[RFC8825]  Alvestrand, H., "Overview: Real-Time Protocols for
           Browser-Based Applications", RFC 8825,
           DOI 10.17487/RFC8825, January 2021,
           <https://www.rfc-editor.org/info/rfc8825>.

[RFC8834]  Perkins, C., Westerlund, M., and J. Ott, "Media Transport
           and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834,
           January 2021, <https://www.rfc-editor.org/info/rfc8834>.

[RFC8861]  Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
           "Sending Multiple RTP Streams in a Single RTP Session:
           Grouping RTP Control Protocol (RTCP) Reception Statistics
           and Other Feedback", RFC 8861, DOI 10.17487/RFC8861,
           January 2021, <https://www.rfc-editor.org/info/rfc8861>.

[RFC8872]  Westerlund, M., Burman, B., Perkins, C., Alvestrand, H.,
           and R. Even, "Guidelines for Using the Multiplexing
           Features of RTP to Support Multiple Media Streams",
           RFC 8872, DOI 10.17487/RFC8872, January 2021,
           <https://www.rfc-editor.org/info/rfc8872>.

[RFC8888]  Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP
           Control Protocol (RTCP) Feedback for Congestion Control",
           RFC 8888, DOI 10.17487/RFC8888, January 2021,
           <https://www.rfc-editor.org/info/rfc8888>.

8. Informative References 🌸

[RFC2508]  Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
           Headers for Low-Speed Serial Links", RFC 2508,
           DOI 10.17487/RFC2508, February 1999,
           <https://www.rfc-editor.org/info/rfc2508>.

[RFC3449]  Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M.
           Sooriyabandara, "TCP Performance Implications of Network
           Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449,
           December 2002, <https://www.rfc-editor.org/info/rfc3449>.

[RFC3545]  Koren, T., Casner, S., Geevarghese, J., Thompson, B., and
           P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with
           High Delay, Packet Loss and Reordering", RFC 3545,
           DOI 10.17487/RFC3545, July 2003,
           <https://www.rfc-editor.org/info/rfc3545>.

[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,
           <https://www.rfc-editor.org/info/rfc3611>.

[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,
           <https://www.rfc-editor.org/info/rfc5348>.

[RFC5795]  Sandlund, K., Pelletier, G., and L. Jonsson, "The RObust
           Header Compression (ROHC) Framework", RFC 5795,
           DOI 10.17487/RFC5795, March 2010,
           <https://www.rfc-editor.org/info/rfc5795>.

[RFC7667]  Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
           DOI 10.17487/RFC7667, November 2015,
           <https://www.rfc-editor.org/info/rfc7667>.

[RFC8445]  Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
           Connectivity Establishment (ICE): A Protocol for Network
           Address Translator (NAT) Traversal", RFC 8445,
           DOI 10.17487/RFC8445, July 2018,
           <https://www.rfc-editor.org/info/rfc8445>.

[RFC8831]  Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data
           Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021,
           <https://www.rfc-editor.org/info/rfc8831>.

[RFC9293]  Eddy, W., Ed., "Transmission Control Protocol (TCP)",
           STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
           <https://www.rfc-editor.org/info/rfc9293>.

Okay bestie, let's wrap this up together 🎀✨

Acknowledgements

Huge thank-yous to Bernard Aboba, Martin Duke, Linda Dunbar, Gorry Fairhurst, Ingemar Johansson, Shuping Peng, Alvaro Retana, Zahed Sarker, John Scudder, Éric Vyncke, Magnus Westerlund, and the whole RMCAT feedback design team for looking this over and giving feedback 💖🫶 you all are literally the reason this is as good as it is 👑

Author's Address

Colin Perkins 🦋 University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom Email: csp@csperkins.org

---

That's the whole thing, bestie!! 🌈💅 Five parts, one very cute RFC, and every single detail is still in there. Go be a main character in your networking era 😭🔥