doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc8888.txt b/doc/rfc/rfc8888.txt
new file mode 100644
index 0000000..7f0985b
--- /dev/null
+++ b/doc/rfc/rfc8888.txt
@@ -0,0 +1,731 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                         Z. Sarker
+Request for Comments: 8888                                   Ericsson AB
+Category: Standards Track                                     C. Perkins
+ISSN: 2070-1721                                    University of Glasgow
+                                                                V. Singh
+                                                            callstats.io
+                                                              M. Ramalho
+                                                           AcousticComms
+                                                            January 2021
+
+
+      RTP Control Protocol (RTCP) Feedback for Congestion Control
+
+Abstract
+
+   An effective RTP congestion control algorithm requires more fine-
+   grained feedback on packet loss, timing, and Explicit Congestion
+   Notification (ECN) marks than is provided by the standard RTP Control
+   Protocol (RTCP) Sender Report (SR) and Receiver Report (RR) packets.
+   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 back to
+   the sender RTCP feedback packets containing the information the
+   sender needs to perform congestion control.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   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).  Further information on
+   Internet Standards is available in 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/rfc8888.
+
+Copyright Notice
+
+   Copyright (c) 2021 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 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.  Terminology
+   3.  RTCP Feedback for Congestion Control
+     3.1.  RTCP Congestion Control Feedback Report
+   4.  Feedback Frequency and Overhead
+   5.  Response to Loss of Feedback Packets
+   6.  SDP Signaling
+   7.  Relationship to RFC 6679
+   8.  Design Rationale
+   9.  IANA Considerations
+   10. Security Considerations
+   11. References
+     11.1.  Normative References
+     11.2.  Informative References
+   Acknowledgements
+   Authors' Addresses
+
+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 a generic
+   congestion control feedback format.
+
+   To help achieve interoperability for unicast RTP congestion control,
+   this memo specifies a common RTCP feedback packet format that can be
+   used by Network-Assisted Dynamic Adaptation (NADA) [RFC8698], Self-
+   Clocked Rate Adaptation for Multimedia (SCReAM) [RFC8298], Google
+   Congestion Control [Google-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",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "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], [RFC4585], and
+   [RFC5506] applies.
+
+3.  RTCP Feedback for Congestion Control
+
+   Based on an analysis of NADA [RFC8698], SCReAM [RFC8298], Google
+   Congestion Control [Google-GCC], and Shared Bottleneck Detection
+   [RFC8382], the following per-RTP packet congestion control feedback
+   information has been determined to be necessary:
+
+   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.
+
+   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.
+
+   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
+      Congestion Experienced (ECN-CE).  ("ECT" stands for "ECN-Capable
+      Transport".)  If the path used by the RTP traffic is ECN capable,
+      the sender can use 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
+   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:
+
+      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=11  |   PT = 205    |          length               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                 SSRC of RTCP packet sender                    |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                   SSRC of 1st RTP Stream                      |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |          begin_seq            |          num_reports          |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |R|ECN|  Arrival time offset    | ...                           .
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     .                                                               .
+     .                                                               .
+     .                                                               .
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                   SSRC of nth RTP Stream                      |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |          begin_seq            |          num_reports          |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |R|ECN|  Arrival time offset    | ...                           |
+     .                                                               .
+     .                                                               .
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                 Report Timestamp (32 bits)                    |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+          Figure 1: RTCP Congestion Control Feedback Packet Format
+
+   The first 8 octets comprise a standard RTCP header, with PT=205 and
+   FMT=11 indicating that this is a congestion control feedback packet,
+   and with the SSRC set to that of the sender of the RTCP packet.
+
+   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 that has a 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 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 0, 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 comprise the R, ECN,
+   and ATO fields as follows:
+
+   Received (R, 1 bit):  A boolean that indicates whether the packet was
+      received.  0 indicates that the packet was not yet received and
+      the subsequent 15 bits (ECN and ATO) in this 16-bit packet metric
+      block are also set to 0 and MUST be ignored.  1 indicates that the
+      packet was received and the subsequent bits in the block need to
+      be parsed.
+
+   ECN (2 bits):  The echoed ECN mark of the packet.  These bits are set
+      to 00 if not received or if ECN is not used.
+
+   Arrival time offset (ATO, 13 bits):  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 the 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 [RFC3550].
+
+   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,
+   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 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.
+   If feedback reports covering overlapping sequence number ranges are
+   sent, information in later feedback reports may update any data sent
+   in previous reports for RTP packets included in both feedback
+   reports.
+
+   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.  ([RTCP-Multimedia-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 for that 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 0
+   (or the report can simply be omitted).  The corresponding Sender
+   Report / Receiver Report (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.  [RTCP-Multimedia-Feedback] discusses this
+   trade-off, suggests desirable RTCP feedback rates, and provides
+   guidance on how to configure, for example, the RTCP bandwidth
+   fraction to make appropriate use of the reporting block described in
+   this memo.  Specifications for RTP congestion control algorithms can
+   also provide guidance.
+
+   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 [RTCP-Multimedia-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-200 ms.  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 bitrate, and the acceptable feedback overhead.
+
+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.
+
+   RTCP packets do not contain a sequence number, so loss of feedback
+   packets has to be inferred based on the time since the last feedback
+   packet.  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 media sender SHOULD rapidly reduce its sending rate as this
+   likely indicates a path failure.  The RTP circuit breaker
+   specification [RFC8083] provides further guidance.
+
+6.  SDP Signaling
+
+   A new "ack" feedback parameter, "ccfb", is defined for use with the
+   "a=rtcp-fb:" Session Description Protocol (SDP) extension to indicate
+   the use of the RTP Congestion Control Feedback Packet format defined
+   in Section 3.  The ABNF definition [RFC5234] 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 Forward Error
+   Correction (FEC) and 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 subsequent offer containing 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 [RFC8843] is used for multiplexing, the
+   "a=rtcp-fb:" attribute has multiplexing category IDENTICAL-PER-PT
+   [RFC8859].
+
+7.  Relationship to RFC 6679
+
+   The use of Explicit Congestion Notification (ECN) with RTP is
+   described in [RFC6679], which 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-capable-rtp:" attribute to
+   negotiate the use of ECN, and the "a=rtcp-fb:" attribute 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.  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 can be used.  The
+   "a=rtcp-fb:" attribute MAY also include the "nack" parameter "ecn" to
+   indicate that the RTCP ECN Feedback Packet is also supported.  If an
+   SDP offer signals support for both RTP Congestion Control Feedback
+   Packets and the RTCP ECN Feedback Packet, the answering party SHOULD
+   signal support for one, but not both, formats in its SDP answer to
+   avoid sending duplicate feedback.
+
+   When using ECN with RTP, the guidelines in Section 7.2 of [RFC6679]
+   MUST be followed to initiate the use of ECN in an RTP session.  The
+   guidelines in Section 7.3 of [RFC6679] regarding the ongoing use of
+   ECN within an RTP session MUST also be followed, with the exception
+   that feedback is sent using the RTCP Congestion Control Feedback
+   Packets described in this memo rather than using RTP ECN Feedback
+   Packets.  Similarly, the guidance in Section 7.4 of [RFC6679] related
+   to detecting failures MUST be followed, with the exception that the
+   necessary information is retrieved from the RTCP Congestion Control
+   Feedback Packets rather than from RTP ECN Feedback Packets.
+
+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
+   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 Stream Bit Rate Request (TMMBR)
+      message.  This is used to convey a temporary maximum bitrate
+      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 bitrate suitable for current available
+      bandwidth on the path; it also assumes that the RTP sender
+      can/will respect that bitrate.  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
+      sender-based congestion control.  TMMBR could, however, be viewed
+      as a complementary mechanism that can inform the sender of the
+      receiver's current view of an acceptable maximum bitrate.
+      Mechanisms that convey the receiver's estimate of the maximum
+      available bitrate provide similar feedback.
+
+   RTCP Extended Reports (XRs):  Numerous RTCP 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
+      information needed for effective sender-based congestion control.
+      However, the result has high overhead in terms of both bandwidth
+      and complexity, due to the need to stack multiple reports.
+
+   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 [RTP-Ext-for-CC].  Such an approach increases the size of
+      each RTP packet by 8 octets, due to the header extension, but
+      reduces the size of the RTCP 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.  IANA Considerations
+
+   The IANA has registered one new RTP/AVPF Transport-Layer Feedback
+   Message in the "FMT Values for RTPFB Payload Types" table [RFC4585]
+   as defined in Section 3.1:
+
+   Name:         CCFB
+   Long name:    RTP Congestion Control Feedback
+   Value:        11
+   Reference:    RFC 8888
+
+   The IANA has also registered 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
+   Mux:          IDENTICAL-PER-PT
+   Reference:    RFC 8888
+
+10.  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 being used (e.g., [RFC8698],
+   [RFC8298], [Google-GCC], or [RFC8382]) apply.
+
+   A receiver that intentionally generates inaccurate RTCP congestion
+   control feedback reports might be able to trick the sender into
+   sending at a greater rate than the path can support, thereby causing
+   congestion on the path.  This scenario will negatively impact the
+   quality of experience of that receiver, potentially causing both
+   denial of service to other traffic sharing the path and excessively
+   increased resource usage at the media sender.  Since RTP is an
+   unreliable transport, a sender can intentionally drop a packet,
+   leaving a gap in the RTP sequence number space without causing
+   serious harm, to check that the receiver is correctly reporting
+   losses.  (This needs to be done with care and some awareness of the
+   media data being sent, to limit impact on the user experience.)
+
+   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.
+
+   An off-path attacker that can spoof RTCP Congestion Control Feedback
+   Packets can similarly trick a sender into sending at an incorrect
+   rate, leading to denial of service.  This attack is difficult, since
+   the attacker needs to guess the SSRC and sequence number in addition
+   to the destination transport address.  As with on-path attacks, the
+   secure RTCP profile [RFC3711] can be used to authenticate RTCP
+   packets to protect against this attack.
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [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,
+              <https://www.rfc-editor.org/info/rfc3168>.
+
+   [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>.
+
+   [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,
+              <https://www.rfc-editor.org/info/rfc3551>.
+
+   [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>.
+
+   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234,
+              DOI 10.17487/RFC5234, January 2008,
+              <https://www.rfc-editor.org/info/rfc5234>.
+
+   [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>.
+
+   [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, <https://www.rfc-editor.org/info/rfc6679>.
+
+   [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>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8843]  Holmberg, C., Alvestrand, H., and C. Jennings,
+              "Negotiating Media Multiplexing Using the Session
+              Description Protocol (SDP)", RFC 8843,
+              DOI 10.17487/RFC8843, January 2021,
+              <https://www.rfc-editor.org/info/rfc8843>.
+
+   [RFC8859]  Nandakumar, S., "A Framework for Session Description
+              Protocol (SDP) Attributes When Multiplexing", RFC 8859,
+              DOI 10.17487/RFC8859, January 2021,
+              <https://www.rfc-editor.org/info/rfc8859>.
+
+11.2.  Informative References
+
+   [feedback-requirements]
+              "RMCAT Feedback Requirements", IETF 95, April 2016,
+              <https://www.ietf.org/proceedings/95/slides/slides-95-
+              rmcat-1.pdf>.
+
+   [Google-GCC]
+              Holmer, S., Lundin, H., Carlucci, G., De Cicco, L., and S.
+              Mascolo, "A Google Congestion Control Algorithm for Real-
+              Time Communication", Work in Progress, Internet-Draft,
+              draft-ietf-rmcat-gcc-02, 8 July 2016,
+              <https://tools.ietf.org/html/draft-ietf-rmcat-gcc-02>.
+
+   [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>.
+
+   [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, <https://www.rfc-editor.org/info/rfc5104>.
+
+   [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,
+              <https://www.rfc-editor.org/info/rfc6843>.
+
+   [RFC8298]  Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation
+              for Multimedia", RFC 8298, DOI 10.17487/RFC8298, December
+              2017, <https://www.rfc-editor.org/info/rfc8298>.
+
+   [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, <https://www.rfc-editor.org/info/rfc8382>.
+
+   [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,
+              <https://www.rfc-editor.org/info/rfc8698>.
+
+   [RTCP-Multimedia-Feedback]
+              Perkins, C., "RTP Control Protocol (RTCP) Feedback for
+              Congestion Control in Interactive Multimedia Conferences",
+              Work in Progress, Internet-Draft, draft-ietf-rmcat-rtp-cc-
+              feedback-05, 4 November 2019,
+              <https://tools.ietf.org/html/draft-ietf-rmcat-rtp-cc-
+              feedback-05>.
+
+   [RTP-Ext-for-CC]
+              Holmer, S., Flodman, M., and E. Sprang, "RTP Extensions
+              for Transport-wide Congestion Control", Work in Progress,
+              Internet-Draft, draft-holmer-rmcat-transport-wide-cc-
+              extensions-01, 19 October 2015,
+              <https://tools.ietf.org/html/draft-holmer-rmcat-transport-
+              wide-cc-extensions-01>.
+
+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
+   feedback.
+
+Authors' Addresses
+
+   Zaheduzzaman Sarker
+   Ericsson AB
+   Torshamnsgatan 23
+   SE-164 83 Stockholm
+   Sweden
+
+   Phone: +46 10 717 37 43
+   Email: zaheduzzaman.sarker@ericsson.com
+
+
+   Colin Perkins
+   University of Glasgow
+   School of Computing Science
+   Glasgow
+   G12 8QQ
+   United Kingdom
+
+   Email: csp@csperkins.org
+
+
+   Varun Singh
+   CALLSTATS I/O Oy
+   Annankatu 31-33 C 42
+   FI-00100 Helsinki
+   Finland
+
+   Email: varun.singh@iki.fi
+   URI:   https://www.callstats.io/
+
+
+   Michael A. Ramalho
+   AcousticComms Consulting
+   6310 Watercrest Way Unit 203
+   Lakewood Ranch, FL 34202-5122
+   United States of America
+
+   Phone: +1 732 832 9723
+   Email: mar42@cornell.edu
+   URI:   http://ramalho.webhop.info/