draft-ietf-avtcore-cc-feedback-message-01.txt   draft-ietf-avtcore-cc-feedback-message-02.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: September 3, 2018 University of Glasgow Expires: January 16, 2019 University of Glasgow
V. Singh V. Singh
callstats.io callstats.io
M. Ramalho M. Ramalho
Cisco Systems Cisco Systems
March 2, 2018 July 15, 2018
RTP Control Protocol (RTCP) Feedback for Congestion Control RTP Control Protocol (RTCP) Feedback for Congestion Control
draft-ietf-avtcore-cc-feedback-message-01 draft-ietf-avtcore-cc-feedback-message-02
Abstract Abstract
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 RTCP
feedback packets to the sender containing the information the sender feedback packets to the sender containing the information the sender
needs to perform congestion control. needs to perform congestion control.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 September 3, 2018. This Internet-Draft will expire on January 16, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 18 skipping to change at page 2, line 18
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
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 . . . . . . . . . . . . . . . 6 4. Feedback Frequency and Overhead . . . . . . . . . . . . . . . 6
5. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 7 5. SDP Signalling . . . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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)
running over the User Datagram Protocol (UDP). RTP does not provide running over the User Datagram Protocol (UDP). RTP does not provide
any guarantee of Quality of Service (QoS), reliability, or timely any guarantee of Quality of Service (QoS), reliability, or timely
delivery, and expects the underlying transport protocol to do so. delivery, and expects the underlying transport protocol to do so.
UDP alone certainly does not meet that expectation. However, the RTP UDP alone certainly does not meet that expectation. However, the RTP
skipping to change at page 2, line 50 skipping to change at page 2, line 51
have developed proprietary RTCP messages that convey only those have developed proprietary RTCP messages that convey only those
parameters needed for their respective designs. As a direct result, parameters needed for their respective designs. As a direct result,
the different congestion control (i.e., rate adaptation) designs are the different congestion control (i.e., rate adaptation) designs are
not interoperable. To enable algorithm evolution as well as not interoperable. To enable algorithm evolution as well as
interoperability across designs (e.g., different rate adaptation interoperability across designs (e.g., different rate adaptation
algorithms), it is highly desirable to have generic congestion algorithms), it is highly desirable to have generic congestion
control feedback format. 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 [I-D.ietf-rmcat-nada], SCReAM used by NADA [I-D.ietf-rmcat-nada], SCReAM [RFC8298], Google
[I-D.ietf-rmcat-scream-cc], Google Congestion Control Congestion Control [I-D.ietf-rmcat-gcc] and Shared Bottleneck
Detection [RFC8382], and hopefully also by future RTP congestion
[I-D.ietf-rmcat-gcc] and Shared Bottleneck Detection
[I-D.ietf-rmcat-sbd], and hopefully also by future RTP congestion
control algorithms. 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
In addition the terminology defined in [RFC3550], [RFC3551], In addition the terminology defined in [RFC3550], [RFC3551],
[RFC3611], [RFC4585], and [RFC5506] applies. [RFC3611], [RFC4585], and [RFC5506] applies.
3. RTCP Feedback for Congestion Control 3. RTCP Feedback for Congestion Control
Based on an analysis of NADA [I-D.ietf-rmcat-nada], SCReAM Based on an analysis of NADA [I-D.ietf-rmcat-nada], SCReAM [RFC8298],
[I-D.ietf-rmcat-scream-cc], Google Congestion Control Google Congestion Control [I-D.ietf-rmcat-gcc] and Shared Bottleneck
[I-D.ietf-rmcat-gcc] and Shared Bottleneck Detection Detection [RFC8382], the following per-RTP packet congestion control
[I-D.ietf-rmcat-sbd], 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 feedback o RTP sequence number: The receiver of an RTP flow needs to feedback
the sequence numbers of the received RTP packets to the sender, so the sequence numbers of the received RTP packets to the sender, so
the sender can determine which packets were received and which the sender can determine which packets were received and which
were lost. Packet loss is used as an indication of congestion by were lost. Packet loss is used as an indication of congestion by
many congestion control algorithms. many congestion control algorithms.
o Packet Arrival Time: The receiver of an RTP flow needs to feedback o Packet Arrival Time: The receiver of an RTP flow needs to feedback
the arrival time of each RTP packet to the sender. Packet delay the arrival time of each RTP packet to the sender. Packet delay
skipping to change at page 4, line 32 skipping to change at page 4, line 31
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 | end_seq | | begin_seq | end_seq+1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|ECN| Arrival time offset | ... . |L|ECN| Arrival time offset | ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of nth RTP Stream | | SSRC of nth RTP Stream |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq | | begin_seq | end_seq+1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|ECN| Arrival time offset | ... | |L|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
skipping to change at page 5, line 18 skipping to change at page 5, line 18
packet. (NOTE TO RFC EDITOR: please replace CCFB here and in the packet. (NOTE TO RFC EDITOR: please replace CCFB here and in the
above diagram with the IANA assigned RTCP feedback packet type, and above diagram with the IANA assigned RTCP feedback packet type, and
remove this note) remove this note)
Section 6.1 of [RFC4585] requires the RTCP header to be followed by Section 6.1 of [RFC4585] requires the RTCP header to be followed by
the SSRC of the RTP flow being reported upon. Accordingly, the RTCP the SSRC of the RTP flow being reported upon. Accordingly, the RTCP
header is followed by a report block for each SSRC from which RTP header is followed by a report block for each SSRC from which RTP
packets have been received, followed by a Report Timestamp. packets have been received, followed by a Report Timestamp.
Each report block begins with the SSRC of the received RTP Stream on Each report block begins with the SSRC of the received RTP Stream on
which it is reporting. Following this, each sequence number between which it is reporting. Following this, the report block contains a
the begin_seq and end_seq (both inclusive; modulo 65535 to account 16-bit packet metric block for each RTP packet with sequence number,
for possible sequence number wrap-around) is represented by a 16-bit seq, in the range begin_seq <= seq < end_seq+1 (calculated using
packet metric block that contains the L, ECN, and ATO fields. If the arithmetic modulo 65535 to account for possible sequence number wrap-
number of 16-bit packet metric blocks included in the report block is around). If the number of 16-bit packet metric blocks included in
not a multiple of two, then 16 bits of zero padding MUST be added the report block is not a multiple of two, then 16 bits of zero
after the last packet metric block, to align the end of the packet padding MUST be added after the last packet metric block, to align
metric blocks with the next 32 bit boundary. In each packet metric the end of the packet metric blocks with the next 32 bit boundary.
block, the L, ECN, and ATO fields are as follows: Each report block MUST NOT include more than 16384 packet metric
blocks (i.e., it MUST NOT report on more than one quarter of the
sequence number space in a single report).
The contents of each 16-bit packet metric block comprises the L, ECN,
and ATO fields are as follows:
o L (1 bit): is a boolean to indicate if the packet was received. 0 o L (1 bit): is a boolean to indicate if the packet was received. 0
represents that the packet was not yet received and all the represents that the packet was not yet received and all the
subsequent bits (ECN and ATO) are also set to 0. 1 represent the subsequent bits (ECN and ATO) are also set to 0. 1 represent the
packet was received and the subsequent bits in the block need to packet was received and the subsequent bits in the block need to
be parsed. 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.
skipping to change at page 6, line 9 skipping to change at page 6, line 12
exact offsets from the RTS field). If the measured value is exact offsets from the RTS field). If the measured value is
greater than 8189/1024 seconds (the value that would be coded as greater than 8189/1024 seconds (the value that would be coded as
0x1FFD), the value 0x1FFE MUST be reported to indicate an over- 0x1FFD), the value 0x1FFE MUST be reported to indicate an over-
range positive measurement. If the measurement is unavailable, range positive measurement. If the measurement is unavailable,
the value 0x1FFF MUST be reported. the value 0x1FFF MUST be reported.
The RTCP congestion control feedback report packet concludes with the The RTCP congestion control feedback report packet concludes with the
Report Timestamp field (RTS, 32 bits). This represents the time Report Timestamp field (RTS, 32 bits). This represents the time
instant when the report packet was generated. The value of RTS field instant when the report packet was generated. The value of RTS field
is derived from the same wallclock used to generate the NTP timestamp is derived from the same wallclock used to generate the NTP timestamp
field in RTCP Sender Report (SR) and Receiver Report (RR) packets. field in RTCP Sender Report (SR) packets. It is formatted as the
It is formatted as the middle 32 bits of an NTP format timestamp, as middle 32 bits of an NTP format timestamp, as described in Section 4
described in Section 4 of [RFC3550]. of [RFC3550].
RTCP congestion control feedback packets SHOULD include a report RTCP congestion control feedback packets SHOULD include a report
block for each SSRC that is being congestion controlled. The block for each SSRC that is being congestion controlled. The
sequence number ranges reported on in consecutive reports for an SSRC sequence number ranges reported on in consecutive reports for an SSRC
SHOULD be consecutive and SHOULD NOT overlap (i.e., begin_seq for a SHOULD be consecutive and SHOULD NOT overlap (i.e., begin_seq for a
report is expected to be one greater, modulo 65535, than end_seq of report is expected to be one greater, modulo 65535, than end_seq of
the previous report for that SSRC). If overlapping reports are sent, the previous report for that SSRC). If overlapping reports are sent,
the information in the later report updates that in any previous the information in the later report updates that in any previous
reports for packets included in both reports (although note that such reports for packets included in both reports (although note that such
updated information will likely arrive too late to affect congestion updated information will likely arrive too late to affect congestion
control decisions at the sender). Reports that cover RTP sequence control decisions at the sender). Reports that cover RTP sequence
number ranges that are more than 16384 (i.e., one quarter of the number ranges that are more than 16384 (i.e., one quarter of the
sequence number space) ahead of the last end_seq received from an sequence number space) ahead of the last end_seq received from an
SSRC, or behind the last begin_seq received from an SSRC, modulo SSRC, or behind the last begin_seq received from an SSRC, modulo
65535 to account for wrap-around, MUST be ignored. 65535 to account for wrap-around, SHOULD be ignored. An exception to
this occurs if sender has sent RTP packets using more than one
quarter of the sequence number space since it last received an RTCP
congestion control feedback packet, then a report on recently sent
RTP packets ought to be accepted, to allow recovery from report
packet loss.
If no packets are received from an SSRC in a reporting interval, then If no packets are received from an SSRC in a reporting interval, a
no report block is sent for that SSRC. A regular SR/RR packet SHOULD report block MAY be sent with begin_seq and end_seq+1 both set to the
be sent instead, since the non-increased extended highest sequence highest sequence number previously received from that SSRC (or, the
number received field of that SR/RR packet will inform the sender report can simply to omitted). The corresponding SR/RR packet will
that no packets have been received. have a non-increased extended highest sequence number received field
that will inform the sender that no packets have been received, but
it can ease processing to have that information available in the
congestion control feedback reports too.
4. Feedback Frequency and Overhead 4. Feedback Frequency and Overhead
There is a trade-off between speed and accuracy of reporting, and the There is a trade-off between speed and accuracy of reporting, and the
overhead of the reports. [I-D.ietf-rmcat-rtp-cc-feedback] discusses overhead of the reports. [I-D.ietf-rmcat-rtp-cc-feedback] discusses
this trade-off, suggests desirable RTCP feedback rates, and provides this trade-off, suggests desirable RTCP feedback rates, and provides
guidance on how to configure the RTCP bandwidth fraction, etc., to guidance on how to configure the RTCP bandwidth fraction, etc., to
make appropriate use of the reporting block described in this memo. 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. guidance.
It is a general understanding that the congestion control algorithms It is a general understanding that the congestion control algorithms
will work better with more frequent feedback - per packet feedback. will work better with more frequent feedback - per packet 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 send from the RTP on how frequently the RTCP feedback messages can be send from the RTP
receiver to the RTP sender. It has been shown receiver to the RTP sender. It has been shown
[I-D.ietf-rmcat-rtp-cc-feedback] that in most cases a per frame [I-D.ietf-rmcat-rtp-cc-feedback] that in most cases a per frame
feedback is a reasonable assumption on how frequent the RTCP feedback feedback is a reasonable assumption on how frequent the RTCP feedback
skipping to change at page 7, line 11 skipping to change at page 7, line 24
feedback is a reasonable assumption on how frequent the RTCP feedback feedback is a reasonable assumption on how frequent the RTCP feedback
messages can be transmitted. It has also been noted that even if a messages can be transmitted. It has also been noted that even if a
higher frequency of feedback is desired it is not viable if the higher frequency of feedback is desired it is not viable if the
feedback messages starts to compete against the RTP traffic on the feedback messages starts to compete against the RTP traffic on the
feedback path during congestion period. Analyzing the feedback feedback path during congestion period. Analyzing the feedback
interval requirement [feedback-requirements] it can be seen that the interval requirement [feedback-requirements] it can be seen that the
candidate algorithms can perform with a feedback interval range of candidate algorithms can perform with a feedback interval range of
50-200ms. A value within this range need to be negotiated at session 50-200ms. A value within this range need to be negotiated at session
setup. setup.
5. Design Rationale 5. SDP Signalling
A new "ack" feedback parameter, "ccfb", is defined to indicate the
use of the RTP Congestion Control feedback packet format defined in
Section 3. The ABNF definition of this SDP parameter extension is:
rtcp-fb-ack-param = <See Section 4.2 of [RFC4584]>
rtcp-fb-ack-param =/ ccfb-par
ccfb-par = SP "ccfb"
The offer/answer rules for these SDP feedback parameters are
specified in the RTP/AVPF profile [RFC4585].
6. Design Rationale
The primary function of RTCP SR/RR packets is to report statistics on The primary function of RTCP SR/RR packets is to report statistics on
the reception of RTP packets. The reception report blocks sent in the reception of RTP packets. The reception report blocks sent in
these packets contain information about observed jitter, fractional these packets contain information about observed jitter, fractional
packet loss, and cumulative packet loss. It was intended that this packet loss, and cumulative packet loss. It was intended that this
information could be used to support congestion control algorithms, information could be used to support congestion control algorithms,
but experience has shown that it is not sufficient for that purpose. but experience has shown that it is not sufficient for that purpose.
An efficient congestion control algorithm requires more fine grained An efficient congestion control algorithm requires more fine grained
information on per packet reception quality than is provided by SR/RR information on per packet reception quality than is provided by SR/RR
packets to react effectively. packets to react effectively.
skipping to change at page 8, line 7 skipping to change at page 8, line 32
time, and ECN marking marking information needed for effective time, and ECN marking marking information needed for effective
sender-based congestion control. However, the result has high sender-based congestion control. However, the result has high
overhead both in terms of bandwidth and complexity, due to the need overhead both in terms of bandwidth and complexity, due to the need
to stack multiple reports. to stack multiple reports.
Considering these issues, we believe it appropriate to design a new Considering these issues, we believe it appropriate to design a new
RTCP feedback mechanism to convey information for sender based RTCP feedback mechanism to convey information for sender based
congestion control algorithms. The new congestion control feedback congestion control algorithms. The new congestion control feedback
RTCP packet described in Section 3 provides such a mechanism. RTCP packet described in Section 3 provides such a mechanism.
6. Acknowledgements 7. Acknowledgements
This document is an outcome of RMCAT design team discussion. We This document is an outcome of RMCAT design team discussion. We
would like to thank all participants specially Xiaoquing Zhu, Stefan would like to thank all participants specially Sergio Mena, Xiaoquing
Holmer, David, Ingemar Johansson, Randell Jesup, Ingemar Johansson, Zhu, Stefan Holmer, David, Ingemar Johansson, Randell Jesup, Ingemar
and Magnus Westerlund for their valuable contribution to the Johansson, and Magnus Westerlund for their valuable contribution to
discussions and to the document. the discussions and to the document.
7. IANA Considerations 8. IANA Considerations
IANA is requested to assign a new value in the "FMT Values for RTPFB The IANA is requested to register one new RTP/AVPF Transport-Layer
Payload Types" registry for the CCFB transport layer feedback packet Feedback Message in the table for FMT values for RTPFB Payload Types
described in Section 3.1. [RFC4585] as defined in Section 3.1:
8. Security Considerations Name: CCFB
Long name: RTP Congestion Control Feedback
Value: (to be assigned by IANA)
Reference: (RFC number of this document, when published)
The IANA is also requested to register one new SDP "rtcp-fb"
attribute "ack" parameter, "ccfb", in the SDP ("ack" and "nack"
Attribute Values) registry:
Value name: ccfb
Long name: Congestion Control Feedback
Usable with: ack
Reference: (RFC number of this document, when published)
9. 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.,
[I-D.ietf-rmcat-nada], [I-D.ietf-rmcat-scream-cc], [I-D.ietf-rmcat-nada], [RFC8298], [I-D.ietf-rmcat-gcc], or [RFC8382])
[I-D.ietf-rmcat-gcc], or [I-D.ietf-rmcat-sbd]) apply. 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 congesting the at a greater rate than the path can support, thereby congesting the
path. This will negatively impact the quality of experience of that path. This will negatively impact the quality of experience of that
receiver. Since RTP is an unreliable transport, a sender can receiver. Since RTP is an unreliable transport, a sender can
intentionally leave a gap in the RTP sequence number space without intentionally leave a gap in the RTP sequence number space without
causing harm, to check that the receiver is correctly reporting causing harm, to check that the receiver is correctly reporting
losses. losses.
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.
9. References 10. References
9.1. Normative References 10.1. Normative References
[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-03 (work in progress), draft-ietf-rmcat-rtp-cc-feedback-03 (work in progress),
November 2016. November 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
skipping to change at page 10, line 15 skipping to change at page 11, line 5
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, DOI 10.17487/RFC5506, April and Consequences", RFC 5506, DOI 10.17487/RFC5506, April
2009, <https://www.rfc-editor.org/info/rfc5506>. 2009, <https://www.rfc-editor.org/info/rfc5506>.
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN) and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August
2012, <https://www.rfc-editor.org/info/rfc6679>. 2012, <https://www.rfc-editor.org/info/rfc6679>.
9.2. Informative References 10.2. Informative References
[feedback-requirements] [feedback-requirements]
"RMCAT Feedback Requirements", "RMCAT Feedback Requirements",
<://www.ietf.org/proceedings/95/slides/slides-95-rmcat- <://www.ietf.org/proceedings/95/slides/slides-95-rmcat-
1.pdf>. 1.pdf>.
[I-D.ietf-rmcat-gcc] [I-D.ietf-rmcat-gcc]
Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S. Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S.
Mascolo, "A Google Congestion Control Algorithm for Real- Mascolo, "A Google Congestion Control Algorithm for Real-
Time Communication", draft-ietf-rmcat-gcc-02 (work in Time Communication", draft-ietf-rmcat-gcc-02 (work in
progress), July 2016. progress), July 2016.
[I-D.ietf-rmcat-nada] [I-D.ietf-rmcat-nada]
Zhu, X., Pan, R., Ramalho, M., Cruz, S., Jones, P., Fu, Zhu, X., Pan, R., Ramalho, M., Cruz, S., Jones, P., Fu,
J., and S. D'Aronco, "NADA: A Unified Congestion Control J., and S. D'Aronco, "NADA: A Unified Congestion Control
Scheme for Real-Time Media", draft-ietf-rmcat-nada-04 Scheme for Real-Time Media", draft-ietf-rmcat-nada-04
(work in progress), March 2017. (work in progress), March 2017.
[I-D.ietf-rmcat-sbd]
Hayes, D., Ferlin, S., Welzl, M., and K. Hiorth, "Shared
Bottleneck Detection for Coupled Congestion Control for
RTP Media.", draft-ietf-rmcat-sbd-08 (work in progress),
July 2017.
[I-D.ietf-rmcat-scream-cc]
Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation
for Multimedia", draft-ietf-rmcat-scream-cc-10 (work in
progress), July 2017.
[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>.
[RFC8298] Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation
for Multimedia", RFC 8298, DOI 10.17487/RFC8298, December
2017, <https://www.rfc-editor.org/info/rfc8298>.
[RFC8382] Hayes, D., Ed., Ferlin, S., Welzl, M., and K. Hiorth,
"Shared Bottleneck Detection for Coupled Congestion
Control for RTP Media", RFC 8382, DOI 10.17487/RFC8382,
June 2018, <https://www.rfc-editor.org/info/rfc8382>.
Authors' Addresses Authors' Addresses
Zaheduzzaman Sarker Zaheduzzaman Sarker
Ericsson AB Ericsson AB
Luleae Luleae
Sweden Sweden
Phone: +46107173743 Phone: +46107173743
Email: zaheduzzaman.sarker@ericsson.com Email: zaheduzzaman.sarker@ericsson.com
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
School of Computing Science School of Computing Science
Glasgow G12 8QQ Glasgow G12 8QQ
United Kingdom United Kingdom
Email: csp@csperkins.org Email: csp@csperkins.org
Varun Singh Varun Singh
CALLSTATS I/O Oy CALLSTATS I/O Oy
 End of changes. 27 change blocks. 
68 lines changed or deleted 104 lines changed or added

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