draft-ietf-avtcore-cc-feedback-message-05.txt   draft-ietf-avtcore-cc-feedback-message-06.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 7, 2020 University of Glasgow Expires: September 10, 2020 University of Glasgow
V. Singh V. Singh
callstats.io callstats.io
M. Ramalho M. Ramalho
November 4, 2019 March 9, 2020
RTP Control Protocol (RTCP) Feedback for Congestion Control RTP Control Protocol (RTCP) Feedback for Congestion Control
draft-ietf-avtcore-cc-feedback-message-05 draft-ietf-avtcore-cc-feedback-message-06
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 May 7, 2020. This Internet-Draft will expire on September 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
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
skipping to change at page 5, line 46 skipping to change at page 5, line 46
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 arrival time of the RTP o Arrival time offset (ATO, 13 bits): is the arrival time of the RTP
packet at the receiver, as an offset before the time represented packet at the receiver, as an offset before the time represented
by the RTS field of this RTCP congestion control feedback report. by the Report Timestamp (RTS) field of this RTCP congestion
The ATO field is in units of 1/1024 seconds (this unit is chosen control feedback report. The ATO field is in units of 1/1024
to give exact offsets from the RTS field) so, for example, an ATO seconds (this unit is chosen to give exact offsets from the RTS
value of 512 indicates that the corresponding RTP packet arrived field) so, for example, an ATO value of 512 indicates that the
exactly half a second before the time instant represented by the corresponding RTP packet arrived exactly half a second before the
RTS field. If the measured value is greater than 8189/1024 time instant represented by the RTS field. If the measured value
seconds (the value that would be coded as 0x1FFD), the value is greater than 8189/1024 seconds (the value that would be coded
0x1FFE MUST be reported to indicate an over-range measurement. If as 0x1FFD), the value 0x1FFE MUST be reported to indicate an over-
the measurement is unavailable, or if the arrival time of the RTP range measurement. If the measurement is unavailable, or if the
packet is after the time represented by the RTS field, then an ATO arrival time of the RTP packet is after the time represented by
value of 0x1FFF MUST be reported for the packet. the RTS field, then an ATO value of 0x1FFF MUST be reported for
the packet.
The RTCP congestion control feedback report packet concludes with the The RTCP congestion control feedback report packet concludes with the
Report Timestamp field (RTS, 32 bits). This denotes the time instant Report Timestamp field (RTS, 32 bits). This denotes the time instant
on which this packet is reporting, and is the instant from which the on which this packet is reporting, and is the instant from which the
arrival time offset values are calculated. The value of RTS field is arrival time offset values are calculated. The value of RTS field is
derived from the same clock used to generate the NTP timestamp field derived from the same clock used to generate the NTP timestamp field
in RTCP Sender Report (SR) packets. It is formatted as the middle 32 in RTCP Sender Report (SR) packets. It is formatted as the middle 32
bits of an NTP format timestamp, as described in Section 4 of bits of an NTP format timestamp, as described in Section 4 of
[RFC3550]. [RFC3550].
skipping to change at page 7, line 23 skipping to change at page 7, line 23
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, 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 a general understanding that the congestion control algorithms It is generally understood that congestion control algorithms work
will work better with more frequent feedback - per packet feedback. better with more frequent feedback. However, RTCP bandwidth and
However, RTCP bandwidth and transmission rules put some upper limits transmission rules put some upper limits on how frequently the RTCP
on how frequently the RTCP feedback messages can be send from the RTP feedback messages can be sent from an RTP receiver to the RTP sender.
receiver to the RTP sender. It has been shown It has been shown [I-D.ietf-rmcat-rtp-cc-feedback] that in many cases
[I-D.ietf-rmcat-rtp-cc-feedback] that in most cases a per frame sending feedback one per frame is an upper bound before the reporting
feedback is a reasonable assumption on how frequent the RTCP feedback overhead becomes excessive, although this will depend on the media
messages can be transmitted. It has also been noted that even if a rate and more frequent feedback might be needed with high-rate media
higher frequency of feedback is desired it is not viable if the flows. Analysis [feedback-requirements] has also shown that some
feedback messages starts to compete against the RTP traffic on the candidate congestion control algorithms can operate with less
feedback path during congestion period. Analyzing the feedback frequent feedback, using a feedback interval range of 50-200ms.
interval requirement [feedback-requirements] it can be seen that the Applications need to negotiate an appropriate congestion control
candidate algorithms can perform with a feedback interval range of feedback interval at session setup time, based on the choice of
50-200ms. A value within this range need to be negotiated at session congestion control algorithm, the expected media bit rate, and the
setup. acceptable feedback 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 12, line 13 skipping to change at page 12, line 13
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] [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-04 (work in progress), draft-ietf-rmcat-rtp-cc-feedback-05 (work in progress),
July 2018. 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 14, line 28 skipping to change at page 14, line 28
[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>.
Authors' Addresses Authors' Addresses
Zaheduzzaman Sarker Zaheduzzaman Sarker
Ericsson AB Ericsson AB
Luleae Torshamnsgatan 21
Stockholm 164 40
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
 End of changes. 9 change blocks. 
34 lines changed or deleted 36 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/