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