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