Skip to main content

RTP Control Protocol (RTCP) Feedback for Congestion Control

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8888.
Authors Zaheduzzaman Sarker , Colin Perkins , Varun Singh , Michael A. Ramalho
Last updated 2020-09-24 (Latest revision 2020-09-02)
Replaces draft-dt-rmcat-feedback-message
RFC stream Internet Engineering Task Force (IETF)
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Associated WG milestone
Jun 2019
Submit Feedback Mechanism for RTP Congestion Control for Proposed Standard
Document shepherd Dr. Bernard D. Aboba
Shepherd write-up Show Last changed 2020-07-23
IESG IESG state Became RFC 8888 (Proposed Standard)
Consensus boilerplate Yes
Telechat date (None)
Needs a YES. Needs 5 more YES or NO OBJECTION positions to pass.
Responsible AD Barry Leiba
Send notices to, Bernard Aboba <>
IANA IANA review state IANA OK - Actions Needed
IANA expert review state Expert Reviews OK
IETF RMCAT Working Group                                       Z. Sarker
Internet-Draft                                               Ericsson AB
Intended status: Standards Track                              C. Perkins
Expires: March 6, 2021                             University of Glasgow
                                                                V. Singh
                                                              M. Ramalho
                                                       September 2, 2020

      RTP Control Protocol (RTCP) Feedback for Congestion Control


   This document describes an RTCP feedback message intended to enable
   congestion control for interactive real-time traffic using RTP.  The
   feedback message is designed for use with a sender-based congestion
   control algorithm, in which the receiver of an RTP flow sends RTCP
   feedback packets to the sender containing the information the sender
   needs to perform congestion control.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 6, 2021.

