draft-ietf-rmcat-rtp-cc-feedback-08.txt | draft-ietf-rmcat-rtp-cc-feedback-09.txt | |||
---|---|---|---|---|
Network Working Group C. Perkins | Network Working Group C. Perkins | |||
Internet-Draft University of Glasgow | Internet-Draft University of Glasgow | |||
Intended status: Informational December 28, 2021 | Intended status: Informational July 11, 2022 | |||
Expires: July 1, 2022 | Expires: January 12, 2023 | |||
Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in | Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in | |||
Interactive Multimedia Conferences | Interactive Multimedia Conferences | |||
draft-ietf-rmcat-rtp-cc-feedback-08 | draft-ietf-rmcat-rtp-cc-feedback-09 | |||
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 July 1, 2022. | This Internet-Draft will expire on January 12, 2023. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are 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 . . . . . . . . . . . . . . 3 | 2. Considerations for RTCP Feedback . . . . . . . . . . . . . . 3 | |||
3. What Feedback is Achievable With RTCP? . . . . . . . . . . . 5 | 3. What Feedback is Achievable With RTCP? . . . . . . . . . . . 5 | |||
3.1. Scenario 1: Voice Telephony . . . . . . . . . . . . . . . 5 | 3.1. Scenario 1: Voice Telephony . . . . . . . . . . . . . . . 5 | |||
3.2. Scenario 2: Point-to-Point Video Conference . . . . . . . 8 | 3.2. Scenario 2: Point-to-Point Video Conference . . . . . . . 8 | |||
4. Discussion and Conclusions . . . . . . . . . . . . . . . . . 11 | 4. Discussion and Conclusions . . . . . . . . . . . . . . . . . 11 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | |||
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 | |||
8. Informative References . . . . . . . . . . . . . . . . . . . 12 | 8. Informative References . . . . . . . . . . . . . . . . . . . 12 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
skipping to change at page 2, line 48 ¶ | skipping to change at page 2, line 48 ¶ | |||
control, or if some form of RTP extension is needed. | control, or if some form of RTP extension is needed. | |||
This memo considers unicast congestion feedback that can be sent | This memo considers unicast congestion feedback that can be sent | |||
using RTCP under the RTP/SAVPF profile [RFC5124] (the secure version | using RTCP under the RTP/SAVPF profile [RFC5124] (the secure version | |||
of the RTP/AVPF profile [RFC4585]). This profile was chosen as it | of the RTP/AVPF profile [RFC4585]). This profile was chosen as it | |||
forms the basis for media transport in WebRTC [RFC8834] systems. | forms the basis for media transport in WebRTC [RFC8834] systems. | |||
Nothing in this memo is specific to the secure version of the | Nothing in this memo is specific to the secure version of the | |||
profile, or to WebRTC, however. It is also assumed that the | profile, or to WebRTC, however. It is also assumed that the | |||
congestion control feedback mechanism described in [RFC8888], and | congestion control feedback mechanism described in [RFC8888], and | |||
common RTCP extensions for efficient feedback [RFC5506], [RFC8108], | common RTCP extensions for efficient feedback [RFC5506], [RFC8108], | |||
[RFC8861], [RFC8861], and [RFC8872] are available. | [RFC8861], and [RFC8872] are available. | |||
2. Possible Models for RTCP Feedback | 2. Considerations for RTCP Feedback | |||
Several questions need to be answered when providing RTCP reception | Several questions need to be answered when providing RTCP reception | |||
quality feedback for congestion control purposes. These include: | quality feedback for congestion control purposes. These include: | |||
o How often is feedback needed? | o How often is feedback needed? | |||
o How much overhead is acceptable? | o How much overhead is acceptable? | |||
o How much, and what, data does each report contain? | o How much, and what, data does each report contain? | |||
skipping to change at page 3, line 37 ¶ | skipping to change at page 3, line 37 ¶ | |||
separate acknowledgement packets when those packets are much smaller | separate acknowledgement packets when those packets are much smaller | |||
than data packets. | than data packets. | |||
Frequent acknowledgements can become a problem, however, when there | Frequent acknowledgements can become a problem, however, when there | |||
is no return traffic on which to piggyback feedback, or if separate | is no return traffic on which to piggyback feedback, or if separate | |||
feedback and data packets are sent and the feedback is similar in | feedback and data packets are sent and the feedback is similar in | |||
size to the data being acknowledged. This can be the case for some | size to the data being acknowledged. This can be the case for some | |||
forms of media traffic, especially for voice over IP flows, leading | forms of media traffic, especially for voice over IP flows, leading | |||
to high overhead when using a transport protocol that sends frequent | to high overhead when using a transport protocol that sends frequent | |||
feedback. Approaches like in-network filtering of acknowledgements | feedback. Approaches like in-network filtering of acknowledgements | |||
can reduce the feedback frequency and overhead in some cases, but | have been proposed to reduce acknowledgement overheads on highly | |||
this so-called "stretch-ACK" behaviour is non-standard and not | asymmetric links (e.g., as mentioned in [RFC3449]) can also reduce | |||
guaranteed. | the feedback frequency and overhead for multimedia traffic, but this | |||
so-called "stretch-ACK" behaviour is non-standard and not guaranteed. | ||||
Accordingly, when implementing congestion control for RTP-based | Accordingly, when implementing congestion control for RTP-based | |||
multimedia traffic, it might make sense to give the option of sending | multimedia traffic, it might make sense to give the option of sending | |||
congestion feedback less often than does TCP. For example, it might | congestion feedback less often than does TCP. For example, it might | |||
be possible to send a feedback packet once per video frame, or every | be possible to send a feedback packet once per video frame, or every | |||
few frames, or once per network round trip time (RTT). This could | few frames, or once per network round trip time (RTT). This could | |||
still give sufficiently frequent feedback for the congestion control | still give sufficiently frequent feedback for the congestion control | |||
loop to be stable and responsive while keeping the overhead | loop to be stable and responsive while keeping the overhead | |||
reasonable when the feedback cannot be piggybacked onto returning | reasonable when the feedback cannot be piggybacked onto returning | |||
data. In this case, it is important to note that RTCP can send much | data. In this case, it is important to note that RTCP can send much | |||
skipping to change at page 4, line 38 ¶ | skipping to change at page 4, line 39 ¶ | |||
contribute to link utilization, and can affect the timing of other | contribute to link utilization, and can affect the timing of other | |||
traffic on the network. This can affect performance on some types of | traffic on the network. This can affect performance on some types of | |||
network, that can be impacted by the rate, timing, and size 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. | 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 is generally acceptable, | |||
providing the ability to change this fraction. Is this still the | while providing the ability to change this fraction. Is this still | |||
case for congestion control feedback? Is there a desire to provide | the case for congestion control feedback? Is there a desire to | |||
more responsive feedback and congestion control, possibility with a | provide more responsive feedback and congestion control, possibly | |||
higher overhead? Or is lower overhead wanted, accepting that this | with a higher overhead? Or is lower overhead wanted, accepting that | |||
might reduce responsiveness of the congestion control algorithm? | this 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? Is it useful | acceptable to send more complex feedback less often? Is it useful | |||
for the congestion control to receive frequent feedback, perhaps to | for the congestion control to receive frequent feedback, perhaps to | |||
provide more accurate round-trip time estimates, or to provide | provide more accurate round-trip time estimates, or to provide | |||
robustness in case feedback packets are lost, even if the media | robustness in case feedback packets are lost, even if the media | |||
sending rate cannot quickly be changed? Or is low-rate feedback, | sending rate cannot quickly be changed? Or is low-rate feedback, | |||
resulting in slowly responsive changes the sending rate, acceptable? | resulting in slowly responsive changes to the sending rate, | |||
Different combinations of congestion control algorithm and media | acceptable? Different combinations of congestion control algorithm | |||
codec might require different trade-offs, and the correct trade-off | and media codec might require different trade-offs, and the correct | |||
for interactive, self-paced, real-time multimedia traffic might not | trade-off for interactive, self-paced, real-time multimedia traffic | |||
be the same as that for TCP congestion control. | 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 | |||
for congestion control, since there is only a single media stream to | for congestion control, since there is only a single media stream to | |||
control. It's complicated, however, by severe bandwidth constraints | control. It's complicated, however, by severe bandwidth constraints | |||
on the feedback, to keep the overhead manageable. | on the feedback, to keep the overhead manageable. | |||
Assume a two-party point-to-point voice-over-IP call, using RTP over | Assume a two-party point-to-point voice-over-IP call, using RTP over | |||
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 = 0.020s in | |||
cases, but values up to 60ms are not uncommon). The congestion | many cases, but values up to 0.060s are not uncommon). The | |||
control algorithm requires feedback every Nr frames, i.e., every Nr * | congestion control algorithm requires feedback every Nr frames, i.e., | |||
Tf seconds, to ensure effective control. Both parties in the call | every Nr * Tf seconds, to ensure effective control. Both parties in | |||
send speech data or comfort noise with sufficient frequency that they | the call send speech data or comfort noise with sufficient frequency | |||
are counted as senders for the purpose of the RTCP reporting interval | that they are counted as senders for the purpose of the RTCP | |||
calculation. | reporting interval 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 [RFC5506]. A compound RTCP packet is | or reduced-size RTCP packets [RFC5506]. A compound RTCP packet is | |||
sent once for every Nnc non-compound RTCP packets. | sent once for every Nrs reduced-size 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]. Reduced-size RTCP packets contain only the | |||
CCFB packet. Since each participant sends only a single RTP media | CCFB packet. Since each participant sends only a single RTP media | |||
stream, the extensions for RTCP report aggregation [RFC8108] and | stream, the extensions for RTCP report aggregation [RFC8108] and | |||
reporting group optimisation [RFC8861] are not used. | reporting group optimisation [RFC8861] are not used. | |||
Within each compound RTCP packet, the SR packet will contain a sender | Within each compound RTCP packet, the SR packet will contain a sender | |||
information block (28 octets) and a single reception report block (24 | information block (28 octets) and a single reception report block (24 | |||
octets), for a total of 52 octets. A minimal SDES packet will | octets), for a total of 52 octets. A minimal SDES packet will | |||
contain a header (4 octets) and a single chunk containing an SSRC (4 | contain a header (4 octets) and a single chunk containing an SSRC (4 | |||
octets) and a CNAME item, and if the recommendations for choosing the | octets) and a CNAME item, and if the recommendations for choosing the | |||
CNAME [RFC7022] are followed, the CNAME item will comprise a 2 octet | CNAME [RFC7022] are followed, the CNAME item will comprise a 2 octet | |||
header, 16 octets of data, and 2 octets of padding, for a total SDES | header, 16 octets of data, and 2 octets of padding, for a total SDES | |||
packet size of 28 octets. The CCFB packets contains an RTCP header | packet size of 28 octets. The CCFB packets contain an RTCP header | |||
and SSRC (8 octets), a report timestamp (4 octets), the SSRC, | and SSRC (8 octets), a report timestamp (4 octets), the SSRC, | |||
beginning and ending sequence numbers (8 octets), and 2*Nr octets of | beginning and ending sequence numbers (8 octets), and 2*Nr octets of | |||
reports, for a total of 20 + 2*Nr octets. The compound Secure RTCP | reports, for a total of 20 + 2*Nr octets. The compound Secure RTCP | |||
packet will include 4 octets of trailer followed by an 80 bit (10 | packet will include 4 octets of trailer followed by an 80 bit (10 | |||
octet) authentication tag if HMAC-SHA1 authentication is used. If | octet) authentication tag if HMAC-SHA1 authentication is used. If | |||
IPv4 is used, with no IP options, the UDP/IP header will be 28 octets | IPv4 is used, with no IP options, the UDP/IP header will be 28 octets | |||
in size. This gives a total compound RTCP packet size of Sc = 142 + | in size. This gives a total compound RTCP packet size of Sc = 142 + | |||
2*Nr octets. | 2*Nr octets. | |||
The non-compound RTCP packets will comprise just the CCFB packet, | The reduced-size RTCP packets will comprise just the CCFB packet, | |||
SRTCP trailer and authentication tag, and a UDP/IP header. It can be | SRTCP trailer and authentication tag, and a UDP/IP header. It can be | |||
seen that these packets will be Snc = 62 + 2*Nr octets in size. | seen that these packets will be Srs = 62 + 2*Nr octets in size. | |||
The RTCP reporting interval calculation ([RFC3550], Section 6.2) for | The RTCP reporting interval calculation ([RFC3550], Section 6.2) for | |||
a two-party session where both participants are senders, reduces to: | a two-party session where both participants are senders, reduces to: | |||
Trtcp = n * Srtcp / Brtcp | Trtcp = n * Srtcp / Brtcp | |||
where Srtcp = (Sc + Nnc * Snc)/(1 + Nnc) is the average RTCP packet | where Srtcp = (Sc + Nrs * Srs)/(1 + Nrs) is the average RTCP packet | |||
size in octets, Brtcp is the bandwidth allocated to RTCP in octets | size in octets, Brtcp is the bandwidth allocated to RTCP in octets | |||
per second, and n is the number of participants in the RTP session | per second, and n is the number of participants in the RTP session | |||
(in this scenario, n = 2). | (in this scenario, n = 2). | |||
To ensure an RTCP report containing congestion control feedback is | To ensure an RTCP report containing congestion control feedback is | |||
sent after every Nr frames of audio, it is necessary to set the RTCP | sent after every Nr frames of audio, it is necessary to set the RTCP | |||
reporting interval Trtcp = Nr * Tf, which when substituted into the | reporting interval Trtcp = Nr * Tf, which when substituted into the | |||
previous gives Nr * Tf = n * Srtcp/Brtcp. Solving this to give the | previous gives Nr * Tf = n * Srtcp/Brtcp. Solving this to give the | |||
RTCP bandwidth, Brtcp, and expanding the definition of Srtcp gives: | RTCP bandwidth, Brtcp, and expanding the definition of Srtcp gives: | |||
Brtcp = (n * (Sc + Nnc * Snc))/(Nr * Tf * (1 + Nnc)). | Brtcp = (n * (Sc + Nrs * Srs))/(Nr * Tf * (1 + Nrs)). | |||
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., Nrs = 0), | |||
the frame duration Tf = 20ms, and an RTCP report is sent for every | the frame duration Tf = 20ms, and an RTCP report is sent for every | |||
second frame (i.e., 25 RTCP reports per second), this gives an RTCP | second frame (i.e., 25 RTCP reports per second), this gives an RTCP | |||
feedback bandwidth, Brtcp = 57kbps. Increasing the frame duration, | feedback bandwidth, Brtcp = 57kbps. Increasing the frame duration, | |||
or reducing the frequency of reports, will reduce the RTCP bandwidth | or reducing the frequency of reports, will reduce the RTCP bandwidth | |||
as shown in Table 1. | as shown in Table 1. | |||
+--------------+-------------+----------------+ | +--------------+-------------+----------------+ | |||
| Tf (seconds) | Nr (frames) | rtcp_bw (kbps) | | | Tf (seconds) | Nr (frames) | rtcp_bw (kbps) | | |||
+--------------+-------------+----------------+ | +--------------+-------------+----------------+ | |||
| 0.020 | 2 | 57.0 | | | 0.020 | 2 | 57.0 | | |||
| 0.020 | 4 | 29.3 | | | 0.020 | 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 feedback | Table 1: RTCP bandwidth needed for VoIP feedback (compound reports | |||
only) | ||||
The final row of Table 1 (60ms frames, report every 16 frames) sends | The final row of Table 1 (60ms frames, report every 16 frames) sends | |||
RTCP reports once per second, giving an RTCP bandwidth overhead of | RTCP reports once per second, giving an RTCP bandwidth overhead of | |||
2.8kbps. | 2.8kbps. | |||
The overhead can be reduced by sending some reports in non-compound | The overhead can be reduced by sending some reports in reduced-size | |||
RTCP packets [RFC5506]. For example, if we alternate compound and | RTCP packets [RFC5506]. For example, if we alternate compound and | |||
non-compound RTCP packets, i.e., Nnc = 1, the calculation gives the | reduced-size RTCP packets, i.e., Nrs = 1, the calculation gives the | |||
results shown in Table 2. | results shown in Table 2. | |||
+--------------+-------------+----------------+ | +--------------+-------------+----------------+ | |||
| Tf (seconds) | Nr (frames) | rtcp_bw (kbps) | | | Tf (seconds) | Nr (frames) | rtcp_bw (kbps) | | |||
+--------------+-------------+----------------+ | +--------------+-------------+----------------+ | |||
| 0.020 | 2 | 41.4 | | | 0.020 | 2 | 41.4 | | |||
| 0.020 | 4 | 21.5 | | | 0.020 | 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 feedback (alternating | Table 2: Required RTCP bandwidth for VoIP feedback (alternating | |||
compound and non-compound reports) | 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.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 reduced-size RTCP | |||
packets, feedback frequency, and frame duration, as needed. | packets, feedback frequency, and frame duration, as needed. | |||
Note: To achieve the RTCP transmission intervals above the RTP/SAVPF | Note: To achieve the RTCP transmission intervals above the RTP/SAVPF | |||
profile with T_rr_interval=0 is used, since even when using the | profile with T_rr_interval=0 is used, since even when using the | |||
reduced minimal transmission interval, the RTP/SAVP profile would | reduced minimal transmission interval, the RTP/SAVP profile would | |||
only allow sending RTCP at most every 0.11s (every third frame of | only allow sending RTCP at most every 0.11s (every third frame of | |||
video). Using RTP/SAVPF with T_rr_interval=0 however is capable of | video). Using RTP/SAVPF with T_rr_interval=0 however is capable of | |||
fully utilizing the configured 5% RTCP bandwidth fraction. | fully utilizing the configured 5% RTCP bandwidth fraction. | |||
3.2. Scenario 2: Point-to-Point Video Conference | 3.2. Scenario 2: Point-to-Point Video Conference | |||
skipping to change at page 8, line 43 ¶ | skipping to change at page 8, line 44 ¶ | |||
feedback sent in each RTCP packet, on the number of members in the | feedback sent in each RTCP packet, on the number of members in the | |||
session, on the size of source description (RTCP SDES) information | session, on the size of source description (RTCP SDES) information | |||
sent, and on the amount of congestion control feedback sent in each | sent, and on the amount of congestion control feedback sent in each | |||
packet. | packet. | |||
As a baseline, each RTCP packet will be a compound RTCP packet that | As a baseline, each RTCP packet will be a compound RTCP packet that | |||
contains an aggregate of a compound RTCP packet generated by the | contains an aggregate of a compound RTCP packet generated by the | |||
video SSRC and a compound RTCP packet generated by the audio SSRC. | video SSRC and a compound RTCP packet generated by the audio SSRC. | |||
When the RTCP reporting group extensions are used, one of these SSRCs | When the RTCP reporting group extensions are used, one of these SSRCs | |||
will be a reporting SSRC, to which the other SSRC will have delegated | will be a reporting SSRC, to which the other SSRC will have delegated | |||
its reports. No non-compound RTCP packets are sent. | its reports. No reduced-size RTCP packets are sent. | |||
The aggregated compound RTCP packet from the non-reporting SSRC will | The aggregated compound RTCP packet from the non-reporting SSRC will | |||
contain an RTCP SR packet, an RTCP SDES packet, and an RTCP RGRS | contain an RTCP SR packet, an RTCP SDES packet, and an RTCP RGRS | |||
packet. The RTCP SR packet contains the 28 octet header and sender | packet. The RTCP SR packet contains the 28 octet header and sender | |||
information, but no report blocks (since the reporting is delegated). | information, but no report blocks (since the reporting is delegated). | |||
The RTCP SDES packet will comprise a header (4 octets), originating | The RTCP SDES packet will comprise a header (4 octets), originating | |||
SSRC (4 octets), a CNAME chunk, a terminating chunk, and any padding. | SSRC (4 octets), a CNAME chunk, a terminating chunk, and any padding. | |||
If the CNAME follows [RFC7022] and [RFC8834] it will be 18 octets in | If the CNAME follows [RFC7022] and [RFC8834] it will be 18 octets in | |||
size, and will need 1 octet of padding, making the SDES packet 28 | size, and will need 1 octet of padding, making the SDES packet 28 | |||
octets in size. The RTCP RGRS packet will be 12 octets in size. | octets in size. The RTCP RGRS packet will be 12 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), | |||
skipping to change at page 10, line 42 ¶ | skipping to change at page 10, line 42 ¶ | |||
| 1400 | 60 | 2 | 1 | 251.2 (17%) | | | 1400 | 60 | 2 | 1 | 251.2 (17%) | | |||
| 2048 | 30 | 6 | 2 | 130.3 ( 6%) | | | 2048 | 30 | 6 | 2 | 130.3 ( 6%) | | |||
| 2048 | 60 | 3 | 1 | 253.1 (12%) | | | 2048 | 60 | 3 | 1 | 253.1 (12%) | | |||
| 4096 | 30 | 12 | 2 | 135.9 ( 3%) | | | 4096 | 30 | 12 | 2 | 135.9 ( 3%) | | |||
| 4096 | 60 | 6 | 1 | 258.8 ( 6%) | | | 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 "reduced-size" RTCP | |||
(actually, compound but reduced size in this case) RTCP packets would | packets would contain an RTCP RGRS packet from the non-reporting | |||
contain an RTCP RGRS packet from the non-reporting SSRC, and an RTCP | SSRC, and an RTCP SDES RGRP packet and a congestion control feedback | |||
SDES RGRP packet and a congestion control feedback packet from the | packet from the reporting SSRC. This will be 12 + 28 + 12 + 8 + 2*Nv | |||
reporting SSRC. This will be 12 + 28 + 12 + 8 + 2*Nv + 8 + 2*Na | + 8 + 2*Na octets, plus the SRTCP trailer and authentication tag, and | |||
octets, plus the SRTCP trailer and authentication tag, and a UDP/IP | a UDP/IP header. That is, the size of the reduced-size packets would | |||
header. That is, the size of the non-compound packets would be (110 | 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 reduced-size reports gives results as shown | |||
alternating compound and non-compound reports gives results as shown | ||||
in Table 4. | in Table 4. | |||
+---------+----------+--------------+--------------+----------------+ | +---------+----------+--------------+--------------+----------------+ | |||
| Data | Video | Video | Audio | Required RTCP | | | Data | Video | Video | Audio | Required RTCP | | |||
| Rate | Frame | Packets per | Packets per | bandwidth: | | | Rate | Frame | Packets per | Packets per | bandwidth: | | |||
| (kbps) | 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%) | | | 350 | 30 | 1 | 2 | 86.7 (24%) | | |||
skipping to change at page 11, line 28 ¶ | skipping to change at page 11, line 28 ¶ | |||
| 2048 | 60 | 3 | 1 | 175.3 ( 8%) | | | 2048 | 60 | 3 | 1 | 175.3 ( 8%) | | |||
| 4096 | 30 | 12 | 2 | 97.0 ( 2%) | | | 4096 | 30 | 12 | 2 | 97.0 ( 2%) | | |||
| 4096 | 60 | 6 | 1 | 180.9 ( 4%) | | | 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 frame. Overall, it is clear that the RTCP | |||
overhead can be reasonable across the range of data and frame rates, | overhead can be reasonable across the range of data and frame rates, | |||
if RTCP is configured carefully. | if RTCP is configured carefully. | |||
4. Discussion and Conclusions | 4. Discussion and Conclusions | |||
Practical systems will generally send some non-media traffic on the | Practical systems will generally send some non-media traffic on the | |||
same path as the media traffic. This can include STUN/TURN packets | same path as the media traffic. This can include STUN/TURN packets | |||
to keep-alive NAT bindings [RFC8445], WebRTC Data Channel packets | to keep-alive NAT bindings [RFC8445], WebRTC Data Channel packets | |||
[RFC8831], etc. Such traffic also needs congestion control, but the | [RFC8831], etc. Such traffic also needs congestion control, but the | |||
means by which this is achieved is out of scope of this memo. | means by which this is achieved is out of scope of this memo. | |||
skipping to change at page 11, line 51 ¶ | skipping to change at page 11, line 51 ¶ | |||
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. | reduced-size RTCP reports in between the regular reports. | |||
If it is desired to use RTCP in something close to it's current form | If it is desired to use RTCP in something close to 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 to be designed to work with feedback sent every few | |||
frames, since that fits within the limitations of RTCP. The provided | frames, since that fits within the limitations of RTCP. The provided | |||
feedback will be more detailed than just an acknowledgement, however, | feedback will be more detailed than just an acknowledgement, however, | |||
and will provide a loss bitmap, relative arrival time, and received | and will provide a loss bitmap, relative arrival time, and received | |||
ECN marks, for each packet sent. This will allow congestion control | ECN marks, for each packet sent. This will allow congestion control | |||
that is effective, if slowly responsive, to be implemented (there is | that is effective, if slowly responsive, to be implemented (there is | |||
guidance on providing effective congestion control in Section 3.1 of | guidance on providing effective congestion control in Section 3.1 of | |||
[RFC8085]). | [RFC8085]). | |||
The format described in [RFC8888] seems sufficient for the needs of | The format described in [RFC8888] seems sufficient for the needs of | |||
congestion control feedback. There is little point optimising this | congestion control feedback. There is little point optimising this | |||
skipping to change at page 13, line 14 ¶ | skipping to change at page 13, line 14 ¶ | |||
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP | [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP | |||
Headers for Low-Speed Serial Links", RFC 2508, | Headers for Low-Speed Serial Links", RFC 2508, | |||
DOI 10.17487/RFC2508, February 1999, | DOI 10.17487/RFC2508, February 1999, | |||
<https://www.rfc-editor.org/info/rfc2508>. | <https://www.rfc-editor.org/info/rfc2508>. | |||
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, | [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, | |||
RFC 2914, DOI 10.17487/RFC2914, September 2000, | RFC 2914, DOI 10.17487/RFC2914, September 2000, | |||
<https://www.rfc-editor.org/info/rfc2914>. | <https://www.rfc-editor.org/info/rfc2914>. | |||
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. | ||||
Sooriyabandara, "TCP Performance Implications of Network | ||||
Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, | ||||
December 2002, <https://www.rfc-editor.org/info/rfc3449>. | ||||
[RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and | [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and | |||
P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with | P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with | |||
High Delay, Packet Loss and Reordering", RFC 3545, | High Delay, Packet Loss and Reordering", RFC 3545, | |||
DOI 10.17487/RFC3545, July 2003, | DOI 10.17487/RFC3545, July 2003, | |||
<https://www.rfc-editor.org/info/rfc3545>. | <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>. | |||
End of changes. 30 change blocks. | ||||
55 lines changed or deleted | 62 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/ |