draft-dt-rmcat-feedback-message-02.txt | draft-dt-rmcat-feedback-message-03.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: November 3, 2017 University of Glasgow | Expires: January 17, 2018 University of Glasgow | |||
V. Singh | V. Singh | |||
callstats.io | callstats.io | |||
M. Ramalho | M. Ramalho | |||
Cisco Systems | Cisco Systems | |||
May 02, 2017 | July 16, 2017 | |||
RTP Control Protocol (RTCP) Feedback for Congestion Control | RTP Control Protocol (RTCP) Feedback for Congestion Control | |||
draft-dt-rmcat-feedback-message-02 | draft-dt-rmcat-feedback-message-03 | |||
Abstract | Abstract | |||
This document describes a feedback message intended to enable | This document describes a feedback message intended to enable | |||
congestion control for interactive real-time traffic. The RTP Media | congestion control for interactive real-time traffic. The RTP Media | |||
Congestion Avoidance Techniques (RMCAT) Working Group formed a design | Congestion Avoidance Techniques (RMCAT) Working Group formed a design | |||
team to analyze feedback requirements from various congestion control | team to analyze feedback requirements from various congestion control | |||
algorithms and to design a generic feedback message to help ensure | algorithms and to design a generic feedback message to help ensure | |||
interoperability across those algorithms. The feedback message is | interoperability across those algorithms. The feedback message is | |||
designed for a sender-based congestion control, which means the | designed for a sender-based congestion control, which means the | |||
skipping to change at page 1, line 43 ¶ | skipping to change at page 1, line 43 ¶ | |||
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 http://datatracker.ietf.org/drafts/current/. | Drafts is at http://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 November 3, 2017. | This Internet-Draft will expire on January 17, 2018. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2017 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 | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://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 6, line 8 ¶ | skipping to change at page 6, line 8 ¶ | |||
report was generated. The sender of the feedback message decides on | report was generated. The sender of the feedback message decides on | |||
the wall-clock. Usually, it should be derived from the same wall- | the wall-clock. Usually, it should be derived from the same wall- | |||
clock that is used for timestamping RTP packets arrival . Consistency | clock that is used for timestamping RTP packets arrival . Consistency | |||
in the unit and resolution (10th of millisecond should be good enough | in the unit and resolution (10th of millisecond should be good enough | |||
) is important here. In addition, the media sender can ask for a | ) is important here. In addition, the media sender can ask for a | |||
specific resolution it wants. | specific resolution it wants. | |||
Each sequence number between the begin_seq and end_seq (both | Each sequence number between the begin_seq and end_seq (both | |||
inclusive) is represented by a packet metric block of 16-bits that | inclusive) is represented by a packet metric block of 16-bits that | |||
contains the L, ECN, and ATO metrics. If an odd number of reports | contains the L, ECN, and ATO metrics. If an odd number of reports | |||
are included, i.e., end_seq - begin_seq is odd then it should be | are included, i.e., end_seq - begin_seq is odd then 16 bits of zero | |||
rounded up to four (4) bytes boundary. [FIXME : the solution will | padding MUST be added after the last report, to align the RTCP packet | |||
depend on the compression used (if any), revisit this if packet | to a four (4) bytes boundary. | |||
format is changed later] | ||||
L (1 bit): is a boolean to indicate if the packet was received. 0 | L (1 bit): is a boolean to indicate if the packet was received. 0 | |||
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 be | packet was received and the subsequent bits in the block need to be | |||
parsed. | parsed. | |||
ECN (2 bits): is the echoed ECN mark of the packet (00 if not | ECN (2 bits): is the echoed ECN mark of the packet (00 if not | |||
received or if ECN is not used). | received or if ECN is not used). | |||
Arrival time offset (ATO, 13 bits): it the relative arrival time of | Arrival time offset (ATO, 13 bits): it the relative arrival time of | |||
the RTP packets at the receiver before this feedback report was | the RTP packets at the receiver before this feedback report was | |||
generated measured in milliseconds. It is calculated by subtracting | generated measured in milliseconds. It is calculated by subtracting | |||
the reception timestamp of the RTP packet denoted by this 16bit block | the reception timestamp of the RTP packet denoted by this 16bit block | |||
and the timestamp (RTS) of this report. | and the timestamp (RTS) of this report. If the measured value is | |||
greater than 8.189 seconds (the value that would be coded as 0x1FFD), | ||||
[FIXME: should reserve 0xFFF to mean anything greater than 0xFFE? | the value 0x1FFE MUST be reported to indicate an over-range positive | |||
This needs to wait until we have fixed the packet format ] | measurement. If the measurement is unavailable, the value 0x1FFF | |||
MUST be reported. | ||||
3.2. RTP/AVPF Transport Layer Feedback for Congestion Control | 3.2. RTP/AVPF Transport Layer Feedback for Congestion Control | |||
Congestion control feedback can also be sent in a non-compound RTCP | Congestion control feedback can also be sent in a non-compound RTCP | |||
packet [RFC5506] if the RTP/AVPF profile [RFC4585] or the RTP/SAVPF | packet [RFC5506] if the RTP/AVPF profile [RFC4585] or the RTP/SAVPF | |||
profile [RFC5124] is used. In this case, the congestion control | profile [RFC5124] is used. In this case, the congestion control | |||
feedback is sent as a Transport Layer FB message (RTCP packet type | feedback is sent as a Transport Layer FB message (RTCP packet type | |||
205), with FMT=2 (congestion control feedback). The format of this | 205), with FMT=2 (congestion control feedback). The format of this | |||
RTCP packet is as follows: | RTCP packet is as follows: | |||
skipping to change at page 11, line 20 ¶ | skipping to change at page 11, line 20 ¶ | |||
[I-D.ietf-rmcat-nada] | [I-D.ietf-rmcat-nada] | |||
Zhu, X., Pan, R., Ramalho, M., Cruz, S., Jones, P., Fu, | Zhu, X., Pan, R., Ramalho, M., Cruz, S., Jones, P., Fu, | |||
J., and S. D'Aronco, "NADA: A Unified Congestion Control | J., and S. D'Aronco, "NADA: A Unified Congestion Control | |||
Scheme for Real-Time Media", draft-ietf-rmcat-nada-04 | Scheme for Real-Time Media", draft-ietf-rmcat-nada-04 | |||
(work in progress), March 2017. | (work in progress), March 2017. | |||
[I-D.ietf-rmcat-sbd] | [I-D.ietf-rmcat-sbd] | |||
Hayes, D., Ferlin, S., Welzl, M., and K. Hiorth, "Shared | Hayes, D., Ferlin, S., Welzl, M., and K. Hiorth, "Shared | |||
Bottleneck Detection for Coupled Congestion Control for | Bottleneck Detection for Coupled Congestion Control for | |||
RTP Media.", draft-ietf-rmcat-sbd-06 (work in progress), | RTP Media.", draft-ietf-rmcat-sbd-08 (work in progress), | |||
February 2017. | July 2017. | |||
[I-D.ietf-rmcat-scream-cc] | [I-D.ietf-rmcat-scream-cc] | |||
Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation | Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation | |||
for Multimedia", draft-ietf-rmcat-scream-cc-07 (work in | for Multimedia", draft-ietf-rmcat-scream-cc-09 (work in | |||
progress), November 2016. | progress), May 2017. | |||
[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, <http://www.rfc-editor.org/info/rfc5104>. | February 2008, <http://www.rfc-editor.org/info/rfc5104>. | |||
Authors' Addresses | Authors' Addresses | |||
Zaheduzzaman Sarker | Zaheduzzaman Sarker | |||
Ericsson AB | Ericsson AB | |||
End of changes. 8 change blocks. | ||||
16 lines changed or deleted | 16 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/ |