draft-dt-rmcat-feedback-message-03.txt   draft-dt-rmcat-feedback-message-04.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: January 17, 2018 University of Glasgow Expires: April 30, 2018 University of Glasgow
V. Singh V. Singh
callstats.io callstats.io
M. Ramalho M. Ramalho
Cisco Systems Cisco Systems
July 16, 2017 October 27, 2017
RTP Control Protocol (RTCP) Feedback for Congestion Control RTP Control Protocol (RTCP) Feedback for Congestion Control
draft-dt-rmcat-feedback-message-03 draft-dt-rmcat-feedback-message-04
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 36 skipping to change at page 1, line 36
the media to perform the congestion control at the sender. the media to perform the congestion control at the sender.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 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 January 17, 2018. This Internet-Draft will expire on April 30, 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 (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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Feedback Message . . . . . . . . . . . . . . . . . . . . . . 3 3. Feedback Message . . . . . . . . . . . . . . . . . . . . . . 3
3.1. RTCP XR Block for Reporting Congestion Control Feedback . 4 3.1. RTCP Congestion Control Feedback Report . . . . . . . . . 4
3.2. RTP/AVPF Transport Layer Feedback for Congestion Control 6 4. Feedback Frequency and Overhead . . . . . . . . . . . . . . . 6
4. Feedback Frequency and Overhead . . . . . . . . . . . . . . . 7 5. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 7
5. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7.1. RTP/AVPF Transport Layer Feedback Message . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2. RTCP XR Report Blocks . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
For interactive real-time traffic the typical protocol choice is For interactive real-time traffic the typical protocol choice is
Realtime Transport Protocol (RTP) over User Datagram Protocol (UDP). Realtime Transport Protocol (RTP) over User Datagram Protocol (UDP).
RTP does not provide any guarantee of Quality of Service (QoS), RTP does not provide any guarantee of Quality of Service (QoS),
reliable or timely delivery and expects the underlying transport reliable or timely delivery and expects the underlying transport
protocol to do so. UDP alone certainly does not meet that protocol to do so. UDP alone certainly does not meet that
expectation. However, RTP Control Protocol (RTCP) provides a expectation. However, RTP Control Protocol (RTCP) provides a
mechanism to periodically send transport and media metrics to the mechanism to periodically send transport and media metrics to the
skipping to change at page 4, line 28 skipping to change at page 4, line 25
process interruptions can occur at inopportune times. Thus, the process interruptions can occur at inopportune times. Thus, the
recording of the sent times at the sender and arrival times at the recording of the sent times at the sender and arrival times at the
receiver should be made with deliberate care. This is because the receiver should be made with deliberate care. This is because the
time duration of host OS interruptions can be significant relative to time duration of host OS interruptions can be significant relative to
the precision desired in the one-way delay estimates. Specifically, the precision desired in the one-way delay estimates. Specifically,
the send time should be recorded at the latest opportunity prior to the send time should be recorded at the latest opportunity prior to
outputting the media packet at the sender (e.g., socket or RTP API) outputting the media packet at the sender (e.g., socket or RTP API)
and the arrival time at the receiver (e.g., socket or RTP API) should and the arrival time at the receiver (e.g., socket or RTP API) should
be recorded at the earliest opportunity available to the receiver. be recorded at the earliest opportunity available to the receiver.
3.1. RTCP XR Block for Reporting Congestion Control Feedback 3.1. RTCP Congestion Control Feedback Report
Congestion control feedback can be sent as part of a scheduled RTCP Congestion control feedback can be sent as part of a regular
report, or as RTP/AVPF early feedback. If sent as part of a scheduled RTCP report, or in an RTP/AVPF early feedback packet. If
scheduled RTCP report, the feedback is sent as an XR block, as part sent as early feedback, congestion control feedback MAY be sent in a
of a regular compound RTCP packet. The format of the RTCP XR report non-compound RTCP packet [RFC5506] if the RTP/AVPF profile [RFC4585]
block is as follows (this will be preceded in the compound RTCP or the RTP/SAVPF profile [RFC5124] is used.
packet by an RTCP XR header, described in [RFC3611], that includes
the SSRC of the report sender): Irrespective of how it is transported, the congestion control
feedback is sent as a Transport Layer Feedback Message (RTCP packet
type 205). The format of this RTCP packet is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=RC2F | Report count | Block Length = TBD | |V=2|P| FMT=CCFB | PT = 205 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report Timestamp (32bits) | | SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of 1st media source | | SSRC of 1st media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq | | begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|ECN| Arrival time offset | ... . |L|ECN| Arrival time offset | ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of nth media source | | SSRC of nth media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq | | begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|ECN| Arrival time offset | ... | |L|ECN| Arrival time offset | ... |
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report Timestamp (32bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The XR Discard RLE report block uses the same format as specified for The first 8 octets are the RTCP header, with PT=205 and FMT=CCFB
the loss and duplicate report blocks in [RFC3611]. The fields "block specifying the remainder is a congestion control feedback packet, and
length", "begin_seq", and "end_seq" have the same semantics and including the SSRC of the packet sender. (NOTE TO RFC EDITOR: please
representation as defined in [RFC3611] replace CCFB here and in the above diagram with the IANA assigned
RTCP feedback packet type)
Block Type (BT, 8 bits): The RMCAT congestion control feedback Report Section 6.1 of [RFC4585] requires the RTCP header to be followed by
Block is identified by the constant RC2F. [Note to RFC Editor: the SSRC of the media source being reported upon. Accordingly, the
Please replace RC2F with the IANA provided RTCP XR block type for RTCP header is followed by a report for each SSRC received, followed
this block.] by the Report Timestamp.
Report Count (8 bits): field describes the number of SSRCs reported The report for each SSRC received starts with the SSRC of that media
by this report block. The number should at least be 1. source. Then, each sequence number between the begin_seq and end_seq
(both inclusive) is represented by a packet metric block of 16-bits
that contains the L, ECN, and ATO fields. If an odd number of
reports are included, i.e., end_seq - begin_seq is odd then 16 bits
of zero padding MUST be added after the last report, to align the
RTCP packet to a four (4) bytes boundary. The L, ECN, and ATO fields
are as follows:
o 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
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 parsed.
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.
o Arrival time offset (ATO, 13 bits): it the relative arrival time
of the RTP packets at the receiver before this feedback report was
generated measured in milliseconds. It is calculated by
subtracting the reception timestamp of the RTP packet denoted by
this 16bit block 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), the value 0x1FFE MUST be reported to indicate
an over-range positive measurement. If the measurement is
unavailable, the value 0x1FFF MUST be reported.
Report Timestamp (RTS, 32 bits): represents the timestamp when this Report Timestamp (RTS, 32 bits): represents the timestamp when this
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
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
are included, i.e., end_seq - begin_seq is odd then 16 bits of zero
padding MUST be added after the last report, to align the RTCP packet
to a four (4) bytes boundary.
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
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
parsed.
ECN (2 bits): is the echoed ECN mark of the packet (00 if not
received or if ECN is not used).
Arrival time offset (ATO, 13 bits): it the relative arrival time of
the RTP packets at the receiver before this feedback report was
generated measured in milliseconds. It is calculated by subtracting
the reception timestamp of the RTP packet denoted by this 16bit block
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),
the value 0x1FFE MUST be reported to indicate an over-range positive
measurement. If the measurement is unavailable, the value 0x1FFF
MUST be reported.
3.2. RTP/AVPF Transport Layer Feedback for Congestion Control
Congestion control feedback can also be sent in a non-compound RTCP
packet [RFC5506] if the RTP/AVPF profile [RFC4585] or the RTP/SAVPF
profile [RFC5124] is used. In this case, the congestion control
feedback is sent as a Transport Layer FB message (RTCP packet type
205), with FMT=2 (congestion control feedback). The format of this
RTCP packet is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT = 2 | PT = 205 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of 1st media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|ECN| Arrival time offset | ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of nth media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|ECN| Arrival time offset | ... |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report Timestamp (32bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first 8 octets are the RTCP header, with PT=205 and FMT=2
specifying the remainder is a congestion control feedback packet, and
including the SSRC of the packet sender.
Section 6.1 of [RFC4585] requires this is followed by the SSRC of the
media source being reported upon. Accordingly, the format of the
report is changed from that of the RTCP XR report block, to move the
timestamp to the end. The meaning of all the fields is a described
in Section 3.1.
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, and the possible rates of feedback. this trade-off, and the possible rates of feedback.
It is a general understanding that the congestion control algorithms It is a general understanding that the congestion control algorithms
will work better with more frequent feedback - per packet feedback. will work better with more frequent feedback - per packet feedback.
However, RTCP bandwidth and transmission rules put some upper limits However, RTCP bandwidth and transmission rules put some upper limits
on how frequently the RTCP feedback messages can be send from the on how frequently the RTCP feedback messages can be send from the
skipping to change at page 9, line 20 skipping to change at page 8, line 7
6. Acknowledgements 6. Acknowledgements
This document is an outcome of RMCAT design team discussion. We This document is an outcome of RMCAT design team discussion. We
would like to thank all participants specially Xiaoquing Zhu, Stefan would like to thank all participants specially Xiaoquing Zhu, Stefan
Holmer, David, Ingemar Johansson and Randell Jesup for their valuable Holmer, David, Ingemar Johansson and Randell Jesup for their valuable
contribution to the discussions and to the document. contribution to the discussions and to the document.
7. IANA Considerations 7. IANA Considerations
7.1. RTP/AVPF Transport Layer Feedback Message IANA is requested to assign a new value in the "FMT Values for RTPFB
Payload Types" registry for the CCFB transport layer feedback packet
TBD described in Section 3.1.
7.2. RTCP XR Report Blocks
TBD
8. Security Considerations 8. Security Considerations
There is a risk of causing congestion if an on-path attacker modifies There is a risk of causing congestion if an on-path attacker modifies
the feedback messages in such a manner to make available bandwidth the feedback messages in such a manner to make available bandwidth
greater than it is in reality. [More on security consideration TBD.] greater than it is in reality. [More on security consideration TBD.]
9. References 9. References
9.1. Normative References 9.1. Normative References
[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-03 (work in progress), draft-ietf-rmcat-rtp-cc-feedback-03 (work in progress),
November 2016. November 2016.
[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,
<http://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,
<http://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
DOI 10.17487/RFC3551, July 2003, DOI 10.17487/RFC3551, July 2003,
<http://www.rfc-editor.org/info/rfc3551>. <https://www.rfc-editor.org/info/rfc3551>.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)", "RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, DOI 10.17487/RFC3611, November 2003, RFC 3611, DOI 10.17487/RFC3611, November 2003,
<http://www.rfc-editor.org/info/rfc3611>. <https://www.rfc-editor.org/info/rfc3611>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006, DOI 10.17487/RFC4585, July 2006,
<http://www.rfc-editor.org/info/rfc4585>. <https://www.rfc-editor.org/info/rfc4585>.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
2008, <http://www.rfc-editor.org/info/rfc5124>. 2008, <https://www.rfc-editor.org/info/rfc5124>.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, DOI 10.17487/RFC5506, April and Consequences", RFC 5506, DOI 10.17487/RFC5506, April
2009, <http://www.rfc-editor.org/info/rfc5506>. 2009, <https://www.rfc-editor.org/info/rfc5506>.
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN) and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August
2012, <http://www.rfc-editor.org/info/rfc6679>. 2012, <https://www.rfc-editor.org/info/rfc6679>.
9.2. Informative References 9.2. Informative References
[feedback-requirements] [feedback-requirements]
"RMCAT Feedback Requirements", "RMCAT Feedback Requirements",
<://www.ietf.org/proceedings/95/slides/slides-95-rmcat- <://www.ietf.org/proceedings/95/slides/slides-95-rmcat-
1.pdf>. 1.pdf>.
[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-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-05
(work in progress), March 2017. (work in progress), September 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-08 (work in progress), RTP Media.", draft-ietf-rmcat-sbd-08 (work in progress),
July 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-09 (work in for Multimedia", draft-ietf-rmcat-scream-cc-13 (work in
progress), May 2017. progress), October 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, <https://www.rfc-editor.org/info/rfc5104>.
Authors' Addresses Authors' Addresses
Zaheduzzaman Sarker Zaheduzzaman Sarker
Ericsson AB Ericsson AB
Luleae Luleae
Sweden Sweden
Phone: +46107173743 Phone: +46107173743
Email: zaheduzzaman.sarker@ericsson.com Email: zaheduzzaman.sarker@ericsson.com
 End of changes. 30 change blocks. 
132 lines changed or deleted 84 lines changed or added

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