idnits 2.17.1 draft-ietf-rmcat-rtp-cc-feedback-04.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 (July 1, 2018) is 2126 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-avtcore-cc-feedback-message-01 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 July 1, 2018 5 Expires: January 2, 2019 7 RTP Control Protocol (RTCP) Feedback for Congestion Control in 8 Interactive Multimedia Conferences 9 draft-ietf-rmcat-rtp-cc-feedback-04 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 http://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 January 2, 2019. 35 Copyright Notice 37 Copyright (c) 2018 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 (http://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 . . . . . . . . . . . . . . 2 54 3. What Feedback is Achievable With RTCP? . . . . . . . . . . . 4 55 3.1. Scenario 1: Voice Telephony . . . . . . . . . . . . . . . 4 56 3.2. Scenario 2: Point-to-Point Video Conference . . . . . . . 6 57 3.3. Scenario 3: Group Video Conference . . . . . . . . . . . 10 58 3.4. Scenario 4: Screen Sharing . . . . . . . . . . . . . . . 10 59 4. Discussion and Conclusions . . . . . . . . . . . . . . . . . 10 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 63 8. Informative References . . . . . . . . . . . . . . . . . . . 11 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 66 1. Introduction 68 The coming deployment of WebRTC systems raises the prospect that high 69 quality video conferencing will see extremely wide use. To ensure 70 the stability of the network in the face of this use, WebRTC systems 71 will need to use some form of congestion control for their RTP-based 72 media traffic. To develop such congestion control, it is necessary 73 to understand the sort of congestion feedback that can be provided 74 within the framework of RTP [RFC3550] and the RTP Control Protocol 75 (RTCP). It then becomes possible to determine if this is sufficient 76 for congestion control, or if some form of RTP extension is needed. 78 This memo considers the congestion feedback that can be sent using 79 RTCP under the RTP/SAVPF profile [RFC5124] (the secure version of the 80 RTP/AVPF profile [RFC4585]). This profile was chosen as it forms the 81 basis for media transport in WebRTC [I-D.ietf-rtcweb-rtp-usage] 82 systems. Nothing in this memo is specific to the secure version of 83 the profile, or to WebRTC, however. 85 2. Possible Models for RTCP Feedback 87 Several questions need to be answered when providing RTCP reception 88 quality feedback for congestion control purposes. These include: 90 o How often is feedback needed? 92 o How much overhead is acceptable? 94 o How much, and what, data does each report contain? 96 The key question is how often does the receiver need to send feedback 97 on the reception quality it is experiencing, and hence the congestion 98 state of the network? Traditional congestion control protocols, such 99 as TCP, send acknowledgements with every packet (or, at least, every 100 couple of packets). That is straight-forward and low overhead when 101 traffic is bidirectional and acknowledgements can be piggybacked onto 102 return path data packets. It can also be acceptable, and can have 103 reasonable overhead, to send separate acknowledgement packets when 104 those packets are much smaller than data packets. It becomes a 105 problem, however, when there is no return traffic on which to 106 piggyback acknowledgements, and when acknowledgements are similar in 107 size to data packets; this can be the case for some forms of media 108 traffic, especially for voice over IP (VoIP) flows, but less so for 109 video. 111 When considering multimedia traffic, it might make sense to consider 112 less frequent feedback. For example, it might be possible to send a 113 feedback packet once per video frame, or every few frames, or once 114 per network round trip time (RTT). This could still give 115 sufficiently frequent feedback for the congestion control loop to be 116 stable and responsive while keeping the overhead reasonable when the 117 feedback cannot be piggybacked onto returning data. In this case, it 118 is important to note that RTCP can send much more detailed feedback 119 than simple acknowledgements. For example, if it were useful, it 120 could be possible to use an RTCP extended report (XR) packet 121 [RFC3611] to send feedback once per RTT comprising a bitmap of lost 122 and received packets, with reception times, over that RTT. As long 123 as feedback is sent frequently enough that the control loop is 124 stable, and the sender is kept informed when data leaves the network 125 (to provide an equivalent to ACK clocking in TCP), it is not 126 necessary to report on every packet at the instant it is received 127 (indeed, it is unlikely that a video codec can react instantly to a 128 rate change anyway, and there is little point in providing feedback 129 more often than the codec can adapt). 131 The amount of overhead due to congestion control feedback that is 132 considered acceptable has to be determined. RTCP data is sent in 133 separate packets to RTP data, and this has some cost in terms of 134 additional header overhead compared to protocols that piggyback 135 feedback on return path data packets. The RTP standards have long 136 said that a 5% overhead for RTCP traffic generally acceptable, while 137 providing the ability to change this fraction. Is this still the 138 case for congestion control feedback? Or is there a desire to either 139 see more responsive feedback and congestion control, possibility with 140 a higher overhead, or is lower overhead wanted, accepting that this 141 might reduce responsiveness of the congestion control algorithm? 143 Finally, the details of how much, and what, data is to be sent in 144 each report will affect the frequency and/or overhead of feedback. 145 There is a fundamental trade-off that the more frequently feedback 146 packets are sent, the less data can be included in each packet to 147 keep the overhead constant. Does the congestion control need high 148 rate but simple feedback (e.g., like TCP acknowledgements), or is it 149 acceptable to send more complex feedback less often? 151 3. What Feedback is Achievable With RTCP? 153 3.1. Scenario 1: Voice Telephony 155 In many ways, point-to-point voice telephony is the simplest scenario 156 for congestion control, since there is only a single media stream to 157 control. It's complicated, however, by severe bandwidth constraints 158 on the feedback, to keep the overhead manageable. 160 Assume a two-party point-to-point voice-over-IP call, using RTP over 161 UDP/IP. A rate adaptive speech codec, such as Opus, is used, encoded 162 into RTP packets in frames of duration Tf seconds (Tf = 20ms in many 163 cases, but values up to 60ms are not uncommon). The congestion 164 control algorithm requires feedback every Nr frames, i.e., every Nr * 165 Tf seconds, to ensure effective control. Both parties in the call 166 send speech data or comfort noise with sufficient frequency that they 167 are counted as senders for the purpose of the RTCP reporting interval 168 calculation. 170 RTCP feedback packets can be full, compound, RTCP feedback packets, 171 or non-compound RTCP packets. A compound RTCP packet is sent once 172 for every Nnc non-compound RTCP packets. 174 Compound RTCP packets contain a Sender Report (SR) packet and a 175 Source Description (SDES) packet, and an RTP Congestion Control 176 Feedback (CCFB) packet [I-D.ietf-avtcore-cc-feedback-message]. Non- 177 compound RTCP packets contain only the CCFB packet. Since each 178 participant sends only a single media stream, the extensions for RTCP 179 report aggregation [RFC8108] and reporting group optimisation 180 [I-D.ietf-avtcore-rtp-multi-stream-optimisation] are not used. 182 Within each compound RTCP packet, the SR packet will contain a sender 183 information block (28 octets) and a single reception report block (24 184 octets), for a total of 52 octets. A minimal SDES packet will 185 contain a header (4 octets) and a single chunk containing an SSRC (4 186 octets) and a CNAME item, and if the recommendations for choosing the 187 CNAME [RFC7022] are followed, the CNAME item will comprise a 2 octet 188 header, 16 octets of data, and 2 octets of padding, for a total SDES 189 packet size of 28 octets. The CCFB packets contains an RTCP header 190 and SSRC (8 octets), a report timestamp (4 octets), the SSRC, 191 beginning and ending sequence numbers (8 octets), and 2*Nr octets of 192 reports, for a total of 20 + 2*Nr octets. If IPv4 is used, with no 193 IP options, the UDP/IP header will be 28 octets in size. This gives 194 a total compound RTCP packet size of Sc = 128 + 2*Nr octets. 196 The non-compound RTCP packets will comprise just the CCFB packet with 197 a UDP/IP header. It can be seen that these packets will be Snc = 48 198 + 2*Nr octets in size. 200 The RTCP reporting interval calculation ([RFC3550], Section 6.2) for 201 a two-party session where both participants are senders, reduces to 202 Trtcp = n * Srtcp/Brtcp where Srtcp = (Sc + Nnc * Snc)/(1 + Nnc) is 203 the average RTCP packet size in octets, Brtcp is the bandwidth 204 allocated to RTCP in octets per second, and n is the number of 205 participants (n=2 in this scenario). 207 To ensure a report is sent every Nr frames, it is necessary to set 208 the RTCP reporting interval Trtcp = Nr * Tf, which when substituted 209 into the previous gives Nr * Tf = n * Srtcp/Brtcp. 211 Solving for the RTCP bandwidth, Brtcp, and expanding the definition 212 of Srtcp gives Brtcp = (n * (Sc + Nnc * Snc))/(Nr * Tf * (1 + Nnc)). 214 If we assume every report is a compound RTCP packet (i.e., Nnc = 0), 215 the frame duration Tf = 20ms, and an RTCP report is sent for every 216 second frame (i.e., 25 RTCP reports per second), this expression 217 gives the needed RTCP bandwidth Brtcp = 51.6kbps. Increasing the 218 frame duration, or reducing the frequency of reports, reduces the 219 RTCP bandwidth, as shown below: 221 +--------------+-------------+----------------+ 222 | Tf (seconds) | Nr (frames) | rtcp_bw (kbps) | 223 +--------------+-------------+----------------+ 224 | 20ms | 2 | 51.6 | 225 | 20ms | 4 | 26.6 | 226 | 20ms | 8 | 14.1 | 227 | 20ms | 16 | 7.8 | 228 | 60ms | 2 | 17.2 | 229 | 60ms | 4 | 8.9 | 230 | 60ms | 8 | 4.7 | 231 | 60ms | 16 | 2.6 | 232 +--------------+-------------+----------------+ 234 Table 1: Required RTCP bandwidth for VoIP feedback 236 The final row of the table (60ms frames, report every 16 frames) 237 sends RTCP reports once per second, giving an RTCP bandwidth of 238 2.6kbps. 240 The overhead can be reduced by sending some reports in non-compound 241 RTCP packets [RFC5506]. For example, if we alternate compound and 242 non-compound RTCP packets, i.e., Nnc = 1, the calculation gives: 244 +--------------+-------------+----------------+ 245 | Tf (seconds) | Nr (frames) | rtcp_bw (kbps) | 246 +--------------+-------------+----------------+ 247 | 20ms | 2 | 35.9 | 248 | 20ms | 4 | 18.8 | 249 | 20ms | 8 | 10.2 | 250 | 20ms | 16 | 5.9 | 251 | 60ms | 2 | 12.0 | 252 | 60ms | 4 | 6.2 | 253 | 60ms | 8 | 3.4 | 254 | 60ms | 16 | 2.0 | 255 +--------------+-------------+----------------+ 257 Table 2: Required RTCP bandwidth for VoIP feedback (alternating 258 compound and non-compound reports) 260 The RTCP bandwidth needed for 60ms frames, reporting every 16 frames 261 (once per second), can be seen to drop to 2.0kbps. This calculation 262 can be repeated for other patterns of compound and non-compound RTCP 263 packets, feedback frequency, and frame duration, as needed. 265 Note: To achieve the RTCP transmission intervals above the RTP/SAVPF 266 profile with T_rr_interval=0 is used, since even when using the 267 reduced minimal transmission interval, the RTP/SAVP profile would 268 only allow sending RTCP at most every 0.11s (every third frame of 269 video). Using RTP/SAVPF with T_rr_interval=0 however is capable of 270 fully utilizing the configured 5% RTCP bandwidth fraction. 272 3.2. Scenario 2: Point-to-Point Video Conference 274 Consider a point to point video call between two end systems. There 275 will be four RTP flows in this scenario, two audio and two video, 276 with all four flows being active for essentially all the time (the 277 audio flows will likely use voice activity detection and comfort 278 noise to reduce the packet rate during silent periods, and does not 279 cause the transmissions to stop). 281 Assume all four flows are sent in a single RTP session, each using a 282 separate SSRC; the RTCP reports from co-located audio and video SSRCs 283 at each end point are aggregated [RFC8108]; the optimisations in 284 [I-D.ietf-avtcore-rtp-multi-stream-optimisation] are used; and 285 congestion control feedback is sent 286 [I-D.ietf-avtcore-cc-feedback-message]. 288 When all members are senders, the RTCP timing rules in Section 6.2 289 and 6.3 of [RFC3550] and [RFC4585] reduce to: 291 rtcp_interval = avg_rtcp_size * n / rtcp_bw 293 where n is the number of members in the session, the avg_rtcp_size is 294 measured in octets, and the rtcp_bw is the bandwidth available for 295 RTCP, measured in octets per second (this will typically be 5% of the 296 session bandwidth). 298 The average RTCP size will depend on the amount of feedback that is 299 sent in each RTCP packet, on the number of members in the session, on 300 the size of source description (RTCP SDES) information sent, and on 301 the amount of congestion control feedback sent in each packet. 303 As a baseline, each RTCP packet will be a compound RTCP packet that 304 contains an aggregate of a compound RTCP packet generated by the 305 video SSRC and a compound RTCP packet generated by the audio SSRC. 306 Since the RTCP reporting group extensions are used, one of these 307 SSRCs will be a reporting SSRC, and the other will delegate its 308 reports to that. 310 The aggregated compound RTCP packet from the non-reporting SSRC will 311 contain an RTCP SR packet, an RTCP SDES packet, and an RTCP RGRS 312 packet. The RTCP SR packet contains the 28 octet header and sender 313 information, but no report blocks (since the reporting is delegated). 314 The RTCP SDES packet will comprise a header (4 octets), originating 315 SSRC (4 octets), a CNAME chunk, a terminating chunk, and any padding. 316 If the CNAME follows [RFC7022] and [I-D.ietf-rtcweb-rtp-usage] it 317 will be 18 octets in size, and will need 1 octet of padding, making 318 the SDES packet 28 octets in size. The RTCP RGRS packet will be 12 319 octets in size. This gives a total of 28 + 28 + 12 = 68 octets. 321 The aggregated compound RTCP packet from the reporting SSRC will 322 contain an RTCP SR packet, an RTCP SDES packet, and an RTCP 323 congestion control feedback packet. The RTCP SR packet will contain 324 two report blocks, one for each of the remote SSRCs (the report for 325 the other local SSRC is suppressed by the reporting group extension), 326 for a total of 28 + (2 * 24) = 76 octets. The RTCP SDES packet will 327 comprise a header (4 octets), originating SSRC (4 octets), a CNAME 328 chunk, an RGRP chunk, a terminating chunk, and any padding. If the 329 CNAME follows [RFC7022] and [I-D.ietf-rtcweb-rtp-usage] it will be 18 330 octets in size. The RGRP chunk similarly comprises 18 octets, and 3 331 octets of padding are needed, for a total of 48 octets. The RTCP 332 congestion control feedback (CCFB) report comprises an 8 octet RTCP 333 header and SSRC,an 4 report timestamp, then for each of the remote 334 audio and video SSRCs, an 8 octet report header, and 2 octets per 335 packet reported upon, and padding to a 4 octet boundary if needed; 336 that is 8 + 4 + 8 + (2 * Nv) + 8 + (2 * Na) where Nv is the number of 337 video packets per report, and Na is the number of audio packets per 338 report. 340 The complete compound RTCP packet contains the RTCP packets from both 341 the reporting and non-reporting SSRCs, an SRTP authentication tag, 342 and a UDP/IPv4 header. The size of this RTCP packet is therefore: 343 248 + (2 * Nv) + (2 * Na) octets. Since the aggregate RTCP packet 344 contains reports from two SSRCs, the RTCP packet size is halved 345 before use [RFC8108]. Accordingly, we define Sc = (248 + (2 * Nv) + 346 (2 * Na))/2 for this scenario. 348 How many packets does the RTCP XR congestion control feedback packet 349 report on? This is obviously highly dependent on the choice of codec 350 and encoding parameters, and might be quite bursty if the codec sends 351 I-frames from which later frames are predicted. For now though, 352 assume constant rate media with an MTU around 1500 octets, with 353 reports for both audio and video being aggregated and sent to align 354 with video frames. This gives the following, assuming Nr =1 and Nnc 355 = 0 (i.e., send a compound RTCP packet for each video frame, and no 356 non-compound packets), and using the calculation from Scenario 1: 357 Brtcp = (n * (Sc + Nnc * Snc))/(Nr * Tf * (1 + Nnc)) 359 +---------+---------+--------------+--------------+-----------------+ 360 | Data | Video | Video | Audio | Required RTCP | 361 | Rate | Frame | Packets per | Packets per | bandwidth: | 362 | (kbps) | Rate | Report: Nv | Report: Na | Brtcp (kbps) | 363 +---------+---------+--------------+--------------+-----------------+ 364 | 100 | 8 | 1 | 6 | 33.2 (33%) | 365 | 200 | 16 | 1 | 3 | 65.0 (32%) | 366 | 350 | 30 | 1 | 2 | 120.9 (34%) | 367 | 700 | 30 | 2 | 2 | 121.9 (17%) | 368 | 700 | 60 | 1 | 1 | 240.0 (34%) | 369 | 1024 | 30 | 3 | 2 | 122.8 (11%) | 370 | 1400 | 60 | 2 | 1 | 241.9 (17%) | 371 | 2048 | 30 | 6 | 2 | 125.6 ( 6%) | 372 | 2048 | 60 | 3 | 1 | 243.8 (11%) | 373 | 4096 | 30 | 12 | 2 | 131.2 ( 3%) | 374 | 4096 | 60 | 6 | 1 | 249.4 ( 6%) | 375 +---------+---------+--------------+--------------+-----------------+ 377 Table 3: Required RTCP bandwidth, reporting on every frame 379 The RTCP bandwidth needed scales inversely with Nr. That is, it is 380 halved if Nr=2 (report on every second packet), is reduced to one- 381 third if Nr=3 (report on every third packet), and so on. 383 The needed RTCP bandwidth scales as a percentage of the data rate 384 following the ratio of the frame rate to the data rate. As can be 385 seen from the table above, the RTCP bandwidth needed is a significant 386 fraction of the media rate, if reporting on every frame for low rate 387 video. This can be solved by reporting less often at lower rates. 388 For example, to report on every frame of 100kbps/8fps video requires 389 the RTCP bandwidth to be 21% of the media rate; reporting every 390 fourth frame (i.e., twice per second) reduces this overhead to 5%. 392 Use of reduced size RTCP [RFC5506] would allow the SR and SDES 393 packets to be omitted from some reports. These "non-compound" 394 (actually, compound but reduced size in this case) RTCP packets would 395 contain an RTCP RGRS packet from the non-reporting SSRC, and an RTCP 396 SDES RGRP packet and a congestion control feedback packet from the 397 reporting SSRC. This will be 12 + 28 + 12 + 8 + 2*Nv + 8 + 2*Na 398 octets, plus UDP/IP header. That is, Snc = (96 + 2*Nv + 2*Na)/2. 399 Repeating the analysis above, but alternating compound and non- 400 compound reports, i.e., setting Nnc = 1, gives: 402 +---------+---------+--------------+--------------+-----------------+ 403 | Data | Video | Video | Audio | Required RTCP | 404 | Rate | Frame | Packets per | Packets per | bandwidth: | 405 | (kbps) | Rate | Report: Nv | Report: Na | Brtcp (kbps) | 406 +---------+---------+--------------+--------------+-----------------+ 407 | 100 | 8 | 1 | 6 | 23.5 (23%) | 408 | 200 | 16 | 1 | 3 | 45.5 (22%) | 409 | 350 | 30 | 1 | 2 | 84.4 (24%) | 410 | 700 | 30 | 2 | 2 | 85.3 (12%) | 411 | 700 | 60 | 1 | 1 | 166.9 (23%) | 412 | 1024 | 30 | 3 | 2 | 86.2 ( 8%) | 413 | 1400 | 60 | 2 | 1 | 168.8 (12%) | 414 | 2048 | 30 | 6 | 2 | 89.1 ( 4%) | 415 | 2048 | 60 | 3 | 1 | 170.6 ( 8%) | 416 | 4096 | 30 | 12 | 2 | 94.7 ( 2%) | 417 | 4096 | 60 | 6 | 1 | 176.2 ( 4%) | 418 +---------+---------+--------------+--------------+-----------------+ 420 Table 4: Required RTCP bandwidth, reporting on every frame, with 421 reduced-size reports 423 The use of reduced-size RTCP gives a noticeable reduction in the 424 needed RTCP bandwidth, and can be combined with reporting every few 425 frames rather than every frames. Overall, it is clear that the RTCP 426 overhead can be reasonable across the range of data and frame rates, 427 if RTCP is configured carefully. 429 3.3. Scenario 3: Group Video Conference 431 (tbd) 433 3.4. Scenario 4: Screen Sharing 435 (tbd) 437 4. Discussion and Conclusions 439 RTCP as it is currently specified cannot be used to send per-packet 440 congestion feedback. RTCP can, however, be used to send congestion 441 feedback on each frame of video sent, provided the session bandwidth 442 exceeds a couple of megabits per second (the exact rate depending on 443 the number of session participants, the RTCP bandwidth fraction, and 444 what RTCP extensions are enabled, and how much detail of feedback is 445 needed). For lower rate sessions, the overhead of reporting on every 446 frame becomes high, but can be reduced to something reasonable by 447 sending reports once per N frames (e.g., every second frame), or by 448 sending non-compound RTCP reports in between the regular reports. 450 If it is desired to use RTCP in something close to it's current form 451 for congestion feedback in WebRTC, the multimedia congestion control 452 algorithm needs be designed to work with feedback sent every few 453 frames, since that fits within the limitations of RTCP. That 454 feedback can be a little more complex than just an acknowledgement, 455 provided care is taken to consider the impact of the extra feedback 456 on the overhead, possibly allowing for a degree of semantic feedback, 457 meaningful to the codec layer as well as the congestion control 458 algorithm. 460 The format described in [I-D.ietf-avtcore-cc-feedback-message] seems 461 sufficient for the needs of congestion control feedback. There is 462 little point optimising this format: the main overhead comes from the 463 UDP/IP headers and the other RTCP packets included in the compound 464 packets, and can be lowered by using the [RFC5506] extensions and 465 sending reports less frequently. 467 Further study of the scenarios of interest is needed, to ensure that 468 the analysis presented is applicable to other media topologies, and 469 to sessions with different data rates and sizes of membership. 471 5. Security Considerations 473 An attacker that can modify or spoof RTCP congestion control feedback 474 packets can manipulate the sender behaviour to cause denial of 475 service. This can be prevented by authentication and integrity 476 protection of RTCP packets, for example using the secure RTP profile 477 [RFC3711][RFC5124], or by other means as discussed in [RFC7201]. 479 6. IANA Considerations 481 There are no actions for IANA. 483 7. Acknowledgements 485 Thanks to Magnus Westerlund and the members of the RMCAT feedback 486 design team for their feedback. 488 8. Informative References 490 [I-D.ietf-avtcore-cc-feedback-message] 491 Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP 492 Control Protocol (RTCP) Feedback for Congestion Control", 493 draft-ietf-avtcore-cc-feedback-message-01 (work in 494 progress), March 2018. 496 [I-D.ietf-avtcore-rtp-multi-stream-optimisation] 497 Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, 498 "Sending Multiple RTP Streams in a Single RTP Session: 499 Grouping RTCP Reception Statistics and Other Feedback", 500 draft-ietf-avtcore-rtp-multi-stream-optimisation-12 (work 501 in progress), March 2016. 503 [I-D.ietf-rtcweb-rtp-usage] 504 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 505 Communication (WebRTC): Media Transport and Use of RTP", 506 draft-ietf-rtcweb-rtp-usage-26 (work in progress), March 507 2016. 509 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 510 Jacobson, "RTP: A Transport Protocol for Real-Time 511 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 512 July 2003, . 514 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 515 "RTP Control Protocol Extended Reports (RTCP XR)", 516 RFC 3611, DOI 10.17487/RFC3611, November 2003, 517 . 519 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 520 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 521 RFC 3711, DOI 10.17487/RFC3711, March 2004, 522 . 524 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 525 "Extended RTP Profile for Real-time Transport Control 526 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 527 DOI 10.17487/RFC4585, July 2006, . 530 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 531 Real-time Transport Control Protocol (RTCP)-Based Feedback 532 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 533 2008, . 535 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 536 Real-Time Transport Control Protocol (RTCP): Opportunities 537 and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 538 2009, . 540 [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, 541 "Guidelines for Choosing RTP Control Protocol (RTCP) 542 Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, 543 September 2013, . 545 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 546 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 547 . 549 [RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, 550 "Sending Multiple RTP Streams in a Single RTP Session", 551 RFC 8108, DOI 10.17487/RFC8108, March 2017, 552 . 554 Author's Address 556 Colin Perkins 557 University of Glasgow 558 School of Computing Science 559 Glasgow G12 8QQ 560 United Kingdom 562 Email: csp@csperkins.org