draft-ietf-avtcore-cc-feedback-message-09.txt   rfc8888.txt 
IETF RMCAT Working Group Z. Sarker Internet Engineering Task Force (IETF) Z. Sarker
Internet-Draft Ericsson AB Request for Comments: 8888 Ericsson AB
Intended status: Standards Track C. Perkins Category: Standards Track C. Perkins
Expires: May 6, 2021 University of Glasgow ISSN: 2070-1721 University of Glasgow
V. Singh V. Singh
callstats.io callstats.io
M. Ramalho M. Ramalho
November 2, 2020 AcousticComms
January 2021
RTP Control Protocol (RTCP) Feedback for Congestion Control RTP Control Protocol (RTCP) Feedback for Congestion Control
draft-ietf-avtcore-cc-feedback-message-09
Abstract Abstract
An effective RTP congestion control algorithm requires more fine- An effective RTP congestion control algorithm requires more fine-
grained feedback on packet loss, timing, and ECN marks than is grained feedback on packet loss, timing, and Explicit Congestion
provided by the standard RTP Control Protocol (RTCP) Sender Report Notification (ECN) marks than is provided by the standard RTP Control
(SR) and Receiver Report (RR) packets. This document describes an Protocol (RTCP) Sender Report (SR) and Receiver Report (RR) packets.
RTCP feedback message intended to enable congestion control for This document describes an RTCP feedback message intended to enable
interactive real-time traffic using RTP. The feedback message is congestion control for interactive real-time traffic using RTP. The
designed for use with a sender-based congestion control algorithm, in feedback message is designed for use with a sender-based congestion
which the receiver of an RTP flow sends RTCP feedback packets to the control algorithm, in which the receiver of an RTP flow sends back to
sender containing the information the sender needs to perform the sender RTCP feedback packets containing the information the
congestion control. sender needs to perform congestion control.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on May 6, 2021. 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 Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. RTCP Feedback for Congestion Control . . . . . . . . . . . . 3 3. RTCP Feedback for Congestion Control
3.1. RTCP Congestion Control Feedback Report . . . . . . . . . 4 3.1. RTCP Congestion Control Feedback Report
4. Feedback Frequency and Overhead . . . . . . . . . . . . . . . 7 4. Feedback Frequency and Overhead
5. Response to Loss of Feedback Packets . . . . . . . . . . . . 8 5. Response to Loss of Feedback Packets
6. SDP Signalling . . . . . . . . . . . . . . . . . . . . . . . 8 6. SDP Signaling
7. Relation to RFC 6679 . . . . . . . . . . . . . . . . . . . . 9 7. Relationship to RFC 6679
8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 10 8. Design Rationale
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. Security Considerations
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11. References
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References
12.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References
12.2. Informative References . . . . . . . . . . . . . . . . . 14 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses
1. Introduction 1. Introduction
For interactive real-time traffic, such as video conferencing flows, For interactive real-time traffic, such as video conferencing flows,
the typical protocol choice is the Real-time Transport Protocol (RTP) the typical protocol choice is the Real-time Transport Protocol (RTP)
[RFC3550] running over the User Datagram Protocol (UDP). RTP does [RFC3550] running over the User Datagram Protocol (UDP). RTP does
not provide any guarantee of Quality of Service (QoS), reliability, not provide any guarantee of Quality of Service (QoS), reliability,
or timely delivery, and expects the underlying transport protocol to or timely delivery, and expects the underlying transport protocol to
do so. UDP alone certainly does not meet that expectation. However, do so. UDP alone certainly does not meet that expectation. However,
the RTP Control Protocol (RTCP) [RFC3550] provides a mechanism by the RTP Control Protocol (RTCP) [RFC3550] provides a mechanism by
skipping to change at page 3, line 8 skipping to change at line 97
In the absence of standardized messages for this purpose, designers In the absence of standardized messages for this purpose, designers
of congestion control algorithms have developed proprietary RTCP of congestion control algorithms have developed proprietary RTCP
messages that convey only those parameters needed for their messages that convey only those parameters needed for their
respective designs. As a direct result, the different congestion respective designs. As a direct result, the different congestion
control designs are not interoperable. To enable algorithm evolution control designs are not interoperable. To enable algorithm evolution
as well as interoperability across designs (e.g., different rate as well as interoperability across designs (e.g., different rate
adaptation algorithms), it is highly desirable to have a generic adaptation algorithms), it is highly desirable to have a generic
congestion control feedback format. congestion control feedback format.
To help achieve interoperability for unicast RTP congestion control, To help achieve interoperability for unicast RTP congestion control,
this memo proposes a common RTCP feedback packet format that can be this memo specifies a common RTCP feedback packet format that can be
used by NADA [RFC8698], SCReAM [RFC8298], Google Congestion Control used by Network-Assisted Dynamic Adaptation (NADA) [RFC8698], Self-
[I-D.ietf-rmcat-gcc] and Shared Bottleneck Detection [RFC8382], and Clocked Rate Adaptation for Multimedia (SCReAM) [RFC8298], Google
hopefully also by future RTP congestion control algorithms. Congestion Control [Google-GCC], and Shared Bottleneck Detection
[RFC8382], and, hopefully, also by future RTP congestion control
algorithms.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
In addition the terminology defined in [RFC3550], [RFC4585], and In addition, the terminology defined in [RFC3550], [RFC4585], and
[RFC5506] applies. [RFC5506] applies.
3. RTCP Feedback for Congestion Control 3. RTCP Feedback for Congestion Control
Based on an analysis of NADA [RFC8698], SCReAM [RFC8298], Google Based on an analysis of NADA [RFC8698], SCReAM [RFC8298], Google
Congestion Control [I-D.ietf-rmcat-gcc] and Shared Bottleneck Congestion Control [Google-GCC], and Shared Bottleneck Detection
Detection [RFC8382], the following per-RTP packet congestion control [RFC8382], the following per-RTP packet congestion control feedback
feedback information has been determined to be necessary: information has been determined to be necessary:
o RTP sequence number: The receiver of an RTP flow needs to feed the RTP Sequence Number: The receiver of an RTP flow needs to feed the
sequence numbers of the received RTP packets back to the sender, sequence numbers of the received RTP packets back to the sender,
so the sender can determine which packets were received and which so the sender can determine which packets were received and which
were lost. Packet loss is used as an indication of congestion by were lost. Packet loss is used as an indication of congestion by
many congestion control algorithms. many congestion control algorithms.
o Packet Arrival Time: The receiver of an RTP flow needs to feed the 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 arrival time of each RTP packet back to the sender. Packet delay
and/or delay variation (jitter) is used as a congestion signal by and/or delay variation (jitter) is used as a congestion signal by
some congestion control algorithms. some congestion control algorithms.
o Packet Explicit Congestion Notification (ECN) Marking: If ECN Packet Explicit Congestion Notification (ECN) Marking: If ECN
[RFC3168], [RFC6679] is used, it is necessary to feed back the [RFC3168] [RFC6679] is used, it is necessary to feed back the
2-bit ECN mark in received RTP packets, indicating for each RTP 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. packet whether it is marked not-ECT, ECT(0), ECT(1), or ECN
If the path used by the RTP traffic is ECN capable the sender can Congestion Experienced (ECN-CE). ("ECT" stands for "ECN-Capable
use Congestion Experienced (ECN-CE) marking information as a Transport".) If the path used by the RTP traffic is ECN capable,
congestion control signal. the sender can use ECN-CE marking information as a congestion
control signal.
Every RTP flow is identified by its Synchronization Source (SSRC) Every RTP flow is identified by its Synchronization Source (SSRC)
identifier. Accordingly, the RTCP feedback format needs to group its identifier. Accordingly, the RTCP feedback format needs to group its
reports by SSRC, sending one report block per received SSRC. reports by SSRC, sending one report block per received SSRC.
As a practical matter, we note that host operating system (OS) As a practical matter, we note that host operating system (OS)
process interruptions can occur at inopportune times. Accordingly, process interruptions can occur at inopportune times. Accordingly,
recording RTP packet send times at the sender, and the corresponding recording RTP packet send times at the sender, and the corresponding
RTP packet arrival times at the receiver, needs to be done with RTP packet arrival times at the receiver, needs to be done with
deliberate care. This is because the time duration of host OS deliberate care. This is because the time duration of host OS
interruptions can be significant relative to the precision desired in interruptions can be significant relative to the precision desired in
the one-way delay estimates. Specifically, the send time needs to be the one-way delay estimates. Specifically, the send time needs to be
recorded at the last opportunity prior to transmitting the RTP packet recorded at the last opportunity prior to transmitting the RTP packet
at the sender, and the arrival time at the receiver needs to be at the sender, and the arrival time at the receiver needs to be
recorded at the earliest available opportunity. recorded at the earliest available opportunity.
3.1. RTCP Congestion Control Feedback Report 3.1. RTCP Congestion Control Feedback Report
Congestion control feedback can be sent as part of a regular Congestion control feedback can be sent as part of a regular
scheduled RTCP report, or in an RTP/AVPF early feedback packet. If scheduled RTCP report or in an RTP/AVPF early feedback packet. If
sent as early feedback, congestion control feedback MAY be sent in a sent as early feedback, congestion control feedback MAY be sent in a
non-compound RTCP packet [RFC5506] if the RTP/AVPF profile [RFC4585] non-compound RTCP packet [RFC5506] if the RTP/AVPF profile [RFC4585]
or the RTP/SAVPF profile [RFC5124] is used. or the RTP/SAVPF profile [RFC5124] is used.
Irrespective of how it is transported, the congestion control Irrespective of how it is transported, the congestion control
feedback is sent as a Transport Layer Feedback Message (RTCP packet feedback is sent as a Transport-Layer Feedback Message (RTCP packet
type 205). The format of this RTCP packet is shown in Figure 1: type 205). The format of this RTCP packet is shown in Figure 1:
0 1 2 3 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 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 | |V=2|P| FMT=11 | PT = 205 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of RTCP packet sender | | SSRC of RTCP packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of 1st RTP Stream | | SSRC of 1st RTP Stream |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | num_reports | | begin_seq | num_reports |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|ECN| Arrival time offset | ... . |R|ECN| Arrival time offset | ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of nth RTP Stream | | SSRC of nth RTP Stream |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | num_reports | | begin_seq | num_reports |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|ECN| Arrival time offset | ... | |R|ECN| Arrival time offset | ... |
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report Timestamp (32bits) | | Report Timestamp (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RTCP Congestion Control Feedback Packet Format Figure 1: RTCP Congestion Control Feedback Packet Format
The first eight octets comprise a standard RTCP header, with PT=205 The first 8 octets comprise a standard RTCP header, with PT=205 and
and FMT=CCFB indicating that this is a congestion control feedback FMT=11 indicating that this is a congestion control feedback packet,
packet, and with the SSRC set to that of the sender of the RTCP and with the SSRC set to that of the sender of the RTCP packet.
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 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 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 header is followed by a report block for each SSRC from which RTP
packets have been received, followed by a Report Timestamp. packets have been received, followed by a Report Timestamp.
Each report block begins with the SSRC of the received RTP Stream on Each report block begins with the SSRC of the received RTP stream on
which it is reporting. Following this, the report block contains a which it is reporting. Following this, the report block contains a
16-bit packet metric block for each RTP packet with sequence number 16-bit packet metric block for each RTP packet that has a sequence
in the range begin_seq to begin_seq+num_reports inclusive (calculated number in the range begin_seq to begin_seq+num_reports inclusive
using arithmetic modulo 65536 to account for possible sequence number (calculated using arithmetic modulo 65536 to account for possible
wrap-around). If the number of 16-bit packet metric blocks included sequence number wrap-around). If the number of 16-bit packet metric
in the report block is not a multiple of two, then 16 bits of zero blocks included in the report block is not a multiple of two, then 16
padding MUST be added after the last packet metric block, to align bits of zero padding MUST be added after the last packet metric
the end of the packet metric blocks with the next 32 bit boundary. block, to align the end of the packet metric blocks with the next
The value of num_reports MAY be zero, indicating that there are no 32-bit boundary. The value of num_reports MAY be 0, indicating that
packet metric blocks included for that SSRC. Each report block MUST there are no packet metric blocks included for that SSRC. Each
NOT include more than 16384 packet metric blocks (i.e., it MUST NOT report block MUST NOT include more than 16384 packet metric blocks
report on more than one quarter of the sequence number space in a (i.e., it MUST NOT report on more than one quarter of the sequence
single report). number space in a single report).
The contents of each 16-bit packet metric block comprises the R, ECN, The contents of each 16-bit packet metric block comprise the R, ECN,
and ATO fields as follows: and ATO fields as follows:
o Received (R, 1 bit): is a boolean to indicate if the packet was Received (R, 1 bit): A boolean that indicates whether the packet was
received. 0 represents that the packet was not yet received and received. 0 indicates that the packet was not yet received and
the subsequent 15-bits (ECN and ATO) in this 16-bit packet metric the subsequent 15 bits (ECN and ATO) in this 16-bit packet metric
block are also set to 0 and MUST be ignored. 1 represents that block are also set to 0 and MUST be ignored. 1 indicates that the
the packet was received and the subsequent bits in the block need packet was received and the subsequent bits in the block need to
to be parsed. be parsed.
o ECN (2 bits): is the echoed ECN mark of the packet. These are set 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. 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 Arrival time offset (ATO, 13 bits): The arrival time of the RTP
packet at the receiver, as an offset before the time represented packet at the receiver, as an offset before the time represented
by the Report Timestamp (RTS) field of this RTCP congestion by the Report Timestamp (RTS) field of this RTCP congestion
control feedback report. The ATO field is in units of 1/1024 control feedback report. The ATO field is in units of 1/1024
seconds (this unit is chosen to give exact offsets from the RTS seconds (this unit is chosen to give exact offsets from the RTS
field) so, for example, an ATO value of 512 indicates that the field) so, for example, an ATO value of 512 indicates that the
corresponding RTP packet arrived exactly half a second before the corresponding RTP packet arrived exactly half a second before the
time instant represented by the RTS field. If the measured value time instant represented by the RTS field. If the measured value
is greater than 8189/1024 seconds (the value that would be coded is greater than 8189/1024 seconds (the value that would be coded
as 0x1FFD), the value 0x1FFE MUST be reported to indicate an over- as 0x1FFD), the value 0x1FFE MUST be reported to indicate an over-
range measurement. If the measurement is unavailable, or if the range measurement. If the measurement is unavailable or if the
arrival time of the RTP packet is after the time represented by 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 RTS field, then an ATO value of 0x1FFF MUST be reported for
the packet. the packet.
The RTCP congestion control feedback report packet concludes with the The RTCP congestion control feedback report packet concludes with the
Report Timestamp field (RTS, 32 bits). This denotes the time instant Report Timestamp field (RTS, 32 bits). This denotes the time instant
on which this packet is reporting, and is the instant from which the 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 arrival time offset values are calculated. The value of the RTS
derived from the same clock used to generate the NTP timestamp field field is derived from the same clock used to generate the NTP
in RTCP Sender Report (SR) packets. It is formatted as the middle 32 timestamp field in RTCP Sender Report (SR) packets. It is formatted
bits of an NTP format timestamp, as described in Section 4 of as the middle 32 bits of an NTP format timestamp, as described in
[RFC3550]. Section 4 of [RFC3550].
RTCP congestion control feedback packets SHOULD include a report RTCP Congestion Control Feedback Packets SHOULD include a report
block for every active SSRC. The sequence number ranges reported on block for every active SSRC. The sequence number ranges reported on
in consecutive reports for a given SSRC will generally be contiguous, in consecutive reports for a given SSRC will generally be contiguous,
but overlapping reports MAY be sent (and need to be sent in cases but overlapping reports MAY be sent (and need to be sent in cases
where RTP packet reordering occurs across the boundary between where RTP packet reordering occurs across the boundary between
consecutive reports). If an RTP packet was reported as received in consecutive reports). If an RTP packet was reported as received in
one report, that packet MUST also be reported as received in any one report, that packet MUST also be reported as received in any
overlapping reports sent later that cover its sequence number range. overlapping reports sent later that cover its sequence number range.
If reports covering overlapping sequence number ranges are sent, If feedback reports covering overlapping sequence number ranges are
information in later reports updates that sent in previous reports sent, information in later feedback reports may update any data sent
for RTP packets included in both reports. in previous reports for RTP packets included in both feedback
reports.
RTCP congestion control feedback packets can be large if they are RTCP Congestion Control Feedback Packets can be large if they are
sent infrequently relative to the number of RTP data packets. If an sent infrequently relative to the number of RTP data packets. If an
RTCP congestion control feedback packet is too large to fit within RTCP Congestion Control Feedback Packet is too large to fit within
the path MTU, its sender SHOULD split it into multiple feedback the path MTU, its sender SHOULD split it into multiple feedback
packets. The RTCP reporting interval SHOULD be chosen such that packets. The RTCP reporting interval SHOULD be chosen such that
feedback packets are sent often enough that they are small enough to 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 fit within the path MTU. ([RTCP-Multimedia-Feedback] discusses how
how to choose the reporting interval; specifications for RTP to choose the reporting interval; specifications for RTP congestion
congestion control algorithms can also provide guidance). control algorithms can also provide guidance.)
If duplicate copies of a particular RTP packet are received, then the 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 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 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 mark MUST be reported for that packet; otherwise, the ECN mark of the
first copy to arrive is reported. first copy to arrive is reported.
If no packets are received from an SSRC in a reporting interval, a 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 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 number previously received from that SSRC and num_reports set to 0
(or, the report can simply to omitted). The corresponding SR/RR (or the report can simply be omitted). The corresponding Sender
packet will have a non-increased extended highest sequence number Report / Receiver Report (SR/RR) packet will have a non-increased
received field that will inform the sender that no packets have been extended highest sequence number received field that will inform the
received, but it can ease processing to have that information sender that no packets have been received, but it can ease processing
available in the congestion control feedback reports too. to have that information available in the congestion control feedback
reports too.
A report block indicating that certain RTP packets were lost is not A report block indicating that certain RTP packets were lost is not
to be interpreted as a request to retransmit the lost packets. The to be interpreted as a request to retransmit the lost packets. The
receiver of such a report might choose to retransmit such packets, receiver of such a report might choose to retransmit such packets,
provided a retransmission payload format has been negotiated, but provided a retransmission payload format has been negotiated, but
there is no requirement that it do so. there is no requirement that it do so.
4. Feedback Frequency and Overhead 4. Feedback Frequency and Overhead
There is a trade-off between speed and accuracy of reporting, and the 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 overhead of the reports. [RTCP-Multimedia-Feedback] discusses this
this trade-off, suggests desirable RTCP feedback rates, and provides trade-off, suggests desirable RTCP feedback rates, and provides
guidance on how to configure the RTCP bandwidth fraction, etc., to guidance on how to configure, for example, the RTCP bandwidth
make appropriate use of the reporting block described in this memo. fraction to make appropriate use of the reporting block described in
this memo. Specifications for RTP congestion control algorithms can
Specifications for RTP congestion control algorithms can also provide also provide guidance.
guidance.
It is generally understood that congestion control algorithms work It is generally understood that congestion control algorithms work
better with more frequent feedback. However, RTCP bandwidth and better with more frequent feedback. However, RTCP bandwidth and
transmission rules put some upper limits on how frequently the RTCP transmission rules put some upper limits on how frequently the RTCP
feedback messages can be sent from an RTP receiver to the RTP sender. 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 In many cases, sending feedback once per frame is an upper bound
before the reporting overhead becomes excessive, although this will before the reporting overhead becomes excessive, although this will
depend on the media rate and more frequent feedback might be needed depend on the media rate and more frequent feedback might be needed
with high-rate media flows [I-D.ietf-rmcat-rtp-cc-feedback]. with high-rate media flows [RTCP-Multimedia-Feedback]. Analysis
Analysis [feedback-requirements] has also shown that some candidate [feedback-requirements] has also shown that some candidate congestion
congestion control algorithms can operate with less frequent control algorithms can operate with less frequent feedback, using a
feedback, using a feedback interval range of 50-200ms. Applications feedback interval range of 50-200 ms. Applications need to negotiate
need to negotiate an appropriate congestion control feedback interval an appropriate congestion control feedback interval at session setup
at session setup time, based on the choice of congestion control time, based on the choice of congestion control algorithm, the
algorithm, the expected media bit rate, and the acceptable feedback expected media bitrate, and the acceptable feedback overhead.
overhead.
5. Response to Loss of Feedback Packets 5. Response to Loss of Feedback Packets
Like all RTCP packets, RTCP congestion control feedback packets might Like all RTCP packets, RTCP Congestion Control Feedback Packets might
be lost. All RTP congestion control algorithms MUST specify how they be lost. All RTP congestion control algorithms MUST specify how they
respond to the loss of feedback packets. respond to the loss of feedback packets.
RTCP packets do not contain a sequence number, so loss of feedback 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 packets has to be inferred based on the time since the last feedback
packet. If only a single congestion control feedback packet is lost, packet. If only a single congestion control feedback packet is lost,
an appropriate response is to assume that the level of congestion has an appropriate response is to assume that the level of congestion has
remained roughly the same as the previous report. However, if remained roughly the same as the previous report. However, if
multiple consecutive congestion control feedback packets are lost, multiple consecutive congestion control feedback packets are lost,
then the media sender SHOULD rapidly reduce its sending rate as this then the media sender SHOULD rapidly reduce its sending rate as this
likely indicates a path failure. The RTP circuit breaker [RFC8083] likely indicates a path failure. The RTP circuit breaker
provides further guidance. specification [RFC8083] provides further guidance.
6. SDP Signalling 6. SDP Signaling
A new "ack" feedback parameter, "ccfb", is defined for use with the 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 "a=rtcp-fb:" Session Description Protocol (SDP) extension to indicate
Control feedback packet format defined in Section 3. The ABNF the use of the RTP Congestion Control Feedback Packet format defined
definition of this SDP parameter extension is: 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 = <See Section 4.2 of [RFC4585]>
rtcp-fb-ack-param =/ ccfb-par rtcp-fb-ack-param =/ ccfb-par
ccfb-par = SP "ccfb" ccfb-par = SP "ccfb"
The payload type used with "ccfb" feedback MUST be the wildcard type The payload type used with "ccfb" feedback MUST be the wildcard type
("*"). This implies that the congestion control feedback is sent for ("*"). This implies that the congestion control feedback is sent for
all payload types in use in the session, including any FEC and all payload types in use in the session, including any Forward Error
retransmission payload types. An example of the resulting SDP Correction (FEC) and retransmission payload types. An example of the
attribute is: resulting SDP attribute is:
a=rtcp-fb:* ack ccfb a=rtcp-fb:* ack ccfb
The offer/answer rules for these SDP feedback parameters are The offer/answer rules for these SDP feedback parameters are
specified in Section 4.2 of the RTP/AVPF profile [RFC4585]. specified in Section 4.2 of the RTP/AVPF profile [RFC4585].
An SDP offer might indicate support for both the congestion control An SDP offer might indicate support for both the congestion control
feedback mechanism specified in this memo and one or more alternative feedback mechanism specified in this memo and one or more alternative
congestion control feedback mechanisms that offer substantially the congestion control feedback mechanisms that offer substantially the
same semantics. In this case, the answering party SHOULD include same semantics. In this case, the answering party SHOULD include
only one of the offered congestion control feedback mechanisms in its only one of the offered congestion control feedback mechanisms in its
answer. If a re-invite offering the same set of congestion control answer. If a subsequent offer containing the same set of congestion
feedback mechanisms is received, the generated answer SHOULD choose control feedback mechanisms is received, the generated answer SHOULD
the same congestion control feedback mechanism as in the original choose the same congestion control feedback mechanism as in the
answer where possible. original answer where possible.
When the SDP BUNDLE extension When the SDP BUNDLE extension [RFC8843] is used for multiplexing, the
[I-D.ietf-mmusic-sdp-bundle-negotiation] is used for multiplexing, "a=rtcp-fb:" attribute has multiplexing category IDENTICAL-PER-PT
the "a=rtcp-fb:" attribute has multiplexing category IDENTICAL-PER-PT [RFC8859].
[I-D.ietf-mmusic-sdp-mux-attributes].
7. Relation to RFC 6679 7. Relationship to RFC 6679
Use of Explicit Congestion Notification (ECN) with RTP is described The use of Explicit Congestion Notification (ECN) with RTP is
in [RFC6679]. That specifies how to negotiate the use of ECN with described in [RFC6679], which specifies how to negotiate the use of
RTP, and defines an RTCP ECN Feedback Packet to carry ECN feedback ECN with RTP and defines an RTCP ECN Feedback Packet to carry ECN
reports. It uses an SDP "a=ecn-capable-rtp:" attribute to negotiate feedback reports. It uses an SDP "a=ecn-capable-rtp:" attribute to
use of ECN, and the "a=rtcp-fb:" attributes with the "nack" parameter negotiate the use of ECN, and the "a=rtcp-fb:" attribute with the
"ecn" to negotiate the use of RTCP ECN Feedback Packets. "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 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 RTP Congestion Control Feedback Packet defined in this memo, since it
provides duplicate information. When congestion control feedback is provides duplicate information. When congestion control feedback is
to be used with RTP and ECN, the SDP offer generated MUST include an 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 "a=ecn-capable-rtp:" attribute to negotiate ECN support, along with
an "a=rtcp-fb:" attribute with the "ack" parameter "ccfb" to indicate an "a=rtcp-fb:" attribute with the "ack" parameter "ccfb" to indicate
that the RTP Congestion Control Feedback Packet can be used. The that the RTP Congestion Control Feedback Packet can be used. The
"a=rtcp-fb:" attribute MAY also include the "nack" parameter "ecn", "a=rtcp-fb:" attribute MAY also include the "nack" parameter "ecn" to
to indicate that the RTCP ECN Feedback Packet is also supported. If indicate that the RTCP ECN Feedback Packet is also supported. If an
an SDP offer signals support for both RTP Congestion Control Feedback SDP offer signals support for both RTP Congestion Control Feedback
Packets and the RTCP ECN Feedback Packet, the answering party SHOULD Packets and the RTCP ECN Feedback Packet, the answering party SHOULD
signal support for one, but not both, formats in its SDP answer to signal support for one, but not both, formats in its SDP answer to
avoid sending duplicate feedback. avoid sending duplicate feedback.
When using ECN with RTP, the guidelines in Section 7.2 of [RFC6679] 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 MUST be followed to initiate the use of ECN in an RTP session. The
guidelines in Section 7.3 of [RFC6679] MUST also be followed about guidelines in Section 7.3 of [RFC6679] regarding the ongoing use of
ongoing use of ECN within an RTP session, with the exception that ECN within an RTP session MUST also be followed, with the exception
feedback is sent using the RTCP Congestion Control Feedback Packets that feedback is sent using the RTCP Congestion Control Feedback
described in this memo rather than using RTP ECN Feedback Packets. Packets described in this memo rather than using RTP ECN Feedback
Similarly, the guidance in Section 7.4 of [RFC6679] around detecting Packets. Similarly, the guidance in Section 7.4 of [RFC6679] related
failures MUST be followed, with the exception that the necessary to detecting failures MUST be followed, with the exception that the
information is retrieved from the RTCP Congestion Control Feedback necessary information is retrieved from the RTCP Congestion Control
Packets rather than from RTP ECN Feedback Packets. Feedback Packets rather than from RTP ECN Feedback Packets.
8. Design Rationale 8. Design Rationale
The primary function of RTCP SR/RR packets is to report statistics on The primary function of RTCP SR/RR packets is to report statistics on
the reception of RTP packets. The reception report blocks sent in the reception of RTP packets. The reception report blocks sent in
these packets contain information about observed jitter, fractional these packets contain information about observed jitter, fractional
packet loss, and cumulative packet loss. It was intended that this packet loss, and cumulative packet loss. It was intended that this
information could be used to support congestion control algorithms, information could be used to support congestion control algorithms,
but experience has shown that it is not sufficient for that purpose. but experience has shown that it is not sufficient for that purpose.
An efficient congestion control algorithm requires more fine-grained An efficient congestion control algorithm requires more fine-grained
information on per-packet reception quality than is provided by SR/RR information on per-packet reception quality than is provided by SR/RR
packets to react effectively. The feedback format defined in this packets to react effectively. The feedback format defined in this
memo provides such fine-grained feedback. memo provides such fine-grained feedback.
Several other RTCP extensions also provide more detailed feedback Several other RTCP extensions also provide more detailed feedback
than SR/RR packets: than SR/RR packets:
TMMBR: The Codec Control Messages for the RTP/AVPF profile [RFC5104] TMMBR: The codec control messages for the RTP/AVPF profile [RFC5104]
include a Temporary Maximum Media Bit Rate (TMMBR) message. This include a Temporary Maximum Media Stream Bit Rate Request (TMMBR)
is used to convey a temporary maximum bit rate limitation from a message. This is used to convey a temporary maximum bitrate
receiver of RTP packets to their sender. Even though it was not limitation from a receiver of RTP packets to their sender. Even
designed to replace congestion control, TMMBR has been used as a though it was not designed to replace congestion control, TMMBR
means to do receiver based congestion control where the session has been used as a means to do receiver-based congestion control
bandwidth is high enough to send frequent TMMBR messages, where the session bandwidth is high enough to send frequent TMMBR
especially when used with non-compound RTCP packets [RFC5506]. messages, especially when used with non-compound RTCP packets
This approach requires the receiver of the RTP packets to monitor [RFC5506]. This approach requires the receiver of the RTP packets
their reception, determine the level of congestion, and recommend to monitor their reception, determine the level of congestion, and
a maximum bit rate suitable for current available bandwidth on the recommend a maximum bitrate suitable for current available
path; it also assumes that the RTP sender can/will respect that bandwidth on the path; it also assumes that the RTP sender
bit rate. This is the opposite of the sender-based congestion can/will respect that bitrate. This is the opposite of the
control approach suggested in this memo, so TMMBR cannot be used sender-based congestion control approach suggested in this memo,
to convey the information needed for a sender-based congestion so TMMBR cannot be used to convey the information needed for
control. TMMBR could, however, be viewed a complementary sender-based congestion control. TMMBR could, however, be viewed
mechanism that can inform the sender of the receiver's current as a complementary mechanism that can inform the sender of the
view of acceptable maximum bit rate. Mechanisms that convey the receiver's current view of an acceptable maximum bitrate.
receiver's estimate of the maximum available bit-rate provide Mechanisms that convey the receiver's estimate of the maximum
similar feedback. available bitrate provide similar feedback.
RTCP Extended Reports (XR): Numerous RTCP extended report (XR) RTCP Extended Reports (XRs): Numerous RTCP XR blocks have been
blocks have been defined to report details of packet loss, arrival defined to report details of packet loss, arrival times [RFC3611],
times [RFC3611], delay [RFC6843], and ECN marking [RFC6679]. It delay [RFC6843], and ECN marking [RFC6679]. It is possible to
is possible to combine several such XR blocks into a compound RTCP combine several such XR blocks into a compound RTCP packet, to
packet, to report the detailed loss, arrival time, and ECN marking report the detailed loss, arrival time, and ECN marking
information needed for effective sender-based congestion control. information needed for effective sender-based congestion control.
However, the result has high overhead both in terms of bandwidth However, the result has high overhead in terms of both bandwidth
and complexity, due to the need to stack multiple reports. and complexity, due to the need to stack multiple reports.
Transport-wide Congestion Control: The format defined in this memo Transport-wide Congestion Control: The format defined in this memo
provides individual feedback on each SSRC. An alternative is to provides individual feedback on each SSRC. An alternative is to
add a header extension to each RTP packet, containing a single, add a header extension to each RTP packet, containing a single,
transport-wide, packet sequence number, then have the receiver transport-wide, packet sequence number, then have the receiver
send RTCP reports giving feedback on these additional sequence send RTCP reports giving feedback on these additional sequence
numbers [I-D.holmer-rmcat-transport-wide-cc-extensions]. Such an numbers [RTP-Ext-for-CC]. Such an approach increases the size of
approach adds the per-packet overhead of the header extension (8 each RTP packet by 8 octets, due to the header extension, but
octets per packet in the referenced format), but reduces the size reduces the size of the RTCP feedback packets, and can simplify
of the feedback packets, and can simplify the rate calculation at the rate calculation at the sender if it maintains a single rate
the sender if it maintains a single rate limit that applies to all limit that applies to all RTP packets sent, irrespective of their
RTP packets sent irrespective of their SSRC. Equally, the use of SSRC. Equally, the use of transport-wide feedback makes it more
transport-wide feedback makes it more difficult to adapt the difficult to adapt the sending rate, or respond to lost packets,
sending rate, or respond to lost packets, based on the reception based on the reception and/or loss patterns observed on a per-SSRC
and/or loss patterns observed on a per-SSRC basis (for example, to basis (for example, to perform differential rate control and
perform differential rate control and repair for audio and video repair for audio and video flows, based on knowledge of what
flows, based on knowledge of what packets from each flow were packets from each flow were lost). Transport-wide feedback is
lost). Transport-wide feedback is also a less natural fit with also a less natural fit with the wider RTP framework, which makes
the wider RTP framework, which makes extensive use of per-SSRC extensive use of per-SSRC sequence numbers and feedback.
sequence numbers and feedback.
Considering these issues, we believe it appropriate to design a new Considering these issues, we believe it appropriate to design a new
RTCP feedback mechanism to convey information for sender-based RTCP feedback mechanism to convey information for sender-based
congestion control algorithms. The new congestion control feedback congestion control algorithms. The new congestion control feedback
RTCP packet described in Section 3 provides such a mechanism. RTCP packet described in Section 3 provides such a mechanism.
9. Acknowledgements 9. IANA Considerations
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.
10. IANA Considerations
The IANA is requested to register one new RTP/AVPF Transport-Layer The IANA has registered one new RTP/AVPF Transport-Layer Feedback
Feedback Message in the table for FMT values for RTPFB Payload Types Message in the "FMT Values for RTPFB Payload Types" table [RFC4585]
[RFC4585] as defined in Section 3.1: as defined in Section 3.1:
Name: CCFB Name: CCFB
Long name: RTP Congestion Control Feedback Long name: RTP Congestion Control Feedback
Value: (to be assigned by IANA) Value: 11
Reference: (RFC number of this document, when published) Reference: RFC 8888
The IANA is also requested to register one new SDP "rtcp-fb" The IANA has also registered one new SDP "rtcp-fb" attribute "ack"
attribute "ack" parameter, "ccfb", in the SDP ("ack" and "nack" parameter, "ccfb", in the SDP '"ack" and "nack" Attribute Values'
Attribute Values) registry: registry:
Value name: ccfb Value name: ccfb
Long name: Congestion Control Feedback Long name: Congestion Control Feedback
Usable with: ack Usable with: ack
Mux: IDENTICAL-PER-PT Mux: IDENTICAL-PER-PT
Reference: (RFC number of this document, when published) Reference: RFC 8888
11. Security Considerations 10. Security Considerations
The security considerations of the RTP specification [RFC3550], the The security considerations of the RTP specification [RFC3550], the
applicable RTP profile (e.g., [RFC3551], [RFC3711], or [RFC4585]), applicable RTP profile (e.g., [RFC3551], [RFC3711], or [RFC4585]),
and the RTP congestion control algorithm that is in use (e.g., and the RTP congestion control algorithm being used (e.g., [RFC8698],
[RFC8698], [RFC8298], [I-D.ietf-rmcat-gcc], or [RFC8382]) apply. [RFC8298], [Google-GCC], or [RFC8382]) apply.
A receiver that intentionally generates inaccurate RTCP congestion A receiver that intentionally generates inaccurate RTCP congestion
control feedback reports might be able trick the sender into sending control feedback reports might be able to trick the sender into
at a greater rate than the path can support, thereby causing sending at a greater rate than the path can support, thereby causing
congestion on the path. This will negatively impact the quality of congestion on the path. This scenario will negatively impact the
experience of that receiver, and potentially cause denial of service quality of experience of that receiver, potentially causing both
to other traffic sharing the path and excessive resource usage at the denial of service to other traffic sharing the path and excessively
media sender. Since RTP is an unreliable transport, a sender can increased resource usage at the media sender. Since RTP is an
intentionally drop a packet, leaving a gap in the RTP sequence number unreliable transport, a sender can intentionally drop a packet,
space without causing serious harm, to check that the receiver is leaving a gap in the RTP sequence number space without causing
correctly reporting losses (this needs to be done with care and some serious harm, to check that the receiver is correctly reporting
awareness of the media data being sent, to limit impact on the user losses. (This needs to be done with care and some awareness of the
experience). media data being sent, to limit impact on the user experience.)
An on-path attacker that can modify RTCP congestion control feedback An on-path attacker that can modify RTCP Congestion Control Feedback
packets can change the reports to trick the sender into sending at Packets can change the reports to trick the sender into sending at
either an excessively high or excessively low rate, leading to denial either an excessively high or excessively low rate, leading to denial
of service. The secure RTCP profile [RFC3711] can be used to of service. The secure RTCP profile [RFC3711] can be used to
authenticate RTCP packets to protect against this attack. authenticate RTCP packets to protect against this attack.
An off-patch attacker that can spoof RTCP congestion control feedback An off-path attacker that can spoof RTCP Congestion Control Feedback
packets can similarly trick a sender into sending at an incorrect Packets can similarly trick a sender into sending at an incorrect
rate, leading to denial of service. This attack is difficult, since rate, leading to denial of service. This attack is difficult, since
the attacker needs to guess the SSRC and sequence number in addition the attacker needs to guess the SSRC and sequence number in addition
to the destination transport address. As with on-patch attacks, the to the destination transport address. As with on-path attacks, the
secure RTCP profile [RFC3711] can be used to authenticate RTCP secure RTCP profile [RFC3711] can be used to authenticate RTCP
packets to protect against this attack. packets to protect against this attack.
12. References 11. References
12.1. Normative References
[I-D.ietf-mmusic-sdp-bundle-negotiation]
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.
[I-D.ietf-mmusic-sdp-mux-attributes] 11.1. Normative References
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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
skipping to change at page 14, line 10 skipping to change at line 583
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006, DOI 10.17487/RFC4585, July 2006,
<https://www.rfc-editor.org/info/rfc4585>. <https://www.rfc-editor.org/info/rfc4585>.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
2008, <https://www.rfc-editor.org/info/rfc5124>. 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 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, DOI 10.17487/RFC5506, April and Consequences", RFC 5506, DOI 10.17487/RFC5506, April
2009, <https://www.rfc-editor.org/info/rfc5506>. 2009, <https://www.rfc-editor.org/info/rfc5506>.
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN) and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August
2012, <https://www.rfc-editor.org/info/rfc6679>. 2012, <https://www.rfc-editor.org/info/rfc6679>.
[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", RFC 8083, Circuit Breakers for Unicast RTP Sessions", RFC 8083,
DOI 10.17487/RFC8083, March 2017, DOI 10.17487/RFC8083, March 2017,
<https://www.rfc-editor.org/info/rfc8083>. <https://www.rfc-editor.org/info/rfc8083>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References [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>.
[feedback-requirements] [RFC8859] Nandakumar, S., "A Framework for Session Description
"RMCAT Feedback Requirements", Protocol (SDP) Attributes When Multiplexing", RFC 8859,
<://www.ietf.org/proceedings/95/slides/slides-95-rmcat- DOI 10.17487/RFC8859, January 2021,
1.pdf>. <https://www.rfc-editor.org/info/rfc8859>.
[I-D.alvestrand-rmcat-remb] 11.2. Informative References
Alvestrand, H., "RTCP message for Receiver Estimated
Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in
progress), October 2013.
[I-D.holmer-rmcat-transport-wide-cc-extensions] [feedback-requirements]
Holmer, S., Flodman, M., and E. Sprang, "RTP Extensions "RMCAT Feedback Requirements", IETF 95, April 2016,
for Transport-wide Congestion Control", draft-holmer- <https://www.ietf.org/proceedings/95/slides/slides-95-
rmcat-transport-wide-cc-extensions-01 (work in progress), rmcat-1.pdf>.
October 2015.
[I-D.ietf-rmcat-gcc] [Google-GCC]
Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S. Holmer, S., Lundin, H., Carlucci, G., De Cicco, L., and S.
Mascolo, "A Google Congestion Control Algorithm for Real- Mascolo, "A Google Congestion Control Algorithm for Real-
Time Communication", draft-ietf-rmcat-gcc-02 (work in Time Communication", Work in Progress, Internet-Draft,
progress), July 2016. draft-ietf-rmcat-gcc-02, 8 July 2016,
<https://tools.ietf.org/html/draft-ietf-rmcat-gcc-02>.
[I-D.ietf-rmcat-rtp-cc-feedback]
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.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)", "RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, DOI 10.17487/RFC3611, November 2003, RFC 3611, DOI 10.17487/RFC3611, November 2003,
<https://www.rfc-editor.org/info/rfc3611>. <https://www.rfc-editor.org/info/rfc3611>.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile "Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
February 2008, <https://www.rfc-editor.org/info/rfc5104>. February 2008, <https://www.rfc-editor.org/info/rfc5104>.
skipping to change at page 15, line 41 skipping to change at line 662
"Shared Bottleneck Detection for Coupled Congestion "Shared Bottleneck Detection for Coupled Congestion
Control for RTP Media", RFC 8382, DOI 10.17487/RFC8382, Control for RTP Media", RFC 8382, DOI 10.17487/RFC8382,
June 2018, <https://www.rfc-editor.org/info/rfc8382>. June 2018, <https://www.rfc-editor.org/info/rfc8382>.
[RFC8698] Zhu, X., Pan, R., Ramalho, M., and S. Mena, "Network- [RFC8698] Zhu, X., Pan, R., Ramalho, M., and S. Mena, "Network-
Assisted Dynamic Adaptation (NADA): A Unified Congestion Assisted Dynamic Adaptation (NADA): A Unified Congestion
Control Scheme for Real-Time Media", RFC 8698, Control Scheme for Real-Time Media", RFC 8698,
DOI 10.17487/RFC8698, February 2020, DOI 10.17487/RFC8698, February 2020,
<https://www.rfc-editor.org/info/rfc8698>. <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 Authors' Addresses
Zaheduzzaman Sarker Zaheduzzaman Sarker
Ericsson AB Ericsson AB
Torshamnsgatan 21 Torshamnsgatan 23
Stockholm 164 40 SE-164 83 Stockholm
Sweden Sweden
Phone: +46107173743 Phone: +46 10 717 37 43
Email: zaheduzzaman.sarker@ericsson.com Email: zaheduzzaman.sarker@ericsson.com
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
School of Computing Science School of Computing Science
Glasgow G12 8QQ Glasgow
G12 8QQ
United Kingdom United Kingdom
Email: csp@csperkins.org Email: csp@csperkins.org
Varun Singh Varun Singh
CALLSTATS I/O Oy CALLSTATS I/O Oy
Annankatu 31-33 C 42 Annankatu 31-33 C 42
Helsinki 00100 FI-00100 Helsinki
Finland Finland
Email: varun.singh@iki.fi Email: varun.singh@iki.fi
URI: http://www.callstats.io/ URI: https://www.callstats.io/
Michael A. Ramalho Michael A. Ramalho
AcousticComms Consulting
6310 Watercrest Way Unit 203 6310 Watercrest Way Unit 203
Lakewood Ranch, FL 34202-5122 Lakewood Ranch, FL 34202-5122
USA United States of America
Phone: +1 732 832 9723 Phone: +1 732 832 9723
Email: mar42@cornell.edu Email: mar42@cornell.edu
URI: http://ramalho.webhop.info/ URI: http://ramalho.webhop.info/
 End of changes. 84 change blocks. 
325 lines changed or deleted 330 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/