draft-ietf-avtcore-cc-feedback-message-08.txt | draft-ietf-avtcore-cc-feedback-message-09.txt | |||
---|---|---|---|---|
IETF RMCAT Working Group Z. Sarker | IETF RMCAT Working Group Z. Sarker | |||
Internet-Draft Ericsson AB | Internet-Draft Ericsson AB | |||
Intended status: Standards Track C. Perkins | Intended status: Standards Track C. Perkins | |||
Expires: March 6, 2021 University of Glasgow | Expires: May 6, 2021 University of Glasgow | |||
V. Singh | V. Singh | |||
callstats.io | callstats.io | |||
M. Ramalho | M. Ramalho | |||
September 2, 2020 | November 2, 2020 | |||
RTP Control Protocol (RTCP) Feedback for Congestion Control | RTP Control Protocol (RTCP) Feedback for Congestion Control | |||
draft-ietf-avtcore-cc-feedback-message-08 | draft-ietf-avtcore-cc-feedback-message-09 | |||
Abstract | Abstract | |||
This document describes an RTCP feedback message intended to enable | An effective RTP congestion control algorithm requires more fine- | |||
congestion control for interactive real-time traffic using RTP. The | grained feedback on packet loss, timing, and ECN marks than is | |||
feedback message is designed for use with a sender-based congestion | provided by the standard RTP Control Protocol (RTCP) Sender Report | |||
control algorithm, in which the receiver of an RTP flow sends RTCP | (SR) and Receiver Report (RR) packets. This document describes an | |||
feedback packets to the sender containing the information the sender | RTCP feedback message intended to enable congestion control for | |||
needs to perform congestion control. | interactive real-time traffic using RTP. The feedback message is | |||
designed for use with a sender-based congestion control algorithm, in | ||||
which the receiver of an RTP flow sends RTCP feedback packets to the | ||||
sender containing the information the sender needs to perform | ||||
congestion control. | ||||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on March 6, 2021. | This Internet-Draft will expire on May 6, 2021. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2020 IETF Trust and the persons identified as the | Copyright (c) 2020 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 | |||
skipping to change at page 2, line 20 ¶ | skipping to change at page 2, line 25 ¶ | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. RTCP Feedback for Congestion Control . . . . . . . . . . . . 3 | 3. RTCP Feedback for Congestion Control . . . . . . . . . . . . 3 | |||
3.1. RTCP Congestion Control Feedback Report . . . . . . . . . 4 | 3.1. RTCP Congestion Control Feedback Report . . . . . . . . . 4 | |||
4. Feedback Frequency and Overhead . . . . . . . . . . . . . . . 7 | 4. Feedback Frequency and Overhead . . . . . . . . . . . . . . . 7 | |||
5. Response to Loss of Feedback Packets . . . . . . . . . . . . 8 | 5. Response to Loss of Feedback Packets . . . . . . . . . . . . 8 | |||
6. SDP Signalling . . . . . . . . . . . . . . . . . . . . . . . 8 | 6. SDP Signalling . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
7. Relation to RFC 6679 . . . . . . . . . . . . . . . . . . . . 9 | 7. Relation to RFC 6679 . . . . . . . . . . . . . . . . . . . . 9 | |||
8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 9 | 8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 10 | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 | |||
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | |||
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . 12 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . 14 | 12.2. Informative References . . . . . . . . . . . . . . . . . 14 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
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 | |||
skipping to change at page 2, line 47 ¶ | skipping to change at page 3, line 4 ¶ | |||
the RTP Control Protocol (RTCP) [RFC3550] provides a mechanism by | the RTP Control Protocol (RTCP) [RFC3550] provides a mechanism by | |||
which the receiver of an RTP flow can periodically send transport and | which the receiver of an RTP flow can periodically send transport and | |||
media quality metrics to the sender of that RTP flow. This | media quality metrics to the sender of that RTP flow. This | |||
information can be used by the sender to perform congestion control. | information can be used by the sender to perform congestion control. | |||
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 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 proposes a common RTCP feedback packet format that can be | |||
used by NADA [RFC8698], SCReAM [RFC8298], Google Congestion Control | used by NADA [RFC8698], SCReAM [RFC8298], Google Congestion Control | |||
[I-D.ietf-rmcat-gcc] and Shared Bottleneck Detection [RFC8382], and | [I-D.ietf-rmcat-gcc] and Shared Bottleneck Detection [RFC8382], and | |||
hopefully also by future RTP congestion control algorithms. | 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 BCP | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | 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], [RFC3551], | In addition the terminology defined in [RFC3550], [RFC4585], and | |||
[RFC3611], [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 [I-D.ietf-rmcat-gcc] and Shared Bottleneck | |||
Detection [RFC8382], the following per-RTP packet congestion control | Detection [RFC8382], the following per-RTP packet congestion control | |||
feedback information has been determined to be necessary: | feedback information has been determined to be necessary: | |||
o RTP sequence number: The receiver of an RTP flow needs to feed the | o RTP sequence number: The receiver of an RTP flow needs to feed the | |||
sequence numbers of the received RTP packets back to the sender, | sequence numbers of the received RTP packets back to the sender, | |||
skipping to change at page 5, line 8 ¶ | skipping to change at page 5, line 8 ¶ | |||
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=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 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|L|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 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|L|ECN| Arrival time offset | ... | | |R|ECN| Arrival time offset | ... | | |||
. . | . . | |||
. . | . . | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Report Timestamp (32bits) | | | Report Timestamp (32bits) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
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 eight octets comprise a standard RTCP header, with PT=205 | |||
and FMT=CCFB indicating that this is a congestion control feedback | and FMT=CCFB indicating that this is a congestion control feedback | |||
skipping to change at page 6, line 13 ¶ | skipping to change at page 6, line 13 ¶ | |||
wrap-around). If the number of 16-bit packet metric blocks included | wrap-around). If the number of 16-bit packet metric blocks included | |||
in the report block is not a multiple of two, then 16 bits of zero | in the report block is not a multiple of two, then 16 bits of zero | |||
padding MUST be added after the last packet metric block, to align | padding MUST be added after the last packet metric block, to align | |||
the end of the packet metric blocks with the next 32 bit boundary. | the end of the packet metric blocks with the next 32 bit boundary. | |||
The value of num_reports MAY be zero, indicating that there are no | The value of num_reports MAY be zero, indicating that there are no | |||
packet metric blocks included for that SSRC. Each report block MUST | packet metric blocks included for that SSRC. Each report block MUST | |||
NOT include more than 16384 packet metric blocks (i.e., it MUST NOT | NOT include more than 16384 packet metric blocks (i.e., it MUST NOT | |||
report on more than one quarter of the sequence number space in a | report on more than one quarter of the sequence number space in a | |||
single report). | single report). | |||
The contents of each 16-bit packet metric block comprises the L, ECN, | The contents of each 16-bit packet metric block comprises the R, ECN, | |||
and ATO fields as follows: | and ATO fields as follows: | |||
o L (1 bit): is a boolean to indicate if the packet was received. 0 | o Received (R, 1 bit): is a boolean to indicate if the packet was | |||
represents that the packet was not yet received and all the | received. 0 represents that the packet was not yet received and | |||
subsequent bits (ECN and ATO) are also set to 0. 1 represents | the subsequent 15-bits (ECN and ATO) in this 16-bit packet metric | |||
that the packet was received and the subsequent bits in the block | block are also set to 0 and MUST be ignored. 1 represents that | |||
need to be parsed. | the packet was received and the subsequent bits in the block need | |||
to be parsed. | ||||
o ECN (2 bits): is the echoed ECN mark of the packet. These are set | o ECN (2 bits): is the echoed ECN mark of the packet. These are set | |||
to 00 if not received, or if ECN is not used. | 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 | o Arrival time offset (ATO, 13 bits): is the arrival time of the RTP | |||
packet at the receiver, as an offset before the time represented | 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 | |||
skipping to change at page 7, line 6 ¶ | skipping to change at page 7, line 7 ¶ | |||
derived from the same clock used to generate the NTP timestamp field | derived from the same clock used to generate the NTP timestamp field | |||
in RTCP Sender Report (SR) packets. It is formatted as the middle 32 | in RTCP Sender Report (SR) packets. It is formatted as the middle 32 | |||
bits of an NTP format timestamp, as described in Section 4 of | bits of an NTP format timestamp, as described in Section 4 of | |||
[RFC3550]. | [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 reports covering overlapping sequence | consecutive reports). If an RTP packet was reported as received in | |||
number ranges are sent, information in later reports updates that in | one report, that packet MUST also be reported as received in any | |||
sent previous reports for RTP packets included in both reports. If | overlapping reports sent later that cover its sequence number range. | |||
an RTP packet was reported as received in one report, that packet | If reports covering overlapping sequence number ranges are sent, | |||
MUST also be reported as received in any overlapping reports sent | information in later reports updates that sent in previous reports | |||
later that cover its sequence number range. | for RTP packets included in both 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 ([I-D.ietf-rmcat-rtp-cc-feedback] discusses | |||
how to choose the reporting interval; specifications for RTP | how to choose the reporting interval; specifications for RTP | |||
congestion control algorithms can also provide guidance). | congestion control algorithms can also provide guidance). | |||
skipping to change at page 8, line 30 ¶ | skipping to change at page 8, line 30 ¶ | |||
at session setup time, based on the choice of congestion control | at session setup time, based on the choice of congestion control | |||
algorithm, the expected media bit rate, and the acceptable feedback | algorithm, the expected media bit rate, 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. | |||
If only a single congestion control feedback packet is lost, an | RTCP packets do not contain a sequence number, so loss of feedback | |||
appropriate response is to assume that the level of congestion has | packets has to be inferred based on the time since the last feedback | |||
packet. If only a single congestion control feedback packet is lost, | ||||
an appropriate response is to assume that the level of congestion has | ||||
remained roughly the same as the previous report. However, if | 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 sender SHOULD rapidly reduce its sending rate as this likely | then the media sender SHOULD rapidly reduce its sending rate as this | |||
indicates a path failure. The RTP circuit breaker [RFC8083] provides | likely indicates a path failure. The RTP circuit breaker [RFC8083] | |||
further guidance. | provides further guidance. | |||
6. SDP Signalling | 6. SDP Signalling | |||
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:" SDP extension to indicate the use of the RTP Congestion | |||
Control feedback packet format defined in Section 3. The ABNF | Control feedback packet format defined in Section 3. The ABNF | |||
definition of this SDP parameter extension is: | definition 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 | |||
skipping to change at page 9, line 32 ¶ | skipping to change at page 9, line 33 ¶ | |||
When the SDP BUNDLE extension | When the SDP BUNDLE extension | |||
[I-D.ietf-mmusic-sdp-bundle-negotiation] is used for multiplexing, | [I-D.ietf-mmusic-sdp-bundle-negotiation] is used for multiplexing, | |||
the "a=rtcp-fb:" attribute has multiplexing category IDENTICAL-PER-PT | the "a=rtcp-fb:" attribute has multiplexing category IDENTICAL-PER-PT | |||
[I-D.ietf-mmusic-sdp-mux-attributes]. | [I-D.ietf-mmusic-sdp-mux-attributes]. | |||
7. Relation to RFC 6679 | 7. Relation to RFC 6679 | |||
Use of Explicit Congestion Notification (ECN) with RTP is described | Use of Explicit Congestion Notification (ECN) with RTP is described | |||
in [RFC6679]. That specifies how to negotiate the use of ECN with | in [RFC6679]. That specifies how to negotiate the use of ECN with | |||
RTP, and defines an RTCP ECN Feedback Packet to carry ECN feedback | RTP, and defines an RTCP ECN Feedback Packet to carry ECN feedback | |||
reports. It uses an SDP "a=ecn-capaable-rtp:" attribute to negotiate | reports. It uses an SDP "a=ecn-capable-rtp:" attribute to negotiate | |||
use of ECN, and the "a=rtcp-fb:" attributes with the "nack" parameter | use of ECN, and the "a=rtcp-fb:" attributes with the "nack" parameter | |||
"ecn" to negotiate the use of RTCP ECN Feedback Packets. | "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. Accordingly, when congestion control | provides duplicate information. When congestion control feedback is | |||
feedback is to be used with RTP and ECN, the SDP offer generated MUST | to be used with RTP and ECN, the SDP offer generated MUST include an | |||
include an "a=ecn-capable-rtp:" attribute to negotiate ECN support, | "a=ecn-capable-rtp:" attribute to negotiate ECN support, along with | |||
along with an "a=rtcp-fb:" attribute with the "ack" parameter "ccfb" | an "a=rtcp-fb:" attribute with the "ack" parameter "ccfb" to indicate | |||
to indicate that the RTP Congestion Control Feedback Packet is to be | that the RTP Congestion Control Feedback Packet can be used. The | |||
used for feedback. The "a=rtcp-fb:" attribute MUST NOT include the | "a=rtcp-fb:" attribute MAY also include the "nack" parameter "ecn", | |||
"nack" parameter "ecn", so the RTCP ECN Feedback Packet will not be | to indicate that the RTCP ECN Feedback Packet is also supported. If | |||
used. | an SDP offer signals support for both RTP Congestion Control Feedback | |||
Packets and the RTCP ECN Feedback Packet, the answering party SHOULD | ||||
signal support for one, but not both, formats in its SDP answer to | ||||
avoid sending duplicate feedback. | ||||
When using ECN with RTP, the guidelines in Section 7.2 of [RFC6679] | ||||
MUST be followed to initiate the use of ECN in an RTP session. The | ||||
guidelines in Section 7.3 of [RFC6679] MUST also be followed about | ||||
ongoing use of ECN within an RTP session, with the exception that | ||||
feedback is sent using the RTCP Congestion Control Feedback Packets | ||||
described in this memo rather than using RTP ECN Feedback Packets. | ||||
Similarly, the guidance in Section 7.4 of [RFC6679] around detecting | ||||
failures MUST be followed, with the exception that the necessary | ||||
information is retrieved from the RTCP Congestion Control Feedback | ||||
Packets rather than from RTP ECN Feedback Packets. | ||||
8. Design Rationale | 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 | |||
skipping to change at page 10, line 32 ¶ | skipping to change at page 10, line 49 ¶ | |||
especially when used with non-compound RTCP packets [RFC5506]. | especially when used with non-compound RTCP packets [RFC5506]. | |||
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 bit rate suitable for current available bandwidth on the | |||
path; it also assumes that the RTP sender can/will respect that | path; it also assumes that the RTP sender can/will respect that | |||
bit rate. This is the opposite of the sender-based congestion | bit rate. This is the opposite of the sender-based congestion | |||
control approach suggested in this memo, so TMMBR cannot be used | control approach suggested in this memo, so TMMBR cannot be used | |||
to convey the information needed for a sender-based congestion | to convey the information needed for a sender-based congestion | |||
control. TMMBR could, however, be viewed a complementary | control. TMMBR could, however, be viewed a complementary | |||
mechanism that can inform the sender of the receiver's current | mechanism that can inform the sender of the receiver's current | |||
view of acceptable maximum bit rate. The Received Estimated | view of acceptable maximum bit rate. Mechanisms that convey the | |||
Maximum Bit-rate (REMB) mechanism [I-D.alvestrand-rmcat-remb] | receiver's estimate of the maximum available bit-rate provide | |||
provides similar feedback. | similar feedback. | |||
RTCP Extended Reports (XR): Numerous RTCP extended report (XR) | RTCP Extended Reports (XR): Numerous RTCP extended report (XR) | |||
blocks have been defined to report details of packet loss, arrival | blocks have been defined to report details of packet loss, arrival | |||
times [RFC3611], delay [RFC6843], and ECN marking [RFC6679]. It | times [RFC3611], delay [RFC6843], and ECN marking [RFC6679]. It | |||
is possible to combine several such XR blocks into a compound RTCP | is possible to combine several such XR blocks into a compound RTCP | |||
packet, to report the detailed loss, arrival time, and ECN marking | packet, to report the detailed loss, arrival time, and ECN marking | |||
marking information needed for effective sender-based congestion | information needed for effective sender-based congestion control. | |||
control. However, the result has high overhead both in terms of | However, the result has high overhead both in terms of bandwidth | |||
bandwidth and complexity, due to the need to stack multiple | and complexity, due to the need to stack multiple reports. | |||
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 [I-D.holmer-rmcat-transport-wide-cc-extensions]. Such an | |||
approach adds the per-packet overhead of the header extension (8 | approach adds the per-packet overhead of the header extension (8 | |||
octets per packet in the referenced format), but reduces the size | octets per packet in the referenced format), but reduces the size | |||
of the feedback packets, and can simplify the rate calculation at | of the feedback packets, and can simplify the rate calculation at | |||
skipping to change at page 11, line 50 ¶ | skipping to change at page 12, line 17 ¶ | |||
Value: (to be assigned by IANA) | Value: (to be assigned by IANA) | |||
Reference: (RFC number of this document, when published) | Reference: (RFC number of this document, when published) | |||
The IANA is also requested to register one new SDP "rtcp-fb" | The IANA is also requested to register one new SDP "rtcp-fb" | |||
attribute "ack" parameter, "ccfb", in the SDP ("ack" and "nack" | attribute "ack" parameter, "ccfb", in the SDP ("ack" and "nack" | |||
Attribute Values) registry: | Attribute Values) 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 | ||||
Reference: (RFC number of this document, when published) | Reference: (RFC number of this document, when published) | |||
11. Security Considerations | 11. 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 that is in use (e.g., | |||
[RFC8698], [RFC8298], [I-D.ietf-rmcat-gcc], or [RFC8382]) apply. | [RFC8698], [RFC8298], [I-D.ietf-rmcat-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 trick the sender into sending | |||
at a greater rate than the path can support, thereby causing | 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 will negatively impact the quality of | |||
experience of that receiver. Since RTP is an unreliable transport, a | experience of that receiver, and potentially cause denial of service | |||
sender can intentionally leave a gap in the RTP sequence number space | to other traffic sharing the path and excessive resource usage at the | |||
without causing harm, to check that the receiver is correctly | media sender. Since RTP is an unreliable transport, a sender can | |||
reporting losses. | intentionally drop a packet, leaving a gap in the RTP sequence number | |||
space without causing serious harm, to check that the receiver is | ||||
correctly reporting losses (this needs to be done with care and some | ||||
awareness of the media data being sent, to limit impact on the user | ||||
experience). | ||||
An on-path attacker that can modify RTCP congestion control feedback | 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 | ||||
packets can similarly trick a sender into sending at an incorrect | ||||
rate, leading to denial of service. This attack is difficult, since | ||||
the attacker needs to guess the SSRC and sequence number in addition | ||||
to the destination transport address. As with on-patch attacks, the | ||||
secure RTCP profile [RFC3711] can be used to authenticate RTCP | ||||
packets to protect against this attack. | ||||
12. References | 12. References | |||
12.1. Normative References | 12.1. Normative References | |||
[I-D.ietf-mmusic-sdp-bundle-negotiation] | [I-D.ietf-mmusic-sdp-bundle-negotiation] | |||
Holmberg, C., Alvestrand, H., and C. Jennings, | Holmberg, C., Alvestrand, H., and C. Jennings, | |||
"Negotiating Media Multiplexing Using the Session | "Negotiating Media Multiplexing Using the Session | |||
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- | Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- | |||
negotiation-54 (work in progress), December 2018. | negotiation-54 (work in progress), December 2018. | |||
skipping to change at page 13, line 15 ¶ | skipping to change at page 13, line 40 ¶ | |||
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | |||
Jacobson, "RTP: A Transport Protocol for Real-Time | Jacobson, "RTP: A Transport Protocol for Real-Time | |||
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, | Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, | |||
July 2003, <https://www.rfc-editor.org/info/rfc3550>. | July 2003, <https://www.rfc-editor.org/info/rfc3550>. | |||
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and | [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and | |||
Video Conferences with Minimal Control", STD 65, RFC 3551, | Video Conferences with Minimal Control", STD 65, RFC 3551, | |||
DOI 10.17487/RFC3551, July 2003, | DOI 10.17487/RFC3551, July 2003, | |||
<https://www.rfc-editor.org/info/rfc3551>. | <https://www.rfc-editor.org/info/rfc3551>. | |||
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., | ||||
"RTP Control Protocol Extended Reports (RTCP XR)", | ||||
RFC 3611, DOI 10.17487/RFC3611, November 2003, | ||||
<https://www.rfc-editor.org/info/rfc3611>. | ||||
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | |||
Norrman, "The Secure Real-time Transport Protocol (SRTP)", | Norrman, "The Secure Real-time Transport Protocol (SRTP)", | |||
RFC 3711, DOI 10.17487/RFC3711, March 2004, | RFC 3711, DOI 10.17487/RFC3711, March 2004, | |||
<https://www.rfc-editor.org/info/rfc3711>. | <https://www.rfc-editor.org/info/rfc3711>. | |||
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, | [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, | |||
"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>. | |||
skipping to change at page 14, line 39 ¶ | skipping to change at page 15, line 11 ¶ | |||
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", draft-ietf-rmcat-gcc-02 (work in | |||
progress), July 2016. | progress), July 2016. | |||
[I-D.ietf-rmcat-rtp-cc-feedback] | [I-D.ietf-rmcat-rtp-cc-feedback] | |||
Perkins, C., "RTP Control Protocol (RTCP) Feedback for | Perkins, C., "RTP Control Protocol (RTCP) Feedback for | |||
Congestion Control in Interactive Multimedia Conferences", | Congestion Control in Interactive Multimedia Conferences", | |||
draft-ietf-rmcat-rtp-cc-feedback-05 (work in progress), | draft-ietf-rmcat-rtp-cc-feedback-05 (work in progress), | |||
November 2019. | November 2019. | |||
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., | ||||
"RTP Control Protocol Extended Reports (RTCP XR)", | ||||
RFC 3611, DOI 10.17487/RFC3611, November 2003, | ||||
<https://www.rfc-editor.org/info/rfc3611>. | ||||
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, | [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>. | |||
[RFC6843] Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol | [RFC6843] Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol | |||
(RTCP) Extended Report (XR) Block for Delay Metric | (RTCP) Extended Report (XR) Block for Delay Metric | |||
Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013, | Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013, | |||
<https://www.rfc-editor.org/info/rfc6843>. | <https://www.rfc-editor.org/info/rfc6843>. | |||
End of changes. 26 change blocks. | ||||
61 lines changed or deleted | 94 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |