draft-dt-rmcat-feedback-message-00.txt   draft-dt-rmcat-feedback-message-01.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 8, 2017 University of Glasgow Expires: May 1, 2017 University of Glasgow
V. Singh V. Singh
callstats.io callstats.io
M. Ramalho M. Ramalho
Cisco Systems Cisco Systems
July 07, 2016 October 28, 2016
RTP Control Protocol (RTCP) Feedback for Congestion Control RTP Control Protocol (RTCP) Feedback for Congestion Control
draft-dt-rmcat-feedback-message-00 draft-dt-rmcat-feedback-message-01
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 January 8, 2017. This Internet-Draft will expire on May 1, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 2, line 20 skipping to change at page 2, line 20
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 Packet format . . . . . . . . . . . . . . . . . . . 4 3.1. RTCP XR Block for Reporting Congestion Control Feedback . 4
4. Feedback Frequency and Overhead . . . . . . . . . . . . . . . 6 3.2. RTP/AVPF Transport Layer Feedback for Congestion Control 6
5. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 7 4. Feedback Frequency and Overhead . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 5. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7.1. RTP/AVPF Transport Layer Feedback Message . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7.2. RTCP XR Report Blocks . . . . . . . . . . . . . . . . . . 8 7.1. RTP/AVPF Transport Layer Feedback Message . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7.2. RTCP XR Report Blocks . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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 46 skipping to change at page 4, line 46
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 Packet format 3.1. RTCP XR Block for Reporting Congestion Control Feedback
The feedback is over RTCP [RFC3550] and it is described as a stand Congestion control feedback can be sent as part of a scheduled RTCP
alone RTCP packet for now, suitable for use in regular RTCP reports. report, or as RTP/AVPF early feedback. If sent as part of a
[FIXME: this is simply a placeholder for now. We can design scheduled RTCP report, the feedback is sent as an XR block, as part
different wire format of this packet with different efficiency in of a regular compound RTCP packet. The format of the RTCP XR report
mind. This doc will contain a very simple format. The optimized block is as follows (this will be preceded in the compound RTCP
versions will be discussed in the group and finally the selected one packet by an RTCP XR header, described in [RFC3611], that includes
will replace this simple format in future. This section will the SSRC of the report sender):
describe a new RTP/AVPF transport feedback message and a new RTCP XR
block report ]
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 | SSRC count | Block Length = TBD | | BT=RC2F | Report count | Block Length = TBD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report Timestamp (32bits) | | Report Timestamp (32bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 | ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
skipping to change at page 5, line 47 skipping to change at page 5, line 43
The XR Discard RLE report block uses the same format as specified for The XR Discard RLE report block uses the same format as specified for
the loss and duplicate report blocks in [RFC3611]. The fields "block the loss and duplicate report blocks in [RFC3611]. The fields "block
length", "begin_seq", and "end_seq" have the same semantics and length", "begin_seq", and "end_seq" have the same semantics and
representation as defined in [RFC3611] representation as defined in [RFC3611]
Block Type (BT, 8 bits): The RMCAT congestion control feedback Report Block Type (BT, 8 bits): The RMCAT congestion control feedback Report
Block is identified by the constant RC2F. [Note to RFC Editor: Block is identified by the constant RC2F. [Note to RFC Editor:
Please replace RC2F with the IANA provided RTCP XR block type for Please replace RC2F with the IANA provided RTCP XR block type for
this block.] this block.]
SSRC Count (8 bits): field describes the number of SSRCs reported by Report Count (8 bits): field describes the number of SSRCs reported
this report block. The number should at least be 1. by this report block. The number should at least be 1.
SSRC of source (32 bits): The SSRC of the RTP source being reported
upon by this report block. This report block MAY report on multiple
SSRC
Report Timestamp (RTS, 32 bits): represents the timestamp when this Report Timestamp (RTS, 32 bits): represents the timestamp when this
report was generated. [FIXME: It is derived from which clock?] report was generated. The sender of the feedback message decides on
the wall-clock. Usually, it should be derived from the same wall-
clock that is used for timestamping RTP packets arrival . Consistency
in the unit and resolution (10th of millisecond should be good enough
) is important here. In addition, the media sender can ask for a
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. [FIXME: if an odd number of contains the L, ECN, and ATO metrics. If an odd number of reports
reports are included, i.e., end_seq - begin_seq is odd OPTION 1: pad are included, i.e., end_seq - begin_seq is odd then it should be
to a 32 bit boundary? How do we mark for padding? OPTION 2: just rounded up to four (4) bytes boundary. [FIXME : the solution will
report on higher than received RTP packet. In both cases the 16bits depend on the compression used (if any), revisit this if packet
are set to zero. A short note on modulo operations for the sequence format is changed later]
number may be made here?]
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.
[FIXME: Should the timestamp of the RTP packets and the RTS be same? [FIXME: should reserve 0xFFF to mean anything greater than 0xFFE?
Needs more information if we go down this path.] [FIXME: should This needs to wait until we have fixed the packet format ]
reserve 0xFFF to mean anything greater than 0xFFE.]
The above packet format is expressed as an RTCP XR report block when 3.2. RTP/AVPF Transport Layer Feedback for Congestion Control
reported with regular RTCP reports. However, the same block
information will need a new RTP/AVPF feedback message if reported Congestion control feedback can also be sent in a non-compound RTCP
more frequently than regular RTCP report. 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
media receiver to the media sender. It has been shown media receiver to the media sender. It has been shown
[I-D.ietf-rmcat-rtp-cc-feedback] that in most cases a per frame [I-D.ietf-rmcat-rtp-cc-feedback] that in most cases a per frame
feedback is a reasonable assumption on how frequent the RTCP feedback feedback is a reasonable assumption on how frequent the RTCP feedback
messages can be transmitted. The design team also have noted that messages can be transmitted. The design team also have noted that
even if a higher frequency of feedback is desired it is not viable if even if a higher frequency of feedback is desired it is not viable if
the feedback messages starts to compete against the media traffic on the feedback messages starts to compete against the media traffic on
the feedback path during congestion period. Analyzing the feedback the feedback path during congestion period. Analyzing the feedback
interval requirement [feedback-requirements] it can be seen that the interval requirement [feedback-requirements] it can be seen that the
skipping to change at page 8, line 42 skipping to change at page 9, line 41
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., "Using RTP Control Protocol (RTCP) Feedback Perkins, C., "Using RTP Control Protocol (RTCP) Feedback
for Unicast Multimedia Congestion Control", draft-ietf- for Unicast Multimedia Congestion Control", draft-ietf-
rmcat-rtp-cc-feedback-00 (work in progress), July 2014. rmcat-rtp-cc-feedback-01 (work in progress), July 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>. <http://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>. <http://www.rfc-editor.org/info/rfc3168>.
skipping to change at page 9, line 31 skipping to change at page 10, line 26
"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>. <http://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>. <http://www.rfc-editor.org/info/rfc4585>.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
2008, <http://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, <http://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, <http://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-01 (work in Time Communication", draft-ietf-rmcat-gcc-02 (work in
progress), October 2015. progress), July 2016.
[I-D.ietf-rmcat-nada] [I-D.ietf-rmcat-nada]
Zhu, X., Pan, R., Ramalho, D., Cruz, S., Jones, P., Fu, Zhu, X., Pan, R., Ramalho, M., Cruz, S., Jones, P., Fu,
J., D'Aronco, S., and C. Ganzhorn, "NADA: A Unified J., D'Aronco, S., and C. Ganzhorn, "NADA: A Unified
Congestion Control Scheme for Real-Time Media", draft- Congestion Control Scheme for Real-Time Media", draft-
ietf-rmcat-nada-02 (work in progress), March 2016. ietf-rmcat-nada-03 (work in progress), September 2016.
[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-04 (work in progress), RTP Media.", draft-ietf-rmcat-sbd-05 (work in progress),
March 2016. September 2016.
[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-05 (work in for Multimedia", draft-ietf-rmcat-scream-cc-06 (work in
progress), June 2016. progress), August 2016.
[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. 21 change blocks. 
59 lines changed or deleted 100 lines changed or added

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