draft-ietf-avtcore-cc-feedback-message-06.txt   draft-ietf-avtcore-cc-feedback-message-07.txt 
IETF RMCAT Working Group Z. Sarker IETF RMCAT Working Group Z. Sarker
Internet-Draft Ericsson AB Internet-Draft Ericsson AB
Intended status: Standards Track C. Perkins Intended status: Standards Track C. Perkins
Expires: September 10, 2020 University of Glasgow Expires: December 12, 2020 University of Glasgow
V. Singh V. Singh
callstats.io callstats.io
M. Ramalho M. Ramalho
March 9, 2020 June 10, 2020
RTP Control Protocol (RTCP) Feedback for Congestion Control RTP Control Protocol (RTCP) Feedback for Congestion Control
draft-ietf-avtcore-cc-feedback-message-06 draft-ietf-avtcore-cc-feedback-message-07
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 39 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 September 10, 2020. This Internet-Draft will expire on December 12, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 22 skipping to change at page 2, line 22
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 . . . . . . . . . . . . 7 5. Response to Loss of Feedback Packets . . . . . . . . . . . . 7
6. SDP Signalling . . . . . . . . . . . . . . . . . . . . . . . 8 6. SDP Signalling . . . . . . . . . . . . . . . . . . . . . . . 8
7. Relation to RFC 6679 . . . . . . . . . . . . . . . . . . . . 8 7. Relation to RFC 6679 . . . . . . . . . . . . . . . . . . . . 8
8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 9 8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 12
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 3, line 4 skipping to change at page 3, line 4
have developed proprietary RTCP messages that convey only those have developed proprietary RTCP messages that convey only those
parameters needed for their respective designs. As a direct result, parameters needed for their respective designs. As a direct result,
the different congestion control (i.e., rate adaptation) designs are the different congestion control (i.e., rate adaptation) designs are
not interoperable. To enable algorithm evolution as well as not interoperable. To enable algorithm evolution as well as
interoperability across designs (e.g., different rate adaptation interoperability across designs (e.g., different rate adaptation
algorithms), it is highly desirable to have generic congestion algorithms), it is highly desirable to have generic congestion
control feedback format. control feedback format.
To help achieve interoperability for unicast RTP congestion control, To help achieve interoperability for unicast RTP congestion control,
this memo proposes a common RTCP feedback packet format that can be this memo proposes a common RTCP feedback packet format that can be
used by NADA [I-D.ietf-rmcat-nada], SCReAM [RFC8298], Google used by NADA [RFC8698], SCReAM [RFC8298], Google Congestion Control
Congestion Control [I-D.ietf-rmcat-gcc] and Shared Bottleneck [I-D.ietf-rmcat-gcc] and Shared Bottleneck Detection [RFC8382], and
Detection [RFC8382], and hopefully also by future RTP congestion hopefully also by future RTP congestion control algorithms.
control algorithms.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
In addition the terminology defined in [RFC3550], [RFC3551], In addition the terminology defined in [RFC3550], [RFC3551],
[RFC3611], [RFC4585], and [RFC5506] applies. [RFC3611], [RFC4585], and [RFC5506] applies.
3. RTCP Feedback for Congestion Control 3. RTCP Feedback for Congestion Control
Based on an analysis of NADA [I-D.ietf-rmcat-nada], SCReAM [RFC8298], Based on an analysis of NADA [RFC8698], SCReAM [RFC8298], Google
Google Congestion Control [I-D.ietf-rmcat-gcc] and Shared Bottleneck Congestion Control [I-D.ietf-rmcat-gcc] and Shared Bottleneck
Detection [RFC8382], the following per-RTP packet congestion control Detection [RFC8382], the following per-RTP packet congestion control
feedback information has been determined to be necessary: feedback information has been determined to be necessary:
o RTP sequence number: The receiver of an RTP flow needs to feedback o RTP sequence number: The receiver of an RTP flow needs to feedback
the sequence numbers of the received RTP packets to the sender, so the sequence numbers of the received RTP packets to the sender, so
the sender can determine which packets were received and which the sender can determine which packets were received and which
were lost. Packet loss is used as an indication of congestion by were lost. Packet loss is used as an indication of congestion by
many congestion control algorithms. many congestion control algorithms.
o Packet Arrival Time: The receiver of an RTP flow needs to feedback o Packet Arrival Time: The receiver of an RTP flow needs to feedback
skipping to change at page 6, line 37 skipping to change at page 6, line 37
an RTP packet was reported as received in one report, that packet an RTP packet was reported as received in one report, that packet
MUST also be reported as received in any overlapping reports sent MUST also be reported as received in any overlapping reports sent
later that cover its sequence number range. later that cover its sequence number range.
RTCP congestion control feedback packets can be large if they are RTCP congestion control feedback packets can be large if they are
sent infrequently relative to the number of RTP data packets. If an sent infrequently relative to the number of RTP data packets. If an
RTCP congestion control feedback packet is too large to fit within RTCP congestion control feedback packet is too large to fit within
the path MTU, its sender SHOULD split it into multiple feedback the path MTU, its sender SHOULD split it into multiple feedback
packets. The RTCP reporting interval SHOULD be chosen such that packets. The RTCP reporting interval SHOULD be chosen such that
feedback packets are sent often enough that they are small enough to feedback packets are sent often enough that they are small enough to
fit within the path MTU ([I-D.ietf-rmcat-rtp-cc-feedback] provides fit within the path MTU ([I-D.ietf-rmcat-rtp-cc-feedback] discusses
guidance on how to choose the reporting interval). how to choose the reporting interval; specifications for RTP
congestion control algorithms can also provide guidance).
If duplicate copies of a particular RTP packet are received, then the If duplicate copies of a particular RTP packet are received, then the
arrival time of the first copy to arrive MUST be reported. If any of arrival time of the first copy to arrive MUST be reported. If any of
the copies of the duplicated packet are ECN-CE marked, then an ECN-CE the copies of the duplicated packet are ECN-CE marked, then an ECN-CE
mark MUST be reported that for packet; otherwise the ECN mark of the mark MUST be reported that for packet; otherwise the ECN mark of the
first copy to arrive is reported. first copy to arrive is reported.
If no packets are received from an SSRC in a reporting interval, a If no packets are received from an SSRC in a reporting interval, a
report block MAY be sent with begin_seq set to the highest sequence report block MAY be sent with begin_seq set to the highest sequence
number previously received from that SSRC and num_reports set to zero number previously received from that SSRC and num_reports set to zero
skipping to change at page 7, line 27 skipping to change at page 7, line 28
this trade-off, suggests desirable RTCP feedback rates, and provides this trade-off, suggests desirable RTCP feedback rates, and provides
guidance on how to configure the RTCP bandwidth fraction, etc., to guidance on how to configure the RTCP bandwidth fraction, etc., to
make appropriate use of the reporting block described in this memo. make appropriate use of the reporting block described in this memo.
Specifications for RTP congestion control algorithms can also provide Specifications for RTP congestion control algorithms can also provide
guidance. guidance.
It is generally understood that congestion control algorithms work It is generally understood that congestion control algorithms work
better with more frequent feedback. However, RTCP bandwidth and better with more frequent feedback. However, RTCP bandwidth and
transmission rules put some upper limits on how frequently the RTCP transmission rules put some upper limits on how frequently the RTCP
feedback messages can be sent from an RTP receiver to the RTP sender. feedback messages can be sent from an RTP receiver to the RTP sender.
It has been shown [I-D.ietf-rmcat-rtp-cc-feedback] that in many cases In many cases, sending feedback once per frame is an upper bound
sending feedback one per frame is an upper bound before the reporting before the reporting overhead becomes excessive, although this will
overhead becomes excessive, although this will depend on the media depend on the media rate and more frequent feedback might be needed
rate and more frequent feedback might be needed with high-rate media with high-rate media flows [I-D.ietf-rmcat-rtp-cc-feedback].
flows. Analysis [feedback-requirements] has also shown that some Analysis [feedback-requirements] has also shown that some candidate
candidate congestion control algorithms can operate with less congestion control algorithms can operate with less frequent
frequent feedback, using a feedback interval range of 50-200ms. feedback, using a feedback interval range of 50-200ms. Applications
Applications need to negotiate an appropriate congestion control need to negotiate an appropriate congestion control feedback interval
feedback interval at session setup time, based on the choice of at session setup time, based on the choice of congestion control
congestion control algorithm, the expected media bit rate, and the algorithm, the expected media bit rate, and the acceptable feedback
acceptable feedback overhead. overhead.
5. Response to Loss of Feedback Packets 5. Response to Loss of Feedback Packets
Like all RTCP packets, RTCP congestion control feedback packets might Like all RTCP packets, RTCP congestion control feedback packets might
be lost. All RTP congestion control algorithms MUST specify how they be lost. All RTP congestion control algorithms MUST specify how they
respond to the loss of feedback packets. respond to the loss of feedback packets.
If only a single congestion control feedback packet is lost, an If only a single congestion control feedback packet is lost, an
appropriate response is to assume that the level of congestion has appropriate response is to assume that the level of congestion has
remained roughly the same as the previous report. However, if remained roughly the same as the previous report. However, if
skipping to change at page 11, line 24 skipping to change at page 11, line 30
Value name: ccfb Value name: ccfb
Long name: Congestion Control Feedback Long name: Congestion Control Feedback
Usable with: ack Usable with: ack
Reference: (RFC number of this document, when published) Reference: (RFC number of this document, when published)
11. Security Considerations 11. Security Considerations
The security considerations of the RTP specification [RFC3550], the The security considerations of the RTP specification [RFC3550], the
applicable RTP profile (e.g., [RFC3551], [RFC3711], or [RFC4585]), applicable RTP profile (e.g., [RFC3551], [RFC3711], or [RFC4585]),
and the RTP congestion control algorithm that is in use (e.g., and the RTP congestion control algorithm that is in use (e.g.,
[I-D.ietf-rmcat-nada], [RFC8298], [I-D.ietf-rmcat-gcc], or [RFC8382]) [RFC8698], [RFC8298], [I-D.ietf-rmcat-gcc], or [RFC8382]) apply.
apply.
A receiver that intentionally generates inaccurate RTCP congestion A receiver that intentionally generates inaccurate RTCP congestion
control feedback reports might be able trick the sender into sending control feedback reports might be able trick the sender into sending
at a greater rate than the path can support, thereby congesting the at a greater rate than the path can support, thereby congesting the
path. This will negatively impact the quality of experience of that path. This will negatively impact the quality of experience of that
receiver. Since RTP is an unreliable transport, a sender can receiver. Since RTP is an unreliable transport, a sender can
intentionally leave a gap in the RTP sequence number space without intentionally leave a gap in the RTP sequence number space without
causing harm, to check that the receiver is correctly reporting causing harm, to check that the receiver is correctly reporting
losses. losses.
skipping to change at page 12, line 10 skipping to change at page 12, line 17
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-54 (work in progress), December 2018. negotiation-54 (work in progress), December 2018.
[I-D.ietf-mmusic-sdp-mux-attributes] [I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17
(work in progress), February 2018. (work in progress), February 2018.
[I-D.ietf-rmcat-rtp-cc-feedback]
Perkins, C., "RTP Control Protocol (RTCP) Feedback for
Congestion Control in Interactive Multimedia Conferences",
draft-ietf-rmcat-rtp-cc-feedback-05 (work in progress),
November 2019.
[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-editor.org/info/rfc2119>. <https://www.rfc-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>.
skipping to change at page 13, line 49 skipping to change at page 14, line 5
for Transport-wide Congestion Control", draft-holmer- for Transport-wide Congestion Control", draft-holmer-
rmcat-transport-wide-cc-extensions-01 (work in progress), rmcat-transport-wide-cc-extensions-01 (work in progress),
October 2015. 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-rtp-cc-feedback]
Zhu, X., *, R., Ramalho, M., and S. Cruz, "NADA: A Unified Perkins, C., "RTP Control Protocol (RTCP) Feedback for
Congestion Control Scheme for Real-Time Media", draft- Congestion Control in Interactive Multimedia Conferences",
ietf-rmcat-nada-13 (work in progress), September 2019. draft-ietf-rmcat-rtp-cc-feedback-05 (work in progress),
November 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>.
[RFC8298] Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation [RFC8298] Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation
for Multimedia", RFC 8298, DOI 10.17487/RFC8298, December for Multimedia", RFC 8298, DOI 10.17487/RFC8298, December
2017, <https://www.rfc-editor.org/info/rfc8298>. 2017, <https://www.rfc-editor.org/info/rfc8298>.
[RFC8382] Hayes, D., Ed., Ferlin, S., Welzl, M., and K. Hiorth, [RFC8382] Hayes, D., Ed., Ferlin, S., Welzl, M., and K. Hiorth,
"Shared Bottleneck Detection for Coupled Congestion "Shared Bottleneck Detection for Coupled Congestion
Control for RTP Media", RFC 8382, DOI 10.17487/RFC8382, Control for RTP Media", RFC 8382, DOI 10.17487/RFC8382,
June 2018, <https://www.rfc-editor.org/info/rfc8382>. June 2018, <https://www.rfc-editor.org/info/rfc8382>.
[RFC8698] Zhu, X., Pan, R., Ramalho, M., and S. Mena, "Network-
Assisted Dynamic Adaptation (NADA): A Unified Congestion
Control Scheme for Real-Time Media", RFC 8698,
DOI 10.17487/RFC8698, February 2020,
<https://www.rfc-editor.org/info/rfc8698>.
Authors' Addresses Authors' Addresses
Zaheduzzaman Sarker Zaheduzzaman Sarker
Ericsson AB Ericsson AB
Torshamnsgatan 21 Torshamnsgatan 21
Stockholm 164 40 Stockholm 164 40
Sweden Sweden
Phone: +46107173743 Phone: +46107173743
Email: zaheduzzaman.sarker@ericsson.com Email: zaheduzzaman.sarker@ericsson.com
 End of changes. 14 change blocks. 
37 lines changed or deleted 37 lines changed or added

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