draft-ietf-avtcore-cc-feedback-message-03.txt   draft-ietf-avtcore-cc-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: June 26, 2019 University of Glasgow Expires: January 9, 2020 University of Glasgow
V. Singh V. Singh
callstats.io callstats.io
M. Ramalho M. Ramalho
Cisco Systems Cisco Systems
December 23, 2018 July 8, 2019
RTP Control Protocol (RTCP) Feedback for Congestion Control RTP Control Protocol (RTCP) Feedback for Congestion Control
draft-ietf-avtcore-cc-feedback-message-03 draft-ietf-avtcore-cc-feedback-message-04
Abstract Abstract
This document describes an RTCP feedback message intended to enable This document describes an RTCP feedback message intended to enable
congestion control for interactive real-time traffic using RTP. The congestion control for interactive real-time traffic using RTP. The
feedback message is designed for use with a sender-based congestion feedback message is designed for use with a sender-based congestion
control algorithm, in which the receiver of an RTP flow sends RTCP control algorithm, in which the receiver of an RTP flow sends RTCP
feedback packets to the sender containing the information the sender feedback packets to the sender containing the information the sender
needs to perform congestion control. needs to perform congestion control.
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 June 26, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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. RTCP Feedback for Congestion Control . . . . . . . . . . . . 3 3. RTCP Feedback for Congestion Control . . . . . . . . . . . . 3
3.1. RTCP Congestion Control Feedback Report . . . . . . . . . 4 3.1. RTCP Congestion Control Feedback Report . . . . . . . . . 4
4. Feedback Frequency and Overhead . . . . . . . . . . . . . . . 6 4. Feedback Frequency and Overhead . . . . . . . . . . . . . . . 7
5. SDP Signalling . . . . . . . . . . . . . . . . . . . . . . . 7 5. Response to Loss of Feedback Packets . . . . . . . . . . . . 8
6. Relation to RFC 6679 . . . . . . . . . . . . . . . . . . . . 7 6. SDP Signalling . . . . . . . . . . . . . . . . . . . . . . . 8
7. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 8 7. Relation to RFC 6679 . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 12.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
For interactive real-time traffic, such as video conferencing flows, For interactive real-time traffic, such as video conferencing flows,
the typical protocol choice is the Real-time Transport Protocol (RTP) the typical protocol choice is the Real-time Transport Protocol (RTP)
running over the User Datagram Protocol (UDP). RTP does not provide running over the User Datagram Protocol (UDP). RTP does not provide
any guarantee of Quality of Service (QoS), reliability, or timely any guarantee of Quality of Service (QoS), reliability, or timely
delivery, and expects the underlying transport protocol to do so. delivery, and expects the underlying transport protocol to do so.
UDP alone certainly does not meet that expectation. However, the RTP UDP alone certainly does not meet that expectation. However, the RTP
Control Protocol (RTCP) provides a mechanism by which the receiver of Control Protocol (RTCP) provides a mechanism by which the receiver of
skipping to change at page 6, line 30 skipping to change at page 7, line 12
in consecutive reports for a given SSRC will generally be contiguous, in consecutive reports for a given SSRC will generally be contiguous,
but overlapping reports MAY be sent (and need to be sent in cases but overlapping reports MAY be sent (and need to be sent in cases
where RTP packet reordering occurs across the boundary between where RTP packet reordering occurs across the boundary between
consecutive reports). If reports covering overlapping sequence consecutive reports). If reports covering overlapping sequence
number ranges are sent, information in later reports updates that in number ranges are sent, information in later reports updates that in
sent previous reports for RTP packets included in both reports. If sent previous reports for RTP packets included in both reports. If
an RTP packet was reported as received in one report, that packet an RTP packet was reported as received in one report, that packet
MUST also be reported as received in any overlapping reports sent MUST also be reported as received in any overlapping reports sent
later that cover its sequence number range. later that cover its sequence number range.
RTCP congestion control feedback packets can be large if they are
sent infrequently relative to the number of RTP data packets. If an
RTCP congestion control feedback packet is too large to fit within
the path MTU, its sender SHOULD split it into multiple feedback
packets. The RTCP reporting interval SHOULD be chosen such that
feedback packets are sent often enough that they are small enough to
fit within the path MTU ([I-D.ietf-rmcat-rtp-cc-feedback] provides
guidance on how to choose the reporting interval).
If duplicate copies of a particular RTP packet are received, then the If duplicate copies of a particular RTP packet are received, then the
arrival time of the first copy to arrive MUST be reported. If any of arrival time of the first copy to arrive MUST be reported. If any of
the copies of the duplicated packet are ECN-CE marked, then an ECN-CE the copies of the duplicated packet are ECN-CE marked, then an ECN-CE
mark MUST be reported that for packet; otherwise the ECN mark of the mark MUST be reported that for packet; otherwise the ECN mark of the
first copy to arrive is reported. first copy to arrive is reported.
If no packets are received from an SSRC in a reporting interval, a If no packets are received from an SSRC in a reporting interval, a
report block MAY be sent with begin_seq set to the highest sequence report block MAY be sent with begin_seq set to the highest sequence
number previously received from that SSRC and num_reports set to zero number previously received from that SSRC and num_reports set to zero
(or, the report can simply to omitted). The corresponding SR/RR (or, the report can simply to omitted). The corresponding SR/RR
packet will have a non-increased extended highest sequence number packet will have a non-increased extended highest sequence number
received field that will inform the sender that no packets have been received field that will inform the sender that no packets have been
received, but it can ease processing to have that information received, but it can ease processing to have that information
available in the congestion control feedback reports too. available in the congestion control feedback reports too.
A report block indicating that certain RTP packets were lost is not
to be interpreted as a request to retransmit the lost packets. The
receiver of such a report might choose to retransmit such packets,
provided a retransmission payload format has been negotiated, but
there is no requirement that it do so.
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, suggests desirable RTCP feedback rates, and provides this trade-off, suggests desirable RTCP feedback rates, and provides
guidance on how to configure the RTCP bandwidth fraction, etc., to guidance on how to configure the RTCP bandwidth fraction, etc., to
make appropriate use of the reporting block described in this memo. make appropriate use of the reporting block described in this memo.
Specifications for RTP congestion control algorithms can also provide Specifications for RTP congestion control algorithms can also provide
guidance. guidance.
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 RTP on how frequently the RTCP feedback messages can be send from the RTP
receiver to the RTP sender. It has been shown receiver to the RTP 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
skipping to change at page 7, line 24 skipping to change at page 8, line 21
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. It has also been noted that even if a messages can be transmitted. It has also been noted that even if a
higher frequency of feedback is desired it is not viable if the higher frequency of feedback is desired it is not viable if the
feedback messages starts to compete against the RTP traffic on the feedback messages starts to compete against the RTP traffic on the
feedback path during congestion period. Analyzing the feedback 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
candidate algorithms can perform with a feedback interval range of candidate algorithms can perform with a feedback interval range of
50-200ms. A value within this range need to be negotiated at session 50-200ms. A value within this range need to be negotiated at session
setup. setup.
5. SDP Signalling 5. Response to Loss of Feedback Packets
Like all RTCP packets, RTCP congestion control feedback packets might
be lost. All RTP congestion control algorithms MUST specify how they
respond to the loss of feedback packets.
If only a single congestion control feedback packet is lost, an
appropriate response is to assume that the level of congestion has
remained roughly the same as the previous report. However, if
multiple consecutive congestion control feedback packets are lost,
the sender SHOULD rapidly reduce its sending rate towards zero, as
this likely indicates a path failure. The RTP circuit breaker
[RFC8083] provides further guidance.
6. SDP Signalling
A new "ack" feedback parameter, "ccfb", is defined for use with the A new "ack" feedback parameter, "ccfb", is defined for use with the
"a=rtcp-fb:" SDP extension to indicate the use of the RTP Congestion "a=rtcp-fb:" SDP extension to indicate the use of the RTP Congestion
Control feedback packet format defined in Section 3. The ABNF Control feedback packet format defined in Section 3. The ABNF
definition of this SDP parameter extension is: definition of this SDP parameter extension is:
rtcp-fb-ack-param = <See Section 4.2 of [RFC4585]> rtcp-fb-ack-param = <See Section 4.2 of [RFC4585]>
rtcp-fb-ack-param =/ ccfb-par rtcp-fb-ack-param =/ ccfb-par
ccfb-par = SP "ccfb" ccfb-par = SP "ccfb"
When used with "ccfb" feedback, the wildcard payload type ("*") MUST
be used. This implies that the congestion control feedback is sent
for all payload types in use in the session, including any FEC and
retransmission payload types. An example of the resulting SDP
attribute is:
a=rtcp-fb:* ack ccfb
The offer/answer rules for these SDP feedback parameters are The offer/answer rules for these SDP feedback parameters are
specified in Section 4.2 of the RTP/AVPF profile [RFC4585]. When specified in Section 4.2 of the RTP/AVPF profile [RFC4585].
used with "ccfb" feedback, the wildcard payload type ("*") MUST be
used.
6. Relation to RFC 6679 An SDP offer might indicate support for both the congestion control
feedback mechanism specified in this memo and one or more alternative
congestion control feedback mechanisms that offer substantially the
same semantics. In this case, the answering party SHOULD include
only one of the offered congestion control feedback mechanisms in its
answer. If a re-invite offering the same set of congestion control
feedback mechanisms is received, the generated answer SHOULD choose
the same congestion control feedback mechanism as in the original
answer where possible.
When the SDP BUNDLE extension
[I-D.ietf-mmusic-sdp-bundle-negotiation] is used for multiplexing,
the "a=rtcp-fb:" attribute has multiplexing category IDENTICAL-PER-PT
[I-D.ietf-mmusic-sdp-mux-attributes].
7. Relation to RFC 6679
Use of Explicit Congestion Notification (ECN) with RTP is described Use of Explicit Congestion Notification (ECN) with RTP is described
in [RFC6679]. That specifies how to negotiate the use of ECN with in [RFC6679]. That specifies how to negotiate the use of ECN with
RTP, and defines an RTCP ECN Feedback Packet to carry ECN feedback RTP, and defines an RTCP ECN Feedback Packet to carry ECN feedback
reports. It uses an SDP "a=ecn-capaable-rtp:" attribute to negotiate reports. It uses an SDP "a=ecn-capaable-rtp:" attribute to negotiate
use of ECN, and the "a=rtcp-fb:" attributes with the "nack" parameter use of ECN, and the "a=rtcp-fb:" attributes with the "nack" parameter
"ecn" to negotiate the use of RTCP ECN Feedback Packets. "ecn" to negotiate the use of RTCP ECN Feedback Packets.
The RTCP ECN Feedback Packet is not useful when ECN is used with the The RTCP ECN Feedback Packet is not useful when ECN is used with the
RTP Congestion Control Feedback Packet defined in this memo since it RTP Congestion Control Feedback Packet defined in this memo since it
provides duplicate information. Accordingly, when congestion control provides duplicate information. Accordingly, when congestion control
feedback is to be used with RTP and ECN, the SDP offer generated MUST feedback is to be used with RTP and ECN, the SDP offer generated MUST
include an "a=ecn-capable-rtp:" attribute to negotiate ECN support, include an "a=ecn-capable-rtp:" attribute to negotiate ECN support,
along with an "a=rtcp-fb:" attribute with the "ack" parameter "ccfb" along with an "a=rtcp-fb:" attribute with the "ack" parameter "ccfb"
to indicate that the RTP Congestion Control Feedback Packet is to be to indicate that the RTP Congestion Control Feedback Packet is to be
used for feedback. The "a=rtcp-fb:" attribute MUST NOT include the used for feedback. The "a=rtcp-fb:" attribute MUST NOT include the
"nack" parameter "ecn", so the RTCP ECN Feedback Packet will not be "nack" parameter "ecn", so the RTCP ECN Feedback Packet will not be
used. used.
7. Design Rationale 8. Design Rationale
The primary function of RTCP SR/RR packets is to report statistics on The primary function of RTCP SR/RR packets is to report statistics on
the reception of RTP packets. The reception report blocks sent in the reception of RTP packets. The reception report blocks sent in
these packets contain information about observed jitter, fractional these packets contain information about observed jitter, fractional
packet loss, and cumulative packet loss. It was intended that this packet loss, and cumulative packet loss. It was intended that this
information could be used to support congestion control algorithms, information could be used to support congestion control algorithms,
but experience has shown that it is not sufficient for that purpose. but experience has shown that it is not sufficient for that purpose.
An efficient congestion control algorithm requires more fine grained An efficient congestion control algorithm requires more fine grained
information on per packet reception quality than is provided by SR/RR information on per packet reception quality than is provided by SR/RR
packets to react effectively. packets to react effectively.
skipping to change at page 9, line 7 skipping to change at page 10, line 39
time, and ECN marking marking information needed for effective time, and ECN marking marking information needed for effective
sender-based congestion control. However, the result has high sender-based congestion control. However, the result has high
overhead both in terms of bandwidth and complexity, due to the need overhead both in terms of bandwidth and complexity, due to the need
to stack multiple reports. to stack multiple reports.
Considering these issues, we believe it appropriate to design a new Considering these issues, we believe it appropriate to design a new
RTCP feedback mechanism to convey information for sender based RTCP feedback mechanism to convey information for sender based
congestion control algorithms. The new congestion control feedback congestion control algorithms. The new congestion control feedback
RTCP packet described in Section 3 provides such a mechanism. RTCP packet described in Section 3 provides such a mechanism.
8. Acknowledgements 9. Acknowledgements
This document is based on the outcome of a design team discussion in This document is based on the outcome of a design team discussion in
the RTP Media Congestion Avoidance Techniques (RMCAT) working group. the RTP Media Congestion Avoidance Techniques (RMCAT) working group.
The authors would like to thank David Hayes, Stefan Holmer, Randell The authors would like to thank David Hayes, Stefan Holmer, Randell
Jesup, Ingemar Johansson, Jonathan Lennox, Sergio Mena, Nils Jesup, Ingemar Johansson, Jonathan Lennox, Sergio Mena, Nils
Ohlmeier, Magnus Westerlund, and Xiaoqing Zhu for their valuable Ohlmeier, Magnus Westerlund, and Xiaoqing Zhu for their valuable
feedback. feedback.
9. IANA Considerations 10. IANA Considerations
The IANA is requested to register one new RTP/AVPF Transport-Layer The IANA is requested to register one new RTP/AVPF Transport-Layer
Feedback Message in the table for FMT values for RTPFB Payload Types Feedback Message in the table for FMT values for RTPFB Payload Types
[RFC4585] as defined in Section 3.1: [RFC4585] as defined in Section 3.1:
Name: CCFB Name: CCFB
Long name: RTP Congestion Control Feedback Long name: RTP Congestion Control Feedback
Value: (to be assigned by IANA) Value: (to be assigned by IANA)
Reference: (RFC number of this document, when published) Reference: (RFC number of this document, when published)
The IANA is also requested to register one new SDP "rtcp-fb" The IANA is also requested to register one new SDP "rtcp-fb"
attribute "ack" parameter, "ccfb", in the SDP ("ack" and "nack" attribute "ack" parameter, "ccfb", in the SDP ("ack" and "nack"
Attribute Values) registry: Attribute Values) registry:
Value name: ccfb Value name: ccfb
Long name: Congestion Control Feedback Long name: Congestion Control Feedback
Usable with: ack Usable with: ack
Reference: (RFC number of this document, when published) Reference: (RFC number of this document, when published)
10. Security Considerations 11. Security Considerations
The security considerations of the RTP specification [RFC3550], the The security considerations of the RTP specification [RFC3550], the
applicable RTP profile (e.g., [RFC3551], [RFC3711], or [RFC4585]), applicable RTP profile (e.g., [RFC3551], [RFC3711], or [RFC4585]),
and the RTP congestion control algorithm that is in use (e.g., and the RTP congestion control algorithm that is in use (e.g.,
[I-D.ietf-rmcat-nada], [RFC8298], [I-D.ietf-rmcat-gcc], or [RFC8382]) [I-D.ietf-rmcat-nada], [RFC8298], [I-D.ietf-rmcat-gcc], or [RFC8382])
apply. apply.
A receiver that intentionally generates inaccurate RTCP congestion A receiver that intentionally generates inaccurate RTCP congestion
control feedback reports might be able trick the sender into sending control feedback reports might be able trick the sender into sending
at a greater rate than the path can support, thereby congesting the at a greater rate than the path can support, thereby congesting the
skipping to change at page 10, line 11 skipping to change at page 11, line 48
intentionally leave a gap in the RTP sequence number space without intentionally leave a gap in the RTP sequence number space without
causing harm, to check that the receiver is correctly reporting causing harm, to check that the receiver is correctly reporting
losses. losses.
An on-path attacker that can modify RTCP congestion control feedback An on-path attacker that can modify RTCP congestion control feedback
packets can change the reports to trick the sender into sending at packets can change the reports to trick the sender into sending at
either an excessively high or excessively low rate, leading to denial either an excessively high or excessively low rate, leading to denial
of service. The secure RTCP profile [RFC3711] can be used to of service. The secure RTCP profile [RFC3711] can be used to
authenticate RTCP packets to protect against this attack. authenticate RTCP packets to protect against this attack.
11. References 12. References
12.1. Normative References
11.1. Normative References [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-54 (work in progress), December 2018.
[I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17
(work in progress), February 2018.
[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-04 (work in progress), draft-ietf-rmcat-rtp-cc-feedback-04 (work in progress),
July 2018. July 2018.
[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, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
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,
<https://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, <https://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, <https://www.rfc- DOI 10.17487/RFC3551, July 2003,
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,
<https://www.rfc-editor.org/info/rfc3611>. <https://www.rfc-editor.org/info/rfc3611>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
[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, <https://www.rfc- DOI 10.17487/RFC4585, July 2006,
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, <https://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, <https://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, <https://www.rfc-editor.org/info/rfc6679>. 2012, <https://www.rfc-editor.org/info/rfc6679>.
11.2. Informative References [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", RFC 8083,
DOI 10.17487/RFC8083, March 2017,
<https://www.rfc-editor.org/info/rfc8083>.
12.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., *, R., Ramalho, M., Cruz, S., Jones, P., Fu, J., Zhu, X., *, R., Ramalho, M., Cruz, S., Jones, P., Fu, J.,
and S. D'Aronco, "NADA: A Unified Congestion Control and S. D'Aronco, "NADA: A Unified Congestion Control
Scheme for Real-Time Media", draft-ietf-rmcat-nada-09 Scheme for Real-Time Media", draft-ietf-rmcat-nada-10
(work in progress), August 2018. (work in progress), February 2019.
[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, <https://www.rfc-editor.org/info/rfc5104>. February 2008, <https://www.rfc-editor.org/info/rfc5104>.
[RFC6843] Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol [RFC6843] Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol
(RTCP) Extended Report (XR) Block for Delay Metric (RTCP) Extended Report (XR) Block for Delay Metric
Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013, Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013,
<https://www.rfc-editor.org/info/rfc6843>. <https://www.rfc-editor.org/info/rfc6843>.
 End of changes. 26 change blocks. 
39 lines changed or deleted 104 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/