draft-ietf-avtcore-cc-feedback-message-07.txt   draft-ietf-avtcore-cc-feedback-message-08.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: December 12, 2020 University of Glasgow Expires: March 6, 2021 University of Glasgow
V. Singh V. Singh
callstats.io callstats.io
M. Ramalho M. Ramalho
June 10, 2020 September 2, 2020
RTP Control Protocol (RTCP) Feedback for Congestion Control RTP Control Protocol (RTCP) Feedback for Congestion Control
draft-ietf-avtcore-cc-feedback-message-07 draft-ietf-avtcore-cc-feedback-message-08
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.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 https://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 December 12, 2020. This Internet-Draft will expire on March 6, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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 . . . . . . . . . . . . . . . 7 4. Feedback Frequency and Overhead . . . . . . . . . . . . . . . 7
5. Response to Loss of Feedback Packets . . . . . . . . . . . . 7 5. Response to Loss of Feedback Packets . . . . . . . . . . . . 8
6. SDP Signalling . . . . . . . . . . . . . . . . . . . . . . . 8 6. SDP Signalling . . . . . . . . . . . . . . . . . . . . . . . 8
7. Relation to RFC 6679 . . . . . . . . . . . . . . . . . . . . 8 7. Relation to RFC 6679 . . . . . . . . . . . . . . . . . . . . 9
8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 9 8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . 12 12.1. Normative References . . . . . . . . . . . . . . . . . . 12
12.2. Informative References . . . . . . . . . . . . . . . . . 13 12.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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 [RFC3550] running over the User Datagram Protocol (UDP). RTP does
any guarantee of Quality of Service (QoS), reliability, or timely not provide any guarantee of Quality of Service (QoS), reliability,
delivery, and expects the underlying transport protocol to do so. or timely delivery, and expects the underlying transport protocol to
UDP alone certainly does not meet that expectation. However, the RTP do so. UDP alone certainly does not meet that expectation. However,
Control Protocol (RTCP) provides a mechanism by which the receiver of the RTP Control Protocol (RTCP) [RFC3550] provides a mechanism by
an RTP flow can periodically send transport and media quality metrics which the receiver of an RTP flow can periodically send transport and
to the sender of that RTP flow. This information can be used by the media quality metrics to the sender of that RTP flow. This
sender to perform congestion control. In the absence of standardized information can be used by the sender to perform congestion control.
messages for this purpose, designers of congestion control algorithms In the absence of standardized messages for this purpose, designers
have developed proprietary RTCP messages that convey only those of congestion control algorithms have developed proprietary RTCP
parameters needed for their respective designs. As a direct result, messages that convey only those parameters needed for their
the different congestion control (i.e., rate adaptation) designs are respective designs. As a direct result, the different congestion
not interoperable. To enable algorithm evolution as well as control designs are not interoperable. To enable algorithm evolution
interoperability across designs (e.g., different rate adaptation as well as interoperability across designs (e.g., different rate
algorithms), it is highly desirable to have generic congestion adaptation algorithms), it is highly desirable to have generic
control feedback format. congestion control feedback format.
To help achieve interoperability for unicast RTP congestion control, To help achieve interoperability for unicast RTP congestion control,
this memo proposes a common RTCP feedback packet format that can be this memo proposes a common RTCP feedback packet format that can be
used by NADA [RFC8698], SCReAM [RFC8298], Google Congestion Control used by NADA [RFC8698], SCReAM [RFC8298], Google Congestion Control
[I-D.ietf-rmcat-gcc] and Shared Bottleneck Detection [RFC8382], and [I-D.ietf-rmcat-gcc] and Shared Bottleneck Detection [RFC8382], and
hopefully also by future RTP congestion control algorithms. hopefully also by future RTP congestion control algorithms.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
In addition the terminology defined in [RFC3550], [RFC3551], In addition the terminology defined in [RFC3550], [RFC3551],
[RFC3611], [RFC4585], and [RFC5506] applies. [RFC3611], [RFC4585], and [RFC5506] applies.
3. RTCP Feedback for Congestion Control 3. RTCP Feedback for Congestion Control
Based on an analysis of NADA [RFC8698], SCReAM [RFC8298], Google Based on an analysis of NADA [RFC8698], SCReAM [RFC8298], Google
Congestion Control [I-D.ietf-rmcat-gcc] and Shared Bottleneck Congestion Control [I-D.ietf-rmcat-gcc] and Shared Bottleneck
Detection [RFC8382], the following per-RTP packet congestion control Detection [RFC8382], the following per-RTP packet congestion control
feedback information has been determined to be necessary: feedback information has been determined to be necessary:
o RTP sequence number: The receiver of an RTP flow needs to feedback o RTP sequence number: The receiver of an RTP flow needs to feed the
the sequence numbers of the received RTP packets to the sender, so sequence numbers of the received RTP packets back to the sender,
the sender can determine which packets were received and which so the sender can determine which packets were received and which
were lost. Packet loss is used as an indication of congestion by were lost. Packet loss is used as an indication of congestion by
many congestion control algorithms. many congestion control algorithms.
o Packet Arrival Time: The receiver of an RTP flow needs to feedback o Packet Arrival Time: The receiver of an RTP flow needs to feed the
the arrival time of each RTP packet to the sender. Packet delay arrival time of each RTP packet back to the sender. Packet delay
and/or delay variation (jitter) is used as a congestion signal by and/or delay variation (jitter) is used as a congestion signal by
some congestion control algorithms. some congestion control algorithms.
o Packet Explicit Congestion Notification (ECN) Marking: If ECN o Packet Explicit Congestion Notification (ECN) Marking: If ECN
[RFC3168], [RFC6679] is used, it is necessary to feedback the [RFC3168], [RFC6679] is used, it is necessary to feed back the
2-bit ECN mark in received RTP packets, indicating for each RTP 2-bit ECN mark in received RTP packets, indicating for each RTP
packet whether it is marked not-ECT, ECT(0), ECT(1), or ECN-CE. packet whether it is marked not-ECT, ECT(0), ECT(1), or ECN-CE.
If the path used by the RTP traffic is ECN capable the sender can If the path used by the RTP traffic is ECN capable the sender can
use Congestion Experienced (ECN-CE) marking information as a use Congestion Experienced (ECN-CE) marking information as a
congestion control signal. congestion control signal.
Every RTP flow is identified by its Synchronization Source (SSRC) Every RTP flow is identified by its Synchronization Source (SSRC)
identifier. Accordingly, the RTCP feedback format needs to group its identifier. Accordingly, the RTCP feedback format needs to group its
reports by SSRC, sending one report block per received SSRC. reports by SSRC, sending one report block per received SSRC.
skipping to change at page 5, line 33 skipping to change at page 6, line 14
in the report block is not a multiple of two, then 16 bits of zero in the report block is not a multiple of two, then 16 bits of zero
padding MUST be added after the last packet metric block, to align padding MUST be added after the last packet metric block, to align
the end of the packet metric blocks with the next 32 bit boundary. the end of the packet metric blocks with the next 32 bit boundary.
The value of num_reports MAY be zero, indicating that there are no The value of num_reports MAY be zero, indicating that there are no
packet metric blocks included for that SSRC. Each report block MUST packet metric blocks included for that SSRC. Each report block MUST
NOT include more than 16384 packet metric blocks (i.e., it MUST NOT NOT include more than 16384 packet metric blocks (i.e., it MUST NOT
report on more than one quarter of the sequence number space in a report on more than one quarter of the sequence number space in a
single report). single report).
The contents of each 16-bit packet metric block comprises the L, ECN, The contents of each 16-bit packet metric block comprises the L, ECN,
and ATO fields are as follows: and ATO fields as follows:
o L (1 bit): is a boolean to indicate if the packet was received. 0 o L (1 bit): is a boolean to indicate if the packet was received. 0
represents that the packet was not yet received and all the 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 represents
packet was received and the subsequent bits in the block need to that the packet was received and the subsequent bits in the block
be parsed. need to be parsed.
o ECN (2 bits): is the echoed ECN mark of the packet. These are set o ECN (2 bits): is the echoed ECN mark of the packet. These are set
to 00 if not received, or if ECN is not used. to 00 if not received, or if ECN is not used.
o Arrival time offset (ATO, 13 bits): is the arrival time of the RTP o Arrival time offset (ATO, 13 bits): is the arrival time of the RTP
packet at the receiver, as an offset before the time represented packet at the receiver, as an offset before the time represented
by the Report Timestamp (RTS) field of this RTCP congestion by the Report Timestamp (RTS) field of this RTCP congestion
control feedback report. The ATO field is in units of 1/1024 control feedback report. The ATO field is in units of 1/1024
seconds (this unit is chosen to give exact offsets from the RTS seconds (this unit is chosen to give exact offsets from the RTS
field) so, for example, an ATO value of 512 indicates that the field) so, for example, an ATO value of 512 indicates that the
skipping to change at page 7, line 50 skipping to change at page 8, line 34
5. Response to Loss of Feedback Packets 5. Response to Loss of Feedback Packets
Like all RTCP packets, RTCP congestion control feedback packets might Like all RTCP packets, RTCP congestion control feedback packets might
be lost. All RTP congestion control algorithms MUST specify how they be lost. All RTP congestion control algorithms MUST specify how they
respond to the loss of feedback packets. respond to the loss of feedback packets.
If only a single congestion control feedback packet is lost, an If only a single congestion control feedback packet is lost, an
appropriate response is to assume that the level of congestion has appropriate response is to assume that the level of congestion has
remained roughly the same as the previous report. However, if remained roughly the same as the previous report. However, if
multiple consecutive congestion control feedback packets are lost, multiple consecutive congestion control feedback packets are lost,
the sender SHOULD rapidly reduce its sending rate towards zero, as then the sender SHOULD rapidly reduce its sending rate as this likely
this likely indicates a path failure. The RTP circuit breaker indicates a path failure. The RTP circuit breaker [RFC8083] provides
[RFC8083] provides further guidance. further guidance.
6. SDP Signalling 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 The payload type used with "ccfb" feedback MUST be the wildcard type
be used. This implies that the congestion control feedback is sent ("*"). This implies that the congestion control feedback is sent for
for all payload types in use in the session, including any FEC and all payload types in use in the session, including any FEC and
retransmission payload types. An example of the resulting SDP retransmission payload types. An example of the resulting SDP
attribute is: attribute is:
a=rtcp-fb:* ack ccfb 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]. specified in Section 4.2 of the RTP/AVPF profile [RFC4585].
An SDP offer might indicate support for both the congestion control An SDP offer might indicate support for both the congestion control
feedback mechanism specified in this memo and one or more alternative feedback mechanism specified in this memo and one or more alternative
skipping to change at page 9, line 24 skipping to change at page 10, line 7
used. used.
8. 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. The feedback format defined in this packets to react effectively. The feedback format defined in this
memo provides such fine grained feedback. memo provides such fine-grained feedback.
Several other RTCP extensions also provide more detailed feedback Several other RTCP extensions also provide more detailed feedback
than SR/RR packets: than SR/RR packets:
TMMBR: The Codec Control Messages for the RTP/AVPF profile [RFC5104] TMMBR: The Codec Control Messages for the RTP/AVPF profile [RFC5104]
include a Temporary Maximum Media Bit Rate (TMMBR) message. This include a Temporary Maximum Media Bit Rate (TMMBR) message. This
is used to convey a temporary maximum bit rate limitation from a is used to convey a temporary maximum bit rate limitation from a
receiver of RTP packets to their sender. Even though it was not receiver of RTP packets to their sender. Even though it was not
designed to replace congestion control, TMMBR has been used as a designed to replace congestion control, TMMBR has been used as a
means to do receiver based congestion control where the session means to do receiver based congestion control where the session
bandwidth is high enough to send frequent TMMBR messages, bandwidth is high enough to send frequent TMMBR messages,
especially when used with non-compound RTCP packets [RFC5506]. especially when used with non-compound RTCP packets [RFC5506].
This approach requires the receiver of the RTP packets to monitor This approach requires the receiver of the RTP packets to monitor
their reception, determine the level of congestion, and recommend their reception, determine the level of congestion, and recommend
a maximum bit rate suitable for current available bandwidth on the a maximum bit rate suitable for current available bandwidth on the
path; it also assumes that the RTP sender can/will respect that path; it also assumes that the RTP sender can/will respect that
bit rate. This is the opposite of the sender based congestion bit rate. This is the opposite of the sender-based congestion
control approach suggested in this memo, so TMMBR cannot be used control approach suggested in this memo, so TMMBR cannot be used
to convey the information needed for a sender based congestion to convey the information needed for a sender-based congestion
control. TMMBR could, however, be viewed a complementary control. TMMBR could, however, be viewed a complementary
mechanism that can inform the sender of the receiver's current mechanism that can inform the sender of the receiver's current
view of acceptable maximum bit rate. The Received Estimated view of acceptable maximum bit rate. The Received Estimated
Maximum Bit-rate (REMB) mechanism [I-D.alvestrand-rmcat-remb] Maximum Bit-rate (REMB) mechanism [I-D.alvestrand-rmcat-remb]
provides similar feedback. provides similar feedback.
RTCP Extended Reports (XR): Numerous RTCP extended report (XR) RTCP Extended Reports (XR): Numerous RTCP extended report (XR)
blocks have been defined to report details of packet loss, arrival blocks have been defined to report details of packet loss, arrival
times [RFC3611], delay [RFC6843], and ECN marking [RFC6679]. It times [RFC3611], delay [RFC6843], and ECN marking [RFC6679]. It
is possible to combine several such XR blocks into a compound RTCP is possible to combine several such XR blocks into a compound RTCP
skipping to change at page 10, line 36 skipping to change at page 11, line 19
transport-wide feedback makes it more difficult to adapt the transport-wide feedback makes it more difficult to adapt the
sending rate, or respond to lost packets, based on the reception sending rate, or respond to lost packets, based on the reception
and/or loss patterns observed on a per-SSRC basis (for example, to and/or loss patterns observed on a per-SSRC basis (for example, to
perform differential rate control and repair for audio and video perform differential rate control and repair for audio and video
flows, based on knowledge of what packets from each flow were flows, based on knowledge of what packets from each flow were
lost). Transport-wide feedback is also a less natural fit with lost). Transport-wide feedback is also a less natural fit with
the wider RTP framework, which makes extensive use of per-SSRC the wider RTP framework, which makes extensive use of per-SSRC
sequence numbers and feedback. sequence numbers and feedback.
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.
9. 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
skipping to change at page 11, line 34 skipping to change at page 12, line 14
11. 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.,
[RFC8698], [RFC8298], [I-D.ietf-rmcat-gcc], or [RFC8382]) apply. [RFC8698], [RFC8298], [I-D.ietf-rmcat-gcc], or [RFC8382]) 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 causing
path. This will negatively impact the quality of experience of that congestion on the path. This will negatively impact the quality of
receiver. Since RTP is an unreliable transport, a sender can experience of that receiver. Since RTP is an unreliable transport, a
intentionally leave a gap in the RTP sequence number space without sender can intentionally leave a gap in the RTP sequence number space
causing harm, to check that the receiver is correctly reporting without causing harm, to check that the receiver is correctly
losses. reporting 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.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-54 (work in progress), December 2018. negotiation-54 (work in progress), December 2018.
[I-D.ietf-mmusic-sdp-mux-attributes] [I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
skipping to change at page 12, line 14 skipping to change at page 12, line 39
12.1. Normative References 12.1. Normative References
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-54 (work in progress), December 2018. negotiation-54 (work in progress), December 2018.
[I-D.ietf-mmusic-sdp-mux-attributes] [I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-19
(work in progress), February 2018. (work in progress), August 2020.
[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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
skipping to change at page 13, line 25 skipping to change at page 14, line 5
[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>.
[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", RFC 8083, Circuit Breakers for Unicast RTP Sessions", RFC 8083,
DOI 10.17487/RFC8083, March 2017, DOI 10.17487/RFC8083, March 2017,
<https://www.rfc-editor.org/info/rfc8083>. <https://www.rfc-editor.org/info/rfc8083>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References 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.alvestrand-rmcat-remb] [I-D.alvestrand-rmcat-remb]
Alvestrand, H., "RTCP message for Receiver Estimated Alvestrand, H., "RTCP message for Receiver Estimated
Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in
 End of changes. 27 change blocks. 
59 lines changed or deleted 66 lines changed or added

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