path: root/doc/rfc/rfc9392.txt

Internet Engineering Task Force (IETF)                        C. Perkins
Request for Comments: 9392                         University of Glasgow
Category: Informational                                       April 2023
ISSN: 2070-1721


 Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in
                   Interactive Multimedia Conferences

Abstract

   This memo discusses the rate at which congestion control feedback can
   be sent using the RTP Control Protocol (RTCP) and the suitability of
   RTCP for implementing congestion control for unicast multimedia
   applications.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   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

   The deployment of WebRTC systems [RFC8825] has resulted in high-
   quality video conferencing seeing extremely wide use.  To ensure the
   stability of the network in the face of this use, WebRTC systems need
   to use some form of congestion control for their RTP-based media
   traffic [RFC2914] [RFC8083] [RFC8085] [RFC8834], allowing them to
   adapt and adjust the media data they send to match changes in the
   available network capacity.  In addition to ensuring the stable
   operation of the network, such adaptation is critical to ensuring a
   good user experience, since it allows the sender to match the media
   to the network capacity, rather than forcing the receiver to
   compensate for uncontrolled packet loss when the available capacity
   is exceeded.

   To develop such congestion control, it is necessary to understand the
   sort of congestion feedback that can be provided within the framework
   of RTP [RFC3550] and the RTP Control Protocol (RTCP).  It then
   becomes possible to determine if this is sufficient for congestion
   control or if some form of RTP extension is needed.

   As this memo will show, if it is desired 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, to match 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 chosen because
   it forms the basis for media transport in WebRTC [RFC8834] systems.
   However, nothing in this memo is specific to the secure version of
   the profile or to WebRTC.  It is also assumed that the congestion
   control feedback mechanism described in [RFC8888] and common RTCP
   extensions for efficient feedback [RFC5506] [RFC8108] [RFC8861]
   [RFC8872] are 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

   Several questions need to be answered when providing RTCP feedback
   for congestion control purposes.  These include:

   *  How often is feedback needed?

   *  How much overhead is acceptable?

   *  How much and what data does each report contain?

   However, the key question is as follows: how often does the receiver
   need to send feedback on the reception quality it is experiencing and
   hence the congestion state of the network?

   Widely used transport protocols, such as TCP, send acknowledgements
   frequently.  For example, a TCP receiver will send an acknowledgement
   at least once every 0.5 seconds or when new data equal to twice the
   maximum segment size has been received [RFC9293].  That has
   relatively low overhead when traffic is bidirectional and
   acknowledgements can be piggybacked onto return path data packets.
   It can also be acceptable, and can have reasonable overhead, to send
   separate acknowledgement packets when those packets are much smaller
   than data packets.

   Frequent acknowledgements can become a problem, however, when there
   is no return traffic on which to piggyback feedback or if separate
   feedback and data packets are sent and the feedback is similar in
   size to the data being acknowledged.  This can be the case for some
   forms of media traffic, especially for Voice over IP (VoIP) flows,
   leading to high overhead when using a transport protocol that sends
   frequent feedback.  Approaches like in-network filtering of
   acknowledgements that have been proposed to reduce acknowledgement
   overheads on highly asymmetric links (e.g., as mentioned in
   [RFC3449]) can also reduce the feedback frequency and overhead for
   multimedia traffic, but this so-called "stretch-ACK" behavior is
   nonstandard and not guaranteed.

   Accordingly, when 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).  This could still
   give sufficiently frequent feedback for the congestion control loop
   to be stable and responsive while keeping the overhead reasonable
   when the feedback cannot be piggybacked onto returning data.  In this
   case, it is important to note that 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; the feedback could
   comprise a bitmap of lost and received packets, with reception times,
   over that RTT.  As long as feedback is sent frequently 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 is not necessary to report on every packet at
   the instant it is received.  Indeed, it is unlikely that a video
   codec can react instantly to a rate change, and there is little point
   in providing 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 the rate of adaptation of the sender.
   In the best case, this will match the media frame rate but might
   often be slower.

   Reducing the feedback frequency compared to TCP will reduce feedback
   overhead but will lead multimedia flows to adapt to congestion more
   slowly than TCP, raising concerns about inter-flow fairness.  Similar
   concerns are noted in [RFC5348], and accordingly, the congestion
   control algorithm described therein 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 is to be noted,
   however, that TCP exhibits inter-flow unfairness when flows with
   differing round-trip times compete, and stretch acknowledgements due
   to 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 consumes resources at the sender
   and receiver.  The feedback packets also incur forwarding costs,
   contribute to link utilization, and can affect the timing of other
   traffic on the network.  This can affect performance on some types of
   networks that can be impacted by the rate, timing, and size of
   feedback packets, as well as the overall volume of feedback bytes.

   The amount of overhead due to congestion control feedback that is
   considered acceptable has to be determined.  RTCP feedback is sent in
   separate packets to RTP data, and this has some cost in terms of
   additional 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
   this still the case for congestion control feedback?  Is there a
   desire to provide more responsive feedback and congestion control,
   possibly with a higher overhead?  Or is lower overhead wanted,
   accepting that this might reduce responsiveness of the congestion
   control algorithm?

   Finally, the details of how much and what data is to be sent in each
   report will affect the frequency and/or overhead of feedback.  There
   is a fundamental trade-off that the more frequently feedback packets
   are sent, the less data can be included in each packet to keep the
   overhead constant.  Does the congestion control need a high rate but
   simple feedback (e.g., like TCP acknowledgements), or is it
   acceptable to send more complex feedback less often?  Is it useful
   for the congestion control to receive frequent feedback, perhaps to
   provide more accurate round-trip time estimates, or to provide
   robustness in case feedback packets are lost, even if the media
   sending rate cannot quickly be changed?  Or is low-rate feedback,
   resulting in slowly responsive changes to the sending rate,
   acceptable?  Different combinations of the congestion control
   algorithm and media codec might require different trade-offs, and the
   correct trade-off for interactive, self-paced, real-time multimedia
   traffic might not be the same as that for TCP congestion control.

