draft-ietf-rmcat-rtp-cc-feedback-10.txt   draft-ietf-rmcat-rtp-cc-feedback-11.txt 
Network Working Group C. Perkins Network Working Group C. Perkins
Internet-Draft University of Glasgow Internet-Draft University of Glasgow
Intended status: Informational July 11, 2022 Intended status: Informational October 7, 2022
Expires: January 12, 2023 Expires: April 10, 2023
Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in
Interactive Multimedia Conferences Interactive Multimedia Conferences
draft-ietf-rmcat-rtp-cc-feedback-10 draft-ietf-rmcat-rtp-cc-feedback-11
Abstract Abstract
This memo discusses the types of congestion control feedback that it This memo discusses the rate at which congestion control feedback can
is possible to send using the RTP Control Protocol (RTCP), and their be sent using the RTP Control Protocol (RTCP) and its suitability for
suitability of use in implementing congestion control for unicast implementing congestion control for unicast multimedia applications.
multimedia applications.
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 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 January 12, 2023. This Internet-Draft will expire on April 10, 2023.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 16 skipping to change at page 2, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Considerations for RTCP Feedback . . . . . . . . . . . . . . 3 2. Considerations for RTCP Feedback . . . . . . . . . . . . . . 3
3. What Feedback is Achievable With RTCP? . . . . . . . . . . . 5 3. What Feedback is Achievable With RTCP? . . . . . . . . . . . 5
3.1. Scenario 1: Voice Telephony . . . . . . . . . . . . . . . 5 3.1. Scenario 1: Voice Telephony . . . . . . . . . . . . . . . 5
3.2. Scenario 2: Point-to-Point Video Conference . . . . . . . 8 3.2. Scenario 2: Point-to-Point Video Conference . . . . . . . 8
4. Discussion and Conclusions . . . . . . . . . . . . . . . . . 11 4. Discussion and Conclusions . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. Informative References . . . . . . . . . . . . . . . . . . . 12 8. Informative References . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
The deployment of WebRTC systems [RFC8825] has resulted in high- The deployment of WebRTC systems [RFC8825] has resulted in high-
quality video conferencing seeing extremely wide use. To ensure the quality video conferencing seeing extremely wide use. To ensure the
stability of the network in the face of this use, WebRTC systems need stability of the network in the face of this use, WebRTC systems need
to use some form of congestion control for their RTP-based media to use some form of congestion control for their RTP-based media
traffic [RFC2914], [RFC8085], [RFC8083], [RFC8834], allowing them to traffic [RFC2914], [RFC8085], [RFC8083], [RFC8834], allowing them to
adapt and adjust the media data they send to match changes in the adapt and adjust the media data they send to match changes in the
skipping to change at page 2, line 48 skipping to change at page 2, line 48
control, or if some form of RTP extension is needed. control, or if some form of RTP extension is needed.
This memo considers unicast congestion feedback that can be sent This memo considers unicast congestion feedback that can be sent
using RTCP under the RTP/SAVPF profile [RFC5124] (the secure version using RTCP under the RTP/SAVPF profile [RFC5124] (the secure version
of the RTP/AVPF profile [RFC4585]). This profile was chosen as it of the RTP/AVPF profile [RFC4585]). This profile was chosen as it
forms the basis for media transport in WebRTC [RFC8834] systems. forms the basis for media transport in WebRTC [RFC8834] systems.
Nothing in this memo is specific to the secure version of the Nothing in this memo is specific to the secure version of the
profile, or to WebRTC, however. It is also assumed that the profile, or to WebRTC, however. It is also assumed that the
congestion control feedback mechanism described in [RFC8888], and congestion control feedback mechanism described in [RFC8888], and
common RTCP extensions for efficient feedback [RFC5506], [RFC8108], common RTCP extensions for efficient feedback [RFC5506], [RFC8108],
[RFC8861], and [RFC8872] are available. [RFC8861], and [RFC8872] are used.
2. Considerations for RTCP Feedback 2. Considerations for RTCP Feedback
Several questions need to be answered when providing RTCP reception Several questions need to be answered when providing RTCP feedback
quality feedback for congestion control purposes. These include: for congestion control purposes. These include:
o How often is feedback needed? o How often is feedback needed?
o How much overhead is acceptable? o How much overhead is acceptable?
o How much, and what, data does each report contain? o How much, and what, data does each report contain?
The key question is how often does the receiver need to send feedback The key question is how often does the receiver need to send feedback
on the reception quality it is experiencing, and hence the congestion on the reception quality it is experiencing and hence the congestion
state of the network? state of the network?
Widely used transport protocols, such as TCP, send acknowledgements Widely used transport protocols, such as TCP, send acknowledgements
frequently. For example, a TCP receiver will send an acknowledgement frequently. For example, a TCP receiver will send an acknowledgement
at least once every 0.5 seconds or when new data equal to twice the at least once every 0.5 seconds or when new data equal to twice the
maximum segment size has been received [I-D.ietf-tcpm-rfc793bis]). maximum segment size has been received [I-D.ietf-tcpm-rfc793bis]).
That has relatively low overhead when traffic is bidirectional and That has relatively low overhead when traffic is bidirectional and
acknowledgements can be piggybacked onto return path data packets. acknowledgements can be piggybacked onto return path data packets.
It can also be acceptable, and can have reasonable overhead, to send It can also be acceptable, and can have reasonable overhead, to send
separate acknowledgement packets when those packets are much smaller separate acknowledgement packets when those packets are much smaller
than data packets. than data packets.
Frequent acknowledgements can become a problem, however, when there Frequent acknowledgements can become a problem, however, when there
is no return traffic on which to piggyback feedback, or if separate is no return traffic on which to piggyback feedback, or if separate
feedback and data packets are sent and the feedback is similar in feedback and data packets are sent and the feedback is similar in
size to the data being acknowledged. This can be the case for some size to the data being acknowledged. This can be the case for some
forms of media traffic, especially for voice over IP flows, leading forms of media traffic, especially for voice over IP flows, leading
to high overhead when using a transport protocol that sends frequent to high overhead when using a transport protocol that sends frequent
feedback. Approaches like in-network filtering of acknowledgements feedback. Approaches like in-network filtering of acknowledgements
have been proposed to reduce acknowledgement overheads on highly that have been proposed to reduce acknowledgement overheads on highly
asymmetric links (e.g., as mentioned in [RFC3449]) can also reduce asymmetric links (e.g., as mentioned in [RFC3449]) can also reduce
the feedback frequency and overhead for multimedia traffic, but this the feedback frequency and overhead for multimedia traffic, but this
so-called "stretch-ACK" behaviour is non-standard and not guaranteed. so-called "stretch-ACK" behaviour is non-standard and not guaranteed.
Accordingly, when implementing congestion control for RTP-based Accordingly, when implementing congestion control for RTP-based
multimedia traffic, it might make sense to give the option of sending multimedia traffic, it might make sense to give the option of sending
congestion feedback less often than does TCP. For example, it might congestion feedback less often than TCP does. For example, it might
be possible to send a feedback packet once per video frame, or every be possible to send a feedback packet once per video frame, or every
few frames, or once per network round trip time (RTT). This could few frames, or once per network round trip time (RTT). This could
still give sufficiently frequent feedback for the congestion control still give sufficiently frequent feedback for the congestion control
loop to be stable and responsive while keeping the overhead loop to be stable and responsive while keeping the overhead
reasonable when the feedback cannot be piggybacked onto returning reasonable when the feedback cannot be piggybacked onto returning
data. In this case, it is important to note that RTCP can send much data. In this case, it is important to note that RTCP can send much
more detailed feedback than simple acknowledgements. For example, if more detailed feedback than simple acknowledgements. For example, if
it were useful, it could be possible to use an RTCP extended report it were useful, it could be possible to use an RTCP extended report
(XR) packet [RFC3611] to send feedback once per RTT comprising a (XR) packet [RFC3611] to send feedback once per RTT comprising a
bitmap of lost and received packets, with reception times, over that bitmap of lost and received packets, with reception times, over that
RTT. As long as feedback is sent frequently enough that the control RTT. As long as feedback is sent frequently enough that the control
loop is stable, and the sender is kept informed when data leaves the loop is stable, and the sender is kept informed when data leaves the
network (to provide an equivalent to ACK clocking in TCP), it is not network (to provide an equivalent to ACK clocking in TCP), it is not
necessary to report on every packet at the instant it is received. necessary to report on every packet at the instant it is received.
Indeed, it is unlikely that a video codec can react instantly to a Indeed, it is unlikely that a video codec can react instantly to a
rate change, and there is little point in providing feedback more rate change, and there is little point in providing feedback more
often than the codec can adapt. This suggests that an RTP receiver often than the codec can adapt. This suggests that an RTP receiver
ought to be configured to provide feedback at a rate that matches the needs to be configured to provide feedback at a rate that matches the
rate of adaptation of the sender. In the best case, this will match rate of adaptation of the sender. In the best case, this will match
the media frame rate, but might often be slower. the media frame rate, but might often be slower.
Reducing the feedback frequency compared to TCP will reduce feedback Reducing the feedback frequency compared to TCP will reduce feedback
overhead but will lead multimedia flows to adapt to congestion more overhead but will lead multimedia flows to adapt to congestion more
slowly than TCP, raising concerns about inter-flow fairness. Similar slowly than TCP, raising concerns about inter-flow fairness. Similar
concerns are noted in [RFC5348], and accordingly the congestion concerns are noted in [RFC5348], and accordingly the congestion
control algorithm described therein aims for "reasonable" fairness control algorithm described therein aims for "reasonable" fairness
and a sending rate that is "generally within a factor of two" of that and a sending rate that is "generally within a factor of two" of that
TCP would achieve under the same conditions. It is to be noted, TCP would achieve under the same conditions. It is to be noted,
skipping to change at page 6, line 10 skipping to change at page 6, line 10
(CCFB) packet [RFC8888]. Reduced-size RTCP packets contain only the (CCFB) packet [RFC8888]. Reduced-size RTCP packets contain only the
CCFB packet. Since each participant sends only a single RTP media CCFB packet. Since each participant sends only a single RTP media
stream, the extensions for RTCP report aggregation [RFC8108] and stream, the extensions for RTCP report aggregation [RFC8108] and
reporting group optimisation [RFC8861] are not used. reporting group optimisation [RFC8861] are not used.
Within each compound RTCP packet, the SR packet will contain a sender Within each compound RTCP packet, the SR packet will contain a sender
information block (28 octets) and a single reception report block (24 information block (28 octets) and a single reception report block (24
octets), for a total of 52 octets. A minimal SDES packet will octets), for a total of 52 octets. A minimal SDES packet will
contain a header (4 octets) and a single chunk containing an SSRC (4 contain a header (4 octets) and a single chunk containing an SSRC (4
octets) and a CNAME item, and if the recommendations for choosing the octets) and a CNAME item, and if the recommendations for choosing the
CNAME [RFC7022] are followed, the CNAME item will comprise a 2 octet CNAME [RFC7022] are followed, the CNAME item will comprise a 2-octet
header, 16 octets of data, and 2 octets of padding, for a total SDES header, 16 octets of data, and 2 octets of padding, for a total SDES
packet size of 28 octets. The CCFB packets contain an RTCP header packet size of 28 octets. The CCFB packets contain an RTCP header
and SSRC (8 octets), a report timestamp (4 octets), the SSRC, and SSRC (8 octets), a report timestamp (4 octets), the SSRC,
beginning and ending sequence numbers (8 octets), and 2*Nr octets of beginning and ending sequence numbers (8 octets), and 2*Nr octets of
reports, for a total of 20 + 2*Nr octets. The compound Secure RTCP reports, for a total of 20 + 2*Nr octets. The compound Secure RTCP
packet will include 4 octets of trailer followed by an 80 bit (10 packet will include 4 octets of trailer followed by an 80 bit (10
octet) authentication tag if HMAC-SHA1 authentication is used. If octet) authentication tag if HMAC-SHA1 authentication is used. If
IPv4 is used, with no IP options, the UDP/IP header will be 28 octets IPv4 is used, with no IP options, the UDP/IP header will be 28 octets
in size. This gives a total compound RTCP packet size of Sc = 142 + in size. This gives a total compound RTCP packet size of Sc = 142 +
2*Nr octets. 2*Nr octets.
skipping to change at page 9, line 6 skipping to change at page 9, line 6
will be a reporting SSRC, to which the other SSRC will have delegated will be a reporting SSRC, to which the other SSRC will have delegated
its reports. No reduced-size RTCP packets are sent. its reports. No reduced-size RTCP packets are sent.
The aggregated compound RTCP packet from the non-reporting SSRC will The aggregated compound RTCP packet from the non-reporting SSRC will
contain an RTCP SR packet, an RTCP SDES packet, and an RTCP RGRS contain an RTCP SR packet, an RTCP SDES packet, and an RTCP RGRS
packet. The RTCP SR packet contains the 28 octet header and sender packet. The RTCP SR packet contains the 28 octet header and sender
information, but no report blocks (since the reporting is delegated). information, but no report blocks (since the reporting is delegated).
The RTCP SDES packet will comprise a header (4 octets), originating The RTCP SDES packet will comprise a header (4 octets), originating
SSRC (4 octets), a CNAME chunk, a terminating chunk, and any padding. SSRC (4 octets), a CNAME chunk, a terminating chunk, and any padding.
If the CNAME follows [RFC7022] and [RFC8834] the CNAME chunk will be If the CNAME follows [RFC7022] and [RFC8834] the CNAME chunk will be
18 octets in size, and will be followed one octet of padding and one 18 octets in size, and will be followed by one octet of padding and
terminating null octet to align the SDES packet to the required one terminating null octet to align the SDES packet to a 32-bit
32-bit boundary ([RFC3550], section 6.5), making the SDES packet 28 boundary ([RFC3550], section 6.5), making the SDES packet 28 octets
octets in size. The RTCP RGRS packet will be 12 octets in size. in size. The RTCP RGRS packet will be 12 octets in size. This gives
This gives a total of 28 + 28 + 12 = 68 octets. a total of 28 + 28 + 12 = 68 octets.
The aggregated compound RTCP packet from the reporting SSRC will The aggregated compound RTCP packet from the reporting SSRC will
contain an RTCP SR packet, an RTCP SDES packet, and an RTCP contain an RTCP SR packet, an RTCP SDES packet, and an RTCP
congestion control feedback packet. The RTCP SR packet will contain congestion control feedback packet. The RTCP SR packet will contain
two report blocks, one for each of the remote SSRCs (the report for two report blocks, one for each of the remote SSRCs (the report for
the other local SSRC is suppressed by the reporting group extension), the other local SSRC is suppressed by the reporting group extension),
for a total of 28 + (2 * 24) = 76 octets. The RTCP SDES packet will for a total of 28 + (2 * 24) = 76 octets. The RTCP SDES packet will
comprise a header (4 octets), originating SSRC (4 octets), a CNAME comprise a header (4 octets), originating SSRC (4 octets), a CNAME
chunk, an RGRP chunk, a terminating chunk, and any padding. If the chunk, an RGRP chunk, a terminating chunk, and any padding. If the
CNAME follows [RFC7022] and [RFC8834] it will be 18 octets in size. CNAME follows [RFC7022] and [RFC8834] it will be 18 octets in size.
The RGRP chunk similarly comprises 18 octets, and 3 octets of padding The RGRP chunk similarly comprises 18 octets, and 3 octets of padding
are needed, for a total of 48 octets. The RTCP congestion control are needed, for a total of 48 octets. The RTCP congestion control
feedback (CCFB) report comprises an 8 octet RTCP header and SSRC, a 4 feedback (CCFB) report comprises an 8-octet RTCP header and SSRC, a
octet report timestamp, and for each of the remote audio and video 4-octet report timestamp, and for each of the remote audio and video
SSRCs, an 8 octet report header, and 2 octets per packet reported SSRCs, an 8-octet report header, and 2 octets per packet reported
upon, and padding to a 4 octet boundary if needed; that is 8 + 4 + 8 upon, and padding to a 4-octet boundary if needed; that is 8 + 4 + 8
+ (2 * Nv) + 8 + (2 * Na) where Nv is the number of video packets per + (2 * Nv) + 8 + (2 * Na) where Nv is the number of video packets per
report, and Na is the number of audio packets per report. report, and Na is the number of audio packets per report.
The complete compound RTCP packet contains the RTCP packets from both The complete compound RTCP packet contains the RTCP packets from both
the reporting and non-reporting SSRCs, an SRTCP trailer and the reporting and non-reporting SSRCs, an SRTCP trailer and
authentication tag, and a UDP/IPv4 header. The size of this RTCP authentication tag, and a UDP/IPv4 header. The size of this RTCP
packet is therefore: 262 + (2 * Nv) + (2 * Na) octets. Since the packet is therefore: 262 + (2 * Nv) + (2 * Na) octets. Since the
aggregate RTCP packet contains reports from two SSRCs, the RTCP aggregate RTCP packet contains reports from two SSRCs, the RTCP
packet size is halved before use [RFC8108]. Accordingly, the size of packet size is halved before use [RFC8108]. Accordingly, the size of
the RTCP packets is: the RTCP packets is:
Srtcp = (262 + (2 * Nv) + (2 * Na)) / 2 Srtcp = (262 + (2 * Nv) + (2 * Na)) / 2
How many RTP packets does the RTCP XR congestion control feedback How many RTP packets does the RTCP XR congestion control feedback
packet included in these compound RTCP packets report on? That is, packet, included in these compound RTCP packets, report on? That is,
what are the values of Nv and Na? This depends on the RTCP reporting what are the values of Nv and Na? This depends on the RTCP reporting
interval, Trtcp, the video bit rate and frame rate, Rf, the audio bit interval, Trtcp, the video bit rate and frame rate, Rf, the audio bit
rate and framing interval, and whether the receiver chooses to send rate and framing interval, and whether the receiver chooses to send
congestion control feedback in each RTCP packet it sends. congestion control feedback in each RTCP packet it sends.
To simplify the calculation, assume it is desired to send one RTCP To simplify the calculation, assume it is desired to send one RTCP
report for each frame of video received (i.e., Trtcp = 1 / Rf) and to report for each frame of video received (i.e., Trtcp = 1 / Rf) and to
include a congestion control feedback packet in each report. Assume include a congestion control feedback packet in each report. Assume
that video has constant bit rate and frame rate, and that each frame that video has constant bit rate and frame rate, and that each frame
of packet has to fit into a 1500 octet MTU. Further, assume that the of packet has to fit into a 1500 octet MTU. Further, assume that the
skipping to change at page 12, line 7 skipping to change at page 12, line 7
RTCP can, however, be used to send congestion feedback on each frame RTCP can, however, be used to send congestion feedback on each frame
of video sent, provided the session bandwidth exceeds a couple of of video sent, provided the session bandwidth exceeds a couple of
megabits per second (the exact rate depending on the number of megabits per second (the exact rate depending on the number of
session participants, the RTCP bandwidth fraction, and what RTCP session participants, the RTCP bandwidth fraction, and what RTCP
extensions are enabled, and how much detail of feedback is needed). extensions are enabled, and how much detail of feedback is needed).
For lower rate sessions, the overhead of reporting on every frame For lower rate sessions, the overhead of reporting on every frame
becomes high, but can be reduced to something reasonable by sending becomes high, but can be reduced to something reasonable by sending
reports once per N frames (e.g., every second frame), or by sending reports once per N frames (e.g., every second frame), or by sending
reduced-size RTCP reports in between the regular reports. reduced-size RTCP reports in between the regular reports.
If it is desired to use RTCP in something close to it's current form If it is desired to use RTCP in something close to its current form
for congestion feedback in WebRTC, the multimedia congestion control for congestion feedback in WebRTC, the multimedia congestion control
algorithm needs to be designed to work with feedback sent every few algorithm needs to be designed to work with feedback sent every few
frames, since that fits within the limitations of RTCP. The provided frames, since that fits within the limitations of RTCP. The provided
feedback will be more detailed than just an acknowledgement, however, feedback will be more detailed than just an acknowledgement, however,
and will provide a loss bitmap, relative arrival time, and received and will provide a loss bitmap, relative arrival time, and received
ECN marks, for each packet sent. This will allow congestion control ECN marks, for each packet sent. This will allow congestion control
that is effective, if slowly responsive, to be implemented (there is that is effective, if slowly responsive, to be implemented (there is
guidance on providing effective congestion control in Section 3.1 of guidance on providing effective congestion control in Section 3.1 of
[RFC8085]). [RFC8085]).
The format described in [RFC8888] seems sufficient for the needs of The format described in [RFC8888] seems sufficient for the needs of
congestion control feedback. There is little point optimising this congestion control feedback. There is little point optimising this
format: the main overhead comes from the UDP/IP headers and the other format: the main overhead comes from the UDP/IP headers and the other
RTCP packets included in the compound packets, and can be lowered by RTCP packets included in the compound packets, and can be lowered by
using the [RFC5506] extensions and sending reports less frequently. using the [RFC5506] extensions and sending reports less frequently.
The use of header compression [RFC2508], [RFC3545], [RFC5795] can The use of header compression [RFC2508], [RFC3545], [RFC5795] can
also be beneficial. also be beneficial.
Further study of the scenarios of interest is needed, to ensure that Further study of the scenarios of interest is needed, to ensure that
the analysis presented is applicable to other media topologies, and the analysis presented is applicable to other media topologies
to sessions with different data rates and sizes of membership. [RFC7667], and to sessions with different data rates and sizes of
membership.
5. Security Considerations 5. Security Considerations
An attacker that can modify or spoof RTCP congestion control feedback An attacker that can modify or spoof RTCP congestion control feedback
packets can manipulate the sender behaviour to cause denial of packets can manipulate the sender behaviour to cause denial of
service. This can be prevented by authentication and integrity service. This can be prevented by authentication and integrity
protection of RTCP packets, for example using the secure RTP profile protection of RTCP packets, for example using the secure RTP profile
[RFC3711][RFC5124], or by other means as discussed in [RFC7201]. [RFC3711][RFC5124], or by other means as discussed in [RFC7201].
6. IANA Considerations 6. IANA Considerations
There are no actions for IANA. There are no actions for IANA.
7. Acknowledgements 7. Acknowledgements
Thanks to Magnus Westerlund, Ingemar Johansson, Gorry Fairhurst, and Thanks to Magnus Westerlund, Ingemar Johansson, Gorry Fairhurst,
the members of the RMCAT feedback design team for their feedback. Linda Dunbar, Shuping Peng, and the members of the RMCAT feedback
design team for their feedback.
8. Informative References 8. Informative References
[I-D.ietf-tcpm-rfc793bis] [I-D.ietf-tcpm-rfc793bis]
Eddy, W., "Transmission Control Protocol (TCP) Eddy, W., "Transmission Control Protocol (TCP)
Specification", draft-ietf-tcpm-rfc793bis-20 (work in Specification", draft-ietf-tcpm-rfc793bis-20 (work in
progress), January 2021. progress), January 2021.
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508, Headers for Low-Speed Serial Links", RFC 2508,
skipping to change at page 14, line 34 skipping to change at page 14, line 34
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP) "Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022,
September 2013, <https://www.rfc-editor.org/info/rfc7022>. September 2013, <https://www.rfc-editor.org/info/rfc7022>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<https://www.rfc-editor.org/info/rfc7201>. <https://www.rfc-editor.org/info/rfc7201>.
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
DOI 10.17487/RFC7667, November 2015,
<https://www.rfc-editor.org/info/rfc7667>.
[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>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, [RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
 End of changes. 19 change blocks. 
32 lines changed or deleted 37 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/