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/ |