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