draft-ietf-avtcore-cc-feedback-message-00.txt | draft-ietf-avtcore-cc-feedback-message-01.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: May 3, 2018 University of Glasgow | Expires: September 3, 2018 University of Glasgow | |||
V. Singh | V. Singh | |||
callstats.io | callstats.io | |||
M. Ramalho | M. Ramalho | |||
Cisco Systems | Cisco Systems | |||
October 30, 2017 | March 2, 2018 | |||
RTP Control Protocol (RTCP) Feedback for Congestion Control | RTP Control Protocol (RTCP) Feedback for Congestion Control | |||
draft-ietf-avtcore-cc-feedback-message-00 | draft-ietf-avtcore-cc-feedback-message-01 | |||
Abstract | Abstract | |||
This document describes a feedback message intended to enable | This document describes an RTCP feedback message intended to enable | |||
congestion control for interactive real-time traffic. The RTP Media | congestion control for interactive real-time traffic using RTP. The | |||
Congestion Avoidance Techniques (RMCAT) Working Group formed a design | feedback message is designed for use with a sender-based congestion | |||
team to analyze feedback requirements from various congestion control | control algorithm, in which the receiver of an RTP flow sends RTCP | |||
algorithms and to design a generic feedback message to help ensure | feedback packets to the sender containing the information the sender | |||
interoperability across those algorithms. The feedback message is | needs to perform congestion control. | |||
designed for a sender-based congestion control, which means the | ||||
receiver of the media will send necessary feedback to the sender of | ||||
the media to perform the congestion control at the sender. | ||||
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 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 May 3, 2018. | This Internet-Draft will expire on September 3, 2018. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2017 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 | |||
(https://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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Feedback Message . . . . . . . . . . . . . . . . . . . . . . 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. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 7 | |||
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 | 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . 9 | 9.2. Informative References . . . . . . . . . . . . . . . . . 10 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
1. Introduction | 1. Introduction | |||
For interactive real-time traffic the typical protocol choice is | For interactive real-time traffic, such as video conferencing flows, | |||
Realtime Transport Protocol (RTP) over User Datagram Protocol (UDP). | the typical protocol choice is the Real-time Transport Protocol (RTP) | |||
RTP does not provide any guarantee of Quality of Service (QoS), | running over the User Datagram Protocol (UDP). RTP does not provide | |||
reliable or timely delivery and expects the underlying transport | any guarantee of Quality of Service (QoS), reliability, or timely | |||
protocol to do so. UDP alone certainly does not meet that | delivery, and expects the underlying transport protocol to do so. | |||
expectation. However, RTP Control Protocol (RTCP) provides a | UDP alone certainly does not meet that expectation. However, the RTP | |||
mechanism to periodically send transport and media metrics to the | Control Protocol (RTCP) provides a mechanism by which the receiver of | |||
media sender which can be utilized and extended for the purposes of | an RTP flow can periodically send transport and media quality metrics | |||
RMCAT congestion control. For a congestion control algorithm which | to the sender of that RTP flow. This information can be used by the | |||
operates at the media sender, RTCP messages can be transmitted from | sender to perform congestion control. In the absence of standardized | |||
the media receiver back to the media sender to enable congestion | messages for this purpose, designers of congestion control algorithms | |||
control. In the absence of standardized messages for this purpose, | have developed proprietary RTCP messages that convey only those | |||
the congestion control algorithm designers have designed proprietary | parameters needed for their respective designs. As a direct result, | |||
RTCP messages that convey only those parameters required for their | the different congestion control (i.e., rate adaptation) designs are | |||
respective designs. As a direct result, the different congestion | not interoperable. To enable algorithm evolution as well as | |||
control (a.k.a. rate adaptation) designs are not interoperable. To | interoperability across designs (e.g., different rate adaptation | |||
enable algorithm evolution as well as interoperability across designs | algorithms), it is highly desirable to have generic congestion | |||
(e.g., different rate adaptation algorithms), it is highly desirable | control feedback format. | |||
to have generic 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 format that can be used by | this memo proposes a common RTCP feedback packet format that can be | |||
NADA [I-D.ietf-rmcat-nada], SCReAM [I-D.ietf-rmcat-scream-cc], Google | used by NADA [I-D.ietf-rmcat-nada], SCReAM | |||
Congestion Control [I-D.ietf-rmcat-gcc] and Shared Bottleneck | [I-D.ietf-rmcat-scream-cc], Google Congestion Control | |||
Detection [I-D.ietf-rmcat-sbd], and hopefully future RTP congestion | ||||
control algorithms as well. | [I-D.ietf-rmcat-gcc] and Shared Bottleneck Detection | |||
[I-D.ietf-rmcat-sbd], and hopefully also by future RTP congestion | ||||
control algorithms. | ||||
2. Terminology | 2. Terminology | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "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. Feedback Message | 3. RTCP Feedback for Congestion Control | |||
The design team analyzed the feedback requirements from the different | Based on an analysis of NADA [I-D.ietf-rmcat-nada], SCReAM | |||
proposed candidate in RMCAT WG. The analysis showed some | [I-D.ietf-rmcat-scream-cc], Google Congestion Control | |||
commonalities between the proposed solution candidate and some can be | [I-D.ietf-rmcat-gcc] and Shared Bottleneck Detection | |||
derived from other information. The design team has agreed to have | [I-D.ietf-rmcat-sbd], the following per-RTP packet congestion control | |||
following packet information block in the feedback message to satisfy | feedback information has been determined to be necessary: | |||
different requirement analyzed. | ||||
o Packet Identifier : RTP sequence number. The RTP packet header | o RTP sequence number: The receiver of an RTP flow needs to feedback | |||
includes an incremental packet sequence number that the sender | the sequence numbers of the received RTP packets to the sender, so | |||
needs to correlate packets sent at the sender with packets | the sender can determine which packets were received and which | |||
received at the receiver. | were lost. Packet loss is used as an indication of congestion by | |||
many congestion control algorithms. | ||||
o Packet Arrival Time : Arrival time stamp at the receiver of the | o Packet Arrival Time: The receiver of an RTP flow needs to feedback | |||
media. The sender requires the arrival time stamp of the | the arrival time of each RTP packet to the sender. Packet delay | |||
respective packet to determine delay and jitter the packet had | and/or delay variation (jitter) is used as a congestion signal by | |||
experienced during transmission. In a sender based congestion | some congestion control algorithms. | |||
control solution the sender requires to keep track of the sent | ||||
packets - usually packet sequence number, packet size and packet | ||||
send time. With the packet arrival time the sender can detect the | ||||
delay and jitter information. Along with packet loss and delay | ||||
information the sender can estimate the available bandwidth and | ||||
thus adapt to the situation. | ||||
o Packet Explicit Congestion Notification (ECN) Marking : If ECN | o Packet Explicit Congestion Notification (ECN) Marking: If ECN | |||
[RFC3168] is used, it is necessary to report on the 2-bit ECN mark | [RFC3168], [RFC6679] is used, it is necessary to feedback the | |||
in received packets, indicating for each packet whether it is | 2-bit ECN mark in received RTP packets, indicating for each RTP | |||
marked not-ECT, ECT(0), ECT(1), or ECN-CE. If the path on which | packet whether it is marked not-ECT, ECT(0), ECT(1), or ECN-CE. | |||
the media traffic traversing is ECN capable then the sender can | If the path used by the RTP traffic is ECN capable the sender can | |||
use the Congestion Experienced (ECN-CE) marking information for | use Congestion Experienced (ECN-CE) marking information as a | |||
congestion control. It is important that the receiver sends the | congestion control signal. | |||
ECN-CE marking information of the packet back to the sender to | ||||
take the advantages of ECN marking. Note that how the receiver | ||||
gets the ECN marking information at application layer is out of | ||||
the scope of this design team. Additional information for ECN use | ||||
with RTP can be found at [RFC6679]. | ||||
The feedback messages can have one or more of the above information | Every RTP flow is identified by its Synchronization Source (SSRC) | |||
blocks. For RTCP based feedback message the packet information block | identifier. Accordingly, the RTCP feedback format needs to group its | |||
will be grouped by Synchronization Source (SSRC) identifier. | reports by SSRC, sending one report block per received SSRC. | |||
As a practical matter, we note that host Operating System (OS) | As a practical matter, we note that host operating system (OS) | |||
process interruptions can occur at inopportune times. Thus, the | process interruptions can occur at inopportune times. Accordingly, | |||
recording of the sent times at the sender and arrival times at the | recording RTP packet send times at the sender, and the corresponding | |||
receiver should be made with deliberate care. This is because the | RTP packet arrival times at the receiver, needs to be done with | |||
time duration of host OS interruptions can be significant relative to | deliberate care. This is because the time duration of host OS | |||
the precision desired in the one-way delay estimates. Specifically, | interruptions can be significant relative to the precision desired in | |||
the send time should be recorded at the latest opportunity prior to | the one-way delay estimates. Specifically, the send time needs to be | |||
outputting the media packet at the sender (e.g., socket or RTP API) | recorded at the last opportunity prior to transmitting the RTP packet | |||
and the arrival time at the receiver (e.g., socket or RTP API) should | at the sender, and the arrival time at the receiver needs to be | |||
be recorded at the earliest opportunity available to the receiver. | recorded at the earliest available opportunity. | |||
3.1. RTCP Congestion Control Feedback Report | 3.1. RTCP Congestion Control Feedback Report | |||
Congestion control feedback can be sent as part of a regular | Congestion control feedback can be sent as part of a regular | |||
scheduled RTCP report, or in an RTP/AVPF early feedback packet. If | scheduled RTCP report, or in an RTP/AVPF early feedback packet. If | |||
sent as early feedback, congestion control feedback MAY be sent in a | sent as early feedback, congestion control feedback MAY be sent in a | |||
non-compound RTCP packet [RFC5506] if the RTP/AVPF profile [RFC4585] | non-compound RTCP packet [RFC5506] if the RTP/AVPF profile [RFC4585] | |||
or the RTP/SAVPF profile [RFC5124] is used. | or the RTP/SAVPF profile [RFC5124] is used. | |||
Irrespective of how it is transported, the congestion control | Irrespective of how it is transported, the congestion control | |||
feedback is sent as a Transport Layer Feedback Message (RTCP packet | feedback is sent as a Transport Layer Feedback Message (RTCP packet | |||
type 205). The format of this RTCP packet is as follows: | 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 packet sender | | | SSRC of RTCP packet sender | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| SSRC of 1st media source | | | SSRC of 1st RTP Stream | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| begin_seq | end_seq | | | begin_seq | end_seq | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|L|ECN| Arrival time offset | ... . | |L|ECN| Arrival time offset | ... . | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
. . | . . | |||
. . | . . | |||
. . | . . | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| SSRC of nth media source | | | SSRC of nth RTP Stream | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| begin_seq | end_seq | | | begin_seq | end_seq | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|L|ECN| Arrival time offset | ... | | |L|ECN| Arrival time offset | ... | | |||
. . | . . | |||
. . | . . | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Report Timestamp (32bits) | | | Report Timestamp (32bits) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
The first 8 octets are the RTCP header, with PT=205 and FMT=CCFB | Figure 1: RTCP Congestion Control Feedback Packet Format | |||
specifying the remainder is a congestion control feedback packet, and | ||||
including the SSRC of the packet sender. (NOTE TO RFC EDITOR: please | The first eight octets comprise a standard RTCP header, with PT=205 | |||
replace CCFB here and in the above diagram with the IANA assigned | and FMT=CCFB indicating that this is a congestion control feedback | |||
RTCP feedback packet type) | packet, and with the SSRC set to that of the sender of the RTCP | |||
packet. (NOTE TO RFC EDITOR: please replace CCFB here and in the | ||||
above diagram with the IANA assigned RTCP feedback packet type, and | ||||
remove this note) | ||||
Section 6.1 of [RFC4585] requires the RTCP header to be followed by | Section 6.1 of [RFC4585] requires the RTCP header to be followed by | |||
the SSRC of the media source being reported upon. Accordingly, the | the SSRC of the RTP flow being reported upon. Accordingly, the RTCP | |||
RTCP header is followed by a report for each SSRC received, followed | header is followed by a report block for each SSRC from which RTP | |||
by the Report Timestamp. | packets have been received, followed by a Report Timestamp. | |||
The report for each SSRC received starts with the SSRC of that media | Each report block begins with the SSRC of the received RTP Stream on | |||
source. Then, each sequence number between the begin_seq and end_seq | which it is reporting. Following this, each sequence number between | |||
(both inclusive) is represented by a packet metric block of 16-bits | the begin_seq and end_seq (both inclusive; modulo 65535 to account | |||
that contains the L, ECN, and ATO fields. If an odd number of | for possible sequence number wrap-around) is represented by a 16-bit | |||
reports are included, i.e., end_seq - begin_seq is odd then 16 bits | packet metric block that contains the L, ECN, and ATO fields. If the | |||
of zero padding MUST be added after the last report, to align the | number of 16-bit packet metric blocks included in the report block is | |||
RTCP packet to a four (4) bytes boundary. The L, ECN, and ATO fields | not a multiple of two, then 16 bits of zero padding MUST be added | |||
are as follows: | after the last packet metric block, to align the end of the packet | |||
metric blocks with the next 32 bit boundary. In each packet metric | ||||
block, 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. | |||
o Arrival time offset (ATO, 13 bits): is the relative arrival time | o Arrival time offset (ATO, 13 bits): is the arrival time of the RTP | |||
of the RTP packets at the receiver before this feedback report was | packet at the receiver. It is measured as an offset from the time | |||
generated measured in milliseconds. It is calculated by | at which the RTCP congestion control feedback report packet is | |||
subtracting the reception timestamp of the RTP packet denoted by | sent. The arrival time offset is calculated by subtracting the | |||
this 16bit block and the timestamp (RTS) of this report. If the | reception time of the RTP packet denoted by this 16 bit packet | |||
measured value is greater than 8.189 seconds (the value that would | metric block from the Report Timestamp (RTS) field of the RTCP | |||
be coded as 0x1FFD), the value 0x1FFE MUST be reported to indicate | congestion control feedback report packet in which the packet | |||
an over-range positive measurement. If the measurement is | metric report block is contained. The arrival time offset is | |||
unavailable, the value 0x1FFF MUST be reported. | measured in units of 1/1024 seconds (this unit is chosen to give | |||
exact offsets from the RTS field). If the measured value is | ||||
greater than 8189/1024 seconds (the value that would be coded as | ||||
0x1FFD), the value 0x1FFE MUST be reported to indicate an over- | ||||
range positive measurement. If the measurement is unavailable, | ||||
the value 0x1FFF MUST be reported. | ||||
Report Timestamp (RTS, 32 bits): represents the timestamp when this | The RTCP congestion control feedback report packet concludes with the | |||
report was generated. The sender of the feedback message decides on | Report Timestamp field (RTS, 32 bits). This represents the time | |||
the wall-clock. Usually, it should be derived from the same wall- | instant when the report packet was generated. The value of RTS field | |||
clock that is used for timestamping RTP packets arrival . Consistency | is derived from the same wallclock used to generate the NTP timestamp | |||
in the unit and resolution (10th of millisecond should be good enough | field in RTCP Sender Report (SR) and Receiver Report (RR) packets. | |||
) is important here. In addition, the media sender can ask for a | It is formatted as the middle 32 bits of an NTP format timestamp, as | |||
specific resolution it wants. | described in Section 4 of [RFC3550]. | |||
RTCP congestion control feedback packets SHOULD include a report | ||||
block for each SSRC that is being congestion controlled. The | ||||
sequence number ranges reported on in consecutive reports for an SSRC | ||||
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 | ||||
the previous report for that SSRC). If overlapping reports are sent, | ||||
the information in the later report updates that in any previous | ||||
reports for packets included in both reports (although note that such | ||||
updated information will likely arrive too late to affect congestion | ||||
control decisions at the sender). Reports that cover RTP sequence | ||||
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 | ||||
SSRC, or behind the last begin_seq received from an SSRC, modulo | ||||
65535 to account for wrap-around, MUST be ignored. | ||||
If no packets are received from an SSRC in a reporting interval, then | ||||
no report block is sent for that SSRC. A regular SR/RR packet SHOULD | ||||
be sent instead, since the non-increased extended highest sequence | ||||
number received field of that SR/RR packet will inform the sender | ||||
that no packets have been received. | ||||
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, and the possible rates of feedback. | this trade-off, suggests desirable RTCP feedback rates, and provides | |||
guidance on how to configure the RTCP bandwidth fraction, etc., to | ||||
make appropriate use of the reporting block described in this memo. | ||||
Specifications for RTP congestion control algorithms can also provide | ||||
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 | on how frequently the RTCP feedback messages can be send from the RTP | |||
media receiver to the media 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 | |||
messages can be transmitted. The design team also have noted that | messages can be transmitted. It has also been noted that even if a | |||
even if a higher frequency of feedback is desired it is not viable if | higher frequency of feedback is desired it is not viable if the | |||
the feedback messages starts to compete against the media traffic on | feedback messages starts to compete against the RTP traffic on the | |||
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. Design Rationale | |||
The primary function of RTCP Sender Report (SR) / Receiver Report | The primary function of RTCP SR/RR packets is to report statistics on | |||
(RR) is to report the reception quality of media. The regular SR / | the reception of RTP packets. The reception report blocks sent in | |||
RR reports contain information about observed jitter, fractional | these packets contain information about observed jitter, fractional | |||
packet loss and cumulative packet loss. The original intent of this | packet loss, and cumulative packet loss. It was intended that this | |||
information was to assist flow and congestion control mechanisms. | information could be used to support congestion control algorithms, | |||
Even though it is possible to do congestion control based on | but experience has shown that it is not sufficient for that purpose. | |||
information provided in the SR/RR reports it is not sufficient to | An efficient congestion control algorithm requires more fine grained | |||
design an efficient congestion control algorithm for interactive | information on per packet reception quality than is provided by SR/RR | |||
real-time communication. An efficient congestion control algorithm | packets to react effectively. | |||
requires more fine grain information on per packet (see Section 3) to | ||||
react to the congestion or to avoid funder congestion on the path. | ||||
Codec Control Message for AVPF [RFC5104] defines Temporary Maximum | The Codec Control Messages for the RTP/AVPF profile [RFC5104] include | |||
Media Bit Rate (TMMBR) message which conveys a temporary maximum | a Temporary Maximum Media Bit Rate (TMMBR) message. This is used to | |||
bitrate limitation from the receiver of the media to the sender of | convey a temporary maximum bit rate limitation from a receiver of RTP | |||
the media. Even though it is not designed to replace congestion | packets to their sender. Even though it was not designed to replace | |||
control, TMMBR has been used as a means to do receiver based | congestion control, TMMBR has been used as a means to do receiver | |||
congestion control where the session bandwidth is high enough to send | based congestion control where the session bandwidth is high enough | |||
frequent TMMBR messages especially with reduced sized reports | to send frequent TMMBR messages, especially when used with non- | |||
[RFC5506]. This requires the receiver of the media to analyze the | compound RTCP packets [RFC5506]. This approach requires the receiver | |||
data reception, detect congestion level and recommend a maximum | of the RTP packets to monitor their reception, determine the level of | |||
bitrate suitable for current available bandwidth on the path with an | congestion, and recommend a maximum bit rate suitable for current | |||
assumption that the sender of the media always honors the TMMBR | available bandwidth on the path; it also assumes that the RTP sender | |||
message. This requirement is completely opposite of the sender based | can/will respect that bit rate. This is the opposite of the sender | |||
congestion control approach. Hence, TMMBR cannot be as a signaling | based congestion control approach suggested in this memo, so TMMBR | |||
means for a sender based congestion control mechanism. However, | cannot be used to convey the information needed for a sender based | |||
TMMBR should be viewed a complimentary signaling mechanism to | congestion control. TMMBR could, however, be viewed a complementary | |||
establish receiver's current view of acceptable maximum bitrate which | mechanism that can inform the sender of the receiver's current view | |||
a sender based congestion control should honor. | of acceptable maximum bit rate. | |||
There are number of RTCP eXtended Report (XR) blocks have been | A number of RTCP eXtended Report (XR) blocks have previously been | |||
defined for reporting of delay, loss and ECN marking. It is possible | defined to report details of packet loss, arrival times [RFC3611], | |||
to combine several XR blocks to report the loss and ECN marking at | delay [RFC6843], and ECN marking [RFC6679]. It is possible to | |||
the cost of overhead and complexity. However, there is no existing | combine several such XR blocks to report the detailed loss, arrival | |||
RTCP XR block to report packet arrival time. | time, and ECN marking marking information needed for effective | |||
sender-based congestion control. However, the result has high | ||||
overhead both in terms of bandwidth and complexity, due to the need | ||||
to stack multiple reports. | ||||
Considering the issues discussed here it is rational to design a new | Considering these issues, we believe it appropriate to design a new | |||
congestion control feedback signaling mechanism for sender based | RTCP feedback mechanism to convey information for sender based | |||
congestion control algorithm. | congestion control algorithms. The new congestion control feedback | |||
RTCP packet described in Section 3 provides such a mechanism. | ||||
6. Acknowledgements | 6. 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 Xiaoquing Zhu, Stefan | |||
Holmer, David, Ingemar Johansson and Randell Jesup for their valuable | Holmer, David, Ingemar Johansson, Randell Jesup, Ingemar Johansson, | |||
contribution to the discussions and to the document. | and Magnus Westerlund for their valuable contribution to the | |||
discussions and to the document. | ||||
7. IANA Considerations | 7. IANA Considerations | |||
IANA is requested to assign a new value in the "FMT Values for RTPFB | IANA is requested to assign a new value in the "FMT Values for RTPFB | |||
Payload Types" registry for the CCFB transport layer feedback packet | Payload Types" registry for the CCFB transport layer feedback packet | |||
described in Section 3.1. | described in Section 3.1. | |||
8. Security Considerations | 8. Security Considerations | |||
There is a risk of causing congestion if an on-path attacker modifies | The security considerations of the RTP specification [RFC3550], the | |||
the feedback messages in such a manner to make available bandwidth | applicable RTP profile (e.g., [RFC3551], [RFC3711], or [RFC4585]), | |||
greater than it is in reality. [More on security consideration TBD.] | 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-gcc], or [I-D.ietf-rmcat-sbd]) apply. | ||||
A receiver that intentionally generates inaccurate RTCP congestion | ||||
control feedback reports might be able trick the sender into sending | ||||
at a greater rate than the path can support, thereby congesting the | ||||
path. This will negatively impact the quality of experience of that | ||||
receiver. Since RTP is an unreliable transport, a sender can | ||||
intentionally leave a gap in the RTP sequence number space without | ||||
causing harm, to check that the receiver is correctly reporting | ||||
losses. | ||||
An on-path attacker that can modify RTCP congestion control feedback | ||||
packets can change the reports to trick the sender into sending at | ||||
either an excessively high or excessively low rate, leading to denial | ||||
of service. The secure RTCP profile [RFC3711] can be used to | ||||
authenticate RTCP packets to protect against this attack. | ||||
9. References | 9. References | |||
9.1. Normative References | 9.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, | DOI 10.17487/RFC2119, March 1997, <https://www.rfc- | |||
<https://www.rfc-editor.org/info/rfc2119>. | editor.org/info/rfc2119>. | |||
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition | [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition | |||
of Explicit Congestion Notification (ECN) to IP", | of Explicit Congestion Notification (ECN) to IP", | |||
RFC 3168, DOI 10.17487/RFC3168, September 2001, | RFC 3168, DOI 10.17487/RFC3168, September 2001, | |||
<https://www.rfc-editor.org/info/rfc3168>. | <https://www.rfc-editor.org/info/rfc3168>. | |||
[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- | |||
<https://www.rfc-editor.org/info/rfc3551>. | editor.org/info/rfc3551>. | |||
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., | [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., | |||
"RTP Control Protocol Extended Reports (RTCP XR)", | "RTP Control Protocol Extended Reports (RTCP XR)", | |||
RFC 3611, DOI 10.17487/RFC3611, November 2003, | RFC 3611, DOI 10.17487/RFC3611, November 2003, | |||
<https://www.rfc-editor.org/info/rfc3611>. | <https://www.rfc-editor.org/info/rfc3611>. | |||
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | ||||
Norrman, "The Secure Real-time Transport Protocol (SRTP)", | ||||
RFC 3711, DOI 10.17487/RFC3711, March 2004, | ||||
<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- | |||
<https://www.rfc-editor.org/info/rfc4585>. | editor.org/info/rfc4585>. | |||
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for | [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for | |||
Real-time Transport Control Protocol (RTCP)-Based Feedback | Real-time Transport Control Protocol (RTCP)-Based Feedback | |||
(RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February | (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February | |||
2008, <https://www.rfc-editor.org/info/rfc5124>. | 2008, <https://www.rfc-editor.org/info/rfc5124>. | |||
[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>. | |||
skipping to change at page 9, line 42 ¶ | skipping to change at page 10, line 31 ¶ | |||
[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-05 | Scheme for Real-Time Media", draft-ietf-rmcat-nada-04 | |||
(work in progress), September 2017. | (work in progress), March 2017. | |||
[I-D.ietf-rmcat-sbd] | [I-D.ietf-rmcat-sbd] | |||
Hayes, D., Ferlin, S., Welzl, M., and K. Hiorth, "Shared | Hayes, D., Ferlin, S., Welzl, M., and K. Hiorth, "Shared | |||
Bottleneck Detection for Coupled Congestion Control for | Bottleneck Detection for Coupled Congestion Control for | |||
RTP Media.", draft-ietf-rmcat-sbd-08 (work in progress), | RTP Media.", draft-ietf-rmcat-sbd-08 (work in progress), | |||
July 2017. | July 2017. | |||
[I-D.ietf-rmcat-scream-cc] | [I-D.ietf-rmcat-scream-cc] | |||
Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation | Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation | |||
for Multimedia", draft-ietf-rmcat-scream-cc-13 (work in | for Multimedia", draft-ietf-rmcat-scream-cc-10 (work in | |||
progress), October 2017. | 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 | ||||
(RTCP) Extended Report (XR) Block for Delay Metric | ||||
Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013, | ||||
<https://www.rfc-editor.org/info/rfc6843>. | ||||
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 | |||
Nemu Dialogue Systems Oy | CALLSTATS I/O Oy | |||
Runeberginkatu 4c A 4 | Annankatu 31-33 C 42 | |||
Helsinki 00100 | Helsinki 00100 | |||
Finland | Finland | |||
Email: varun.singh@iki.fi | Email: varun.singh@iki.fi | |||
URI: http://www.callstats.io/ | URI: http://www.callstats.io/ | |||
Michael A. Ramalho | Michael A. Ramalho | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
6310 Watercrest Way Unit 203 | 6310 Watercrest Way Unit 203 | |||
Lakewood Ranch, FL 34202 | Lakewood Ranch, FL 34202 | |||
End of changes. 48 change blocks. | ||||
188 lines changed or deleted | 240 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/ |