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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/