3.  What Feedback is Achievable with RTCP?

   The following sections illustrate how the RTCP congestion control
   feedback report [RFC8888] can be used in different scenarios and
   illustrate the overheads of this approach.

3.1.  Scenario 1: Voice Telephony

   In many ways, point-to-point voice telephony is the simplest scenario
   for congestion control, since there is only a single media stream to
   control.  It's complicated, however, by severe bandwidth constraints
   on the feedback, to keep the overhead manageable.

   Assume a two-party, point-to-point VoIP call, using RTP over UDP/IP.
   A rate-adaptive speech codec, such as Opus, is used, encoded into RTP
   packets in frames of a duration of Tf seconds (Tf = 0.020 s in many
   cases, but values up to 0.060 s are not uncommon).  The congestion
   control algorithm requires feedback every Nr frames, i.e., every Nr *
   Tf seconds, to ensure effective control.  Both parties in the call
   send speech data or comfort noise with sufficient frequency that they
   are counted as senders for the purpose of the RTCP reporting interval
   calculation.

   RTCP feedback packets can be full (compound) RTCP feedback packets or
   reduced-size RTCP packets [RFC5506].  A compound RTCP packet is sent
   once for every Nrs reduced-size RTCP packets.

   Compound RTCP packets contain a Sender Report (SR) packet, a Source
   Description (SDES) packet, and an RTP Congestion Control Feedback
   (CCFB) packet [RFC8888].  Reduced-size RTCP packets contain only the
   CCFB packet.  Since each participant sends only a single RTP media
   stream, the extensions for RTCP report aggregation [RFC8108] and
   reporting group optimization [RFC8861] are not used.

   Within each compound RTCP packet, the SR packet will contain a sender
   information block (28 octets) and a single reception report block (24
   octets), for a total of 52 octets.  A minimal SDES packet will
   contain a header (4 octets), a single chunk containing a
   synchronization source (SSRC) (4 octets), and a CNAME item, and if
   the recommendations for choosing the CNAME [RFC7022] are followed,
   the CNAME item will comprise a 2-octet header, 16 octets of data, and
   2 octets of padding, for a total SDES packet size of 28 octets.  The
   CCFB packets contain 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 will include 4 octets of trailer, followed by an 80-bit
   (10-octet) authentication tag if HMAC-SHA1 authentication is used.
   If IPv4 is used, with no IP options, the UDP/IP header will be 28
   octets in size.  This gives a total compound RTCP packet size of Sc =
   142 + (2 * Nr) octets.

   The reduced-size RTCP packets will comprise just the CCFB packet,
   SRTCP trailer and authentication tag, and a UDP/IP header.  It can be
   seen that these packets will be Srs = 62 + (2 * Nr) octets in size.

   The RTCP reporting interval calculation (Sections 6.2 and 6.3 of
   [RFC3550] and [RFC4585]) for a two-party session where both
   participants are senders reduces to:

      Trtcp = n * Srtcp / Brtcp

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

   To ensure an RTCP report containing congestion control feedback is
   sent after every Nr frames of audio, it is necessary to set the RTCP
   reporting interval to Trtcp = Nr * Tf, which when substituted into
   the previous, gives Nr * Tf = n * Srtcp / Brtcp.  Solving this to
   give the RTCP bandwidth (Brtcp) and expanding the definition of Srtcp
   gives:

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

   If we assume every report is a compound RTCP packet (i.e., Nrs = 0),
   the frame duration is Tf = 20 ms, and an RTCP report is sent for
   every second frame (i.e., 25 RTCP reports per second), this gives an
   RTCP feedback bandwidth of Brtcp = 57 kbps.  Increasing the frame
   duration or reducing the frequency of reports will reduce the RTCP
   bandwidth, as shown in Table 1.

              +==============+=============+================+
              | 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 final row of Table 1 (60 ms frames, reporting every 16 frames)
   sends RTCP reports once per second, giving an RTCP bandwidth overhead
   of 2.8 kbps.

   The overhead can be reduced by sending some reports in reduced-size
   RTCP packets [RFC5506].  For example, if we alternate compound and
   reduced-size RTCP packets, i.e., Nrs = 1, the calculation gives the
   results shown 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)

   The RTCP bandwidth needed for 60 ms frames, reporting every 16 frames
   (once per second), can be seen to drop to 2.2 kbps.  This calculation
   can be repeated for other patterns of compound and reduced-size RTCP
   packets, feedback frequency, and frame duration, as needed.

      |  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 use of IPv6 will increase the overhead by 20 octets per packet,
   due to the increased size of the IPv6 header compared to IPv4,
   assuming no IP options in either case.  This increases the size of
   compound packets to Sc = 162 + (2 * Nr) octets and reduced-size
   packets to Srs = 82 + (2 * Nr).  Rerunning the calculations from
   Table 1 with these packet sizes gives the results shown in Table 3.
   As can be seen, there is a significant increase in overhead due to
   the use of 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

   Repeating the calculations from Table 2 using IPv6 gives the results
   shown in Table 4.  As can be seen, the overhead still increases with
   IPv6 when a mix of compound and reduced-size reports is used, but the
   effect is less pronounced 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

   Consider a point-to-point video call between two end systems.  There
   will be four RTP flows in this scenario (two audio and two video),
   with all four flows being active for essentially all the time (the
   audio flows will likely use voice activity detection and comfort
   noise to reduce the packet rate during silent periods, but this does
   not cause the transmissions to stop).

   Assume all four flows are sent in a single RTP session, each using a
   separate SSRC.  The RTCP reports from the co-located audio and video
   SSRCs at each end point are aggregated [RFC8108], the optimizations
   in [RFC8861] are used, and RTCP congestion control feedback is sent
   [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] reduces to:

      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 the amount of
   feedback sent in each RTCP packet, the number of members in the
   session, the size of source description (RTCP SDES) information sent,
   and the amount of congestion control feedback sent in each packet.

   As a baseline, each RTCP packet will be a compound RTCP packet that
   contains an aggregate of a compound RTCP packet generated by the
   video SSRC and a compound RTCP packet generated by the audio SSRC.
   When the RTCP reporting group extensions are used, one of these SSRCs
   will be a reporting SSRC, to which the other SSRC will have delegated
   its reports.  No reduced-size RTCP packets are sent.

   The aggregated compound RTCP packet from the non-reporting SSRC will
   contain an RTCP SR packet, an RTCP SDES packet, and an RTCP Reporting
   Group Reporting Sources (RGRS) packet.  The RTCP SR packet contains
   the 28-octet UDP/IP header (assuming IPv4 with no options) and sender
   information but no report blocks (since the reporting is delegated).
   The RTCP SDES packet will comprise 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 will be 18 octets in size and will be followed by one octet of
   padding and one terminating null octet to align the SDES packet to a
   32-bit boundary ([RFC3550], Section 6.5), making the SDES packet 28
   octets in size.  The RTCP RGRS packet will be 12 octets in size.
   This gives a total of 28 + 28 + 12 = 68 octets.

   The aggregated compound RTCP packet from the reporting SSRC will
   contain an RTCP SR packet, an RTCP SDES packet, and an RTCP
   congestion control feedback packet.  The RTCP SR packet will contain
   two report blocks, one for each of the remote SSRCs (the report for
   the other local SSRC is suppressed by the reporting group extension),
   for a total of 28 + (2 * 24) = 76 octets.  The RTCP SDES packet will
   comprise 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 will be 18
   octets in size.  The RGRP chunk similarly comprises 18 octets, the
   terminating chunk is comprised of 1 octet, and 3 octets of padding
   are needed, for a total of 48 octets.  The RTCP congestion control
   feedback (CCFB) report comprises an 8-octet RTCP header and SSRC, a
   4-octet report timestamp, and 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 needed; that is, 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 contains 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 is therefore 262 + (2 * Nv) + (2 * Na) octets.  Since the
   aggregate RTCP packet contains reports from two SSRCs, the RTCP
   packet size is halved before use [RFC8108].  Accordingly, the size of
   the RTCP packets is:

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

   How many RTP packets does the RTCP XR congestion control feedback
   packet, included in these compound RTCP packets, report on?  That is,
   what are the values of Nv and Na?  This 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 simplify the calculation, assume it is desired to send one RTCP
   report for each frame of video received (i.e., Trtcp = 1 / Rf) and to
   include a congestion control feedback packet in each report.  Assume
   that video has a constant bit rate and frame rate and that each frame
   of video has to fit into a 1500-octet MTU.  Further, assume that the
   audio takes negligible bandwidth and that the audio framing interval
   can be varied within reasonable bounds, so that an integral number of
   audio frames align 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.

   It can be seen that, for example, with a data rate of 1024 kbps and a
   video sent at 30 frames per second, the RTCP congestion control
   feedback report sent for each video frame will include reports on 3
   video packets and 2 audio packets.  The RTCP bandwidth needed to
   sustain this reporting rate is 127.5 kbps (12% of the data rate).
   This assumes an audio framing interval of 16.67 ms, so that 2 audio
   packets are sent for each video frame.

   +===========+==========+=============+=============+===============+
   | 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 allow the SR and SDES
   packets to be omitted from some reports.  These reduced-size RTCP
   packets would contain an RTCP RGRS packet from the non-reporting SSRC
   and an RTCP SDES RGRP packet and a congestion control feedback packet
   from the reporting SSRC.  This will be 12 + 28 + 12 + 8 + (2 * Nv) +
   8 + (2 * Na) octets, plus the SRTCP trailer and authentication tag
   and a UDP/IP header.  That is, the size of the reduced-size packets
   would be (110 + (2 * Nv) + (2 * Na)) / 2 octets.  Repeating the
   analysis above, but alternating compound and reduced-size reports,
   gives the results shown 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 reduction in the
   needed RTCP bandwidth and can be combined with reporting every few
   frames, rather than every frame.  Overall, it is clear that the RTCP
   overhead can be reasonable across the range of data and frame rates
   if RTCP is configured carefully.

   As discussed in Section 3.1, the reporting overhead will increase if
   IPv6 is used, due to the increased size of the IPv6 header.  Table 7
   shows the overhead in this case, compared to Table 6.  As can be
   seen, the increase in overhead due to IPv6 rapidly becomes less
   significant as the data rate increases.

   +===========+==========+=============+=============+===============+
   | 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

   Practical systems will generally send some non-media traffic on the
   same path as the media traffic.  This can include Session Traversal
   Utilities for NAT (STUN) / Traversal Using Relays around NAT (TURN)
   packets to keep alive NAT bindings [RFC8445], WebRTC data channel
   packets [RFC8831], etc.  Such traffic also needs congestion control,
   but the means by which this is achieved is out of the scope of this
   memo.

   RTCP, as it is currently specified, cannot be used to send per-packet
   congestion feedback with reasonable overhead.

   RTCP can, however, be used to send congestion feedback on each frame
   of video sent, provided the session bandwidth exceeds a couple of
   megabits per second (the exact rate depends on the number of session
   participants, the RTCP bandwidth fraction, what RTCP extensions are
   enabled, and how much detail of feedback is needed).  For lower-rate
   sessions, the overhead of reporting on every frame becomes high but
   can be reduced to something reasonable by sending reports once per N
   frames (e.g., every second frame) or by sending reduced-size RTCP
   reports in between the regular reports.  The improved compression of
   new video codecs exacerbates the reporting overhead for a given video
   quality level, although this is to some extent countered by the use
   of higher-quality video over time.

   If it is desired 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 within the limitations of RTCP.  The provided
   feedback will be more detailed than just an acknowledgement, however,
   and will provide a loss bitmap, relative arrival time, and received
   Explicit Congestion Notification (ECN) marks for each packet sent.
   This will allow congestion control that is effective, if slowly
   responsive, to be implemented (there is guidance on providing
   effective congestion control in Section 3.1 of [RFC8085]).

   The format described in [RFC8888] seems sufficient for the needs of
   congestion control feedback.  There is little point optimizing this
   format; the main overhead comes from the UDP/IP headers and the other
   RTCP packets included in the compound packets and can be lowered by
   using the extensions described in [RFC5506] and sending reports less
   frequently.  The use of header compression [RFC2508] [RFC3545]
   [RFC5795] can also be beneficial.

   Further study of the scenarios of interest is needed to ensure that
   the analysis presented is applicable to other media topologies
   [RFC7667] and to sessions with different data rates and sizes of
   membership.

5.  Security Considerations

   An attacker that can modify or spoof RTCP congestion control feedback
   packets can manipulate the sender behavior to cause denial of
   service.  This can be prevented by authentication and integrity
   protection of RTCP packets, for example, using the secure RTP profile
   [RFC3711] [RFC5124] or other means as discussed in [RFC7201].

6.  IANA Considerations

   This document has no IANA actions.

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>.

Acknowledgements

   Thanks 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 members of the RMCAT
   feedback design team for their feedback.

Author's Address

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