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/