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/