rfc8888xml2.original.xml   rfc8888.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc strict="yes" ?>
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
<?rfc tocdepth="4"?> tf-avtcore-cc-feedback-message-09" number="8888" ipr="trust200902" obsoletes=""
<?rfc symrefs="yes"?> updates="" submissionType="IETF" consensus="true" xml:lang="en" tocInclude="true
<?rfc sortrefs="yes" ?> " tocDepth="4" symRefs="true" sortRefs="true" version="3">
<?rfc compact="yes" ?> <!-- xml2rfc v2v3 conversion 3.5.0 -->
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-ietf-avtcore-cc-feedback-message-09"
ipr="trust200902">
<front> <front>
<title abbrev="Congestion Control Feedback in RTCP">RTP Control Protocol <title abbrev="Congestion Control Feedback in RTCP">RTP Control Protocol
(RTCP) Feedback for Congestion Control</title> (RTCP) Feedback for Congestion Control</title>
<seriesInfo name="RFC" value="8888"/>
<author fullname="Zaheduzzaman Sarker" initials="Z." surname="Sarker"> <author fullname="Zaheduzzaman Sarker" initials="Z." surname="Sarker">
<organization>Ericsson AB</organization> <organization>Ericsson AB</organization>
<address> <address>
<postal> <postal>
<street>Torshamnsgatan 21</street> <street>Torshamnsgatan 23</street>
<city>Stockholm</city> <city>Stockholm</city>
<region/>
<region></region> <code>164 83</code>
<code>164 40</code>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<phone>+46 10 717 37 43</phone>
<phone>+46107173743</phone>
<email>zaheduzzaman.sarker@ericsson.com</email> <email>zaheduzzaman.sarker@ericsson.com</email>
</address> </address>
</author> </author>
<author fullname="Colin Perkins" initials="C." surname="Perkins">
<author fullname="Colin Perkins" initials="C. S." surname="Perkins">
<organization>University of Glasgow</organization> <organization>University of Glasgow</organization>
<address> <address>
<postal> <postal>
<street>School of Computing Science</street> <street>School of Computing Science</street>
<city>Glasgow</city> <city>Glasgow</city>
<code>G12 8QQ</code> <code>G12 8QQ</code>
<country>United Kingdom</country> <country>United Kingdom</country>
</postal> </postal>
<email>csp@csperkins.org</email> <email>csp@csperkins.org</email>
</address> </address>
</author> </author>
<author fullname="Varun Singh" initials="V." surname="Singh"> <author fullname="Varun Singh" initials="V." surname="Singh">
<organization abbrev="callstats.io">CALLSTATS I/O Oy</organization> <organization abbrev="callstats.io">CALLSTATS I/O Oy</organization>
<address> <address>
<postal> <postal>
<street>Annankatu 31-33 C 42</street> <street>Annankatu 31-33 C 42</street>
<city>Helsinki</city> <city>Helsinki</city>
<code>00100</code> <code>00100</code>
<country>Finland</country> <country>Finland</country>
</postal> </postal>
<email>varun.singh@iki.fi</email> <email>varun.singh@iki.fi</email>
<uri>https://www.callstats.io/</uri>
<uri>http://www.callstats.io/</uri>
</address> </address>
</author> </author>
<author fullname="Michael A. Ramalho" initials="M." surname="Ramalho">
<author fullname="Michael A. Ramalho" initials="M. A." surname="Ramalho"> <organization abbrev="AcousticComms">AcousticComms Consulting</organization
>
<address> <address>
<postal> <postal>
<street>6310 Watercrest Way Unit 203</street> <street>6310 Watercrest Way Unit 203</street>
<city>Lakewood Ranch</city> <city>Lakewood Ranch</city>
<region>FL</region> <region>FL</region>
<code>34202-5122</code> <code>34202-5122</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<phone>+1 732 832 9723</phone> <phone>+1 732 832 9723</phone>
<email>mar42@cornell.edu</email> <email>mar42@cornell.edu</email>
<uri>http://ramalho.webhop.info/</uri> <uri>http://ramalho.webhop.info/</uri>
</address> </address>
</author> </author>
<date month="January" year="2021"/>
<date day="2" month="November" year="2020" /> <keyword>Congestion control</keyword>
<keyword>feedback message</keyword>
<area>Transport</area> <keyword>RTP</keyword>
<keyword>RTCP</keyword>
<workgroup>IETF RMCAT Working Group</workgroup>
<keyword>Congestion control, feedback message, RTP, RTCP</keyword>
<abstract> <abstract>
<t> <t>
An effective RTP congestion control algorithm requires more fine-grained An effective RTP congestion control algorithm requires more fine-grained
feedback on packet loss, timing, and ECN marks than is provided by the feedback on packet loss, timing, and Explicit Congestion Notification (E CN) marks than is provided by the
standard RTP Control Protocol (RTCP) Sender Report (SR) and Receiver standard RTP Control Protocol (RTCP) Sender Report (SR) and Receiver
Report (RR) packets. Report (RR) packets.
This document describes an RTCP feedback message intended to enable This document describes an RTCP feedback message intended to enable
congestion control for interactive real-time traffic using RTP. The congestion control for interactive real-time traffic using RTP. The
feedback message is designed for use with a sender-based congestion feedback message is designed for use with a sender-based congestion
control algorithm, in which the receiver of an RTP flow sends RTCP control algorithm, in which the receiver of an RTP flow sends back to th
feedback packets to the sender containing the information the sender e sender RTCP
feedback packets containing the information the sender
needs to perform congestion control. needs to perform congestion control.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t>For interactive real-time traffic, such as video conferencing <t>For interactive real-time traffic, such as video conferencing
flows, the typical protocol choice is the Real-time Transport flows, the typical protocol choice is the Real-time Transport
Protocol (RTP) <xref target="RFC3550"/> running over the User Datagram Pro tocol (UDP). RTP Protocol (RTP) <xref target="RFC3550" format="default"/> running over the User Datagram Protocol (UDP). RTP
does not provide any guarantee of Quality of Service (QoS), reliability, does 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) <xref target="RFC3550"/> provides a mechan ism by which the the RTP Control Protocol (RTCP) <xref target="RFC3550" format="default"/> provides a mechanism by which the
receiver of an RTP flow can periodically send transport and media receiver of an RTP flow can periodically send transport and media
quality metrics to the sender of that RTP flow. This information can quality metrics to the sender of that RTP flow. This information can
be used by the sender to perform congestion control. In the absence be used by the sender to perform congestion control. In the absence
of standardized messages for this purpose, designers of congestion of standardized messages for this purpose, designers of congestion
control algorithms have developed proprietary RTCP messages that control algorithms have developed proprietary RTCP messages that
convey only those parameters needed for their respective designs. convey only those parameters needed for their respective designs.
As a direct result, the different congestion control As a direct result, the different congestion control
designs are not interoperable. To enable algorithm designs are not interoperable. To enable algorithm
evolution as well as interoperability across designs (e.g., different evolution as well as interoperability across designs (e.g., different
rate adaptation algorithms), it is highly desirable to have a generic rate adaptation algorithms), it is highly desirable to have a generic
skipping to change at line 135 skipping to change at line 106
quality metrics to the sender of that RTP flow. This information can quality metrics to the sender of that RTP flow. This information can
be used by the sender to perform congestion control. In the absence be used by the sender to perform congestion control. In the absence
of standardized messages for this purpose, designers of congestion of standardized messages for this purpose, designers of congestion
control algorithms have developed proprietary RTCP messages that control algorithms have developed proprietary RTCP messages that
convey only those parameters needed for their respective designs. convey only those parameters needed for their respective designs.
As a direct result, the different congestion control As a direct result, the different congestion control
designs are not interoperable. To enable algorithm designs are not interoperable. To enable algorithm
evolution as well as interoperability across designs (e.g., different evolution as well as interoperability across designs (e.g., different
rate adaptation algorithms), it is highly desirable to have a generic rate adaptation algorithms), it is highly desirable to have a generic
congestion control feedback format.</t> congestion control feedback format.</t>
<t>To help achieve interoperability for unicast RTP congestion control, <t>To help achieve interoperability for unicast RTP congestion control,
this memo proposes a common RTCP feedback packet format that can be used b this memo specifies a common RTCP feedback packet format that can be used
y by
NADA <xref target="RFC8698"></xref>, SCReAM <xref Network-Assisted Dynamic Adaptation
target="RFC8298"></xref>, Google Congestion Control (NADA) <xref target="RFC8698" format="default"/>,
<xref target="I-D.ietf-rmcat-gcc"></xref> and Shared Bottleneck Self-Clocked Rate Adaptation for Multimedia (SCReAM) <xref target="RFC8298
Detection <xref target="RFC8382"></xref>, and hopefully " format="default"/>, Google Congestion Control
also by future RTP congestion control algorithms.</t> <xref target="Google-GCC"/>, and Shared Bottleneck
Detection <xref target="RFC8382" format="default"/>, and, hopefully,
also by future RTP congestion control algorithms.
</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Terminology"> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in BCP "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only "<bcp14>SHOULD NOT</bcp14>",
when, they appear in all capitals, as shown here.</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
<t>In addition the terminology defined in <xref target="RFC3550"></xref>, are to be interpreted as described in BCP&nbsp;14
<xref target="RFC4585"></xref>, and <xref target="RFC5506"></xref> applies <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
.</t> when, they appear in all capitals, as shown here.</t>
<t>In addition, the terminology defined in <xref target="RFC3550" format="
default"/>,
<xref target="RFC4585" format="default"/>, and <xref target="RFC5506" form
at="default"/> applies.</t>
</section> </section>
<section anchor="feedback_message" numbered="true" toc="default">
<section anchor="feedback_message" title="RTCP Feedback for Congestion Contr <name>RTCP Feedback for Congestion Control</name>
ol"> <t>Based on an analysis of NADA <xref target="RFC8698" format="default"/>,
<t>Based on an analysis of NADA <xref target="RFC8698"></xref>, SCReAM <xref target="RFC8298" format="default"/>, Google
SCReAM <xref target="RFC8298"></xref>, Google Congestion Control <xref target="Google-GCC"/>, and
Congestion Control <xref target="I-D.ietf-rmcat-gcc"></xref> and Shared Bottleneck Detection <xref target="RFC8382" format="default"/>,
Shared Bottleneck Detection <xref target="RFC8382"></xref>,
the following per-RTP packet congestion control feedback information the following per-RTP packet congestion control feedback information
has been determined to be necessary:</t> has been determined to be necessary:</t>
<dl newline="false" spacing="normal">
<t> <dt>RTP Sequence Number:</dt><dd>The receiver of an RTP flow needs to fe
<list style="symbols"> ed
<t>RTP sequence number: The receiver of an RTP flow needs to feed
the sequence numbers of the received RTP packets back to the sender, s o the the sequence numbers of the received RTP packets back to the sender, s o the
sender can determine which packets were received and which were lost. sender can determine which packets were received and which were lost.
Packet loss is used as an indication of congestion by many congestion Packet loss is used as an indication of congestion by many congestion
control algorithms.</t> control algorithms.</dd>
<dt>Packet Arrival Time:</dt><dd>The receiver of an RTP flow needs to fe
<t>Packet Arrival Time: The receiver of an RTP flow needs to feed ed
the arrival time of each RTP packet back to the sender. Packet delay a nd/or the arrival time of each RTP packet back to the sender. Packet delay a nd/or
delay variation (jitter) is used as a congestion signal by some conges tion delay variation (jitter) is used as a congestion signal by some conges tion
control algorithms.</t> control algorithms.</dd>
<dt>Packet Explicit Congestion Notification (ECN) Marking:</dt><dd>If EC
<t>Packet Explicit Congestion Notification (ECN) Marking: If ECN N
<xref target="RFC3168"></xref>, <xref target="RFC6679"></xref> is <xref target="RFC3168" format="default"/> <xref target="RFC6679" forma
t="default"/> is
used, it is necessary to feed back the 2-bit ECN mark in received 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 RTP packets, indicating for each RTP packet whether it is marked
not-ECT, ECT(0), ECT(1), or ECN-CE. If the path used by the RTP not-ECT, ECT(0), ECT(1), or ECN Congestion Experienced (ECN-CE).
traffic is ECN capable the sender can use Congestion Experienced ("ECT" stands for "ECN-Capable Transport".) If the path used by the RT
(ECN-CE) marking information as a congestion control signal.</t> P
</list> traffic is ECN capable, the sender can use ECN-CE marking information
</t> as a congestion control signal.</dd>
</dl>
<t>Every RTP flow is identified by its Synchronization Source (SSRC) <t>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.</t> reports by SSRC, sending one report block per received SSRC.</t>
<t>As a practical matter, we note that host operating system (OS) <t>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 RTP packet arrival times at the
receiver, needs to be done with deliberate care. This is because the time receiver, needs to be done with deliberate care. This is because the time
duration of host OS interruptions can be significant relative to the duration of host OS interruptions can be significant relative to the
precision desired in the one-way delay estimates. Specifically, the send precision desired in the one-way delay estimates. Specifically, the send
time needs to be recorded at the last opportunity prior to transmitting 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 the RTP packet at the sender, and the arrival time at the receiver needs
to be recorded at the earliest available opportunity.</t> to be recorded at the earliest available opportunity.</t>
skipping to change at line 201 skipping to change at line 169
<t>As a practical matter, we note that host operating system (OS) <t>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 RTP packet arrival times at the
receiver, needs to be done with deliberate care. This is because the time receiver, needs to be done with deliberate care. This is because the time
duration of host OS interruptions can be significant relative to the duration of host OS interruptions can be significant relative to the
precision desired in the one-way delay estimates. Specifically, the send precision desired in the one-way delay estimates. Specifically, the send
time needs to be recorded at the last opportunity prior to transmitting 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 the RTP packet at the sender, and the arrival time at the receiver needs
to be recorded at the earliest available opportunity.</t> to be recorded at the earliest available opportunity.</t>
<section anchor="sec_ccfb" numbered="true" toc="default">
<section anchor="sec:ccfb" title="RTCP Congestion Control Feedback Report" <name>RTCP Congestion Control Feedback Report</name>
>
<t>Congestion control feedback can be sent as part of a regular <t>Congestion control feedback can be sent as part of a regular
scheduled RTCP report, or in an RTP/AVPF early feedback packet. scheduled RTCP report or in an RTP/AVPF early feedback packet.
If sent as early feedback, congestion control feedback MAY be If sent as early feedback, congestion control feedback <bcp14>MAY</bcp14
sent in a non-compound RTCP packet <xref target="RFC5506"></xref> > be
if the RTP/AVPF profile <xref target="RFC4585"></xref> or the sent in a non-compound RTCP packet <xref target="RFC5506" format="defaul
RTP/SAVPF profile <xref target="RFC5124"></xref> is used.</t> t"/>
if the RTP/AVPF profile <xref target="RFC4585" format="default"/> or the
RTP/SAVPF profile <xref target="RFC5124" format="default"/> is used.</t>
<t>Irrespective of how it is transported, the congestion control <t>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 type 205). The format of this RTCP packet is shown in
<xref target="rtcp-packet"></xref>:</t> <xref target="rtcp-packet" format="default"/>:</t>
<figure anchor="rtcp-packet">
<t><figure anchor="rtcp-packet" title="RTCP Congestion Control Feedback <name>RTCP Congestion Control Feedback Packet Format</name>
Packet Format"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[ 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=11 | PT = 205 | length |
|V=2|P| FMT=CCFB| 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 (32 bits) |
| Report Timestamp (32bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </figure>
]]></artwork> <t>The first 8 octets comprise a standard RTCP header, with
</figure></t> PT=205 and FMT=11 indicating that this is a congestion control
<t>The first eight octets comprise a standard RTCP header, with
PT=205 and FMT=CCFB indicating that this is a congestion control
feedback packet, and with the SSRC set to that of the sender of feedback packet, and with the SSRC set to that of the sender of
the RTCP packet. (NOTE TO RFC EDITOR: please replace CCFB here and the RTCP packet.</t>
in the above diagram with the IANA assigned RTCP feedback packet
type, and remove this note)</t>
<t>Section 6.1 of <xref target="RFC4585"></xref> requires the RTCP <t><xref target="RFC4585" sectionFormat="of" section="6.1"/>
requires the RTCP
header to be followed by the SSRC of the RTP flow being reported header to be followed by the SSRC of the RTP flow being reported
upon. Accordingly, the RTCP header is followed by a report block upon. Accordingly, the RTCP header is followed by a report block
for each SSRC from which RTP packets have been received, followed for each SSRC from which RTP packets have been received, followed
by a Report Timestamp.</t> by a Report Timestamp.</t>
<t>Each report block begins with the SSRC of the received RTP stream
<t>Each report block begins with the SSRC of the received RTP Stream
on which it is reporting. Following this, the report block contains a on 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 numbe r
in the range begin_seq to begin_seq+num_reports inclusive (calculated us ing in the range begin_seq to begin_seq+num_reports inclusive (calculated us ing
arithmetic modulo 65536 to account for possible sequence number wrap-aro und). arithmetic modulo 65536 to account for possible sequence number wrap-aro und).
If the number of 16-bit packet metric blocks included in the report 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 block is not a multiple of two, then 16 bits of zero padding <bcp14>MUST </bcp14> be
added after the last packet metric block, to align the end of the added after the last packet metric block, to align the end of the
packet metric blocks with the next 32 bit boundary. packet metric blocks with the next 32-bit boundary.
The value of num_reports MAY be zero, indicating that there are no The value of num_reports <bcp14>MAY</bcp14> be 0, indicating that there
are no
packet metric blocks included for that SSRC. packet metric blocks included for that SSRC.
Each report block MUST NOT include more than 16384 packet metric blocks Each report block <bcp14>MUST NOT</bcp14> include more than 16384 packet
(i.e., it MUST NOT report on more than one quarter of the sequence metric blocks
(i.e., it <bcp14>MUST NOT</bcp14> report on more than one quarter of the
sequence
number space in a single report). number space in a single report).
</t> </t>
<t> <t>
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:
<list style="symbols"> </t>
<t> <dl newline="false" spacing="normal">
Received (R, 1 bit): is a boolean to indicate if the packet was <dt>Received (R, 1 bit):</dt><dd>A boolean that indicates whether the
received. 0 represents that the packet was not yet received and packet was
the subsequent 15-bits (ECN and ATO) in this 16-bit packet received. &nbsp;0 indicates that the packet was not yet received a
metric block are also set to 0 and MUST be ignored. nd
1 represents that the packet was received and the subsequent the subsequent 15 bits (ECN and ATO) in this 16-bit packet
bits in the block need to be parsed. metric block are also set to 0 and <bcp14>MUST</bcp14> be ignored.
</t> 1 indicates that the packet was received and the subsequent
bits in the block need to be parsed.</dd>
<t> <dt>ECN (2 bits):</dt><dd>The echoed ECN mark of the packet. These bit
ECN (2 bits): is the echoed ECN mark of the packet. These s
are set to 00 if not received, or if ECN is not used. are set to 00 if not received or if ECN is not used.</dd>
</t> <dt>Arrival time offset (ATO, 13 bits):</dt><dd>The arrival time of
<t>
Arrival time offset (ATO, 13 bits): is the arrival time of
the RTP packet at the receiver, as an offset before the time the RTP packet at the receiver, as an offset before the time
represented by the Report Timestamp (RTS) field of this RTCP conge stion control represented by the Report Timestamp (RTS) field of this RTCP conge stion control
feedback report. The ATO field is in units of 1/1024 seconds feedback report. The ATO field is in units of 1/1024 seconds
(this unit is chosen to give exact offsets from the RTS field) (this unit is chosen to give exact offsets from the RTS field)
so, for example, an ATO value of 512 indicates that the so, for example, an ATO value of 512 indicates that the
corresponding RTP packet arrived exactly half a second before corresponding RTP packet arrived exactly half a second before
the time instant represented by the RTS field. the time instant represented by the RTS field.
If the measured value is greater than 8189/1024 seconds (the If the measured value is greater than 8189/1024 seconds (the
value that would be coded as 0x1FFD), the value 0x1FFE MUST value that would be coded as 0x1FFD), the value 0x1FFE <bcp14>MUST </bcp14>
be reported to indicate an over-range measurement. be reported to indicate an over-range measurement.
If the measurement is unavailable, or if the arrival time of If the measurement is unavailable or if the arrival time of
the RTP packet is after the time represented by the RTS field, the RTP packet is after the time represented by the RTS field,
then an ATO value of 0x1FFF MUST be reported for the packet. then an ATO value of 0x1FFF <bcp14>MUST</bcp14> be reported for th
</t> e packet.</dd>
</list> </dl>
</t>
<t>The RTCP congestion control feedback report packet concludes with <t>The RTCP congestion control feedback report packet concludes with
the Report Timestamp field (RTS, 32 bits). This denotes the time the Report Timestamp field (RTS, 32 bits). This denotes the time
instant on which this packet is reporting, and is the instant from instant on which this packet is reporting and is the instant from
which the arrival time offset values are calculated. which the arrival time offset values are calculated.
The value of RTS field is derived from the same clock used to generate The value of the RTS field is derived from the same clock used to genera te
the NTP timestamp field in RTCP Sender Report (SR) packets. It the NTP timestamp field in RTCP Sender Report (SR) packets. It
is formatted as the middle 32 bits of an NTP format timestamp, as is formatted as the middle 32 bits of an NTP format timestamp, as
described in Section 4 of <xref target="RFC3550"></xref>.</t> described in <xref target="RFC3550" sectionFormat="of" section="4"/>.</t
>
<t>RTCP congestion control feedback packets SHOULD include a report <t>RTCP Congestion Control Feedback Packets <bcp14>SHOULD</bcp14> includ
e a report
block for every active SSRC. The sequence block for every active SSRC. The sequence
number ranges reported on in consecutive reports for a given SSRC will number ranges reported on in consecutive reports for a given SSRC will
generally be contiguous, but overlapping reports MAY be sent (and need generally be contiguous, but overlapping reports <bcp14>MAY</bcp14> be s ent (and need
to be sent in cases where RTP packet reordering occurs across the to be sent in cases where RTP packet reordering occurs across the
boundary between consecutive reports). boundary between consecutive reports).
If an RTP packet was reported as received in one report, that packet If an RTP packet was reported as received in one report, that packet
MUST also be reported as received in any overlapping reports sent <bcp14>MUST</bcp14> also be reported as received in any overlapping repo
later that cover its sequence number range. rts 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 sent,
information in later reports updates that sent in previous reports information in later feedback reports may update any data sent in previous
for RTP packets included in both reports. reports for RTP packets included in both feedback reports.
</t> </t>
<t>RTCP Congestion Control Feedback Packets can be large if they are
<t>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 the RTCP Congestion Control Feedback Packet is too large to fit within the
path MTU, its sender SHOULD split it into multiple feedback packets. path MTU, its sender <bcp14>SHOULD</bcp14> split it into multiple feedba
The RTCP reporting interval SHOULD be chosen such that feedback packets ck packets.
The RTCP reporting interval <bcp14>SHOULD</bcp14> be chosen such that fe
edback packets
are sent often enough that they are small enough to fit within the path are sent often enough that they are small enough to fit within the path
MTU (<xref target="I-D.ietf-rmcat-rtp-cc-feedback"/> discusses how to MTU. (<xref target="I-D.ietf-rmcat-rtp-cc-feedback" format="default"/> d iscusses how to
choose the reporting interval; specifications for RTP congestion control choose the reporting interval; specifications for RTP congestion control
algorithms can also provide guidance).</t> algorithms can also provide guidance.)</t>
<t>If duplicate copies of a particular RTP packet are received, then the <t>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 arrival time of the first copy to arrive <bcp14>MUST</bcp14> be reported . If any of the
copies of the duplicated packet are ECN-CE marked, then an ECN-CE mark copies of the duplicated packet are ECN-CE marked, then an ECN-CE mark
MUST be reported that for packet; otherwise the ECN mark of the first <bcp14>MUST</bcp14> be reported for that packet; otherwise, the ECN mark of the first
copy to arrive is reported.</t> copy to arrive is reported.</t>
<t>If no packets are received from an SSRC in a reporting interval, <t>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 a report block <bcp14>MAY</bcp14> be sent with begin_seq set to the high
number previously received from that SSRC and num_reports set to zero est sequence
(or, the report can simply to omitted). The corresponding SR/RR packet 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 will have a non-increased extended highest sequence number received
field that will inform the sender that no packets have been 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 but it can ease processing to have that information available in the
congestion control feedback reports too.</t> congestion control feedback reports too.</t>
<t>A report block indicating that certain RTP packets were lost is <t>A report block indicating that certain RTP packets were lost is
not to be interpreted as a request to retransmit the lost packets. not to be interpreted as a request to retransmit the lost packets.
The receiver of such a report might choose to retransmit such packets, The 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.</t> there is no requirement that it do so.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Feedback Frequency and Overhead"> <name>Feedback Frequency and Overhead</name>
<t>There is a trade-off between speed and accuracy of reporting, and the <t>There is a trade-off between speed and accuracy of reporting, and the
overhead of the reports. <xref target="I-D.ietf-rmcat-rtp-cc-feedback"/> overhead of the reports. <xref target="I-D.ietf-rmcat-rtp-cc-feedback" for mat="default"/>
discusses this trade-off, suggests desirable RTCP feedback rates, and discusses this trade-off, suggests desirable RTCP feedback rates, and
provides guidance on how to configure the RTCP bandwidth fraction, etc., provides guidance on how to configure, for example, the RTCP bandwidth fra ction
to make appropriate use of the reporting block described in this memo. to make appropriate use of the reporting block described in this memo.
Specifications for RTP congestion control algorithms can also provide Specifications for RTP congestion control algorithms can also provide
guidance.</t> guidance.</t>
<t>It is generally understood that congestion control algorithms work <t>It is generally understood that congestion control algorithms work
better with more frequent feedback. better with more frequent feedback.
However, RTCP bandwidth and transmission rules put some upper limits However, RTCP bandwidth and transmission rules put some upper limits
on how frequently the RTCP feedback messages can be sent from an RTP on how frequently the RTCP feedback messages can be sent from an RTP
receiver to the RTP sender. 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 <xref target="I-D.ietf-rmcat-rtp-cc-feedback">< with high-rate media flows <xref target="I-D.ietf-rmcat-rtp-cc-feedback" f
/xref>. ormat="default"/>.
Analysis <xref target="feedback-requirements"></xref> has also shown Analysis <xref target="feedback-requirements" format="default"/> has also
shown
that some candidate congestion control algorithms can operate with less that some candidate congestion control algorithms can operate with less
frequent feedback, using a feedback interval range of 50-200ms. frequent feedback, using a feedback interval range of 50-200 ms.
Applications need to negotiate an appropriate congestion control Applications need to negotiate an appropriate congestion control
feedback interval at session setup time, based on the choice of feedback interval at session setup time, based on the choice of
congestion control algorithm, the expected media bit rate, and congestion control algorithm, the expected media bitrate, and
the acceptable feedback overhead. the acceptable feedback overhead.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Response to Loss of Feedback Packets"> <name>Response to Loss of Feedback Packets</name>
<t> <t>
Like all RTCP packets, RTCP congestion control feedback packets Like all RTCP packets, RTCP Congestion Control Feedback Packets
might be lost. All RTP congestion control algorithms MUST specify might be lost. All RTP congestion control algorithms <bcp14>MUST</bcp14>
specify
how they respond to the loss of feedback packets. how they respond to the loss of feedback packets.
</t> </t>
<t> <t>
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. packet.
If only a single congestion control feedback packet is lost, an If only a single congestion control feedback packet is lost, an
appropriate response is to assume that the level of congestion appropriate response is to assume that the level of congestion
has remained roughly the same as the previous report. However, has remained roughly the same as the previous report. However,
if multiple consecutive congestion control feedback packets are if multiple consecutive congestion control feedback packets are
lost, then the media sender SHOULD rapidly reduce its sending rate as lost, then the media sender <bcp14>SHOULD</bcp14> rapidly reduce its sen ding rate as
this likely indicates a path failure. The RTP circuit this likely indicates a path failure. The RTP circuit
breaker <xref target="RFC8083"/> provides further guidance. breaker specification <xref target="RFC8083" format="default"/> provides further guidance.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="SDP Signalling"> <name>SDP Signaling</name>
<t> <t>
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 th
Control feedback packet format defined in <xref target="feedback_message e use of the RTP Congestion
"/>. Control Feedback Packet format defined in <xref target="feedback_message
The ABNF definition of this SDP parameter extension is: " format="default"/>.
</t> The ABNF definition <xref target="RFC5234"/> of this SDP parameter exten
<figure> sion is:</t>
<artwork><![CDATA[ <sourcecode type="abnf"><![CDATA[
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"]]></sourcecode>
]]></artwork>
</figure>
<t> <t>
The payload type used with "ccfb" feedback MUST be the wildcard type ("* "). The payload type used with "ccfb" feedback <bcp14>MUST</bcp14> be the wi ldcard type ("*").
This implies that the congestion control feedback is sent This implies that the congestion control feedback is sent
for all payload types in use in the session, including any FEC and for all payload types in use in the session, including any Forward Error Correction (FEC) and
retransmission payload types. retransmission payload types.
An example of the resulting SDP attribute is: An example of the resulting SDP attribute is:
</t> </t>
<figure> <sourcecode name="" type="sdp"><![CDATA[
<artwork><![CDATA[ a=rtcp-fb:* ack ccfb]]></sourcecode>
a=rtcp-fb:* ack ccfb
]]></artwork>
</figure>
<t> <t>
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 <xref target="RFC4585"/ >. specified in <xref target="RFC4585" sectionFormat="of" section="4.2">the RTP/AVPF profile</xref>.
</t> </t>
<t> <t>
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 <bcp14>SHOULD</bcp14> 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 con
feedback mechanisms is received, the generated answer SHOULD choose trol
feedback mechanisms is received, the generated answer <bcp14>SHOULD</bcp
14> choose
the same congestion control feedback mechanism as in the original the same congestion control feedback mechanism as in the original
answer where possible. answer where possible.
</t> </t>
<t> <t>
When the SDP BUNDLE extension <xref target="I-D.ietf-mmusic-sdp-bundle-n egotiation"/> When the SDP BUNDLE extension <xref target="RFC8843" format="default"/>
is used for multiplexing, the "a=rtcp-fb:" attribute has multiplexing ca tegory is used for multiplexing, the "a=rtcp-fb:" attribute has multiplexing ca tegory
IDENTICAL-PER-PT <xref target="I-D.ietf-mmusic-sdp-mux-attributes"/>. IDENTICAL-PER-PT <xref target="RFC8859"/>.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Relation to RFC 6679"> <name>Relationship to RFC 6679</name>
<t> <t>
Use of Explicit Congestion Notification (ECN) with RTP is The use of Explicit Congestion Notification (ECN) with RTP is
described in <xref target="RFC6679"/>. That specifies how described in <xref target="RFC6679" format="default"/>, which specifies
to negotiate the use of ECN with RTP, and defines an RTCP ECN 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 Feedback Packet to carry ECN feedback reports. It uses an SDP
"a=ecn-capable-rtp:" attribute to negotiate use of ECN, and "a=ecn-capable-rtp:" attribute to negotiate the use of ECN, and
the "a=rtcp-fb:" attributes with the "nack" parameter "ecn" to the "a=rtcp-fb:" attribute with the "nack" parameter "ecn" to
negotiate the use of RTCP ECN Feedback Packets. negotiate the use of RTCP ECN Feedback Packets.</t>
</t>
<t> <t>
The RTCP ECN Feedback Packet is not useful when ECN is used with The RTCP ECN Feedback Packet is not useful when ECN is used with
the RTP Congestion Control Feedback Packet defined in this memo the RTP Congestion Control Feedback Packet defined in this memo,
since it provides duplicate information. When since it provides duplicate information. When
congestion control feedback is to be used with RTP and ECN, congestion control feedback is to be used with RTP and ECN,
the SDP offer generated MUST include an "a=ecn-capable-rtp:" the SDP offer generated <bcp14>MUST</bcp14> include an "a=ecn-capable-rt p:"
attribute to negotiate ECN support, along with an "a=rtcp-fb:" attribute to negotiate ECN support, along with an "a=rtcp-fb:"
attribute with the "ack" parameter "ccfb" to indicate that the attribute with the "ack" parameter "ccfb" to indicate that the
RTP Congestion Control Feedback Packet can be used. RTP Congestion Control Feedback Packet can be used.
The "a=rtcp-fb:" attribute MAY also include the "nack" parameter The "a=rtcp-fb:" attribute <bcp14>MAY</bcp14> also include the "nack" pa
"ecn", to indicate that the RTCP ECN Feedback Packet is also rameter
"ecn" to indicate that the RTCP ECN Feedback Packet is also
supported. If an SDP offer signals support for both RTP supported. If an SDP offer signals support for both RTP
Congestion Control Feedback Packets and the RTCP ECN Feedback Congestion Control Feedback Packets and the RTCP ECN Feedback
Packet, the answering party SHOULD signal support for one, but Packet, the answering party <bcp14>SHOULD</bcp14> signal support for one , but
not both, formats in its SDP answer to avoid sending duplicate not both, formats in its SDP answer to avoid sending duplicate
feedback. feedback.
</t> </t>
<t> <t>
When using ECN with RTP, the guidelines in Section 7.2 of When using ECN with RTP, the guidelines in <xref target="RFC6679" sectio
<xref target="RFC6679"/> MUST be followed to initiate the use of ECN in nFormat="of" section="7.2"/>
an <bcp14>MUST</bcp14> be followed to initiate the use of ECN in an
RTP session. The guidelines in Section 7.3 of <xref target="RFC6679"/> RTP session. The guidelines in <xref target="RFC6679" sectionFormat="of"
MUST also be followed about ongoing use of ECN within an RTP section="7.3"/> regarding the ongoing use of ECN within an RTP
session, with the exception that feedback is sent using the RTCP session <bcp14>MUST</bcp14> also be followed, with the exception that fe
edback is sent using the RTCP
Congestion Control Feedback Packets described in this memo rather Congestion Control Feedback Packets described in this memo rather
than using RTP ECN Feedback Packets. Similarly, the guidance than using RTP ECN Feedback Packets. Similarly, the guidance
in Section 7.4 of <xref target="RFC6679"/> around detecting failures in <xref target="RFC6679" sectionFormat="of" section="7.4"/>
MUST be followed, with the exception that the necessary information is related to detecting failures
<bcp14>MUST</bcp14> be followed, with the exception that the necessary i
nformation is
retrieved from the RTCP Congestion Control Feedback Packets rather than retrieved from the RTCP Congestion Control Feedback Packets rather than
from RTP ECN Feedback Packets. from RTP ECN Feedback Packets.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Design Rationale"> <name>Design Rationale</name>
<t>The primary function of RTCP SR/RR packets is to report statistics <t>The primary function of RTCP SR/RR packets is to report statistics
on the reception of RTP packets. The reception report blocks sent in on 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 memo packets to react effectively. The feedback format defined in this memo
provides such fine-grained feedback.</t> provides such fine-grained feedback.</t>
skipping to change at line 525 skipping to change at line 458
<t>The primary function of RTCP SR/RR packets is to report statistics <t>The primary function of RTCP SR/RR packets is to report statistics
on the reception of RTP packets. The reception report blocks sent in on 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 memo packets to react effectively. The feedback format defined in this memo
provides such fine-grained feedback.</t> provides such fine-grained feedback.</t>
<t>Several other RTCP extensions also provide more detailed feedback <t>Several other RTCP extensions also provide more detailed feedback
than SR/RR packets:</t> than SR/RR packets:</t>
<dl newline="false" spacing="normal">
<t> <dt>TMMBR:</dt>
<list style="hanging"> <dd>The codec control messages for the RTP/AVPF profile
<t hangText="TMMBR:">The Codec Control Messages for the RTP/AVPF profi <xref target="RFC5104" format="default"/> include a
le Temporary Maximum Media Stream Bit Rate Request (TMMBR) message. This
<xref target="RFC5104"></xref> include a Temporary Maximum Media Bit is used to convey a temporary maximum bitrate limitation from a receiver of RTP
Rate (TMMBR) message. This is used to convey a temporary maximum bit packets to their sender. Even
rate limitation from a receiver of RTP packets to their sender. Even
though it was not designed to replace congestion control, TMMBR has though it was not designed to replace congestion control, TMMBR has
been used as a means to do receiver based congestion control where been used as a means to do receiver-based congestion control where
the session bandwidth is high enough to send frequent TMMBR messages, the session bandwidth is high enough to send frequent TMMBR messages,
especially when used with non-compound RTCP packets <xref target="RF C5506"></xref>. especially when used with non-compound RTCP packets <xref target="RF C5506" format="default"/>.
This approach requires the receiver of the RTP packets to monitor This approach requires the receiver of the RTP packets to monitor
their reception, determine the level of congestion, and recommend their reception, determine the level of congestion, and recommend
a maximum bit rate suitable for current available bandwidth on the a maximum bitrate suitable for current available bandwidth on the
path; it also assumes that the RTP sender can/will respect that bit path; it also assumes that the RTP sender can&wj;/will respect that bi
rate. This is the opposite of the sender-based congestion control trate. This is the opposite of the sender-based congestion control
approach suggested in this memo, so TMMBR cannot be used to convey approach suggested in this memo, so TMMBR cannot be used to convey
the information needed for a sender-based congestion control. TMMBR the information needed for sender-based congestion control. TMMBR
could, however, be viewed a complementary mechanism that can inform could, however, be viewed as a complementary mechanism that can inform
the sender of the receiver's current view of acceptable maximum bit the sender of the receiver's current view of an acceptable maximum bit
rate. Mechanisms that convey the receiver's estimate of the maximum rate. Mechanisms that convey the receiver's estimate of the maximum
available bit-rate provide similar feedback. available bitrate provide similar feedback.
</t> </dd>
<dt>RTCP Extended Reports (XRs):</dt>
<t hangText="RTCP Extended Reports (XR):">Numerous RTCP extended <dd>Numerous RTCP XR blocks have been defined to report details of packe
report (XR) blocks have been defined to report details of packet t
loss, arrival times <xref target="RFC3611"/>, delay loss, arrival times <xref target="RFC3611" format="default"/>, delay
<xref target="RFC6843"/>, and ECN marking <xref target="RFC6679"/>. <xref target="RFC6843" format="default"/>, and ECN marking <xref targe
t="RFC6679" format="default"/>.
It is possible to combine several such XR blocks into a compound It is possible to combine several such XR blocks into a compound
RTCP packet, to report the detailed loss, arrival time, and ECN RTCP packet, to report the detailed loss, arrival time, and ECN
marking information needed for effective sender-based marking information needed for effective sender-based
congestion control. However, the result has high overhead both congestion control. However, the result has high overhead
in terms of bandwidth and complexity, due to the need to stack in terms of both bandwidth and complexity, due to the need to stack
multiple reports.</t> multiple reports.</dd>
<dt>Transport-wide Congestion Control:</dt>
<t hangText="Transport-wide Congestion Control:">The format <dd>The format
defined in this memo provides individual feedback on each SSRC. defined in this memo provides individual feedback on each SSRC.
An alternative is to add a header extension to each RTP packet, An alternative is to add a header extension to each RTP packet,
containing a single, transport-wide, packet sequence number, containing a single, transport-wide, packet sequence number,
then have the receiver send RTCP reports giving feedback on then have the receiver send RTCP reports giving feedback on
these additional sequence numbers these additional sequence numbers
<xref target="I-D.holmer-rmcat-transport-wide-cc-extensions"/>. <xref target="I-D.holmer-rmcat-transport-wide-cc-extensions" format="d
Such an approach adds the per-packet overhead of the header efault"/>.
extension (8 octets per packet in the referenced format), Such an approach increases the size of each RTP packet by 8 octets, du
but reduces the size of the feedback packets, and can simplify e to
the header extension, but reduces the size of the RTCP feedback packet
s,
and can simplify
the rate calculation at the sender if it maintains a single the rate calculation at the sender if it maintains a single
rate limit that applies to all RTP packets sent irrespective rate limit that applies to all RTP packets sent, irrespective
of their SSRC. Equally, the use of transport-wide feedback makes of their SSRC.
Equally, the use of transport-wide feedback makes
it more difficult to adapt the sending rate, or respond to lost it more difficult to adapt the sending rate, or respond to lost
packets, based on the reception and/or loss patterns observed packets, based on the reception and/or loss patterns observed
on a per-SSRC basis (for example, to perform differential rate on a per-SSRC basis (for example, to perform differential rate
control and repair for audio and video flows, based on knowledge control and repair for audio and video flows, based on knowledge
of what packets from each flow were lost). Transport-wide of what packets from each flow were lost). Transport-wide
feedback is also a less natural fit with the wider RTP framework, feedback is also a less natural fit with the wider RTP framework,
which makes extensive use of per-SSRC sequence numbers and which makes extensive use of per-SSRC sequence numbers and
feedback.</t> feedback.</dd>
</dl>
</list>
</t>
<t>Considering these issues, we believe it appropriate to design a <t>Considering these issues, we believe it appropriate to design a
new RTCP feedback mechanism to convey information for sender-based new 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 <xref target="feedback_message"></xref> RTCP packet described in <xref target="feedback_message" format="default"/ >
provides such a mechanism.</t> provides such a mechanism.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>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.</t>
</section> </section>
<!-- Possibly a 'Contributors' section ... --> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="IANA" title="IANA Considerations">
<t> <t>
The IANA is requested to register one new RTP/AVPF Transport-Layer The IANA has registered one new RTP/AVPF Transport-Layer
Feedback Message in the table for FMT values for RTPFB Payload Types Feedback Message in the "FMT Values for RTPFB Payload Types" table
<xref target="RFC4585"/> as defined in <xref target="sec:ccfb"/>: <xref target="RFC4585" format="default"/> as defined in <xref target="se
c_ccfb" format="default"/>:
</t> </t>
<dl indent="14" newline="false" spacing="compact">
<figure> <dt>Name:</dt><dd>CCFB</dd>
<artwork><![CDATA[ <dt>Long name:</dt><dd>RTP Congestion Control Feedback</dd>
Name: CCFB <dt>Value:</dt><dd>11</dd>
Long name: RTP Congestion Control Feedback <dt>Reference:</dt><dd>RFC 8888</dd>
Value: (to be assigned by IANA) </dl>
Reference: (RFC number of this document, when published)
]]></artwork>
</figure>
<t> <t>
The IANA is also requested to register one new SDP "rtcp-fb" attribute The IANA has also registered one new SDP "rtcp-fb" attribute
"ack" parameter, "ccfb", in the SDP ("ack" and "nack" Attribute Values) "ack" parameter, "ccfb", in the SDP '"ack" and "nack" Attribute Values'
registry: registry:
</t> </t>
<dl indent="14" newline="false" spacing="compact">
<figure> <dt>Value name:</dt><dd>ccfb</dd>
<artwork><![CDATA[ <dt>Long name:</dt><dd>Congestion Control Feedback</dd>
Value name: ccfb <dt>Usable with:</dt><dd>ack</dd>
Long name: Congestion Control Feedback <dt>Mux:</dt><dd>IDENTICAL-PER-PT</dd>
Usable with: ack <dt>Reference:</dt><dd>RFC 8888</dd>
Mux: IDENTICAL-PER-PT </dl>
Reference: (RFC number of this document, when published)
]]></artwork>
</figure>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>The security considerations of the RTP specification <t>The security considerations of the RTP specification
<xref target="RFC3550"/>, the applicable RTP profile (e.g., <xref target="RFC3550" format="default"/>, the applicable RTP profile (e.g
<xref target="RFC3551"/>, <xref target="RFC3711"/>, or .,
<xref target="RFC4585"/>), and the RTP congestion control algorithm <xref target="RFC3551" format="default"/>, <xref target="RFC3711" format="
that is in use (e.g., <xref target="RFC8698"/>, default"/>, or
<xref target="RFC8298"/>, <xref target="RFC4585" format="default"/>), and the RTP congestion control
<xref target="I-D.ietf-rmcat-gcc"/>, or algorithm
<xref target="RFC8382"/>) apply.</t> being used (e.g., <xref target="RFC8698" format="default"/>,
<xref target="RFC8298" format="default"/>,
<xref target="Google-GCC"/>, or
<xref target="RFC8382" format="default"/>) apply.</t>
<t>A receiver that intentionally generates inaccurate RTCP congestion <t>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 sending
at a greater rate than the path can support, thereby causing congestion on the at a greater rate than the path can support, thereby causing congestion on the
path. This will negatively impact the quality of experience of that path.
receiver, and potentially cause denial of service to other traffic This scenario will negatively impact the quality of experience
sharing the path and excessive resource usage at the media sender. 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 pa cket, Since RTP is an unreliable transport, a sender can intentionally drop a pa cket,
leaving a gap in the RTP sequence number space without causing serious har m, to leaving a gap in the RTP sequence number space without causing serious har m, to
check that the receiver is correctly reporting losses (this needs to be do ne with check that the receiver is correctly reporting losses. (This needs to be d one with
care and some awareness of the media data being sent, to limit impact on t he user care and some awareness of the media data being sent, to limit impact on t he user
experience).</t> experience.)</t>
<t>An on-path attacker that can modify RTCP Congestion Control Feedback
<t>An on-path attacker that can modify RTCP congestion control feedback Packets can change the reports to trick the sender into sending at either
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. an excessively high or excessively low rate, leading to denial of service.
The secure RTCP profile <xref target="RFC3711"/> can be used to authentica te The secure RTCP profile <xref target="RFC3711" format="default"/> can be u sed to authenticate
RTCP packets to protect against this attack.</t> RTCP packets to protect against this attack.</t>
<t>An off-path attacker that can spoof RTCP Congestion Control Feedback
<t>An off-patch 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 the 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 attacker needs to guess the SSRC and sequence number in addition to the
destination transport address. As with on-patch attacks, the secure RTCP destination transport address. As with on-path attacks, the secure RTCP
profile <xref target="RFC3711"/> can be used to authenticate RTCP packets profile <xref target="RFC3711" format="default"/> can be used to authentic
ate RTCP packets
to protect against this attack.</t> to protect against this attack.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.3168'?>
<?rfc include='reference.RFC.3550'?>
<?rfc include='reference.RFC.3551'?>
<?rfc include='reference.RFC.3711'?> <displayreference target="I-D.ietf-rmcat-rtp-cc-feedback" to="RTCP-Multimedia-
Feedback"/>
<?rfc include='reference.RFC.4585'?> <displayreference target="I-D.holmer-rmcat-transport-wide-cc-extensions" to="R
TP-Ext-for-CC"/>
<?rfc include='reference.RFC.5124'?>
<?rfc include='reference.RFC.5506'?>
<?rfc include='reference.RFC.6679'?>
<?rfc include='reference.RFC.8083'?>
<?rfc include='reference.RFC.8174'?>
<?rfc include='reference.I-D.ietf-mmusic-sdp-bundle-negotiation'?>
<?rfc include='reference.I-D.ietf-mmusic-sdp-mux-attributes'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-rmcat-rtp-cc-feedback'?>
<?rfc include="reference.I-D.ietf-rmcat-gcc"?>
<?rfc include='reference.RFC.3611'?>
<?rfc include='reference.RFC.5104'?>
<?rfc include='reference.RFC.6843'?>
<?rfc include="reference.RFC.8298"?> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3168.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3550.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3551.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3711.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4585.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5124.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5234.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5506.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6679.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8083.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<?rfc include="reference.RFC.8382"?> <!-- draft-ietf-mmusic-sdp-bundle-negotiation (RFC 8843) -->
<reference anchor="RFC8843" target="https://www.rfc-editor.org/info/rfc8843"
>
<front>
<title>Negotiating Media Multiplexing Using the Session Description Prot
ocol (SDP)</title>
<author initials="C" surname="Holmberg" fullname="Christer Holmberg">
<organization/>
</author>
<author initials="H" surname="Alvestrand" fullname="Harald Alvestrand">
<organization/>
</author>
<author initials="C" surname="Jennings" fullname="Cullen Jennings">
<organization/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8843"/>
<seriesInfo name="DOI" value="10.17487/RFC8843"/>
</reference>
<?rfc include='reference.RFC.8698"?> <!-- draft-ietf-mmusic-sdp-mux-attributes (RFC 8859) -->
<reference anchor="RFC8859" target="https://www.rfc-editor.org/info/rfc8859">
<front>
<title>A Framework for Session Description Protocol (SDP) Attributes When Mu
ltiplexing</title>
<author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar">
<organization/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8859"/>
<seriesInfo name="DOI" value="10.17487/RFC8859"/>
</reference>
<?rfc include="reference.I-D.holmer-rmcat-transport-wide-cc-extensions"?> </references>
<references>
<name>Informative References</name>
<!-- draft-ietf-rmcat-rtp-cc-feedback (Expired) -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-rm
cat-rtp-cc-feedback.xml"/>
<?rfc include="reference.I-D.alvestrand-rmcat-remb"?> <!-- draft-ietf-rmcat-gcc (Expired)
Have to do long way in order to fix "De Cicco" -->
<reference anchor='Google-GCC'>
<front>
<title>A Google Congestion Control Algorithm for Real-Time Communication</title>
<author initials='S' surname='Holmer' fullname='Stefan Holmer'>
<organization />
</author>
<author initials='H' surname='Lundin' fullname='Henrik Lundin'>
<organization />
</author>
<author initials='G' surname='Carlucci' fullname='Gaetano Carlucci'>
<organization />
</author>
<author initials='L' surname='De Cicco' fullname='Luca De Cicco'>
<organization />
</author>
<author initials='S' surname='Mascolo' fullname='Saverio Mascolo'>
<organization />
</author>
<date month='July' day='8' year='2016' />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-rmcat-gcc-02"/>
</reference>
<reference anchor="feedback-requirements" <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
target="://www.ietf.org/proceedings/95/slides/slides-95-rmcat-1 FC.3611.xml"/>
.pdf"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.5104.xml"/>
<title>RMCAT Feedback Requirements</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6843.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8298.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8382.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8698.xml"/>
<author> <!-- draft-holmer-rmcat-transport-wide-cc-extensions (Expired) -->
<organization></organization> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-holmer-
</author> rmcat-transport-wide-cc-extensions.xml"/>
<date /> <reference anchor="feedback-requirements" target="https://www.ietf.org/p
</front> roceedings/95/slides/slides-95-rmcat-1.pdf">
</reference> <front>
<title>RMCAT Feedback Requirements</title>
<author>
<organization/>
</author>
<date month="April" year="2016"/>
</front>
<refcontent>IETF 95</refcontent>
</reference>
</references>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>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
<contact fullname="David Hayes"/>,
<contact fullname="Stefan Holmer"/>,
<contact fullname="Randell Jesup"/>,
<contact fullname="Ingemar Johansson"/>,
<contact fullname="Jonathan Lennox"/>,
<contact fullname="Sergio Mena"/>,
<contact fullname="Nils Ohlmeier"/>,
<contact fullname="Magnus Westerlund"/>,
and
<contact fullname="Xiaoqing Zhu"/>
for their valuable feedback.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 144 change blocks. 
451 lines changed or deleted 484 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/