Copyright Notice

   Copyright (c) 2020 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
   ( in effect on the date of
   publication of this document.  Please review these documents

Sarker, et al.            Expires March 6, 2021                 [Page 1]
Internet-Draft     Congestion Control Feedback in RTCP    September 2020

   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  RTCP Feedback for Congestion Control  . . . . . . . . . . . .   3
     3.1.  RTCP Congestion Control Feedback Report . . . . . . . . .   4
   4.  Feedback Frequency and Overhead . . . . . . . . . . . . . . .   7
   5.  Response to Loss of Feedback Packets  . . . . . . . . . . . .   8
   6.  SDP Signalling  . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  Relation to RFC 6679  . . . . . . . . . . . . . . . . . . . .   9
   8.  Design Rationale  . . . . . . . . . . . . . . . . . . . . . .   9
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  12
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     12.2.  Informative References . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   For interactive real-time traffic, such as video conferencing flows,
   the typical protocol choice is the Real-time Transport Protocol (RTP)
   [RFC3550] running over the User Datagram Protocol (UDP).  RTP does
   not provide any guarantee of Quality of Service (QoS), reliability,
   or timely delivery, and expects the underlying transport protocol to
   do so.  UDP alone certainly does not meet that expectation.  However,
   the RTP Control Protocol (RTCP) [RFC3550] provides a mechanism by
   which the receiver of an RTP flow can periodically send transport and
   media quality metrics to the sender of that RTP flow.  This
   information can be used by the sender to perform congestion control.
   In the absence of standardized messages for this purpose, designers
   of congestion control algorithms have developed proprietary RTCP
   messages that convey only those parameters needed for their
   respective designs.  As a direct result, the different congestion
   control designs are not interoperable.  To enable algorithm evolution
   as well as interoperability across designs (e.g., different rate
   adaptation algorithms), it is highly desirable to have generic
   congestion control feedback format.

   To help achieve interoperability for unicast RTP congestion control,
   this memo proposes a common RTCP feedback packet format that can be

Sarker, et al.            Expires March 6, 2021                 [Page 2]
Internet-Draft     Congestion Control Feedback in RTCP    September 2020

   used by NADA [RFC8698], SCReAM [RFC8298], Google Congestion Control
   [I-D.ietf-rmcat-gcc] and Shared Bottleneck Detection [RFC8382], and
   hopefully also by future RTP congestion control algorithms.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   In addition the terminology defined in [RFC3550], [RFC3551],
   [RFC3611], [RFC4585], and [RFC5506] applies.

3.  RTCP Feedback for Congestion Control

   Based on an analysis of NADA [RFC8698], SCReAM [RFC8298], Google
   Congestion Control [I-D.ietf-rmcat-gcc] and Shared Bottleneck
   Detection [RFC8382], the following per-RTP packet congestion control
   feedback information has been determined to be necessary:

   o  RTP sequence number: The receiver of an RTP flow needs to feed the
      sequence numbers of the received RTP packets back to the sender,
      so the sender can determine which packets were received and which
      were lost.  Packet loss is used as an indication of congestion by
      many congestion control algorithms.

   o  Packet Arrival Time: The receiver of an RTP flow needs to feed the
      arrival time of each RTP packet back to the sender.  Packet delay
      and/or delay variation (jitter) is used as a congestion signal by
      some congestion control algorithms.

   o  Packet Explicit Congestion Notification (ECN) Marking: If ECN
      [RFC3168], [RFC6679] is used, it is necessary to feed back the
      2-bit ECN mark in received RTP packets, indicating for each RTP
      packet whether it is marked not-ECT, ECT(0), ECT(1), or ECN-CE.
      If the path used by the RTP traffic is ECN capable the sender can
      use Congestion Experienced (ECN-CE) marking information as a
      congestion control signal.

   Every RTP flow is identified by its Synchronization Source (SSRC)
   identifier.  Accordingly, the RTCP feedback format needs to group its
   reports by SSRC, sending one report block per received SSRC.

   As a practical matter, we note that host operating system (OS)
   process interruptions can occur at inopportune times.  Accordingly,
   recording RTP packet send times at the sender, and the corresponding

Sarker, et al.            Expires March 6, 2021                 [Page 3]
Internet-Draft     Congestion Control Feedback in RTCP    September 2020

   RTP packet arrival times at the receiver, needs to be done with
   deliberate care.  This is because the time duration of host OS
   interruptions can be significant relative to the precision desired in
   the one-way delay estimates.  Specifically, the send time needs to be
   recorded at the last opportunity prior to transmitting the RTP packet
   at the sender, and the arrival time at the receiver needs to be
   recorded at the earliest available opportunity.

3.1.  RTCP Congestion Control Feedback Report

   Congestion control feedback can be sent as part of a regular
   scheduled RTCP report, or in an RTP/AVPF early feedback packet.  If
   sent as early feedback, congestion control feedback MAY be sent in a
   non-compound RTCP packet [RFC5506] if the RTP/AVPF profile [RFC4585]
   or the RTP/SAVPF profile [RFC5124] is used.

   Irrespective of how it is transported, the congestion control
   feedback is sent as a Transport Layer Feedback Message (RTCP packet
   type 205).  The format of this RTCP packet is shown in Figure 1:

Sarker, et al.            Expires March 6, 2021                 [Page 4]
Internet-Draft     Congestion Control Feedback in RTCP    September 2020

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       |V=2|P| FMT=CCFB |   PT = 205   |          length               |
       |                 SSRC of RTCP packet sender                    |
       |                   SSRC of 1st RTP Stream                      |
       |          begin_seq            |          num_reports          |
       |L|ECN|  Arrival time offset    | ...                           .
       .                                                               .
       .                                                               .
       .                                                               .
       |                   SSRC of nth RTP Stream                      |
       |          begin_seq            |          num_reports          |
       |L|ECN|  Arrival time offset    | ...                           |
       .                                                               .
       .                                                               .
       |                 Report Timestamp (32bits)                     |

         Figure 1: RTCP Congestion Control Feedback Packet Format

   The first eight octets comprise a standard RTCP header, with PT=205
   and FMT=CCFB indicating that this is a congestion control feedback
   packet, and with the SSRC set to that of the sender of the RTCP
   packet.  (NOTE TO RFC EDITOR: please replace CCFB here and in the
   above diagram with the IANA assigned RTCP feedback packet type, and
   remove this note)

   Section 6.1 of [RFC4585] requires the RTCP header to be followed by
   the SSRC of the RTP flow being reported upon.  Accordingly, the RTCP
   header is followed by a report block for each SSRC from which RTP
   packets have been received, followed by a Report Timestamp.

   Each report block begins with the SSRC of the received RTP Stream on
   which it is reporting.  Following this, the report block contains a
   16-bit packet metric block for each RTP packet with sequence number
   in the range begin_seq to begin_seq+num_reports inclusive (calculated
   using arithmetic modulo 65536 to account for possible sequence number
   wrap-around).  If the number of 16-bit packet metric blocks included

Sarker, et al.            Expires March 6, 2021                 [Page 5]
Internet-Draft     Congestion Control Feedback in RTCP    September 2020

   in the report block is not a multiple of two, then 16 bits of zero
   padding MUST be added after the last packet metric block, to align
   the end of the packet metric blocks with the next 32 bit boundary.
   The value of num_reports MAY be zero, indicating that there are no
   packet metric blocks included for that SSRC.  Each report block MUST
   NOT include more than 16384 packet metric blocks (i.e., it MUST NOT
   report on more than one quarter of the sequence number space in a
   single report).

   The contents of each 16-bit packet metric block comprises the L, ECN,
   and ATO fields as follows:

   o  L (1 bit): is a boolean to indicate if the packet was received. 0
      represents that the packet was not yet received and all the
      subsequent bits (ECN and ATO) are also set to 0.  1 represents
      that the packet was received and the subsequent bits in the block
      need to be parsed.

   o  ECN (2 bits): is the echoed ECN mark of the packet.  These are set
      to 00 if not received, or if ECN is not used.

   o  Arrival time offset (ATO, 13 bits): is the arrival time of the RTP
      packet at the receiver, as an offset before the time represented
      by the Report Timestamp (RTS) field of this RTCP congestion
      control feedback report.  The ATO field is in units of 1/1024
      seconds (this unit is chosen to give exact offsets from the RTS
      field) so, for example, an ATO value of 512 indicates that the
      corresponding RTP packet arrived exactly half a second before the
      time instant represented by the RTS field.  If the measured value
      is greater than 8189/1024 seconds (the value that would be coded
      as 0x1FFD), the value 0x1FFE MUST be reported to indicate an over-
      range measurement.  If the measurement is unavailable, or if the
      arrival time of the RTP packet is after the time represented by
      the RTS field, then an ATO value of 0x1FFF MUST be reported for
      the packet.

   The RTCP congestion control feedback report packet concludes with the
   Report Timestamp field (RTS, 32 bits).  This denotes the time instant
   on which this packet is reporting, and is the instant from which the
   arrival time offset values are calculated.  The value of RTS field is
   derived from the same clock used to generate the NTP timestamp field
   in RTCP Sender Report (SR) packets.  It is formatted as the middle 32
   bits of an NTP format timestamp, as described in Section 4 of

   RTCP congestion control feedback packets SHOULD include a report
   block for every active SSRC.  The sequence number ranges reported on
   in consecutive reports for a given SSRC will generally be contiguous,

Sarker, et al.            Expires March 6, 2021                 [Page 6]
Internet-Draft     Congestion Control Feedback in RTCP    September 2020

   but overlapping reports MAY be sent (and need to be sent in cases
   where RTP packet reordering occurs across the boundary between
   consecutive reports).  If reports covering overlapping sequence
   number ranges are sent, information in later reports updates that in
   sent previous reports for RTP packets included in both reports.  If
   an RTP packet was reported as received in one report, that packet
   MUST also be reported as received in any overlapping reports sent
   later that cover its sequence number range.

   RTCP congestion control feedback packets can be large if they are
   sent infrequently relative to the number of RTP data packets.  If an
   RTCP congestion control feedback packet is too large to fit within
   the path MTU, its sender SHOULD split it into multiple feedback
   packets.  The RTCP reporting interval SHOULD be chosen such that
   feedback packets are sent often enough that they are small enough to
   fit within the path MTU ([I-D.ietf-rmcat-rtp-cc-feedback] discusses
   how to choose the reporting interval; specifications for RTP
   congestion control algorithms can also provide guidance).

   If duplicate copies of a particular RTP packet are received, then the
   arrival time of the first copy to arrive MUST be reported.  If any of
   the copies of the duplicated packet are ECN-CE marked, then an ECN-CE
   mark MUST be reported that for packet; otherwise the ECN mark of the
   first copy to arrive is reported.

   If no packets are received from an SSRC in a reporting interval, a
   report block MAY be sent with begin_seq set to the highest sequence
   number previously received from that SSRC and num_reports set to zero
   (or, the report can simply to omitted).  The corresponding SR/RR
   packet will have a non-increased extended highest sequence number
   received field that will inform the sender that no packets have been
   received, but it can ease processing to have that information
   available in the congestion control feedback reports too.

   A report block indicating that certain RTP packets were lost is not
   to be interpreted as a request to retransmit the lost packets.  The
   receiver of such a report might choose to retransmit such packets,
   provided a retransmission payload format has been negotiated, but
   there is no requirement that it do so.

4.  Feedback Frequency and Overhead

   There is a trade-off between speed and accuracy of reporting, and the
   overhead of the reports.  [I-D.ietf-rmcat-rtp-cc-feedback] discusses
   this trade-off, suggests desirable RTCP feedback rates, and provides
   guidance on how to configure the RTCP bandwidth fraction, etc., to
   make appropriate use of the reporting block described in this memo.

Sarker, et al.            Expires March 6, 2021                 [Page 7]
Internet-Draft     Congestion Control Feedback in RTCP    September 2020

   Specifications for RTP congestion control algorithms can also provide

   It is generally understood that congestion control algorithms work
   better with more frequent feedback.  However, RTCP bandwidth and
   transmission rules put some upper limits on how frequently the RTCP
   feedback messages can be sent from an RTP receiver to the RTP sender.
   In many cases, sending feedback once per frame is an upper bound
   before the reporting overhead becomes excessive, although this will
   depend on the media rate and more frequent feedback might be needed
   with high-rate media flows [I-D.ietf-rmcat-rtp-cc-feedback].
   Analysis [feedback-requirements] has also shown that some candidate
   congestion control algorithms can operate with less frequent
   feedback, using a feedback interval range of 50-200ms.  Applications
   need to negotiate an appropriate congestion control feedback interval
   at session setup time, based on the choice of congestion control
   algorithm, the expected media bit rate, and the acceptable feedback

5.  Response to Loss of Feedback Packets

   Like all RTCP packets, RTCP congestion control feedback packets might
   be lost.  All RTP congestion control algorithms MUST specify how they
   respond to the loss of feedback packets.

   If only a single congestion control feedback packet is lost, an
   appropriate response is to assume that the level of congestion has
   remained roughly the same as the previous report.  However, if
   multiple consecutive congestion control feedback packets are lost,
   then the sender SHOULD rapidly reduce its sending rate as this likely
   indicates a path failure.  The RTP circuit breaker [RFC8083] provides
   further guidance.

6.  SDP Signalling

   A new "ack" feedback parameter, "ccfb", is defined for use with the
   "a=rtcp-fb:" SDP extension to indicate the use of the RTP Congestion
   Control feedback packet format defined in Section 3.  The ABNF
   definition of this SDP parameter extension is:

           rtcp-fb-ack-param = <See Section 4.2 of [RFC4585]>
           rtcp-fb-ack-param =/ ccfb-par
           ccfb-par          = SP "ccfb"

   The payload type used with "ccfb" feedback MUST be the wildcard type
   ("*").  This implies that the congestion control feedback is sent for
   all payload types in use in the session, including any FEC and

Sarker, et al.            Expires March 6, 2021                 [Page 8]
Internet-Draft     Congestion Control Feedback in RTCP    September 2020

   retransmission payload types.  An example of the resulting SDP
   attribute is:

           a=rtcp-fb:* ack ccfb

   The offer/answer rules for these SDP feedback parameters are
   specified in Section 4.2 of the RTP/AVPF profile [RFC4585].

   An SDP offer might indicate support for both the congestion control
   feedback mechanism specified in this memo and one or more alternative
   congestion control feedback mechanisms that offer substantially the
   same semantics.  In this case, the answering party SHOULD include
   only one of the offered congestion control feedback mechanisms in its
   answer.  If a re-invite offering the same set of congestion control
   feedback mechanisms is received, the generated answer SHOULD choose
   the same congestion control feedback mechanism as in the original
   answer where possible.

   When the SDP BUNDLE extension
   [I-D.ietf-mmusic-sdp-bundle-negotiation] is used for multiplexing,
   the "a=rtcp-fb:" attribute has multiplexing category IDENTICAL-PER-PT

7.  Relation to RFC 6679

   Use of Explicit Congestion Notification (ECN) with RTP is described
   in [RFC6679].  That specifies how to negotiate the use of ECN with
   RTP, and defines an RTCP ECN Feedback Packet to carry ECN feedback
   reports.  It uses an SDP "a=ecn-capaable-rtp:" attribute to negotiate
   use of ECN, and the "a=rtcp-fb:" attributes with the "nack" parameter
   "ecn" to negotiate the use of RTCP ECN Feedback Packets.

   The RTCP ECN Feedback Packet is not useful when ECN is used with the
   RTP Congestion Control Feedback Packet defined in this memo since it
   provides duplicate information.  Accordingly, when congestion control
   feedback is to be used with RTP and ECN, the SDP offer generated MUST
   include an "a=ecn-capable-rtp:" attribute to negotiate ECN support,
   along with an "a=rtcp-fb:" attribute with the "ack" parameter "ccfb"
   to indicate that the RTP Congestion Control Feedback Packet is to be
   used for feedback.  The "a=rtcp-fb:" attribute MUST NOT include the
   "nack" parameter "ecn", so the RTCP ECN Feedback Packet will not be

8.  Design Rationale

   The primary function of RTCP SR/RR packets is to report statistics on
   the reception of RTP packets.  The reception report blocks sent in
   these packets contain information about observed jitter, fractional

Sarker, et al.            Expires March 6, 2021                 [Page 9]
Internet-Draft     Congestion Control Feedback in RTCP    September 2020

   packet loss, and cumulative packet loss.  It was intended that this
   information could be used to support congestion control algorithms,
   but experience has shown that it is not sufficient for that purpose.
   An efficient congestion control algorithm requires more fine-grained
   information on per-packet reception quality than is provided by SR/RR
   packets to react effectively.  The feedback format defined in this
   memo provides such fine-grained feedback.

   Several other RTCP extensions also provide more detailed feedback
   than SR/RR packets:

   TMMBR:  The Codec Control Messages for the RTP/AVPF profile [RFC5104]
      include a Temporary Maximum Media Bit Rate (TMMBR) message.  This
      is used to convey a temporary maximum bit rate limitation from a
      receiver of RTP packets to their sender.  Even though it was not
      designed to replace congestion control, TMMBR has been used as a
      means to do receiver based congestion control where the session
      bandwidth is high enough to send frequent TMMBR messages,
      especially when used with non-compound RTCP packets [RFC5506].
      This approach requires the receiver of the RTP packets to monitor
      their reception, determine the level of congestion, and recommend
      a maximum bit rate suitable for current available bandwidth on the
      path; it also assumes that the RTP sender can/will respect that
      bit rate.  This is the opposite of the sender-based congestion
      control approach suggested in this memo, so TMMBR cannot be used
      to convey the information needed for a sender-based congestion
      control.  TMMBR could, however, be viewed a complementary
      mechanism that can inform the sender of the receiver's current
      view of acceptable maximum bit rate.  The Received Estimated
      Maximum Bit-rate (REMB) mechanism [I-D.alvestrand-rmcat-remb]
      provides similar feedback.

   RTCP Extended Reports (XR):  Numerous RTCP extended report (XR)
      blocks have been defined to report details of packet loss, arrival
      times [RFC3611], delay [RFC6843], and ECN marking [RFC6679].  It
      is possible to combine several such XR blocks into a compound RTCP
      packet, to report the detailed loss, arrival time, and ECN marking
      marking information needed for effective sender-based congestion
      control.  However, the result has high overhead both in terms of
      bandwidth and complexity, due to the need to stack multiple

   Transport-wide Congestion Control:  The format defined in this memo
      provides individual feedback on each SSRC.  An alternative is to
      add a header extension to each RTP packet, containing a single,
      transport-wide, packet sequence number, then have the receiver
      send RTCP reports giving feedback on these additional sequence
      numbers [I-D.holmer-rmcat-transport-wide-cc-extensions].  Such an

Sarker, et al.            Expires March 6, 2021                [Page 10]
Internet-Draft     Congestion Control Feedback in RTCP    September 2020

      approach adds the per-packet overhead of the header extension (8
      octets per packet in the referenced format), but reduces the size
      of the feedback packets, and can simplify the rate calculation at
      the sender if it maintains a single rate limit that applies to all
      RTP packets sent irrespective of their SSRC.  Equally, the use of
      transport-wide feedback makes it more difficult to adapt the
      sending rate, or respond to lost packets, based on the reception
      and/or loss patterns observed on a per-SSRC basis (for example, to
      perform differential rate control and repair for audio and video
      flows, based on knowledge of what packets from each flow were
      lost).  Transport-wide feedback is also a less natural fit with
      the wider RTP framework, which makes extensive use of per-SSRC
      sequence numbers and feedback.

   Considering these issues, we believe it appropriate to design a new
   RTCP feedback mechanism to convey information for sender-based
   congestion control algorithms.  The new congestion control feedback
   RTCP packet described in Section 3 provides such a mechanism.

9.  Acknowledgements

   This document is based on the outcome of a design team discussion in
   the RTP Media Congestion Avoidance Techniques (RMCAT) working group.
   The authors would like to thank David Hayes, Stefan Holmer, Randell
   Jesup, Ingemar Johansson, Jonathan Lennox, Sergio Mena, Nils
   Ohlmeier, Magnus Westerlund, and Xiaoqing Zhu for their valuable

10.  IANA Considerations

   The IANA is requested to register one new RTP/AVPF Transport-Layer
   Feedback Message in the table for FMT values for RTPFB Payload Types
   [RFC4585] as defined in Section 3.1:

         Name:      CCFB
         Long name: RTP Congestion Control Feedback
         Value:     (to be assigned by IANA)
         Reference: (RFC number of this document, when published)

   The IANA is also requested to register one new SDP "rtcp-fb"
   attribute "ack" parameter, "ccfb", in the SDP ("ack" and "nack"
   Attribute Values) registry:

         Value name:  ccfb
         Long name:   Congestion Control Feedback
         Usable with: ack
         Reference:   (RFC number of this document, when published)

Sarker, et al.            Expires March 6, 2021                [Page 11]
Internet-Draft     Congestion Control Feedback in RTCP    September 2020

11.  Security Considerations

   The security considerations of the RTP specification [RFC3550], the
   applicable RTP profile (e.g., [RFC3551], [RFC3711], or [RFC4585]),
   and the RTP congestion control algorithm that is in use (e.g.,
   [RFC8698], [RFC8298], [I-D.ietf-rmcat-gcc], or [RFC8382]) apply.

   A receiver that intentionally generates inaccurate RTCP congestion
   control feedback reports might be able trick the sender into sending
   at a greater rate than the path can support, thereby causing
   congestion on the path.  This will negatively impact the quality of
   experience of that receiver.  Since RTP is an unreliable transport, a
   sender can intentionally leave a gap in the RTP sequence number space
   without causing harm, to check that the receiver is correctly
   reporting losses.

   An on-path attacker that can modify RTCP congestion control feedback
   packets can change the reports to trick the sender into sending at
   either an excessively high or excessively low rate, leading to denial
   of service.  The secure RTCP profile [RFC3711] can be used to
   authenticate RTCP packets to protect against this attack.

12.  References

12.1.  Normative References

              Holmberg, C., Alvestrand, H., and C. Jennings,
              "Negotiating Media Multiplexing Using the Session
              Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
              negotiation-54 (work in progress), December 2018.

              Nandakumar, S., "A Framework for SDP Attributes when
              Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-19
              (work in progress), August 2020.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [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,

Sarker, et al.            Expires March 6, 2021                [Page 12]
Internet-Draft     Congestion Control Feedback in RTCP    September 2020

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

   [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,

   [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,

   [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,

   [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,

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

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

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

   [RFC8083]  Perkins, C. and V. Singh, "Multimedia Congestion Control:
              Circuit Breakers for Unicast RTP Sessions", RFC 8083,
              DOI 10.17487/RFC8083, March 2017,

Sarker, et al.            Expires March 6, 2021                [Page 13]
Internet-Draft     Congestion Control Feedback in RTCP    September 2020

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <>.

12.2.  Informative References

              "RMCAT Feedback Requirements",

              Alvestrand, H., "RTCP message for Receiver Estimated
              Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in
              progress), October 2013.

              Holmer, S., Flodman, M., and E. Sprang, "RTP Extensions
              for Transport-wide Congestion Control", draft-holmer-
              rmcat-transport-wide-cc-extensions-01 (work in progress),
              October 2015.

              Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S.
              Mascolo, "A Google Congestion Control Algorithm for Real-
              Time Communication", draft-ietf-rmcat-gcc-02 (work in
              progress), July 2016.

              Perkins, C., "RTP Control Protocol (RTCP) Feedback for
              Congestion Control in Interactive Multimedia Conferences",
              draft-ietf-rmcat-rtp-cc-feedback-05 (work in progress),
              November 2019.

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

   [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,

   [RFC8298]  Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation
              for Multimedia", RFC 8298, DOI 10.17487/RFC8298, December
              2017, <>.

Sarker, et al.            Expires March 6, 2021                [Page 14]
Internet-Draft     Congestion Control Feedback in RTCP    September 2020

   [RFC8382]  Hayes, D., Ed., Ferlin, S., Welzl, M., and K. Hiorth,
              "Shared Bottleneck Detection for Coupled Congestion
              Control for RTP Media", RFC 8382, DOI 10.17487/RFC8382,
              June 2018, <>.

   [RFC8698]  Zhu, X., Pan, R., Ramalho, M., and S. Mena, "Network-
              Assisted Dynamic Adaptation (NADA): A Unified Congestion
              Control Scheme for Real-Time Media", RFC 8698,
              DOI 10.17487/RFC8698, February 2020,

Authors' Addresses

   Zaheduzzaman Sarker
   Ericsson AB
   Torshamnsgatan 21
   Stockholm  164 40

   Phone: +46107173743

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


   Varun Singh
   Annankatu 31-33 C 42
   Helsinki  00100


Sarker, et al.            Expires March 6, 2021                [Page 15]
Internet-Draft     Congestion Control Feedback in RTCP    September 2020

   Michael A. Ramalho
   6310 Watercrest Way Unit 203
   Lakewood Ranch, FL  34202-5122

   Phone: +1 732 832 9723

Sarker, et al.            Expires March 6, 2021                [Page 16]