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/ |