draft-ietf-rmcat-rtp-cc-feedback-11.txt   draft-ietf-rmcat-rtp-cc-feedback-12.txt 
Network Working Group C. Perkins Network Working Group C. S. Perkins
Internet-Draft University of Glasgow Internet-Draft University of Glasgow
Intended status: Informational October 7, 2022 Intended status: Informational 21 December 2022
Expires: April 10, 2023 Expires: 24 June 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-11 draft-ietf-rmcat-rtp-cc-feedback-12
Abstract Abstract
This memo discusses the rate at which congestion control feedback can This memo discusses the rate at which congestion control feedback can
be sent using the RTP Control Protocol (RTCP) and its suitability for be sent using the RTP Control Protocol (RTCP) and its suitability for
implementing congestion control for unicast multimedia applications. implementing congestion control for unicast 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
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 April 10, 2023. This Internet-Draft will expire on 24 June 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
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 . . . . . . . 10
4. Discussion and Conclusions . . . . . . . . . . . . . . . . . 11 4. Discussion and Conclusions . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
8. Informative References . . . . . . . . . . . . . . . . . . . 13 8. Normative References . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Informative References . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
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
available network capacity. In addition to ensuring the stable available network capacity. In addition to ensuring the stable
skipping to change at page 2, line 40 skipping to change at page 2, line 41
to the network capacity, rather than forcing the receiver to to the network capacity, rather than forcing the receiver to
compensate for uncontrolled packet loss when the available capacity compensate for uncontrolled packet loss when the available capacity
is exceeded. is exceeded.
To develop such congestion control, it is necessary to understand the To develop such congestion control, it is necessary to understand the
sort of congestion feedback that can be provided within the framework sort of congestion feedback that can be provided within the framework
of RTP [RFC3550] and the RTP Control Protocol (RTCP). It then of RTP [RFC3550] and the RTP Control Protocol (RTCP). It then
becomes possible to determine if this is sufficient for congestion becomes possible to determine if this is sufficient for congestion
control, or if some form of RTP extension is needed. control, or if some form of RTP extension is needed.
As this memo will show, if it is desired to use RTCP in something
close to its current form for congestion feedback, the multimedia
congestion control algorithm needs to be designed to work with
detailed feedback sent every few frames, rather than per-frame
acknowledgement, to match the constraints of RTCP.
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 used. [RFC8861], and [RFC8872] are used.
2. Considerations for RTCP Feedback 2. Considerations for RTCP Feedback
Several questions need to be answered when providing RTCP feedback Several questions need to be answered when providing RTCP feedback
for congestion control purposes. These include: for congestion control purposes. These include:
o How often is feedback needed? * How often is feedback needed?
o How much overhead is acceptable? * How much overhead is acceptable?
o How much, and what, data does each report contain? * 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 [RFC9293]). That has
That has relatively low overhead when traffic is bidirectional and 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
skipping to change at page 6, line 29 skipping to change at page 6, line 36
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.
The reduced-size RTCP packets will comprise just the CCFB packet, The reduced-size RTCP packets will comprise just the CCFB packet,
SRTCP trailer and authentication tag, and a UDP/IP header. It can be SRTCP trailer and authentication tag, and a UDP/IP header. It can be
seen that these packets will be Srs = 62 + 2*Nr octets in size. seen that these packets will be Srs = 62 + 2*Nr octets in size.
The RTCP reporting interval calculation ([RFC3550], Section 6.2) for The RTCP reporting interval calculation ([RFC3550], Section 6.2) for
a two-party session where both participants are senders, reduces to: a two-party session where both participants are senders, reduces to:
Trtcp = n * Srtcp / Brtcp | Trtcp = n * Srtcp / Brtcp
where Srtcp = (Sc + Nrs * Srs)/(1 + Nrs) is the average RTCP packet where Srtcp = (Sc + Nrs * Srs)/(1 + Nrs) is the average RTCP packet
size in octets, Brtcp is the bandwidth allocated to RTCP in octets size in octets, Brtcp is the bandwidth allocated to RTCP in octets
per second, and n is the number of participants in the RTP session per second, and n is the number of participants in the RTP session
(in this scenario, n = 2). (in this scenario, n = 2).
To ensure an RTCP report containing congestion control feedback is To ensure an RTCP report containing congestion control feedback is
sent after every Nr frames of audio, it is necessary to set the RTCP sent after every Nr frames of audio, it is necessary to set the RTCP
reporting interval Trtcp = Nr * Tf, which when substituted into the reporting interval Trtcp = Nr * Tf, which when substituted into the
previous gives Nr * Tf = n * Srtcp/Brtcp. Solving this to give the previous gives Nr * Tf = n * Srtcp/Brtcp. Solving this to give the
RTCP bandwidth, Brtcp, and expanding the definition of Srtcp gives: RTCP bandwidth, Brtcp, and expanding the definition of Srtcp gives:
Brtcp = (n * (Sc + Nrs * Srs))/(Nr * Tf * (1 + Nrs)). | Brtcp = (n * (Sc + Nrs * Srs))/(Nr * Tf * (1 + Nrs)).
If we assume every report is a compound RTCP packet (i.e., Nrs = 0), If we assume every report is a compound RTCP packet (i.e., Nrs = 0),
the frame duration Tf = 20ms, and an RTCP report is sent for every the frame duration Tf = 20ms, and an RTCP report is sent for every
second frame (i.e., 25 RTCP reports per second), this gives an RTCP second frame (i.e., 25 RTCP reports per second), this gives an RTCP
feedback bandwidth, Brtcp = 57kbps. Increasing the frame duration, feedback bandwidth, Brtcp = 57kbps. Increasing the frame duration,
or reducing the frequency of reports, will reduce the RTCP bandwidth or reducing the frequency of reports, will reduce the RTCP bandwidth
as shown in Table 1. as shown in Table 1.
+--------------+-------------+----------------+ +--------------+-------------+----------------+
| Tf (seconds) | Nr (frames) | rtcp_bw (kbps) | | Tf (seconds) | Nr (frames) | rtcp_bw (kbps) |
+--------------+-------------+----------------+ +--------------+-------------+----------------+
| 0.020 | 2 | 57.0 | | 0.020 | 2 | 57.0 |
| 0.020 | 4 | 29.3 | +--------------+-------------+----------------+
| 0.020 | 8 | 15.4 | | 0.020 | 4 | 29.3 |
| 0.020 | 16 | 8.5 | +--------------+-------------+----------------+
| 0.060 | 2 | 19.0 | | 0.020 | 8 | 15.4 |
| 0.060 | 4 | 9.8 | +--------------+-------------+----------------+
| 0.060 | 8 | 5.1 | | 0.020 | 16 | 8.5 |
| 0.060 | 16 | 2.8 | +--------------+-------------+----------------+
| 0.060 | 2 | 19.0 |
+--------------+-------------+----------------+
| 0.060 | 4 | 9.8 |
+--------------+-------------+----------------+
| 0.060 | 8 | 5.1 |
+--------------+-------------+----------------+
| 0.060 | 16 | 2.8 |
+--------------+-------------+----------------+ +--------------+-------------+----------------+
Table 1: RTCP bandwidth needed for VoIP feedback (compound reports Table 1: RTCP bandwidth needed for VoIP
only) feedback (compound reports only)
The final row of Table 1 (60ms frames, report every 16 frames) sends The final row of Table 1 (60ms frames, report every 16 frames) sends
RTCP reports once per second, giving an RTCP bandwidth overhead of RTCP reports once per second, giving an RTCP bandwidth overhead of
2.8kbps. 2.8kbps.
The overhead can be reduced by sending some reports in reduced-size The overhead can be reduced by sending some reports in reduced-size
RTCP packets [RFC5506]. For example, if we alternate compound and RTCP packets [RFC5506]. For example, if we alternate compound and
reduced-size RTCP packets, i.e., Nrs = 1, the calculation gives the reduced-size RTCP packets, i.e., Nrs = 1, the calculation gives the
results shown in Table 2. results shown in Table 2.
+--------------+-------------+----------------+ +--------------+-------------+----------------+
| Tf (seconds) | Nr (frames) | rtcp_bw (kbps) | | Tf (seconds) | Nr (frames) | rtcp_bw (kbps) |
+--------------+-------------+----------------+ +--------------+-------------+----------------+
| 0.020 | 2 | 41.4 | | 0.020 | 2 | 41.4 |
| 0.020 | 4 | 21.5 | +--------------+-------------+----------------+
| 0.020 | 8 | 11.5 | | 0.020 | 4 | 21.5 |
| 0.020 | 16 | 6.5 | +--------------+-------------+----------------+
| 0.060 | 2 | 13.8 | | 0.020 | 8 | 11.5 |
| 0.060 | 4 | 7.2 | +--------------+-------------+----------------+
| 0.060 | 8 | 3.8 | | 0.020 | 16 | 6.5 |
| 0.060 | 16 | 2.2 | +--------------+-------------+----------------+
| 0.060 | 2 | 13.8 |
+--------------+-------------+----------------+
| 0.060 | 4 | 7.2 |
+--------------+-------------+----------------+
| 0.060 | 8 | 3.8 |
+--------------+-------------+----------------+
| 0.060 | 16 | 2.2 |
+--------------+-------------+----------------+ +--------------+-------------+----------------+
Table 2: Required RTCP bandwidth for VoIP feedback (alternating Table 2: Required RTCP bandwidth for VoIP
compound and non-compound reports) feedback (alternating compound and reduced-
size reports)
The RTCP bandwidth needed for 60ms frames, reporting every 16 frames The RTCP bandwidth needed for 60ms frames, reporting every 16 frames
(once per second), can be seen to drop to 2.2kbps. This calculation (once per second), can be seen to drop to 2.2kbps. This calculation
can be repeated for other patterns of compound and reduced-size RTCP can be repeated for other patterns of compound and reduced-size RTCP
packets, feedback frequency, and frame duration, as needed. packets, feedback frequency, and frame duration, as needed.
Note: To achieve the RTCP transmission intervals above the RTP/SAVPF Note: To achieve the RTCP transmission intervals above the RTP/SAVPF
profile with T_rr_interval=0 is used, since even when using the profile with T_rr_interval=0 is used, since even when using the
reduced minimal transmission interval, the RTP/SAVP profile would reduced minimal transmission interval, the RTP/SAVP profile would
only allow sending RTCP at most every 0.11s (every third frame of only allow sending RTCP at most every 0.11s (every third frame of
video). Using RTP/SAVPF with T_rr_interval=0 however is capable of video). Using RTP/SAVPF with T_rr_interval=0 however is capable of
fully utilizing the configured 5% RTCP bandwidth fraction. fully utilizing the configured 5% RTCP bandwidth fraction.
The use of IPv6 will increase the overhead by 20 octets per packet,
due to the increased size of the IPv6 header compared to IPv4,
assuming no IP options in either case. This increases the size of
compound packets to Sc = 162 + 2*Nr octets and reduced size packets
to Srs = 82 + 2*Nr. Re-running the calculations from Table 1 with
these packet sizes gives the results shown in Table 3. As can be
seen, there is a significant increase in overhead due to the use of
IPv6.
+--------------+-------------+----------------+
| Tf (seconds) | Nr (frames) | rtcp_bw (kbps) |
+--------------+-------------+----------------+
| 0.020 | 2 | 64.8 |
+--------------+-------------+----------------+
| 0.020 | 4 | 33.2 |
+--------------+-------------+----------------+
| 0.020 | 8 | 17.4 |
+--------------+-------------+----------------+
| 0.020 | 16 | 9.5 |
+--------------+-------------+----------------+
| 0.060 | 2 | 21.6 |
+--------------+-------------+----------------+
| 0.060 | 4 | 11.1 |
+--------------+-------------+----------------+
| 0.060 | 8 | 5.8 |
+--------------+-------------+----------------+
| 0.060 | 16 | 3.2 |
+--------------+-------------+----------------+
Table 3: RTCP bandwidth needed for VoIP
feedback (compound reports only) using IPv6
Repeating the calculations from Table 2 using IPv6 gives the results
shown in Table 4. As can be seen, the overhead still increases with
IPv6 when a mix of compound and reduced-size reports is used, but the
effect is less pronounced than with compound reports only.
+--------------+-------------+----------------+
| Tf (seconds) | Nr (frames) | rtcp_bw (kbps) |
+--------------+-------------+----------------+
| 0.020 | 2 | 49.2 |
+--------------+-------------+----------------+
| 0.020 | 4 | 25.4 |
+--------------+-------------+----------------+
| 0.020 | 8 | 13.5 |
+--------------+-------------+----------------+
| 0.020 | 16 | 7.5 |
+--------------+-------------+----------------+
| 0.060 | 2 | 16.4 |
+--------------+-------------+----------------+
| 0.060 | 4 | 8.5 |
+--------------+-------------+----------------+
| 0.060 | 8 | 4.5 |
+--------------+-------------+----------------+
| 0.060 | 16 | 2.5 |
+--------------+-------------+----------------+
Table 4: Required RTCP bandwidth for VoIP
feedback (alternating compound and reduced-
size reports) using IPv6
3.2. Scenario 2: Point-to-Point Video Conference 3.2. Scenario 2: Point-to-Point Video Conference
Consider a point-to-point video call between two end systems. There Consider a point-to-point video call between two end systems. There
will be four RTP flows in this scenario, two audio and two video, will be four RTP flows in this scenario, two audio and two video,
with all four flows being active for essentially all the time (the with all four flows being active for essentially all the time (the
audio flows will likely use voice activity detection and comfort audio flows will likely use voice activity detection and comfort
noise to reduce the packet rate during silent periods, but this does noise to reduce the packet rate during silent periods, but this does
not cause the transmissions to stop). not cause the transmissions to stop).
Assume all four flows are sent in a single RTP session, each using a Assume all four flows are sent in a single RTP session, each using a
separate SSRC. The RTCP reports from the co-located audio and video separate SSRC. The RTCP reports from the co-located audio and video
SSRCs at each end point are aggregated [RFC8108], the optimisations SSRCs at each end point are aggregated [RFC8108], the optimisations
in [RFC8861] are used, and RTCP congestion control feedback is sent in [RFC8861] are used, and RTCP congestion control feedback is sent
[RFC8888]. [RFC8888].
As in Section 3.1, when all members are senders the RTCP reporting As in Section 3.1, when all members are senders the RTCP reporting
interval calculation in Section 6.2 and 6.3 of [RFC3550] and interval calculation in Section 6.2 and 6.3 of [RFC3550] and
[RFC4585] reduces to: [RFC4585] reduces to:
Trtcp = n * Srtcp / Brtcp | Trtcp = n * Srtcp / Brtcp
where n is the number of members in the session, Srtcp is the average where n is the number of members in the session, Srtcp is the average
RTCP packet size in octets, and the Brtcp is the RTCP bandwidth in RTCP packet size in octets, and the Brtcp is the RTCP bandwidth in
octets per second. octets per second.
The average RTCP packet size, Srtcp, depends on the amount of The average RTCP packet size, Srtcp, depends on the amount of
feedback sent in each RTCP packet, on the number of members in the feedback sent in each RTCP packet, on the number of members in the
session, on the size of source description (RTCP SDES) information session, on the size of source description (RTCP SDES) information
sent, and on the amount of congestion control feedback sent in each sent, and on the amount of congestion control feedback sent in each
packet. packet.
As a baseline, each RTCP packet will be a compound RTCP packet that As a baseline, each RTCP packet will be a compound RTCP packet that
contains an aggregate of a compound RTCP packet generated by the contains an aggregate of a compound RTCP packet generated by the
video SSRC and a compound RTCP packet generated by the audio SSRC. video SSRC and a compound RTCP packet generated by the audio SSRC.
When the RTCP reporting group extensions are used, one of these SSRCs When the RTCP reporting group extensions are used, one of these SSRCs
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 UDP/IP header
information, but no report blocks (since the reporting is delegated). (assuming IPv4 with no options) and sender information, but no report
The RTCP SDES packet will comprise a header (4 octets), originating blocks (since the reporting is delegated). The RTCP SDES packet will
SSRC (4 octets), a CNAME chunk, a terminating chunk, and any padding. comprise a header (4 octets), originating SSRC (4 octets), a CNAME
If the CNAME follows [RFC7022] and [RFC8834] the CNAME chunk will be chunk, a terminating chunk, and any padding. If the CNAME follows
18 octets in size, and will be followed by one octet of padding and [RFC7022] and [RFC8834] the CNAME chunk will be 18 octets in size,
one terminating null octet to align the SDES packet to a 32-bit and will be followed by one octet of padding and one terminating null
boundary ([RFC3550], section 6.5), making the SDES packet 28 octets octet to align the SDES packet to a 32-bit boundary ([RFC3550],
in size. The RTCP RGRS packet will be 12 octets in size. This gives section 6.5), making the SDES packet 28 octets in size. The RTCP
a total of 28 + 28 + 12 = 68 octets. RGRS packet will be 12 octets in size. This gives 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.
skipping to change at page 9, line 38 skipping to change at page 12, line 9
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 video has to fit into a 1500 octet MTU. Further, assume that the
audio takes negligible bandwidth, and that the audio framing interval audio takes negligible bandwidth, and that the audio framing interval
can be varied within reasonable bounds, so that an integral number of can be varied within reasonable bounds, so that an integral number of
audio frames align with video frame boundaries. audio frames align with video frame boundaries.
Table 3 shows the resulting values of Nv and Na, the number of video Table 5 shows the resulting values of Nv and Na, the number of video
and audio packets covered by each congestion control feedback report, and audio packets covered by each congestion control feedback report,
for a range of data rates and video frame rates, assuming congestion for a range of data rates and video frame rates, assuming congestion
control feedback is sent once per video frame. The table also shows control feedback is sent once per video frame. The table also shows
the result of inverting the RTCP reporting interval calculation to the result of inverting the RTCP reporting interval calculation to
find the corresponding RTCP bandwidth, Brtcp. The RTCP bandwidth is find the corresponding RTCP bandwidth, Brtcp. The RTCP bandwidth is
given in kbps and as a fraction of the data rate. given in kbps and as a fraction of the data rate.
It can be seen that, for example, with a date rate of 1024 kbps and It can be seen that, for example, with a date rate of 1024 kbps and
video sent at 30 frames-per-second, the RTCP congestion control video sent at 30 frames-per-second, the RTCP congestion control
feedback report sent for each video frame will include reports on 3 feedback report sent for each video frame will include reports on 3
video packets and 2 audio packets. The RTCP bandwidth needed to video packets and 2 audio packets. The RTCP bandwidth needed to
sustain this reporting rate is 127.5kbps (12% of the data rate). sustain this reporting rate is 127.5kbps (12% of the data rate).
This assumes an audio framing interval of 16.67ms, so that two audio This assumes an audio framing interval of 16.67ms, so that two audio
packets are sent for each video frame. packets are sent for each video frame.
+---------+----------+--------------+--------------+----------------+ +-----------+----------+-------------+-------------+---------------+
| Data | Video | Video | Audio | Required RTCP | | Data Rate | Video | Video | Audio | Required RTCP |
| Rate | Frame | Packets per | Packets per | bandwidth: | | (kbps) | Frame | Packets per | Packets per | bandwidth: |
| (kbps) | Rate: Rf | Report: Nv | Report: Na | Brtcp (kbps) | | | Rate: Rf | Report: Nv | Report: Na | Brtcp (kbps) |
+---------+----------+--------------+--------------+----------------+ +-----------+----------+-------------+-------------+---------------+
| 100 | 8 | 1 | 6 | 34.5 (34%) | | 100 | 8 | 1 | 6 | 34.5 (34%) |
| 200 | 16 | 1 | 3 | 67.5 (33%) | +-----------+----------+-------------+-------------+---------------+
| 350 | 30 | 1 | 2 | 125.6 (35%) | | 200 | 16 | 1 | 3 | 67.5 (33%) |
| 700 | 30 | 2 | 2 | 126.6 (18%) | +-----------+----------+-------------+-------------+---------------+
| 700 | 60 | 1 | 1 | 249.4 (35%) | | 350 | 30 | 1 | 2 | 125.6 (35%) |
| 1024 | 30 | 3 | 2 | 127.5 (12%) | +-----------+----------+-------------+-------------+---------------+
| 1400 | 60 | 2 | 1 | 251.2 (17%) | | 700 | 30 | 2 | 2 | 126.6 (18%) |
| 2048 | 30 | 6 | 2 | 130.3 ( 6%) | +-----------+----------+-------------+-------------+---------------+
| 2048 | 60 | 3 | 1 | 253.1 (12%) | | 700 | 60 | 1 | 1 | 249.4 (35%) |
| 4096 | 30 | 12 | 2 | 135.9 ( 3%) | +-----------+----------+-------------+-------------+---------------+
| 4096 | 60 | 6 | 1 | 258.8 ( 6%) | | 1024 | 30 | 3 | 2 | 127.5 (12%) |
+---------+----------+--------------+--------------+----------------+ +-----------+----------+-------------+-------------+---------------+
| 1400 | 60 | 2 | 1 | 251.2 (17%) |
+-----------+----------+-------------+-------------+---------------+
| 2048 | 30 | 6 | 2 | 130.3 ( 6%) |
+-----------+----------+-------------+-------------+---------------+
| 2048 | 60 | 3 | 1 | 253.1 (12%) |
+-----------+----------+-------------+-------------+---------------+
| 4096 | 30 | 12 | 2 | 135.9 ( 3%) |
+-----------+----------+-------------+-------------+---------------+
| 4096 | 60 | 6 | 1 | 258.8 ( 6%) |
+-----------+----------+-------------+-------------+---------------+
Table 3: Required RTCP bandwidth, reporting on every frame Table 5: Required RTCP bandwidth, reporting on every frame
Use of reduced size RTCP [RFC5506] would allow the SR and SDES Use of reduced size RTCP [RFC5506] would allow the SR and SDES
packets to be omitted from some reports. These "reduced-size" RTCP packets to be omitted from some reports. These "reduced-size" RTCP
packets would contain an RTCP RGRS packet from the non-reporting packets would contain an RTCP RGRS packet from the non-reporting
SSRC, and an RTCP SDES RGRP packet and a congestion control feedback SSRC, and an RTCP SDES RGRP packet and a congestion control feedback
packet from the reporting SSRC. This will be 12 + 28 + 12 + 8 + 2*Nv packet from the reporting SSRC. This will be 12 + 28 + 12 + 8 + 2*Nv
+ 8 + 2*Na octets, plus the SRTCP trailer and authentication tag, and + 8 + 2*Na octets, plus the SRTCP trailer and authentication tag, and
a UDP/IP header. That is, the size of the reduced-size packets would a UDP/IP header. That is, the size of the reduced-size packets would
be (110 + 2*Nv + 2*Na)/2 octets. Repeating the analysis above, but be (110 + 2*Nv + 2*Na)/2 octets. Repeating the analysis above, but
alternating compound and reduced-size reports gives results as shown alternating compound and reduced-size reports gives results as shown
in Table 4. in Table 6.
+---------+----------+--------------+--------------+----------------+ +-----------+----------+-------------+-------------+---------------+
| Data | Video | Video | Audio | Required RTCP | | Data Rate | Video | Video | Audio | Required RTCP |
| Rate | Frame | Packets per | Packets per | bandwidth: | | (kbps) | Frame | Packets per | Packets per | bandwidth: |
| (kbps) | Rate: Rf | Report: Nv | Report: Na | Brtcp (kbps) | | | Rate: Rf | Report: Nv | Report: Na | Brtcp (kbps) |
+---------+----------+--------------+--------------+----------------+ +-----------+----------+-------------+-------------+---------------+
| 100 | 8 | 1 | 6 | 24.1 (24%) | | 100 | 8 | 1 | 6 | 25.0 (25%) |
| 200 | 16 | 1 | 3 | 46.8 (23%) | +-----------+----------+-------------+-------------+---------------+
| 350 | 30 | 1 | 2 | 86.7 (24%) | | 200 | 16 | 1 | 3 | 48.5 (24%) |
| 700 | 30 | 2 | 2 | 87.7 (12%) | +-----------+----------+-------------+-------------+---------------+
| 700 | 60 | 1 | 1 | 171.6 (24%) | | 350 | 30 | 1 | 2 | 90.0 (25%) |
| 1024 | 30 | 3 | 2 | 88.6 ( 8%) | +-----------+----------+-------------+-------------+---------------+
| 1400 | 60 | 2 | 1 | 173.4 (12%) | | 700 | 30 | 2 | 2 | 90.9 (12%) |
| 2048 | 30 | 6 | 2 | 91.4 ( 4%) | +-----------+----------+-------------+-------------+---------------+
| 2048 | 60 | 3 | 1 | 175.3 ( 8%) | | 700 | 60 | 1 | 1 | 178.1 (25%) |
| 4096 | 30 | 12 | 2 | 97.0 ( 2%) | +-----------+----------+-------------+-------------+---------------+
| 4096 | 60 | 6 | 1 | 180.9 ( 4%) | | 1024 | 30 | 3 | 2 | 91.9 ( 8%) |
+---------+----------+--------------+--------------+----------------+ +-----------+----------+-------------+-------------+---------------+
| 1400 | 60 | 2 | 1 | 180.0 (12%) |
+-----------+----------+-------------+-------------+---------------+
| 2048 | 30 | 6 | 2 | 94.7 ( 4%) |
+-----------+----------+-------------+-------------+---------------+
| 2048 | 60 | 3 | 1 | 181.9 ( 8%) |
+-----------+----------+-------------+-------------+---------------+
| 4096 | 30 | 12 | 2 | 100.3 ( 2%) |
+-----------+----------+-------------+-------------+---------------+
| 4096 | 60 | 6 | 1 | 187.5 ( 4%) |
+-----------+----------+-------------+-------------+---------------+
Table 4: Required RTCP bandwidth, reporting on every frame, with Table 6: Required RTCP bandwidth, reporting on every frame, with
reduced-size reports reduced-size reports
The use of reduced-size RTCP gives a noticeable reduction in the The use of reduced-size RTCP gives a noticeable reduction in the
needed RTCP bandwidth, and can be combined with reporting every few needed RTCP bandwidth, and can be combined with reporting every few
frames rather than every frame. Overall, it is clear that the RTCP frames rather than every frame. Overall, it is clear that the RTCP
overhead can be reasonable across the range of data and frame rates, overhead can be reasonable across the range of data and frame rates,
if RTCP is configured carefully. if RTCP is configured carefully.
As discussed in Section 3.1, the reporting overhead will increase if
IPv6 is used, due to the increased size of the IPv6 header. Table 7
shows the overhead in this case, compared to Table 6. As can be
seen, the increase in overhead due to IPv6 rapidly becomes less
significant as the data rate increases.
+-----------+----------+-------------+-------------+---------------+
| Data Rate | Video | Video | Audio | Required RTCP |
| (kbps) | Frame | Packets per | Packets per | bandwidth: |
| | Rate: Rf | Report: Nv | Report: Na | Brtcp (kbps) |
+-----------+----------+-------------+-------------+---------------+
| 100 | 8 | 1 | 6 | 27.5 (27%) |
+-----------+----------+-------------+-------------+---------------+
| 200 | 16 | 1 | 3 | 53.5 (26%) |
+-----------+----------+-------------+-------------+---------------+
| 350 | 30 | 1 | 2 | 99.4 (28%) |
+-----------+----------+-------------+-------------+---------------+
| 700 | 30 | 2 | 2 | 100.3 (14%) |
+-----------+----------+-------------+-------------+---------------+
| 700 | 60 | 1 | 1 | 196.9 (28%) |
+-----------+----------+-------------+-------------+---------------+
| 1024 | 30 | 3 | 2 | 101.2 ( 9%) |
+-----------+----------+-------------+-------------+---------------+
| 1400 | 60 | 2 | 1 | 198.8 (14%) |
+-----------+----------+-------------+-------------+---------------+
| 2048 | 30 | 6 | 2 | 104.1 ( 5%) |
+-----------+----------+-------------+-------------+---------------+
| 2048 | 60 | 3 | 1 | 200.6 ( 9%) |
+-----------+----------+-------------+-------------+---------------+
| 4096 | 30 | 12 | 2 | 109.7 ( 2%) |
+-----------+----------+-------------+-------------+---------------+
| 4096 | 60 | 6 | 1 | 206.2 ( 5%) |
+-----------+----------+-------------+-------------+---------------+
Table 7: Required RTCP bandwidth, reporting on every frame, with
reduced-size reports, using IPv6
4. Discussion and Conclusions 4. Discussion and Conclusions
Practical systems will generally send some non-media traffic on the Practical systems will generally send some non-media traffic on the
same path as the media traffic. This can include STUN/TURN packets same path as the media traffic. This can include STUN/TURN packets
to keep-alive NAT bindings [RFC8445], WebRTC Data Channel packets to keep-alive NAT bindings [RFC8445], WebRTC Data Channel packets
[RFC8831], etc. Such traffic also needs congestion control, but the [RFC8831], etc. Such traffic also needs congestion control, but the
means by which this is achieved is out of scope of this memo. means by which this is achieved is out of scope of this memo.
RTCP as it is currently specified cannot be used to send per-packet RTCP as it is currently specified cannot be used to send per-packet
congestion feedback with reasonable overhead. congestion feedback with reasonable overhead.
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. The
improved compression of new video codecs exacerbates the reporting
overhead for a given video quality level, although this is to some
extent countered by the use of higher quality video over time.
If it is desired to use RTCP in something close to its 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
skipping to change at page 12, line 45 skipping to change at page 17, line 7
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, Thanks to Bernard Aboba, Martin Duke, Linda Dunbar, Gorry Fairhurst,
Linda Dunbar, Shuping Peng, and the members of the RMCAT feedback Ingemar Johansson, Shuping Peng, Alvaro Retana, Zahed Sarker, John
design team for their feedback. Scudder, Éric Vyncke, Magnus Westerlund, and the members of the
RMCAT feedback design team for their feedback.
8. Informative References
[I-D.ietf-tcpm-rfc793bis]
Eddy, W., "Transmission Control Protocol (TCP)
Specification", draft-ietf-tcpm-rfc793bis-20 (work in
progress), January 2021.
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 8. Normative References
Headers for Low-Speed Serial Links", RFC 2508,
DOI 10.17487/RFC2508, February 1999,
<https://www.rfc-editor.org/info/rfc2508>.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, DOI 10.17487/RFC2914, September 2000, RFC 2914, DOI 10.17487/RFC2914, September 2000,
<https://www.rfc-editor.org/info/rfc2914>. <https://www.rfc-editor.org/info/rfc2914>.
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M.
Sooriyabandara, "TCP Performance Implications of Network
Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449,
December 2002, <https://www.rfc-editor.org/info/rfc3449>.
[RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and
P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with
High Delay, Packet Loss and Reordering", RFC 3545,
DOI 10.17487/RFC3545, July 2003,
<https://www.rfc-editor.org/info/rfc3545>.
[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>.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, DOI 10.17487/RFC3611, November 2003,
<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, DOI 10.17487/RFC4585, July 2006,
<https://www.rfc-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>.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, DOI 10.17487/RFC5348, September 2008,
<https://www.rfc-editor.org/info/rfc5348>.
[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>.
[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
Header Compression (ROHC) Framework", RFC 5795,
DOI 10.17487/RFC5795, March 2010,
<https://www.rfc-editor.org/info/rfc5795>.
[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, [RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
DOI 10.17487/RFC7667, November 2015, "Sending Multiple RTP Streams in a Single RTP Session",
<https://www.rfc-editor.org/info/rfc7667>. RFC 8108, DOI 10.17487/RFC8108, March 2017,
<https://www.rfc-editor.org/info/rfc8108>.
[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,
"Sending Multiple RTP Streams in a Single RTP Session",
RFC 8108, DOI 10.17487/RFC8108, March 2017,
<https://www.rfc-editor.org/info/rfc8108>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>.
[RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for [RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for
Browser-Based Applications", RFC 8825, Browser-Based Applications", RFC 8825,
DOI 10.17487/RFC8825, January 2021, DOI 10.17487/RFC8825, January 2021,
<https://www.rfc-editor.org/info/rfc8825>. <https://www.rfc-editor.org/info/rfc8825>.
[RFC8831] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021,
<https://www.rfc-editor.org/info/rfc8831>.
[RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport [RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport
and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834, and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834,
January 2021, <https://www.rfc-editor.org/info/rfc8834>. January 2021, <https://www.rfc-editor.org/info/rfc8834>.
[RFC8861] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, [RFC8861] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
"Sending Multiple RTP Streams in a Single RTP Session: "Sending Multiple RTP Streams in a Single RTP Session:
Grouping RTP Control Protocol (RTCP) Reception Statistics Grouping RTP Control Protocol (RTCP) Reception Statistics
and Other Feedback", RFC 8861, DOI 10.17487/RFC8861, and Other Feedback", RFC 8861, DOI 10.17487/RFC8861,
January 2021, <https://www.rfc-editor.org/info/rfc8861>. January 2021, <https://www.rfc-editor.org/info/rfc8861>.
skipping to change at page 15, line 41 skipping to change at page 18, line 45
and R. Even, "Guidelines for Using the Multiplexing and R. Even, "Guidelines for Using the Multiplexing
Features of RTP to Support Multiple Media Streams", Features of RTP to Support Multiple Media Streams",
RFC 8872, DOI 10.17487/RFC8872, January 2021, RFC 8872, DOI 10.17487/RFC8872, January 2021,
<https://www.rfc-editor.org/info/rfc8872>. <https://www.rfc-editor.org/info/rfc8872>.
[RFC8888] Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP [RFC8888] Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP
Control Protocol (RTCP) Feedback for Congestion Control", Control Protocol (RTCP) Feedback for Congestion Control",
RFC 8888, DOI 10.17487/RFC8888, January 2021, RFC 8888, DOI 10.17487/RFC8888, January 2021,
<https://www.rfc-editor.org/info/rfc8888>. <https://www.rfc-editor.org/info/rfc8888>.
Author's Address 9. Informative References
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508,
DOI 10.17487/RFC2508, February 1999,
<https://www.rfc-editor.org/info/rfc2508>.
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M.
Sooriyabandara, "TCP Performance Implications of Network
Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449,
December 2002, <https://www.rfc-editor.org/info/rfc3449>.
[RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and
P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with
High Delay, Packet Loss and Reordering", RFC 3545,
DOI 10.17487/RFC3545, July 2003,
<https://www.rfc-editor.org/info/rfc3545>.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, DOI 10.17487/RFC3611, November 2003,
<https://www.rfc-editor.org/info/rfc3611>.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, DOI 10.17487/RFC5348, September 2008,
<https://www.rfc-editor.org/info/rfc5348>.
[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
Header Compression (ROHC) Framework", RFC 5795,
DOI 10.17487/RFC5795, March 2010,
<https://www.rfc-editor.org/info/rfc5795>.
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
DOI 10.17487/RFC7667, November 2015,
<https://www.rfc-editor.org/info/rfc7667>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>.
[RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data
Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021,
<https://www.rfc-editor.org/info/rfc8831>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
Author's Address
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
School of Computing Science School of Computing Science
Glasgow G12 8QQ Glasgow
G12 8QQ
United Kingdom United Kingdom
Email: csp@csperkins.org Email: csp@csperkins.org
 End of changes. 43 change blocks. 
160 lines changed or deleted 304 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/