idnits 2.17.1 draft-ietf-rmcat-rtp-cc-feedback-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 28, 2021) is 851 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-rfc793bis-20 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Perkins 3 Internet-Draft University of Glasgow 4 Intended status: Informational December 28, 2021 5 Expires: July 1, 2022 7 Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in 8 Interactive Multimedia Conferences 9 draft-ietf-rmcat-rtp-cc-feedback-08 11 Abstract 13 This memo discusses the types of congestion control feedback that it 14 is possible to send using the RTP Control Protocol (RTCP), and their 15 suitability of use in implementing congestion control for unicast 16 multimedia applications. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 1, 2022. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Possible Models for RTCP Feedback . . . . . . . . . . . . . . 3 54 3. What Feedback is Achievable With RTCP? . . . . . . . . . . . 5 55 3.1. Scenario 1: Voice Telephony . . . . . . . . . . . . . . . 5 56 3.2. Scenario 2: Point-to-Point Video Conference . . . . . . . 8 57 4. Discussion and Conclusions . . . . . . . . . . . . . . . . . 11 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 61 8. Informative References . . . . . . . . . . . . . . . . . . . 12 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 64 1. Introduction 66 The deployment of WebRTC systems [RFC8825] has resulted in high- 67 quality video conferencing seeing extremely wide use. To ensure the 68 stability of the network in the face of this use, WebRTC systems need 69 to use some form of congestion control for their RTP-based media 70 traffic [RFC2914], [RFC8085], [RFC8083], [RFC8834], allowing them to 71 adapt and adjust the media data they send to match changes in the 72 available network capacity. In addition to ensuring the stable 73 operation of the network, such adaptation is critical to ensuring a 74 good user experience, since it allows the sender to match the media 75 to the network capacity, rather than forcing the receiver to 76 compensate for uncontrolled packet loss when the available capacity 77 is exceeded. 79 To develop such congestion control, it is necessary to understand the 80 sort of congestion feedback that can be provided within the framework 81 of RTP [RFC3550] and the RTP Control Protocol (RTCP). It then 82 becomes possible to determine if this is sufficient for congestion 83 control, or if some form of RTP extension is needed. 85 This memo considers unicast congestion feedback that can be sent 86 using RTCP under the RTP/SAVPF profile [RFC5124] (the secure version 87 of the RTP/AVPF profile [RFC4585]). This profile was chosen as it 88 forms the basis for media transport in WebRTC [RFC8834] systems. 89 Nothing in this memo is specific to the secure version of the 90 profile, or to WebRTC, however. It is also assumed that the 91 congestion control feedback mechanism described in [RFC8888], and 92 common RTCP extensions for efficient feedback [RFC5506], [RFC8108], 93 [RFC8861], [RFC8861], and [RFC8872] are available. 95 2. Possible Models for RTCP Feedback 97 Several questions need to be answered when providing RTCP reception 98 quality feedback for congestion control purposes. These include: 100 o How often is feedback needed? 102 o How much overhead is acceptable? 104 o How much, and what, data does each report contain? 106 The key question is how often does the receiver need to send feedback 107 on the reception quality it is experiencing, and hence the congestion 108 state of the network? 110 Widely used transport protocols, such as TCP, send acknowledgements 111 frequently. For example, a TCP receiver will send an acknowledgement 112 at least once every 0.5 seconds or when new data equal to twice the 113 maximum segment size has been received [I-D.ietf-tcpm-rfc793bis]). 114 That has relatively low overhead when traffic is bidirectional and 115 acknowledgements can be piggybacked onto return path data packets. 116 It can also be acceptable, and can have reasonable overhead, to send 117 separate acknowledgement packets when those packets are much smaller 118 than data packets. 120 Frequent acknowledgements can become a problem, however, when there 121 is no return traffic on which to piggyback feedback, or if separate 122 feedback and data packets are sent and the feedback is similar in 123 size to the data being acknowledged. This can be the case for some 124 forms of media traffic, especially for voice over IP flows, leading 125 to high overhead when using a transport protocol that sends frequent 126 feedback. Approaches like in-network filtering of acknowledgements 127 can reduce the feedback frequency and overhead in some cases, but 128 this so-called "stretch-ACK" behaviour is non-standard and not 129 guaranteed. 131 Accordingly, when implementing congestion control for RTP-based 132 multimedia traffic, it might make sense to give the option of sending 133 congestion feedback less often than does TCP. For example, it might 134 be possible to send a feedback packet once per video frame, or every 135 few frames, or once per network round trip time (RTT). This could 136 still give sufficiently frequent feedback for the congestion control 137 loop to be stable and responsive while keeping the overhead 138 reasonable when the feedback cannot be piggybacked onto returning 139 data. In this case, it is important to note that RTCP can send much 140 more detailed feedback than simple acknowledgements. For example, if 141 it were useful, it could be possible to use an RTCP extended report 142 (XR) packet [RFC3611] to send feedback once per RTT comprising a 143 bitmap of lost and received packets, with reception times, over that 144 RTT. As long as feedback is sent frequently enough that the control 145 loop is stable, and the sender is kept informed when data leaves the 146 network (to provide an equivalent to ACK clocking in TCP), it is not 147 necessary to report on every packet at the instant it is received 148 (indeed, it is unlikely that a video codec can react instantly to a 149 rate change anyway, and there is little point in providing feedback 150 more often than the codec can adapt). 152 Reducing the feedback frequency compared to TCP will reduce feedback 153 overhead but will lead multimedia flows to adapt to congestion more 154 slowly than TCP, raising concerns about inter-flow fairness. Similar 155 concerns are noted in [RFC5348], and accordingly the congestion 156 control algorithm described therein aims for "reasonable" fairness 157 and a sending rate that is "generally within a factor of two" of that 158 TCP would achieve under the same conditions. It is to be noted, 159 however, that TCP exhibits inter-flow unfairness when flows with 160 differing round-trip times compete, and stretch acknowledgements due 161 to in-network traffic manipulation are not uncommon and also raise 162 fairness concerns. Implementations need to balance potential 163 unfairness against feedback overhead. 165 Generating and processing feedback consumes resources at the sender 166 and receiver. The feedback packets also incur forwarding costs, 167 contribute to link utilization, and can affect the timing of other 168 traffic on the network. This can affect performance on some types of 169 network, that can be impacted by the rate, timing, and size of 170 feedback packets, as well as by the overall volume of feedback bytes. 172 The amount of overhead due to congestion control feedback that is 173 considered acceptable has to be determined. RTCP feedback is sent in 174 separate packets to RTP data, and this has some cost in terms of 175 additional header overhead compared to protocols that piggyback 176 feedback on return path data packets. The RTP standards have long 177 said that a 5% overhead for RTCP traffic generally acceptable, while 178 providing the ability to change this fraction. Is this still the 179 case for congestion control feedback? Is there a desire to provide 180 more responsive feedback and congestion control, possibility with a 181 higher overhead? Or is lower overhead wanted, accepting that this 182 might reduce responsiveness of the congestion control algorithm? 184 Finally, the details of how much, and what, data is to be sent in 185 each report will affect the frequency and/or overhead of feedback. 186 There is a fundamental trade-off that the more frequently feedback 187 packets are sent, the less data can be included in each packet to 188 keep the overhead constant. Does the congestion control need high 189 rate but simple feedback (e.g., like TCP acknowledgements), or is it 190 acceptable to send more complex feedback less often? Is it useful 191 for the congestion control to receive frequent feedback, perhaps to 192 provide more accurate round-trip time estimates, or to provide 193 robustness in case feedback packets are lost, even if the media 194 sending rate cannot quickly be changed? Or is low-rate feedback, 195 resulting in slowly responsive changes the sending rate, acceptable? 196 Different combinations of congestion control algorithm and media 197 codec might require different trade-offs, and the correct trade-off 198 for interactive, self-paced, real-time multimedia traffic might not 199 be the same as that for TCP congestion control. 201 3. What Feedback is Achievable With RTCP? 203 The following sections illustrate how the RTCP congestion control 204 feedback report [RFC8888] can be used in different scenarios, and 205 illustrate the overheads of this approach. 207 3.1. Scenario 1: Voice Telephony 209 In many ways, point-to-point voice telephony is the simplest scenario 210 for congestion control, since there is only a single media stream to 211 control. It's complicated, however, by severe bandwidth constraints 212 on the feedback, to keep the overhead manageable. 214 Assume a two-party point-to-point voice-over-IP call, using RTP over 215 UDP/IP. A rate adaptive speech codec, such as Opus, is used, encoded 216 into RTP packets in frames of duration Tf seconds (Tf = 20ms in many 217 cases, but values up to 60ms are not uncommon). The congestion 218 control algorithm requires feedback every Nr frames, i.e., every Nr * 219 Tf seconds, to ensure effective control. Both parties in the call 220 send speech data or comfort noise with sufficient frequency that they 221 are counted as senders for the purpose of the RTCP reporting interval 222 calculation. 224 RTCP feedback packets can be full, compound, RTCP feedback packets, 225 or non-compound RTCP packets [RFC5506]. A compound RTCP packet is 226 sent once for every Nnc non-compound RTCP packets. 228 Compound RTCP packets contain a Sender Report (SR) packet, a Source 229 Description (SDES) packet, and an RTP Congestion Control Feedback 230 (CCFB) packet [RFC8888]. Non-compound RTCP packets contain only the 231 CCFB packet. Since each participant sends only a single RTP media 232 stream, the extensions for RTCP report aggregation [RFC8108] and 233 reporting group optimisation [RFC8861] are not used. 235 Within each compound RTCP packet, the SR packet will contain a sender 236 information block (28 octets) and a single reception report block (24 237 octets), for a total of 52 octets. A minimal SDES packet will 238 contain a header (4 octets) and a single chunk containing an SSRC (4 239 octets) and a CNAME item, and if the recommendations for choosing the 240 CNAME [RFC7022] are followed, the CNAME item will comprise a 2 octet 241 header, 16 octets of data, and 2 octets of padding, for a total SDES 242 packet size of 28 octets. The CCFB packets contains an RTCP header 243 and SSRC (8 octets), a report timestamp (4 octets), the SSRC, 244 beginning and ending sequence numbers (8 octets), and 2*Nr octets of 245 reports, for a total of 20 + 2*Nr octets. The compound Secure RTCP 246 packet will include 4 octets of trailer followed by an 80 bit (10 247 octet) authentication tag if HMAC-SHA1 authentication is used. If 248 IPv4 is used, with no IP options, the UDP/IP header will be 28 octets 249 in size. This gives a total compound RTCP packet size of Sc = 142 + 250 2*Nr octets. 252 The non-compound RTCP packets will comprise just the CCFB packet, 253 SRTCP trailer and authentication tag, and a UDP/IP header. It can be 254 seen that these packets will be Snc = 62 + 2*Nr octets in size. 256 The RTCP reporting interval calculation ([RFC3550], Section 6.2) for 257 a two-party session where both participants are senders, reduces to: 259 Trtcp = n * Srtcp / Brtcp 261 where Srtcp = (Sc + Nnc * Snc)/(1 + Nnc) is the average RTCP packet 262 size in octets, Brtcp is the bandwidth allocated to RTCP in octets 263 per second, and n is the number of participants in the RTP session 264 (in this scenario, n = 2). 266 To ensure an RTCP report containing congestion control feedback is 267 sent after every Nr frames of audio, it is necessary to set the RTCP 268 reporting interval Trtcp = Nr * Tf, which when substituted into the 269 previous gives Nr * Tf = n * Srtcp/Brtcp. Solving this to give the 270 RTCP bandwidth, Brtcp, and expanding the definition of Srtcp gives: 272 Brtcp = (n * (Sc + Nnc * Snc))/(Nr * Tf * (1 + Nnc)). 274 If we assume every report is a compound RTCP packet (i.e., Nnc = 0), 275 the frame duration Tf = 20ms, and an RTCP report is sent for every 276 second frame (i.e., 25 RTCP reports per second), this gives an RTCP 277 feedback bandwidth, Brtcp = 57kbps. Increasing the frame duration, 278 or reducing the frequency of reports, will reduce the RTCP bandwidth 279 as shown in Table 1. 281 +--------------+-------------+----------------+ 282 | Tf (seconds) | Nr (frames) | rtcp_bw (kbps) | 283 +--------------+-------------+----------------+ 284 | 0.020 | 2 | 57.0 | 285 | 0.020 | 4 | 29.3 | 286 | 0.020 | 8 | 15.4 | 287 | 0.020 | 16 | 8.5 | 288 | 0.060 | 2 | 19.0 | 289 | 0.060 | 4 | 9.8 | 290 | 0.060 | 8 | 5.1 | 291 | 0.060 | 16 | 2.8 | 292 +--------------+-------------+----------------+ 294 Table 1: RTCP bandwidth needed for VoIP feedback 296 The final row of Table 1 (60ms frames, report every 16 frames) sends 297 RTCP reports once per second, giving an RTCP bandwidth overhead of 298 2.8kbps. 300 The overhead can be reduced by sending some reports in non-compound 301 RTCP packets [RFC5506]. For example, if we alternate compound and 302 non-compound RTCP packets, i.e., Nnc = 1, the calculation gives the 303 results shown in Table 2. 305 +--------------+-------------+----------------+ 306 | Tf (seconds) | Nr (frames) | rtcp_bw (kbps) | 307 +--------------+-------------+----------------+ 308 | 0.020 | 2 | 41.4 | 309 | 0.020 | 4 | 21.5 | 310 | 0.020 | 8 | 11.5 | 311 | 0.020 | 16 | 6.5 | 312 | 0.060 | 2 | 13.8 | 313 | 0.060 | 4 | 7.2 | 314 | 0.060 | 8 | 3.8 | 315 | 0.060 | 16 | 2.2 | 316 +--------------+-------------+----------------+ 318 Table 2: Required RTCP bandwidth for VoIP feedback (alternating 319 compound and non-compound reports) 321 The RTCP bandwidth needed for 60ms frames, reporting every 16 frames 322 (once per second), can be seen to drop to 2.2kbps. This calculation 323 can be repeated for other patterns of compound and non-compound RTCP 324 packets, feedback frequency, and frame duration, as needed. 326 Note: To achieve the RTCP transmission intervals above the RTP/SAVPF 327 profile with T_rr_interval=0 is used, since even when using the 328 reduced minimal transmission interval, the RTP/SAVP profile would 329 only allow sending RTCP at most every 0.11s (every third frame of 330 video). Using RTP/SAVPF with T_rr_interval=0 however is capable of 331 fully utilizing the configured 5% RTCP bandwidth fraction. 333 3.2. Scenario 2: Point-to-Point Video Conference 335 Consider a point-to-point video call between two end systems. There 336 will be four RTP flows in this scenario, two audio and two video, 337 with all four flows being active for essentially all the time (the 338 audio flows will likely use voice activity detection and comfort 339 noise to reduce the packet rate during silent periods, but this does 340 not cause the transmissions to stop). 342 Assume all four flows are sent in a single RTP session, each using a 343 separate SSRC. The RTCP reports from the co-located audio and video 344 SSRCs at each end point are aggregated [RFC8108], the optimisations 345 in [RFC8861] are used, and RTCP congestion control feedback is sent 346 [RFC8888]. 348 When all members are senders, the RTCP reporting interval calculation 349 in Section 6.2 and 6.3 of [RFC3550] and [RFC4585] reduces to: 351 Trtcp = n * Srtcp / Brtcp 353 where n is the number of members in the session, Srtcp is the average 354 RTCP packet size in octets, and the Brtcp is the RTCP bandwidth in 355 octets per second. 357 The average RTCP packet size, Srtcp, depends on the amount of 358 feedback sent in each RTCP packet, on the number of members in the 359 session, on the size of source description (RTCP SDES) information 360 sent, and on the amount of congestion control feedback sent in each 361 packet. 363 As a baseline, each RTCP packet will be a compound RTCP packet that 364 contains an aggregate of a compound RTCP packet generated by the 365 video SSRC and a compound RTCP packet generated by the audio SSRC. 366 When the RTCP reporting group extensions are used, one of these SSRCs 367 will be a reporting SSRC, to which the other SSRC will have delegated 368 its reports. No non-compound RTCP packets are sent. 370 The aggregated compound RTCP packet from the non-reporting SSRC will 371 contain an RTCP SR packet, an RTCP SDES packet, and an RTCP RGRS 372 packet. The RTCP SR packet contains the 28 octet header and sender 373 information, but no report blocks (since the reporting is delegated). 374 The RTCP SDES packet will comprise a header (4 octets), originating 375 SSRC (4 octets), a CNAME chunk, a terminating chunk, and any padding. 376 If the CNAME follows [RFC7022] and [RFC8834] it will be 18 octets in 377 size, and will need 1 octet of padding, making the SDES packet 28 378 octets in size. The RTCP RGRS packet will be 12 octets in size. 379 This gives a total of 28 + 28 + 12 = 68 octets. 381 The aggregated compound RTCP packet from the reporting SSRC will 382 contain an RTCP SR packet, an RTCP SDES packet, and an RTCP 383 congestion control feedback packet. The RTCP SR packet will contain 384 two report blocks, one for each of the remote SSRCs (the report for 385 the other local SSRC is suppressed by the reporting group extension), 386 for a total of 28 + (2 * 24) = 76 octets. The RTCP SDES packet will 387 comprise a header (4 octets), originating SSRC (4 octets), a CNAME 388 chunk, an RGRP chunk, a terminating chunk, and any padding. If the 389 CNAME follows [RFC7022] and [RFC8834] it will be 18 octets in size. 390 The RGRP chunk similarly comprises 18 octets, and 3 octets of padding 391 are needed, for a total of 48 octets. The RTCP congestion control 392 feedback (CCFB) report comprises an 8 octet RTCP header and SSRC, a 4 393 octet report timestamp, and for each of the remote audio and video 394 SSRCs, an 8 octet report header, and 2 octets per packet reported 395 upon, and padding to a 4 octet boundary if needed; that is 8 + 4 + 8 396 + (2 * Nv) + 8 + (2 * Na) where Nv is the number of video packets per 397 report, and Na is the number of audio packets per report. 399 The complete compound RTCP packet contains the RTCP packets from both 400 the reporting and non-reporting SSRCs, an SRTCP trailer and 401 authentication tag, and a UDP/IPv4 header. The size of this RTCP 402 packet is therefore: 262 + (2 * Nv) + (2 * Na) octets. Since the 403 aggregate RTCP packet contains reports from two SSRCs, the RTCP 404 packet size is halved before use [RFC8108]. Accordingly, the size of 405 the RTCP packets is: 407 Srtcp = (262 + (2 * Nv) + (2 * Na)) / 2 409 How many RTP packets does the RTCP XR congestion control feedback 410 packet included in these compound RTCP packets report on? That is, 411 what are the values of Nv and Na? This depends on the RTCP reporting 412 interval, Trtcp, the video bit rate and frame rate, Rf, the audio bit 413 rate and framing interval, and whether the receiver chooses to send 414 congestion control feedback in each RTCP packet it sends. 416 To simplify the calculation, assume it is desired to send one RTCP 417 report for each frame of video received (i.e., Trtcp = 1 / Rf) and to 418 include a congestion control feedback packet in each report. Assume 419 that video has constant bit rate and frame rate, and that each frame 420 of packet has to fit into a 1500 octet MTU. Further, assume that the 421 audio takes negligible bandwidth, and that the audio framing interval 422 can be varied within reasonable bounds, so that an integral number of 423 audio frames align with video frame boundaries. 425 Table 3 shows the resulting values of Nv and Na, the number of video 426 and audio packets covered by each congestion control feedback report, 427 for a range of data rates and video frame rates, assuming congestion 428 control feedback is sent once per video frame. The table also shows 429 the result of inverting the RTCP reporting interval calculation to 430 find the corresponding RTCP bandwidth, Brtcp. The RTCP bandwidth is 431 given in kbps and as a fraction of the data rate. 433 It can be seen that, for example, with a date rate of 1024 kbps and 434 video sent at 30 frames-per-second, the RTCP congestion control 435 feedback report sent for each video frame will include reports on 3 436 video packets and 2 audio packets. The RTCP bandwidth needed to 437 sustain this reporting rate is 127.5kbps (12% of the data rate). 438 This assumes an audio framing interval of 16.67ms, so that two audio 439 packets are sent for each video frame. 441 +---------+----------+--------------+--------------+----------------+ 442 | Data | Video | Video | Audio | Required RTCP | 443 | Rate | Frame | Packets per | Packets per | bandwidth: | 444 | (kbps) | Rate: Rf | Report: Nv | Report: Na | Brtcp (kbps) | 445 +---------+----------+--------------+--------------+----------------+ 446 | 100 | 8 | 1 | 6 | 34.5 (34%) | 447 | 200 | 16 | 1 | 3 | 67.5 (33%) | 448 | 350 | 30 | 1 | 2 | 125.6 (35%) | 449 | 700 | 30 | 2 | 2 | 126.6 (18%) | 450 | 700 | 60 | 1 | 1 | 249.4 (35%) | 451 | 1024 | 30 | 3 | 2 | 127.5 (12%) | 452 | 1400 | 60 | 2 | 1 | 251.2 (17%) | 453 | 2048 | 30 | 6 | 2 | 130.3 ( 6%) | 454 | 2048 | 60 | 3 | 1 | 253.1 (12%) | 455 | 4096 | 30 | 12 | 2 | 135.9 ( 3%) | 456 | 4096 | 60 | 6 | 1 | 258.8 ( 6%) | 457 +---------+----------+--------------+--------------+----------------+ 459 Table 3: Required RTCP bandwidth, reporting on every frame 461 Use of reduced size RTCP [RFC5506] would allow the SR and SDES 462 packets to be omitted from some reports. These "non-compound" 463 (actually, compound but reduced size in this case) RTCP packets would 464 contain an RTCP RGRS packet from the non-reporting SSRC, and an RTCP 465 SDES RGRP packet and a congestion control feedback packet from the 466 reporting SSRC. This will be 12 + 28 + 12 + 8 + 2*Nv + 8 + 2*Na 467 octets, plus the SRTCP trailer and authentication tag, and a UDP/IP 468 header. That is, the size of the non-compound packets would be (110 469 + 2*Nv + 2*Na)/2 octets. Repeating the analysis above, but 470 alternating compound and non-compound reports gives results as shown 471 in Table 4. 473 +---------+----------+--------------+--------------+----------------+ 474 | Data | Video | Video | Audio | Required RTCP | 475 | Rate | Frame | Packets per | Packets per | bandwidth: | 476 | (kbps) | Rate: Rf | Report: Nv | Report: Na | Brtcp (kbps) | 477 +---------+----------+--------------+--------------+----------------+ 478 | 100 | 8 | 1 | 6 | 24.1 (24%) | 479 | 200 | 16 | 1 | 3 | 46.8 (23%) | 480 | 350 | 30 | 1 | 2 | 86.7 (24%) | 481 | 700 | 30 | 2 | 2 | 87.7 (12%) | 482 | 700 | 60 | 1 | 1 | 171.6 (24%) | 483 | 1024 | 30 | 3 | 2 | 88.6 ( 8%) | 484 | 1400 | 60 | 2 | 1 | 173.4 (12%) | 485 | 2048 | 30 | 6 | 2 | 91.4 ( 4%) | 486 | 2048 | 60 | 3 | 1 | 175.3 ( 8%) | 487 | 4096 | 30 | 12 | 2 | 97.0 ( 2%) | 488 | 4096 | 60 | 6 | 1 | 180.9 ( 4%) | 489 +---------+----------+--------------+--------------+----------------+ 491 Table 4: Required RTCP bandwidth, reporting on every frame, with 492 reduced-size reports 494 The use of reduced-size RTCP gives a noticeable reduction in the 495 needed RTCP bandwidth, and can be combined with reporting every few 496 frames rather than every frames. Overall, it is clear that the RTCP 497 overhead can be reasonable across the range of data and frame rates, 498 if RTCP is configured carefully. 500 4. Discussion and Conclusions 502 Practical systems will generally send some non-media traffic on the 503 same path as the media traffic. This can include STUN/TURN packets 504 to keep-alive NAT bindings [RFC8445], WebRTC Data Channel packets 505 [RFC8831], etc. Such traffic also needs congestion control, but the 506 means by which this is achieved is out of scope of this memo. 508 RTCP as it is currently specified cannot be used to send per-packet 509 congestion feedback with reasonable overhead. 511 RTCP can, however, be used to send congestion feedback on each frame 512 of video sent, provided the session bandwidth exceeds a couple of 513 megabits per second (the exact rate depending on the number of 514 session participants, the RTCP bandwidth fraction, and what RTCP 515 extensions are enabled, and how much detail of feedback is needed). 516 For lower rate sessions, the overhead of reporting on every frame 517 becomes high, but can be reduced to something reasonable by sending 518 reports once per N frames (e.g., every second frame), or by sending 519 non-compound RTCP reports in between the regular reports. 521 If it is desired to use RTCP in something close to it's current form 522 for congestion feedback in WebRTC, the multimedia congestion control 523 algorithm needs be designed to work with feedback sent every few 524 frames, since that fits within the limitations of RTCP. The provided 525 feedback will be more detailed than just an acknowledgement, however, 526 and will provide a loss bitmap, relative arrival time, and received 527 ECN marks, for each packet sent. This will allow congestion control 528 that is effective, if slowly responsive, to be implemented (there is 529 guidance on providing effective congestion control in Section 3.1 of 530 [RFC8085]). 532 The format described in [RFC8888] seems sufficient for the needs of 533 congestion control feedback. There is little point optimising this 534 format: the main overhead comes from the UDP/IP headers and the other 535 RTCP packets included in the compound packets, and can be lowered by 536 using the [RFC5506] extensions and sending reports less frequently. 537 The use of header compression [RFC2508], [RFC3545], [RFC5795] can 538 also be beneficial. 540 Further study of the scenarios of interest is needed, to ensure that 541 the analysis presented is applicable to other media topologies, and 542 to sessions with different data rates and sizes of membership. 544 5. Security Considerations 546 An attacker that can modify or spoof RTCP congestion control feedback 547 packets can manipulate the sender behaviour to cause denial of 548 service. This can be prevented by authentication and integrity 549 protection of RTCP packets, for example using the secure RTP profile 550 [RFC3711][RFC5124], or by other means as discussed in [RFC7201]. 552 6. IANA Considerations 554 There are no actions for IANA. 556 7. Acknowledgements 558 Thanks to Magnus Westerlund, Ingemar Johansson, Gorry Fairhurst, and 559 the members of the RMCAT feedback design team for their feedback. 561 8. Informative References 563 [I-D.ietf-tcpm-rfc793bis] 564 Eddy, W., "Transmission Control Protocol (TCP) 565 Specification", draft-ietf-tcpm-rfc793bis-20 (work in 566 progress), January 2021. 568 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 569 Headers for Low-Speed Serial Links", RFC 2508, 570 DOI 10.17487/RFC2508, February 1999, 571 . 573 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 574 RFC 2914, DOI 10.17487/RFC2914, September 2000, 575 . 577 [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and 578 P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with 579 High Delay, Packet Loss and Reordering", RFC 3545, 580 DOI 10.17487/RFC3545, July 2003, 581 . 583 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 584 Jacobson, "RTP: A Transport Protocol for Real-Time 585 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 586 July 2003, . 588 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 589 "RTP Control Protocol Extended Reports (RTCP XR)", 590 RFC 3611, DOI 10.17487/RFC3611, November 2003, 591 . 593 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 594 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 595 RFC 3711, DOI 10.17487/RFC3711, March 2004, 596 . 598 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 599 "Extended RTP Profile for Real-time Transport Control 600 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 601 DOI 10.17487/RFC4585, July 2006, 602 . 604 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 605 Real-time Transport Control Protocol (RTCP)-Based Feedback 606 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 607 2008, . 609 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 610 Friendly Rate Control (TFRC): Protocol Specification", 611 RFC 5348, DOI 10.17487/RFC5348, September 2008, 612 . 614 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 615 Real-Time Transport Control Protocol (RTCP): Opportunities 616 and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 617 2009, . 619 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 620 Header Compression (ROHC) Framework", RFC 5795, 621 DOI 10.17487/RFC5795, March 2010, 622 . 624 [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, 625 "Guidelines for Choosing RTP Control Protocol (RTCP) 626 Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, 627 September 2013, . 629 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 630 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 631 . 633 [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: 634 Circuit Breakers for Unicast RTP Sessions", RFC 8083, 635 DOI 10.17487/RFC8083, March 2017, 636 . 638 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 639 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 640 March 2017, . 642 [RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, 643 "Sending Multiple RTP Streams in a Single RTP Session", 644 RFC 8108, DOI 10.17487/RFC8108, March 2017, 645 . 647 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 648 Connectivity Establishment (ICE): A Protocol for Network 649 Address Translator (NAT) Traversal", RFC 8445, 650 DOI 10.17487/RFC8445, July 2018, 651 . 653 [RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for 654 Browser-Based Applications", RFC 8825, 655 DOI 10.17487/RFC8825, January 2021, 656 . 658 [RFC8831] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 659 Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021, 660 . 662 [RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport 663 and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834, 664 January 2021, . 666 [RFC8861] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, 667 "Sending Multiple RTP Streams in a Single RTP Session: 668 Grouping RTP Control Protocol (RTCP) Reception Statistics 669 and Other Feedback", RFC 8861, DOI 10.17487/RFC8861, 670 January 2021, . 672 [RFC8872] Westerlund, M., Burman, B., Perkins, C., Alvestrand, H., 673 and R. Even, "Guidelines for Using the Multiplexing 674 Features of RTP to Support Multiple Media Streams", 675 RFC 8872, DOI 10.17487/RFC8872, January 2021, 676 . 678 [RFC8888] Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP 679 Control Protocol (RTCP) Feedback for Congestion Control", 680 RFC 8888, DOI 10.17487/RFC8888, January 2021, 681 . 683 Author's Address 685 Colin Perkins 686 University of Glasgow 687 School of Computing Science 688 Glasgow G12 8QQ 689 United Kingdom 691 Email: csp@csperkins.org