draft-ietf-rmcat-rtp-cc-feedback-07.txt   draft-ietf-rmcat-rtp-cc-feedback-08.txt 
Network Working Group C. S. Perkins Network Working Group C. Perkins
Internet-Draft University of Glasgow Internet-Draft University of Glasgow
Intended status: Informational 25 October 2021 Intended status: Informational December 28, 2021
Expires: 28 April 2022 Expires: July 1, 2022
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-07 draft-ietf-rmcat-rtp-cc-feedback-08
Abstract Abstract
This memo discusses the types of congestion control feedback that it This memo discusses the types of congestion control feedback that it
is possible to send using the RTP Control Protocol (RTCP), and their is possible to send using the RTP Control Protocol (RTCP), and their
suitability of use in implementing congestion control for unicast suitability of use in implementing congestion control for unicast
multimedia applications. multimedia applications.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 28 April 2022. This Internet-Draft will expire on July 1, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Simplified BSD License text as described in Section 4.e of
provided without warranty as described in the Simplified BSD License. the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Possible Models for RTCP Feedback . . . . . . . . . . . . . . 2 2. Possible Models for RTCP Feedback . . . . . . . . . . . . . . 3
3. What Feedback is Achievable With RTCP? . . . . . . . . . . . 4 3. What Feedback is Achievable With RTCP? . . . . . . . . . . . 5
3.1. Scenario 1: Voice Telephony . . . . . . . . . . . . . . . 4 3.1. Scenario 1: Voice Telephony . . . . . . . . . . . . . . . 5
3.2. Scenario 2: Point-to-Point Video Conference . . . . . . . 7 3.2. Scenario 2: Point-to-Point Video Conference . . . . . . . 8
4. Discussion and Conclusions . . . . . . . . . . . . . . . . . 12 4. Discussion and Conclusions . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. Informative References . . . . . . . . . . . . . . . . . . . 13 8. Informative References . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 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. To develop such congestion control, it is necessary to traffic [RFC2914], [RFC8085], [RFC8083], [RFC8834], allowing them to
understand the sort of congestion feedback that can be provided adapt and adjust the media data they send to match changes in the
within the framework of RTP [RFC3550] and the RTP Control Protocol available network capacity. In addition to ensuring the stable
(RTCP). It then becomes possible to determine if this is sufficient operation of the network, such adaptation is critical to ensuring a
for congestion control, or if some form of RTP extension is needed. good user experience, since it allows the sender to match the media
to the network capacity, rather than forcing the receiver to
compensate for uncontrolled packet loss when the available capacity
is exceeded.
This memo considers the congestion feedback that can be sent using To develop such congestion control, it is necessary to understand the
RTCP under the RTP/SAVPF profile [RFC5124] (the secure version of the sort of congestion feedback that can be provided within the framework
RTP/AVPF profile [RFC4585]). This profile was chosen as it forms the of RTP [RFC3550] and the RTP Control Protocol (RTCP). It then
basis for media transport in WebRTC [RFC8834] systems. Nothing in becomes possible to determine if this is sufficient for congestion
this memo is specific to the secure version of the profile, or to control, or if some form of RTP extension is needed.
WebRTC, however.
This memo considers unicast congestion feedback that can be sent
using RTCP under the RTP/SAVPF profile [RFC5124] (the secure version
of the RTP/AVPF profile [RFC4585]). This profile was chosen as it
forms the basis for media transport in WebRTC [RFC8834] systems.
Nothing in this memo is specific to the secure version of the
profile, or to WebRTC, however. It is also assumed that the
congestion control feedback mechanism described in [RFC8888], and
common RTCP extensions for efficient feedback [RFC5506], [RFC8108],
[RFC8861], [RFC8861], and [RFC8872] are available.
2. Possible Models for RTCP Feedback 2. Possible Models for RTCP Feedback
Several questions need to be answered when providing RTCP reception Several questions need to be answered when providing RTCP reception
quality feedback for congestion control purposes. These include: quality feedback for congestion control purposes. These include:
* How often is feedback needed? o How often is feedback needed?
* How much overhead is acceptable? o How much overhead is acceptable?
* 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? Traditional congestion control protocols, such state of the network?
as TCP, send acknowledgements with every packet (or, at least, every
couple of packets). That is straight-forward and low overhead when
traffic is bidirectional and acknowledgements can be piggybacked onto
return path data packets. It can also be acceptable, and can have
reasonable overhead, to send separate acknowledgement packets when
those packets are much smaller than data packets. It becomes a
problem, however, when there is no return traffic on which to
piggyback acknowledgements, and when acknowledgements are similar in
size to data packets; this can be the case for some forms of media
traffic, especially for voice over IP (VoIP) flows, but less so for
video.
When considering multimedia traffic, it might make sense to consider Widely used transport protocols, such as TCP, send acknowledgements
less frequent feedback. For example, it might be possible to send a frequently. For example, a TCP receiver will send an acknowledgement
feedback packet once per video frame, or every few frames, or once at least once every 0.5 seconds or when new data equal to twice the
per network round trip time (RTT). This could still give maximum segment size has been received [I-D.ietf-tcpm-rfc793bis]).
sufficiently frequent feedback for the congestion control loop to be That has relatively low overhead when traffic is bidirectional and
stable and responsive while keeping the overhead reasonable when the acknowledgements can be piggybacked onto return path data packets.
feedback cannot be piggybacked onto returning data. In this case, it It can also be acceptable, and can have reasonable overhead, to send
is important to note that RTCP can send much more detailed feedback separate acknowledgement packets when those packets are much smaller
than simple acknowledgements. For example, if it were useful, it than data packets.
could be possible to use an RTCP extended report (XR) packet
[RFC3611] to send feedback once per RTT comprising a bitmap of lost Frequent acknowledgements can become a problem, however, when there
and received packets, with reception times, over that RTT. As long is no return traffic on which to piggyback feedback, or if separate
as feedback is sent frequently enough that the control loop is feedback and data packets are sent and the feedback is similar in
stable, and the sender is kept informed when data leaves the network size to the data being acknowledged. This can be the case for some
(to provide an equivalent to ACK clocking in TCP), it is not forms of media traffic, especially for voice over IP flows, leading
to high overhead when using a transport protocol that sends frequent
feedback. Approaches like in-network filtering of acknowledgements
can reduce the feedback frequency and overhead in some cases, but
this so-called "stretch-ACK" behaviour is non-standard and not
guaranteed.
Accordingly, when implementing congestion control for RTP-based
multimedia traffic, it might make sense to give the option of sending
congestion feedback less often than does TCP. For example, it might
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
still give sufficiently frequent feedback for the congestion control
loop to be stable and responsive while keeping the overhead
reasonable when the feedback cannot be piggybacked onto returning
data. In this case, it is important to note that RTCP can send much
more detailed feedback than simple acknowledgements. For example, if
it were useful, it could be possible to use an RTCP extended report
(XR) packet [RFC3611] to send feedback once per RTT comprising a
bitmap of lost and received packets, with reception times, over that
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
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 anyway, and there is little point in providing feedback rate change anyway, and there is little point in providing feedback
more often than the codec can adapt). more often than the codec can adapt).
Reducing the feedback frequency compared to TCP will reduce feedback
overhead but will lead multimedia flows to adapt to congestion more
slowly than TCP, raising concerns about inter-flow fairness. Similar
concerns are noted in [RFC5348], and accordingly the congestion
control algorithm described therein aims for "reasonable" fairness
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,
however, that TCP exhibits inter-flow unfairness when flows with
differing round-trip times compete, and stretch acknowledgements due
to in-network traffic manipulation are not uncommon and also raise
fairness concerns. Implementations need to balance potential
unfairness against feedback overhead.
Generating and processing feedback consumes resources at the sender
and receiver. The feedback packets also incur forwarding costs,
contribute to link utilization, and can affect the timing of other
traffic on the network. This can affect performance on some types of
network, that can be impacted by the rate, timing, and size of
feedback packets, as well as by the overall volume of feedback bytes.
The amount of overhead due to congestion control feedback that is The amount of overhead due to congestion control feedback that is
considered acceptable has to be determined. RTCP feedback is sent in considered acceptable has to be determined. RTCP feedback is sent in
separate packets to RTP data, and this has some cost in terms of separate packets to RTP data, and this has some cost in terms of
additional header overhead compared to protocols that piggyback additional header overhead compared to protocols that piggyback
feedback on return path data packets. The RTP standards have long feedback on return path data packets. The RTP standards have long
said that a 5% overhead for RTCP traffic generally acceptable, while said that a 5% overhead for RTCP traffic generally acceptable, while
providing the ability to change this fraction. Is this still the providing the ability to change this fraction. Is this still the
case for congestion control feedback? Or is there a desire to either case for congestion control feedback? Is there a desire to provide
see more responsive feedback and congestion control, possibility with more responsive feedback and congestion control, possibility with a
a higher overhead, or is lower overhead wanted, accepting that this higher overhead? Or is lower overhead wanted, accepting that this
might reduce responsiveness of the congestion control algorithm? might reduce responsiveness of the congestion control algorithm?
Finally, the details of how much, and what, data is to be sent in Finally, the details of how much, and what, data is to be sent in
each report will affect the frequency and/or overhead of feedback. each report will affect the frequency and/or overhead of feedback.
There is a fundamental trade-off that the more frequently feedback There is a fundamental trade-off that the more frequently feedback
packets are sent, the less data can be included in each packet to packets are sent, the less data can be included in each packet to
keep the overhead constant. Does the congestion control need high keep the overhead constant. Does the congestion control need high
rate but simple feedback (e.g., like TCP acknowledgements), or is it rate but simple feedback (e.g., like TCP acknowledgements), or is it
acceptable to send more complex feedback less often? acceptable to send more complex feedback less often? Is it useful
for the congestion control to receive frequent feedback, perhaps to
provide more accurate round-trip time estimates, or to provide
robustness in case feedback packets are lost, even if the media
sending rate cannot quickly be changed? Or is low-rate feedback,
resulting in slowly responsive changes the sending rate, acceptable?
Different combinations of congestion control algorithm and media
codec might require different trade-offs, and the correct trade-off
for interactive, self-paced, real-time multimedia traffic might not
be the same as that for TCP congestion control.
3. What Feedback is Achievable With RTCP? 3. What Feedback is Achievable With RTCP?
The following sections illustrate how the RTCP congestion control The following sections illustrate how the RTCP congestion control
feedback report [RFC8888] can be used in different scenarios, and feedback report [RFC8888] can be used in different scenarios, and
illustrate the overheads of this approach. illustrate the overheads of this approach.
3.1. Scenario 1: Voice Telephony 3.1. Scenario 1: Voice Telephony
In many ways, point-to-point voice telephony is the simplest scenario In many ways, point-to-point voice telephony is the simplest scenario
skipping to change at page 4, line 36 skipping to change at page 5, line 38
UDP/IP. A rate adaptive speech codec, such as Opus, is used, encoded UDP/IP. A rate adaptive speech codec, such as Opus, is used, encoded
into RTP packets in frames of duration Tf seconds (Tf = 20ms in many into RTP packets in frames of duration Tf seconds (Tf = 20ms in many
cases, but values up to 60ms are not uncommon). The congestion cases, but values up to 60ms are not uncommon). The congestion
control algorithm requires feedback every Nr frames, i.e., every Nr * control algorithm requires feedback every Nr frames, i.e., every Nr *
Tf seconds, to ensure effective control. Both parties in the call Tf seconds, to ensure effective control. Both parties in the call
send speech data or comfort noise with sufficient frequency that they send speech data or comfort noise with sufficient frequency that they
are counted as senders for the purpose of the RTCP reporting interval are counted as senders for the purpose of the RTCP reporting interval
calculation. calculation.
RTCP feedback packets can be full, compound, RTCP feedback packets, RTCP feedback packets can be full, compound, RTCP feedback packets,
or non-compound RTCP packets. A compound RTCP packet is sent once or non-compound RTCP packets [RFC5506]. A compound RTCP packet is
for every Nnc non-compound RTCP packets. sent once for every Nnc non-compound RTCP packets.
Compound RTCP packets contain a Sender Report (SR) packet, a Source Compound RTCP packets contain a Sender Report (SR) packet, a Source
Description (SDES) packet, and an RTP Congestion Control Feedback Description (SDES) packet, and an RTP Congestion Control Feedback
(CCFB) packet [RFC8888]. Non-compound RTCP packets contain only the (CCFB) packet [RFC8888]. Non-compound 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
skipping to change at page 6, line 5 skipping to change at page 7, line 5
Brtcp = (n * (Sc + Nnc * Snc))/(Nr * Tf * (1 + Nnc)). Brtcp = (n * (Sc + Nnc * Snc))/(Nr * Tf * (1 + Nnc)).
If we assume every report is a compound RTCP packet (i.e., Nnc = 0), If we assume every report is a compound RTCP packet (i.e., Nnc = 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 | 4 | 29.3 |
+--------------+-------------+----------------+
| 0.020 | 8 | 15.4 | | 0.020 | 8 | 15.4 |
+--------------+-------------+----------------+
| 0.020 | 16 | 8.5 | | 0.020 | 16 | 8.5 |
+--------------+-------------+----------------+
| 0.060 | 2 | 19.0 | | 0.060 | 2 | 19.0 |
+--------------+-------------+----------------+
| 0.060 | 4 | 9.8 | | 0.060 | 4 | 9.8 |
+--------------+-------------+----------------+
| 0.060 | 8 | 5.1 | | 0.060 | 8 | 5.1 |
+--------------+-------------+----------------+
| 0.060 | 16 | 2.8 | | 0.060 | 16 | 2.8 |
+--------------+-------------+----------------+ +--------------+-------------+----------------+
Table 1: RTCP bandwidth needed for VoIP Table 1: RTCP bandwidth needed for VoIP feedback
feedback
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 non-compound The overhead can be reduced by sending some reports in non-compound
RTCP packets [RFC5506]. For example, if we alternate compound and RTCP packets [RFC5506]. For example, if we alternate compound and
non-compound RTCP packets, i.e., Nnc = 1, the calculation gives the non-compound RTCP packets, i.e., Nnc = 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 | 4 | 21.5 |
+--------------+-------------+----------------+
| 0.020 | 8 | 11.5 | | 0.020 | 8 | 11.5 |
+--------------+-------------+----------------+
| 0.020 | 16 | 6.5 | | 0.020 | 16 | 6.5 |
+--------------+-------------+----------------+
| 0.060 | 2 | 13.8 | | 0.060 | 2 | 13.8 |
+--------------+-------------+----------------+
| 0.060 | 4 | 7.2 | | 0.060 | 4 | 7.2 |
+--------------+-------------+----------------+
| 0.060 | 8 | 3.8 | | 0.060 | 8 | 3.8 |
+--------------+-------------+----------------+
| 0.060 | 16 | 2.2 | | 0.060 | 16 | 2.2 |
+--------------+-------------+----------------+ +--------------+-------------+----------------+
Table 2: Required RTCP bandwidth for VoIP Table 2: Required RTCP bandwidth for VoIP feedback (alternating
feedback (alternating compound and non- compound and non-compound reports)
compound 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 non-compound RTCP can be repeated for other patterns of compound and non-compound 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.
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
skipping to change at page 10, line 13 skipping to change at page 10, line 21
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 Rate | Video | Video | Audio | Required RTCP | | Data | Video | Video | Audio | Required RTCP |
| (kbps) | Frame | Packets per | Packets per | bandwidth: | | Rate | Frame | Packets per | Packets per | bandwidth: |
| | Rate: Rf | Report: Nv | Report: Na | Brtcp (kbps) | | (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%) |
| 200 | 16 | 1 | 3 | 67.5 (33%) | | 350 | 30 | 1 | 2 | 125.6 (35%) |
+-----------+----------+-------------+-------------+---------------+ | 700 | 30 | 2 | 2 | 126.6 (18%) |
| 350 | 30 | 1 | 2 | 125.6 (35%) | | 700 | 60 | 1 | 1 | 249.4 (35%) |
+-----------+----------+-------------+-------------+---------------+ | 1024 | 30 | 3 | 2 | 127.5 (12%) |
| 700 | 30 | 2 | 2 | 126.6 (18%) | | 1400 | 60 | 2 | 1 | 251.2 (17%) |
+-----------+----------+-------------+-------------+---------------+ | 2048 | 30 | 6 | 2 | 130.3 ( 6%) |
| 700 | 60 | 1 | 1 | 249.4 (35%) | | 2048 | 60 | 3 | 1 | 253.1 (12%) |
+-----------+----------+-------------+-------------+---------------+ | 4096 | 30 | 12 | 2 | 135.9 ( 3%) |
| 1024 | 30 | 3 | 2 | 127.5 (12%) | | 4096 | 60 | 6 | 1 | 258.8 ( 6%) |
+-----------+----------+-------------+-------------+---------------+ +---------+----------+--------------+--------------+----------------+
| 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 3: 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 "non-compound" packets to be omitted from some reports. These "non-compound"
(actually, compound but reduced size in this case) RTCP packets would (actually, compound but reduced size in this case) RTCP packets would
contain an RTCP RGRS packet from the non-reporting SSRC, and an RTCP contain an RTCP RGRS packet from the non-reporting SSRC, and an RTCP
SDES RGRP packet and a congestion control feedback packet from the SDES RGRP packet and a congestion control feedback packet from the
reporting SSRC. This will be 12 + 28 + 12 + 8 + 2*Nv + 8 + 2*Na reporting SSRC. This will be 12 + 28 + 12 + 8 + 2*Nv + 8 + 2*Na
octets, plus the SRTCP trailer and authentication tag, and a UDP/IP octets, plus the SRTCP trailer and authentication tag, and a UDP/IP
header. That is, the size of the non-compound packets would be (110 header. That is, the size of the non-compound packets would be (110
+ 2*Nv + 2*Na)/2 octets. Repeating the analysis above, but + 2*Nv + 2*Na)/2 octets. Repeating the analysis above, but
alternating compound and non-compound reports gives results as shown alternating compound and non-compound reports gives results as shown
in Table 4. in Table 4.
+===========+==========+=============+=============+===============+ +---------+----------+--------------+--------------+----------------+
| Data Rate | Video | Video | Audio | Required RTCP | | Data | Video | Video | Audio | Required RTCP |
| (kbps) | Frame | Packets per | Packets per | bandwidth: | | Rate | Frame | Packets per | Packets per | bandwidth: |
| | Rate: Rf | Report: Nv | Report: Na | Brtcp (kbps) | | (kbps) | Rate: Rf | Report: Nv | Report: Na | Brtcp (kbps) |
+===========+==========+=============+=============+===============+ +---------+----------+--------------+--------------+----------------+
| 100 | 8 | 1 | 6 | 24.1 (24%) | | 100 | 8 | 1 | 6 | 24.1 (24%) |
+-----------+----------+-------------+-------------+---------------+ | 200 | 16 | 1 | 3 | 46.8 (23%) |
| 200 | 16 | 1 | 3 | 46.8 (23%) | | 350 | 30 | 1 | 2 | 86.7 (24%) |
+-----------+----------+-------------+-------------+---------------+ | 700 | 30 | 2 | 2 | 87.7 (12%) |
| 350 | 30 | 1 | 2 | 86.7 (24%) | | 700 | 60 | 1 | 1 | 171.6 (24%) |
+-----------+----------+-------------+-------------+---------------+ | 1024 | 30 | 3 | 2 | 88.6 ( 8%) |
| 700 | 30 | 2 | 2 | 87.7 (12%) | | 1400 | 60 | 2 | 1 | 173.4 (12%) |
+-----------+----------+-------------+-------------+---------------+ | 2048 | 30 | 6 | 2 | 91.4 ( 4%) |
| 700 | 60 | 1 | 1 | 171.6 (24%) | | 2048 | 60 | 3 | 1 | 175.3 ( 8%) |
+-----------+----------+-------------+-------------+---------------+ | 4096 | 30 | 12 | 2 | 97.0 ( 2%) |
| 1024 | 30 | 3 | 2 | 88.6 ( 8%) | | 4096 | 60 | 6 | 1 | 180.9 ( 4%) |
+-----------+----------+-------------+-------------+---------------+ +---------+----------+--------------+--------------+----------------+
| 1400 | 60 | 2 | 1 | 173.4 (12%) |
+-----------+----------+-------------+-------------+---------------+
| 2048 | 30 | 6 | 2 | 91.4 ( 4%) |
+-----------+----------+-------------+-------------+---------------+
| 2048 | 60 | 3 | 1 | 175.3 ( 8%) |
+-----------+----------+-------------+-------------+---------------+
| 4096 | 30 | 12 | 2 | 97.0 ( 2%) |
+-----------+----------+-------------+-------------+---------------+
| 4096 | 60 | 6 | 1 | 180.9 ( 4%) |
+-----------+----------+-------------+-------------+---------------+
Table 4: Required RTCP bandwidth, reporting on every frame, with Table 4: 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 frames. Overall, it is clear that the RTCP frames rather than every frames. 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.
4. Discussion and Conclusions 4. Discussion and Conclusions
Practical systems will generally send some non-media traffic on the
same path as the media traffic. This can include STUN/TURN packets
to keep-alive NAT bindings [RFC8445], WebRTC Data Channel packets
[RFC8831], etc. Such traffic also needs congestion control, but the
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
non-compound RTCP reports in between the regular reports. non-compound 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 it's current form
for congestion feedback in WebRTC, the multimedia congestion control for congestion feedback in WebRTC, the multimedia congestion control
algorithm needs be designed to work with feedback sent every few algorithm needs 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. that is effective, if slowly responsive, to be implemented (there is
guidance on providing effective congestion control in Section 3.1 of
[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
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, and
to sessions with different data rates and sizes of membership. 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 and the members of the RMCAT feedback Thanks to Magnus Westerlund, Ingemar Johansson, Gorry Fairhurst, and
design team for their feedback. the members of the RMCAT feedback design team for their feedback.
8. Informative References 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
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,
RFC 2914, DOI 10.17487/RFC2914, September 2000,
<https://www.rfc-editor.org/info/rfc2914>.
[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., [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)", "RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, DOI 10.17487/RFC3611, November 2003, RFC 3611, DOI 10.17487/RFC3611, November 2003,
<https://www.rfc-editor.org/info/rfc3611>. <https://www.rfc-editor.org/info/rfc3611>.
skipping to change at page 13, line 38 skipping to change at page 13, line 46
"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>.
[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", RFC 8083,
DOI 10.17487/RFC8083, March 2017,
<https://www.rfc-editor.org/info/rfc8083>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/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,
"Sending Multiple RTP Streams in a Single RTP Session", "Sending Multiple RTP Streams in a Single RTP Session",
RFC 8108, DOI 10.17487/RFC8108, March 2017, RFC 8108, DOI 10.17487/RFC8108, March 2017,
<https://www.rfc-editor.org/info/rfc8108>. <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>.
[RFC8872] Westerlund, M., Burman, B., Perkins, C., Alvestrand, H.,
and R. Even, "Guidelines for Using the Multiplexing
Features of RTP to Support Multiple Media Streams",
RFC 8872, DOI 10.17487/RFC8872, January 2021,
<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 Author's Address
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
School of Computing Science School of Computing Science
Glasgow Glasgow G12 8QQ
G12 8QQ
United Kingdom United Kingdom
Email: csp@csperkins.org Email: csp@csperkins.org
 End of changes. 54 change blocks. 
150 lines changed or deleted 232 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/