draft-ietf-avtcore-cc-feedback-message-04.txt | draft-ietf-avtcore-cc-feedback-message-05.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: January 9, 2020 University of Glasgow | Expires: May 7, 2020 University of Glasgow | |||
V. Singh | V. Singh | |||
callstats.io | callstats.io | |||
M. Ramalho | M. Ramalho | |||
Cisco Systems | November 4, 2019 | |||
July 8, 2019 | ||||
RTP Control Protocol (RTCP) Feedback for Congestion Control | RTP Control Protocol (RTCP) Feedback for Congestion Control | |||
draft-ietf-avtcore-cc-feedback-message-04 | draft-ietf-avtcore-cc-feedback-message-05 | |||
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 39 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on January 9, 2020. | This Internet-Draft will expire on May 7, 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 18 ¶ | skipping to change at page 2, line 17 ¶ | |||
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 . . . . . . . . . . . . . . . 7 | 4. Feedback Frequency and Overhead . . . . . . . . . . . . . . . 7 | |||
5. Response to Loss of Feedback Packets . . . . . . . . . . . . 8 | 5. Response to Loss of Feedback Packets . . . . . . . . . . . . 7 | |||
6. SDP Signalling . . . . . . . . . . . . . . . . . . . . . . . 8 | 6. SDP Signalling . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
7. Relation to RFC 6679 . . . . . . . . . . . . . . . . . . . . 9 | 7. Relation to RFC 6679 . . . . . . . . . . . . . . . . . . . . 8 | |||
8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 9 | 8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 9 | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 | |||
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . 12 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . 13 | 12.2. Informative References . . . . . . . . . . . . . . . . . 13 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
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. | |||
skipping to change at page 10, line 5 ¶ | skipping to change at page 9, line 23 ¶ | |||
8. Design Rationale | 8. Design Rationale | |||
The primary function of RTCP SR/RR packets is to report statistics on | The primary function of RTCP SR/RR packets is to report statistics on | |||
the reception of RTP packets. The reception report blocks sent in | the reception of RTP packets. The reception report blocks sent in | |||
these packets contain information about observed jitter, fractional | these packets contain information about observed jitter, fractional | |||
packet loss, and cumulative packet loss. It was intended that this | packet loss, and cumulative packet loss. It was intended that this | |||
information could be used to support congestion control algorithms, | information could be used to support congestion control algorithms, | |||
but experience has shown that it is not sufficient for that purpose. | but experience has shown that it is not sufficient for that purpose. | |||
An efficient congestion control algorithm requires more fine grained | An efficient congestion control algorithm requires more fine grained | |||
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. The feedback format defined in this | |||
memo provides such fine grained feedback. | ||||
The Codec Control Messages for the RTP/AVPF profile [RFC5104] include | Several other RTCP extensions also provide more detailed feedback | |||
a Temporary Maximum Media Bit Rate (TMMBR) message. This is used to | than SR/RR packets: | |||
convey a temporary maximum bit rate limitation from a receiver of RTP | ||||
packets to their sender. Even though it was not designed to replace | ||||
congestion control, TMMBR has been used as a means to do receiver | ||||
based congestion control where the session bandwidth is high enough | ||||
to send frequent TMMBR messages, especially when used with non- | ||||
compound RTCP packets [RFC5506]. This approach requires the receiver | ||||
of the RTP packets to monitor their reception, determine the level of | ||||
congestion, and recommend a maximum bit rate suitable for current | ||||
available bandwidth on the path; it also assumes that the RTP sender | ||||
can/will respect that bit rate. This is the opposite of the sender | ||||
based congestion control approach suggested in this memo, so TMMBR | ||||
cannot be used to convey the information needed for a sender based | ||||
congestion control. TMMBR could, however, be viewed a complementary | ||||
mechanism that can inform the sender of the receiver's current view | ||||
of acceptable maximum bit rate. | ||||
A number of RTCP eXtended Report (XR) blocks have previously been | TMMBR: The Codec Control Messages for the RTP/AVPF profile [RFC5104] | |||
defined to report details of packet loss, arrival times [RFC3611], | include a Temporary Maximum Media Bit Rate (TMMBR) message. This | |||
delay [RFC6843], and ECN marking [RFC6679]. It is possible to | is used to convey a temporary maximum bit rate limitation from a | |||
combine several such XR blocks to report the detailed loss, arrival | receiver of RTP packets to their sender. Even though it was not | |||
time, and ECN marking marking information needed for effective | designed to replace congestion control, TMMBR has been used as a | |||
sender-based congestion control. However, the result has high | means to do receiver based congestion control where the session | |||
overhead both in terms of bandwidth and complexity, due to the need | bandwidth is high enough to send frequent TMMBR messages, | |||
to stack multiple reports. | especially when used with non-compound RTCP packets [RFC5506]. | |||
This approach requires the receiver of the RTP packets to monitor | ||||
their reception, determine the level of congestion, and recommend | ||||
a maximum bit rate suitable for current available bandwidth on the | ||||
path; it also assumes that the RTP sender can/will respect that | ||||
bit rate. This is the opposite of the sender based congestion | ||||
control approach suggested in this memo, so TMMBR cannot be used | ||||
to convey the information needed for a sender based congestion | ||||
control. TMMBR could, however, be viewed a complementary | ||||
mechanism that can inform the sender of the receiver's current | ||||
view of acceptable maximum bit rate. The Received Estimated | ||||
Maximum Bit-rate (REMB) mechanism [I-D.alvestrand-rmcat-remb] | ||||
provides similar feedback. | ||||
RTCP Extended Reports (XR): Numerous RTCP extended report (XR) | ||||
blocks have been defined to report details of packet loss, arrival | ||||
times [RFC3611], delay [RFC6843], and ECN marking [RFC6679]. It | ||||
is possible to combine several such XR blocks into a compound RTCP | ||||
packet, to report the detailed loss, arrival 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. | ||||
Transport-wide Congestion Control: The format defined in this memo | ||||
provides individual feedback on each SSRC. An alternative is to | ||||
add a header extension to each RTP packet, containing a single, | ||||
transport-wide, packet sequence number, then have the receiver | ||||
send RTCP reports giving feedback on these additional sequence | ||||
numbers [I-D.holmer-rmcat-transport-wide-cc-extensions]. Such an | ||||
approach adds the per-packet overhead of the header extension (8 | ||||
octets per packet in the referenced format), but reduces the size | ||||
of the feedback packets, and can simplify the rate calculation at | ||||
the sender if it maintains a single rate limit that applies to all | ||||
RTP packets sent irrespective of their SSRC. Equally, the use of | ||||
transport-wide feedback makes it more difficult to adapt the | ||||
sending rate, or respond to lost packets, based on the reception | ||||
and/or loss patterns observed on a per-SSRC basis (for example, to | ||||
perform differential rate control and repair for audio and video | ||||
flows, based on knowledge of what packets from each flow were | ||||
lost). Transport-wide feedback is also a less natural fit with | ||||
the wider RTP framework, which makes extensive use of per-SSRC | ||||
sequence numbers and feedback. | ||||
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. | |||
9. Acknowledgements | 9. Acknowledgements | |||
This document is based on the outcome of a design team discussion in | This document is based on the outcome of a design team discussion in | |||
the RTP Media Congestion Avoidance Techniques (RMCAT) working group. | the RTP Media Congestion Avoidance Techniques (RMCAT) working group. | |||
skipping to change at page 13, line 38 ¶ | skipping to change at page 13, line 32 ¶ | |||
DOI 10.17487/RFC8083, March 2017, | DOI 10.17487/RFC8083, March 2017, | |||
<https://www.rfc-editor.org/info/rfc8083>. | <https://www.rfc-editor.org/info/rfc8083>. | |||
12.2. Informative References | 12.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.alvestrand-rmcat-remb] | ||||
Alvestrand, H., "RTCP message for Receiver Estimated | ||||
Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in | ||||
progress), October 2013. | ||||
[I-D.holmer-rmcat-transport-wide-cc-extensions] | ||||
Holmer, S., Flodman, M., and E. Sprang, "RTP Extensions | ||||
for Transport-wide Congestion Control", draft-holmer- | ||||
rmcat-transport-wide-cc-extensions-01 (work in progress), | ||||
October 2015. | ||||
[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., *, R., Ramalho, M., Cruz, S., Jones, P., Fu, J., | Zhu, X., *, R., Ramalho, M., and S. Cruz, "NADA: A Unified | |||
and S. D'Aronco, "NADA: A Unified Congestion Control | Congestion Control Scheme for Real-Time Media", draft- | |||
Scheme for Real-Time Media", draft-ietf-rmcat-nada-10 | ietf-rmcat-nada-13 (work in progress), September 2019. | |||
(work in progress), February 2019. | ||||
[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>. | |||
skipping to change at page 15, line 5 ¶ | skipping to change at page 15, line 5 ¶ | |||
Varun Singh | Varun Singh | |||
CALLSTATS I/O Oy | CALLSTATS I/O Oy | |||
Annankatu 31-33 C 42 | 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. | ||||
6310 Watercrest Way Unit 203 | 6310 Watercrest Way Unit 203 | |||
Lakewood Ranch, FL 34202 | Lakewood Ranch, FL 34202-5122 | |||
USA | USA | |||
Phone: +1 919 476 2038 | Phone: +1 732 832 9723 | |||
Email: mramalho@cisco.com | Email: mar42@cornell.edu | |||
URI: http://ramalho.webhop.info/ | ||||
End of changes. 16 change blocks. | ||||
41 lines changed or deleted | 77 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/ |