draft-ietf-rmcat-rtp-cc-feedback-05.txt   draft-ietf-rmcat-rtp-cc-feedback-06.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 November 4, 2019 Intended status: Informational 12 July 2021
Expires: May 7, 2020 Expires: 13 January 2022
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-05 draft-ietf-rmcat-rtp-cc-feedback-06
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 May 7, 2020. This Internet-Draft will expire on 13 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2019 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 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 Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as 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 Simplified BSD License.
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 . . . . . . . . . . . . . . 2
3. What Feedback is Achievable With RTCP? . . . . . . . . . . . 4 3. What Feedback is Achievable With RTCP? . . . . . . . . . . . 4
3.1. Scenario 1: Voice Telephony . . . . . . . . . . . . . . . 4 3.1. Scenario 1: Voice Telephony . . . . . . . . . . . . . . . 4
3.2. Scenario 2: Point-to-Point Video Conference . . . . . . . 6 3.2. Scenario 2: Point-to-Point Video Conference . . . . . . . 7
3.3. Scenario 3: Group Video Conference . . . . . . . . . . . 10 3.3. Scenario 3: Group Video Conference . . . . . . . . . . . 11
3.4. Scenario 4: Screen Sharing . . . . . . . . . . . . . . . 10 3.4. Scenario 4: Screen Sharing . . . . . . . . . . . . . . . 12
4. Discussion and Conclusions . . . . . . . . . . . . . . . . . 10 4. Discussion and Conclusions . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
8. Informative References . . . . . . . . . . . . . . . . . . . 11 8. Informative References . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The coming deployment of WebRTC systems raises the prospect that high The deployment of WebRTC systems [RFC8825] has resulted in high-
quality video conferencing will see extremely wide use. To ensure quality video conferencing seeing extremely wide use. To ensure the
the stability of the network in the face of this use, WebRTC systems stability of the network in the face of this use, WebRTC systems need
will need to use some form of congestion control for their RTP-based to use some form of congestion control for their RTP-based media
media traffic. To develop such congestion control, it is necessary traffic. To develop such congestion control, it is necessary to
to understand the sort of congestion feedback that can be provided understand the sort of congestion feedback that can be provided
within the framework of RTP [RFC3550] and the RTP Control Protocol within the framework of RTP [RFC3550] and the RTP Control Protocol
(RTCP). It then becomes possible to determine if this is sufficient (RTCP). It then becomes possible to determine if this is sufficient
for congestion control, or if some form of RTP extension is needed. for congestion control, or if some form of RTP extension is needed.
This memo considers the congestion feedback that can be sent using This memo considers the congestion feedback that can be sent using
RTCP under the RTP/SAVPF profile [RFC5124] (the secure version of the RTCP under the RTP/SAVPF profile [RFC5124] (the secure version of the
RTP/AVPF profile [RFC4585]). This profile was chosen as it forms the RTP/AVPF profile [RFC4585]). This profile was chosen as it forms the
basis for media transport in WebRTC [I-D.ietf-rtcweb-rtp-usage] basis for media transport in WebRTC [RFC8834] systems. Nothing in
systems. Nothing in this memo is specific to the secure version of this memo is specific to the secure version of the profile, or to
the profile, or to WebRTC, however. WebRTC, however.
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:
o How often is feedback needed? * How often is feedback needed?
o How much overhead is acceptable?
o How much, and what, data does each report contain? * How much overhead is acceptable?
* 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? Traditional congestion control protocols, such
as TCP, send acknowledgements with every packet (or, at least, every as TCP, send acknowledgements with every packet (or, at least, every
couple of packets). That is straight-forward and low overhead when couple of packets). That is straight-forward and low overhead when
traffic is bidirectional and acknowledgements can be piggybacked onto traffic is bidirectional and acknowledgements can be piggybacked onto
return path data packets. It can also be acceptable, and can have return path data packets. It can also be acceptable, and can have
reasonable overhead, to send separate acknowledgement packets when reasonable overhead, to send separate acknowledgement packets when
those packets are much smaller than data packets. It becomes a those packets are much smaller than data packets. It becomes a
problem, however, when there is no return traffic on which to problem, however, when there is no return traffic on which to
skipping to change at page 4, line 34 skipping to change at page 4, line 37
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. A compound RTCP packet is sent once
for every Nnc non-compound RTCP packets. for every Nnc non-compound RTCP packets.
Compound RTCP packets contain a Sender Report (SR) packet and a Compound RTCP packets contain a Sender Report (SR) packet and a
Source Description (SDES) packet, and an RTP Congestion Control Source Description (SDES) packet, and an RTP Congestion Control
Feedback (CCFB) packet [I-D.ietf-avtcore-cc-feedback-message]. Non- Feedback (CCFB) packet [RFC8888]. Non-compound RTCP packets contain
compound RTCP packets contain only the CCFB packet. Since each only the CCFB packet. Since each participant sends only a single
participant sends only a single media stream, the extensions for RTCP media stream, the extensions for RTCP report aggregation [RFC8108]
report aggregation [RFC8108] and reporting group optimisation and reporting group optimisation [RFC8861] are not used.
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] are not used.
Within each compound RTCP packet, the SR packet will contain a sender Within each compound RTCP packet, the SR packet will contain a sender
information block (28 octets) and a single reception report block (24 information block (28 octets) and a single reception report block (24
octets), for a total of 52 octets. A minimal SDES packet will octets), for a total of 52 octets. A minimal SDES packet will
contain a header (4 octets) and a single chunk containing an SSRC (4 contain a header (4 octets) and a single chunk containing an SSRC (4
octets) and a CNAME item, and if the recommendations for choosing the octets) and a CNAME item, and if the recommendations for choosing the
CNAME [RFC7022] are followed, the CNAME item will comprise a 2 octet CNAME [RFC7022] are followed, the CNAME item will comprise a 2 octet
header, 16 octets of data, and 2 octets of padding, for a total SDES header, 16 octets of data, and 2 octets of padding, for a total SDES
packet size of 28 octets. The CCFB packets contains an RTCP header packet size of 28 octets. The CCFB packets contains an RTCP header
and SSRC (8 octets), a report timestamp (4 octets), the SSRC, and SSRC (8 octets), a report timestamp (4 octets), the SSRC,
skipping to change at page 5, line 32 skipping to change at page 6, line 5
Solving for the RTCP bandwidth, Brtcp, and expanding the definition Solving for the RTCP bandwidth, Brtcp, and expanding the definition
of Srtcp gives Brtcp = (n * (Sc + Nnc * Snc))/(Nr * Tf * (1 + Nnc)). of Srtcp gives 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 expression second frame (i.e., 25 RTCP reports per second), this expression
gives the needed RTCP bandwidth Brtcp = 51.6kbps. Increasing the gives the needed RTCP bandwidth Brtcp = 51.6kbps. Increasing the
frame duration, or reducing the frequency of reports, reduces the frame duration, or reducing the frequency of reports, reduces the
RTCP bandwidth, as shown below: RTCP bandwidth, as shown below:
+--------------+-------------+----------------+ +==============+=============+================+
| Tf (seconds) | Nr (frames) | rtcp_bw (kbps) | | Tf (seconds) | Nr (frames) | rtcp_bw (kbps) |
+--------------+-------------+----------------+ +==============+=============+================+
| 20ms | 2 | 51.6 | | 20ms | 2 | 51.6 |
+--------------+-------------+----------------+
| 20ms | 4 | 26.6 | | 20ms | 4 | 26.6 |
+--------------+-------------+----------------+
| 20ms | 8 | 14.1 | | 20ms | 8 | 14.1 |
+--------------+-------------+----------------+
| 20ms | 16 | 7.8 | | 20ms | 16 | 7.8 |
+--------------+-------------+----------------+
| 60ms | 2 | 17.2 | | 60ms | 2 | 17.2 |
+--------------+-------------+----------------+
| 60ms | 4 | 8.9 | | 60ms | 4 | 8.9 |
+--------------+-------------+----------------+
| 60ms | 8 | 4.7 | | 60ms | 8 | 4.7 |
+--------------+-------------+----------------+
| 60ms | 16 | 2.6 | | 60ms | 16 | 2.6 |
+--------------+-------------+----------------+ +--------------+-------------+----------------+
Table 1: Required RTCP bandwidth for VoIP feedback Table 1: Required RTCP bandwidth for VoIP
feedback
The final row of the table (60ms frames, report every 16 frames) The final row of the table (60ms frames, report every 16 frames)
sends RTCP reports once per second, giving an RTCP bandwidth of sends RTCP reports once per second, giving an RTCP bandwidth of
2.6kbps. 2.6kbps.
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: non-compound RTCP packets, i.e., Nnc = 1, the calculation gives:
+--------------+-------------+----------------+ +==============+=============+================+
| Tf (seconds) | Nr (frames) | rtcp_bw (kbps) | | Tf (seconds) | Nr (frames) | rtcp_bw (kbps) |
+--------------+-------------+----------------+ +==============+=============+================+
| 20ms | 2 | 35.9 | | 20ms | 2 | 35.9 |
+--------------+-------------+----------------+
| 20ms | 4 | 18.8 | | 20ms | 4 | 18.8 |
+--------------+-------------+----------------+
| 20ms | 8 | 10.2 | | 20ms | 8 | 10.2 |
+--------------+-------------+----------------+
| 20ms | 16 | 5.9 | | 20ms | 16 | 5.9 |
+--------------+-------------+----------------+
| 60ms | 2 | 12.0 | | 60ms | 2 | 12.0 |
+--------------+-------------+----------------+
| 60ms | 4 | 6.2 | | 60ms | 4 | 6.2 |
+--------------+-------------+----------------+
| 60ms | 8 | 3.4 | | 60ms | 8 | 3.4 |
+--------------+-------------+----------------+
| 60ms | 16 | 2.0 | | 60ms | 16 | 2.0 |
+--------------+-------------+----------------+ +--------------+-------------+----------------+
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 non-
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.0kbps. This calculation (once per second), can be seen to drop to 2.0kbps. 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
skipping to change at page 6, line 49 skipping to change at page 8, line 8
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, and does not noise to reduce the packet rate during silent periods, and does not
cause the transmissions to stop). 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 co-located audio and video SSRCs separate SSRC; the RTCP reports from co-located audio and video SSRCs
at each end point are aggregated [RFC8108]; the optimisations in at each end point are aggregated [RFC8108]; the optimisations in
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] are used; and [RFC8861] are used; and congestion control feedback is sent
congestion control feedback is sent [RFC8888].
[I-D.ietf-avtcore-cc-feedback-message].
When all members are senders, the RTCP timing rules in Section 6.2 When all members are senders, the RTCP timing rules in Section 6.2
and 6.3 of [RFC3550] and [RFC4585] reduce to: and 6.3 of [RFC3550] and [RFC4585] reduce to:
rtcp_interval = avg_rtcp_size * n / rtcp_bw rtcp_interval = avg_rtcp_size * n / rtcp_bw
where n is the number of members in the session, the avg_rtcp_size is where n is the number of members in the session, the avg_rtcp_size is
measured in octets, and the rtcp_bw is the bandwidth available for measured in octets, and the rtcp_bw is the bandwidth available for
RTCP, measured in octets per second (this will typically be 5% of the RTCP, measured in octets per second (this will typically be 5% of the
session bandwidth). session bandwidth).
skipping to change at page 7, line 33 skipping to change at page 8, line 39
Since the RTCP reporting group extensions are used, one of these Since the RTCP reporting group extensions are used, one of these
SSRCs will be a reporting SSRC, and the other will delegate its SSRCs will be a reporting SSRC, and the other will delegate its
reports to that. reports to that.
The aggregated compound RTCP packet from the non-reporting SSRC will The aggregated compound RTCP packet from the non-reporting SSRC will
contain an RTCP SR packet, an RTCP SDES packet, and an RTCP RGRS contain an RTCP SR packet, an RTCP SDES packet, and an RTCP RGRS
packet. The RTCP SR packet contains the 28 octet header and sender packet. The RTCP SR packet contains the 28 octet header and sender
information, but no report blocks (since the reporting is delegated). information, but no report blocks (since the reporting is delegated).
The RTCP SDES packet will comprise a header (4 octets), originating The RTCP SDES packet will comprise a header (4 octets), originating
SSRC (4 octets), a CNAME chunk, a terminating chunk, and any padding. SSRC (4 octets), a CNAME chunk, a terminating chunk, and any padding.
If the CNAME follows [RFC7022] and [I-D.ietf-rtcweb-rtp-usage] it If the CNAME follows [RFC7022] and [RFC8834] it will be 18 octets in
will be 18 octets in size, and will need 1 octet of padding, making size, and will need 1 octet of padding, making the SDES packet 28
the SDES packet 28 octets in size. The RTCP RGRS packet will be 12 octets in size. The RTCP RGRS packet will be 12 octets in size.
octets in size. This gives a total of 28 + 28 + 12 = 68 octets. 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 [I-D.ietf-rtcweb-rtp-usage] it will be 18 CNAME follows [RFC7022] and [RFC8834] it will be 18 octets in size.
octets in size. The RGRP chunk similarly comprises 18 octets, and 3
octets of padding are needed, for a total of 48 octets. The RTCP The RGRP chunk similarly comprises 18 octets, and 3 octets of padding
congestion control feedback (CCFB) report comprises an 8 octet RTCP are needed, for a total of 48 octets. The RTCP congestion control
header and SSRC,an 4 report timestamp, then for each of the remote feedback (CCFB) report comprises an 8 octet RTCP header and SSRC,an 4
audio and video SSRCs, an 8 octet report header, and 2 octets per report timestamp, then for each of the remote audio and video SSRCs,
packet reported upon, and padding to a 4 octet boundary if needed; an 8 octet report header, and 2 octets per packet reported upon, and
that is 8 + 4 + 8 + (2 * Nv) + 8 + (2 * Na) where Nv is the number of padding to a 4 octet boundary if needed; that is 8 + 4 + 8 + (2 * Nv)
video packets per report, and Na is the number of audio packets per + 8 + (2 * Na) where Nv is the number of video 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 SRTP authentication tag, the reporting and non-reporting SSRCs, an SRTP authentication tag,
and a UDP/IPv4 header. The size of this RTCP packet is therefore: and a UDP/IPv4 header. The size of this RTCP packet is therefore:
248 + (2 * Nv) + (2 * Na) octets. Since the aggregate RTCP packet 248 + (2 * Nv) + (2 * Na) octets. Since the aggregate RTCP packet
contains reports from two SSRCs, the RTCP packet size is halved contains reports from two SSRCs, the RTCP packet size is halved
before use [RFC8108]. Accordingly, we define Sc = (248 + (2 * Nv) + before use [RFC8108]. Accordingly, we define Sc = (248 + (2 * Nv) +
(2 * Na))/2 for this scenario. (2 * Na))/2 for this scenario.
How many packets does the RTCP XR congestion control feedback packet How many packets does the RTCP XR congestion control feedback packet
report on? This is obviously highly dependent on the choice of codec report on? This is obviously highly dependent on the choice of codec
and encoding parameters, and might be quite bursty if the codec sends and encoding parameters, and might be quite bursty if the codec sends
I-frames from which later frames are predicted. For now though, I-frames from which later frames are predicted. For now though,
assume constant rate media with an MTU around 1500 octets, with assume constant rate media with an MTU around 1500 octets, with
reports for both audio and video being aggregated and sent to align reports for both audio and video being aggregated and sent to align
with video frames. This gives the following, assuming Nr =1 and Nnc with video frames. This gives the following, assuming Nr =1 and Nnc
= 0 (i.e., send a compound RTCP packet for each video frame, and no = 0 (i.e., send a compound RTCP packet for each video frame, and no
non-compound packets), and using the calculation from Scenario 1: non-compound packets), and using the calculation from Scenario 1:
Brtcp = (n * (Sc + Nnc * Snc))/(Nr * Tf * (1 + Nnc)) Brtcp = (n * (Sc + Nnc * Snc))/(Nr * Tf * (1 + Nnc))
+===========+=======+=============+=============+===============+
| Data Rate | Video | Video | Audio | Required RTCP |
| (kbps) | Frame | Packets per | Packets per | bandwidth: |
| | Rate | Report: Nv | Report: Na | Brtcp (kbps) |
+===========+=======+=============+=============+===============+
| 100 | 8 | 1 | 6 | 32.8 (32%) |
+-----------+-------+-------------+-------------+---------------+
| 200 | 16 | 1 | 3 | 64.0 (32%) |
+-----------+-------+-------------+-------------+---------------+
| 350 | 30 | 1 | 2 | 119.1 (34%) |
+-----------+-------+-------------+-------------+---------------+
| 700 | 30 | 2 | 2 | 120.0 (17%) |
+-----------+-------+-------------+-------------+---------------+
| 700 | 60 | 1 | 1 | 236.2 (33%) |
+-----------+-------+-------------+-------------+---------------+
| 1024 | 30 | 3 | 2 | 120.9 (11%) |
+-----------+-------+-------------+-------------+---------------+
| 1400 | 60 | 2 | 1 | 238.1 (17%) |
+-----------+-------+-------------+-------------+---------------+
| 2048 | 30 | 6 | 2 | 123.8 ( 6%) |
+-----------+-------+-------------+-------------+---------------+
| 2048 | 60 | 3 | 1 | 240.0 (11%) |
+-----------+-------+-------------+-------------+---------------+
| 4096 | 30 | 12 | 2 | 129.4 ( 3%) |
+-----------+-------+-------------+-------------+---------------+
| 4096 | 60 | 6 | 1 | 245.6 ( 5%) |
+-----------+-------+-------------+-------------+---------------+
+---------+---------+--------------+--------------+-----------------+ Table 3: Required RTCP bandwidth, reporting on every frame
| Data | Video | Video | Audio | Required RTCP |
| Rate | Frame | Packets per | Packets per | bandwidth: |
| (kbps) | Rate | Report: Nv | Report: Na | Brtcp (kbps) |
+---------+---------+--------------+--------------+-----------------+
| 100 | 8 | 1 | 6 | 32.8 (32%) |
| 200 | 16 | 1 | 3 | 64.0 (32%) |
| 350 | 30 | 1 | 2 | 119.1 (34%) |
| 700 | 30 | 2 | 2 | 120.0 (17%) |
| 700 | 60 | 1 | 1 | 236.2 (33%) |
| 1024 | 30 | 3 | 2 | 120.9 (11%) |
| 1400 | 60 | 2 | 1 | 238.1 (17%) |
| 2048 | 30 | 6 | 2 | 123.8 ( 6%) |
| 2048 | 60 | 3 | 1 | 240.0 (11%) |
| 4096 | 30 | 12 | 2 | 129.4 ( 3%) |
| 4096 | 60 | 6 | 1 | 245.6 ( 5%) |
+---------+---------+--------------+--------------+-----------------+
Table 3: Required RTCP bandwidth, reporting on every frame
The RTCP bandwidth needed scales inversely with Nr. That is, it is The RTCP bandwidth needed scales inversely with Nr. That is, it is
halved if Nr=2 (report on every second packet), is reduced to one- halved if Nr=2 (report on every second packet), is reduced to one-
third if Nr=3 (report on every third packet), and so on. third if Nr=3 (report on every third packet), and so on.
The needed RTCP bandwidth scales as a percentage of the data rate The needed RTCP bandwidth scales as a percentage of the data rate
following the ratio of the frame rate to the data rate. As can be following the ratio of the frame rate to the data rate. As can be
seen from the table above, the RTCP bandwidth needed is a significant seen from the table above, the RTCP bandwidth needed is a significant
fraction of the media rate, if reporting on every frame for low rate fraction of the media rate, if reporting on every frame for low rate
video. This can be solved by reporting less often at lower rates. video. This can be solved by reporting less often at lower rates.
skipping to change at page 9, line 24 skipping to change at page 11, line 9
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 UDP/IP header. That is, Snc = (96 + 2*Nv + 2*Na)/2. octets, plus UDP/IP header. That is, Snc = (96 + 2*Nv + 2*Na)/2.
Repeating the analysis above, but alternating compound and non- Repeating the analysis above, but alternating compound and non-
compound reports, i.e., setting Nnc = 1, gives: compound reports, i.e., setting Nnc = 1, gives:
+---------+---------+--------------+--------------+-----------------+ +===========+=======+=============+=============+===============+
| 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 | Report: Nv | Report: Na | Brtcp (kbps) | | | Rate | Report: Nv | Report: Na | Brtcp (kbps) |
+---------+---------+--------------+--------------+-----------------+ +===========+=======+=============+=============+===============+
| 100 | 8 | 1 | 6 | 23.2 (23%) | | 100 | 8 | 1 | 6 | 23.2 (23%) |
| 200 | 16 | 1 | 3 | 45.0 (22%) | +-----------+-------+-------------+-------------+---------------+
| 350 | 30 | 1 | 2 | 83.4 (23%) | | 200 | 16 | 1 | 3 | 45.0 (22%) |
| 700 | 30 | 2 | 2 | 84.4 (12%) | +-----------+-------+-------------+-------------+---------------+
| 700 | 60 | 1 | 1 | 165.0 (23%) | | 350 | 30 | 1 | 2 | 83.4 (23%) |
| 1024 | 30 | 3 | 2 | 85.3 ( 8%) | +-----------+-------+-------------+-------------+---------------+
| 1400 | 60 | 2 | 1 | 166.9 (11%) | | 700 | 30 | 2 | 2 | 84.4 (12%) |
| 2048 | 30 | 6 | 2 | 88.1 ( 4%) | +-----------+-------+-------------+-------------+---------------+
| 2048 | 60 | 3 | 1 | 168.8 ( 8%) | | 700 | 60 | 1 | 1 | 165.0 (23%) |
| 4096 | 30 | 12 | 2 | 93.8 ( 2%) | +-----------+-------+-------------+-------------+---------------+
| 4096 | 60 | 6 | 1 | 174.4 ( 4%) | | 1024 | 30 | 3 | 2 | 85.3 ( 8%) |
+---------+---------+--------------+--------------+-----------------+ +-----------+-------+-------------+-------------+---------------+
| 1400 | 60 | 2 | 1 | 166.9 (11%) |
+-----------+-------+-------------+-------------+---------------+
| 2048 | 30 | 6 | 2 | 88.1 ( 4%) |
+-----------+-------+-------------+-------------+---------------+
| 2048 | 60 | 3 | 1 | 168.8 ( 8%) |
+-----------+-------+-------------+-------------+---------------+
| 4096 | 30 | 12 | 2 | 93.8 ( 2%) |
+-----------+-------+-------------+-------------+---------------+
| 4096 | 60 | 6 | 1 | 174.4 ( 4%) |
+-----------+-------+-------------+-------------+---------------+
Table 4: Required RTCP bandwidth, reporting on every frame, with Table 4: Required RTCP bandwidth, reporting on every frame,
reduced-size reports with 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.
3.3. Scenario 3: Group Video Conference 3.3. Scenario 3: Group Video Conference
(tbd) (tbd)
skipping to change at page 10, line 36 skipping to change at page 12, line 32
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. That frames, since that fits within the limitations of RTCP. That
feedback can be a little more complex than just an acknowledgement, feedback can be a little more complex than just an acknowledgement,
provided care is taken to consider the impact of the extra feedback provided care is taken to consider the impact of the extra feedback
on the overhead, possibly allowing for a degree of semantic feedback, on the overhead, possibly allowing for a degree of semantic feedback,
meaningful to the codec layer as well as the congestion control meaningful to the codec layer as well as the congestion control
algorithm. algorithm.
The format described in [I-D.ietf-avtcore-cc-feedback-message] seems The format described in [RFC8888] seems sufficient for the needs of
sufficient for the needs of congestion control feedback. There is congestion control feedback. There is little point optimising this
little point optimising this format: the main overhead comes from the format: the main overhead comes from the UDP/IP headers and the other
UDP/IP headers and the other RTCP packets included in the compound RTCP packets included in the compound packets, and can be lowered by
packets, and can be lowered by using the [RFC5506] extensions and using the [RFC5506] extensions and sending reports less frequently.
sending reports less frequently.
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
skipping to change at page 11, line 18 skipping to change at page 13, line 16
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 and the members of the RMCAT feedback
design team for their feedback. design team for their feedback.
8. Informative References 8. Informative References
[I-D.ietf-avtcore-cc-feedback-message]
Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP
Control Protocol (RTCP) Feedback for Congestion Control",
draft-ietf-avtcore-cc-feedback-message-04 (work in
progress), July 2019.
[I-D.ietf-avtcore-rtp-multi-stream-optimisation]
Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
"Sending Multiple RTP Streams in a Single RTP Session:
Grouping RTCP Reception Statistics and Other Feedback",
draft-ietf-avtcore-rtp-multi-stream-optimisation-12 (work
in progress), March 2016.
[I-D.ietf-rtcweb-rtp-usage]
Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time
Communication (WebRTC): Media Transport and Use of RTP",
draft-ietf-rtcweb-rtp-usage-26 (work in progress), March
2016.
[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 12, line 35 skipping to change at page 14, line 14
[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>.
[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>.
[RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for
Browser-Based Applications", RFC 8825,
DOI 10.17487/RFC8825, January 2021,
<https://www.rfc-editor.org/info/rfc8825>.
[RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport
and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834,
January 2021, <https://www.rfc-editor.org/info/rfc8834>.
[RFC8861] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
"Sending Multiple RTP Streams in a Single RTP Session:
Grouping RTP Control Protocol (RTCP) Reception Statistics
and Other Feedback", RFC 8861, DOI 10.17487/RFC8861,
January 2021, <https://www.rfc-editor.org/info/rfc8861>.
[RFC8888] Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP
Control Protocol (RTCP) Feedback for Congestion Control",
RFC 8888, DOI 10.17487/RFC8888, January 2021,
<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 G12 8QQ Glasgow
G12 8QQ
United Kingdom United Kingdom
Email: csp@csperkins.org Email: csp@csperkins.org
 End of changes. 45 change blocks. 
130 lines changed or deleted 162 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/