idnits 2.17.1 draft-ietf-rmcat-rtp-cc-feedback-03.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 (November 14, 2016) is 2717 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-dt-rmcat-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 November 14, 2016 5 Expires: May 18, 2017 7 RTP Control Protocol (RTCP) Feedback for Congestion Control in 8 Interactive Multimedia Conferences 9 draft-ietf-rmcat-rtp-cc-feedback-03 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 May 18, 2017. 35 Copyright Notice 37 Copyright (c) 2016 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 (RC2F) packet [I-D.dt-rmcat-feedback-message]. Non-compound 177 RTCP packets contain only the RC2F packet. Since each participant 178 sends only a single media stream, the extensions for RTCP report 179 aggregation [I-D.ietf-avtcore-rtp-multi-stream] and reporting group 180 optimisation [I-D.ietf-avtcore-rtp-multi-stream-optimisation] are not 181 used. 183 Within each compound RTCP packet, the SR packet will contain a sender 184 information block (28 octets) and a single reception report block (24 185 octets), for a total of 52 octets. A minimal SDES packet will 186 contain a header (4 octets) and a single chunk containing an SSRC (4 187 octets) and a CNAME item, and if the recommendations for choosing the 188 CNAME [RFC7022] are followed, the CNAME item will comprise a 2 octet 189 header, 16 octets of data, and 2 octets of padding, for a total SDES 190 packet size of 28 octets. The RC2F packets contains an XR block 191 header and SSRC (8 octets), a block type and timestamp (8 octets), 192 the SSRC, beginning and ending sequence numbers (8 octets), and 2*Nr 193 octets of reports, for a total of 24 + 2*Nr octets. If IPv4 is used, 194 with no IP options, the UDP/IP header will be 28 octets in size. 195 This gives a total compound RTCP packet size of Sc = 132 + 2*Nr 196 octets. 198 The non-compound RTCP packets will comprise just the RC2F packet with 199 a UDP/IP header. It can be seen that these packets will be Snc = 48 200 + 2*Nr octets in size. 202 The RTCP reporting interval calculation ([RFC3550], Section 6.2) for 203 a two-party session where both participants are senders, reduces to 204 Trtcp = n * Srtcp/Brtcp where Srtcp = (Sc + Nnc * Snc)/(1 + Nnc) is 205 the average RTCP packet size in octets, Brtcp is the bandwidth 206 allocated to RTCP in octets per second, and n is the number of 207 participants (n=2 in this scenario). 209 To ensure a report is sent every Nr frames, it is necessary to set 210 the RTCP reporting interval Trtcp = Nr * Tf, which when substituted 211 into the previous gives Nr * Tf = n * Srtcp/Brtcp. 213 Solving for the RTCP bandwidth, Brtcp, and expanding the definition 214 of Srtcp gives Brtcp = (n * (Sc + Nnc * Snc))/(Nr * Tf * (1 + Nnc)). 216 If we assume every report is a compound RTCP packet (i.e., Nnc = 0), 217 the frame duration Tf = 20ms, and an RTCP report is sent for every 218 second frame (i.e., 25 RTCP reports per second), this expression 219 gives the needed RTCP bandwidth Brtcp = 53.1kbps. Increasing the 220 frame duration, or reducing the frequency of reports, reduces the 221 RTCP bandwidth, as shown below: 223 +--------------+-------------+----------------+ 224 | Tf (seconds) | Nr (frames) | rtcp_bw (kbps) | 225 +--------------+-------------+----------------+ 226 | 20ms | 2 | 53.1 | 227 | 20ms | 4 | 27.3 | 228 | 20ms | 8 | 14.5 | 229 | 20ms | 16 | 8.01 | 230 | 60ms | 2 | 17.7 | 231 | 60ms | 4 | 9.1 | 232 | 60ms | 8 | 4.8 | 233 | 60ms | 16 | 2.66 | 234 +--------------+-------------+----------------+ 236 Table 1: Required RTCP bandwidth for VoIP feedback 238 The final row of the table (60ms frames, report every 16 frames) 239 sends RTCP reports once per second, giving an RTCP bandwidth of 240 2.66kbps. 242 The overhead can be reduced by sending some reports in non-compound 243 RTCP packets [RFC5506]. For example, if we alternate compound and 244 non-compound RTCP packets, i.e., Nnc = 1, the calculation gives: 246 +--------------+-------------+----------------+ 247 | Tf (seconds) | Nr (frames) | rtcp_bw (kbps) | 248 +--------------+-------------+----------------+ 249 | 20ms | 2 | 36.7 | 250 | 20ms | 4 | 19.1 | 251 | 20ms | 8 | 10.4 | 252 | 20ms | 16 | 6.0 | 253 | 60ms | 2 | 12.2 | 254 | 60ms | 4 | 6.4 | 255 | 60ms | 8 | 3.5 | 256 | 60ms | 16 | 2.0 | 257 +--------------+-------------+----------------+ 259 Table 2: Required RTCP bandwidth for VoIP feedback (alternating 260 compound and non-compound reports) 262 The RTCP bandwidth needed for 60ms frames, reporting every 16 frames 263 (once per second), can be seen to drop to 2.01kbps. This calculation 264 can be repeated for other patterns of compound and non-compound RTCP 265 packets, feedback frequency, and frame duration, as needed. 267 Note: To achieve the RTCP transmission intervals above the RTP/SAVPF 268 profile with T_rr_interval=0 is used, since even when using the 269 reduced minimal transmission interval, the RTP/SAVP profile would 270 only allow sending RTCP at most every 0.11s (every third frame of 271 video). Using RTP/SAVPF with T_rr_interval=0 however is capable of 272 fully utilizing the configured 5% RTCP bandwidth fraction. 274 3.2. Scenario 2: Point-to-Point Video Conference 276 Consider a point to point video call between two end systems. There 277 will be four RTP flows in this scenario, two audio and two video, 278 with all four flows being active for essentially all the time (the 279 audio flows will likely use voice activity detection and comfort 280 noise to reduce the packet rate during silent periods, and does not 281 cause the transmissions to stop). 283 Assume all four flows are sent in a single RTP session, each using a 284 separate SSRC; the RTCP reports from co-located audio and video SSRCs 285 at each end point are aggregated [I-D.ietf-avtcore-rtp-multi-stream]; 286 the optimisations in [I-D.ietf-avtcore-rtp-multi-stream-optimisation] 287 are used; and congestion control feedback is sent 288 [I-D.dt-rmcat-feedback-message]. 290 When all members are senders, the RTCP timing rules in Section 6.2 291 and 6.3 of [RFC3550] and [RFC4585] reduce to: 293 rtcp_interval = avg_rtcp_size * n / rtcp_bw 295 where n is the number of members in the session, the avg_rtcp_size is 296 measured in octets, and the rtcp_bw is the bandwidth available for 297 RTCP, measured in octets per second (this will typically be 5% of the 298 session bandwidth). 300 The average RTCP size will depend on the amount of feedback that is 301 sent in each RTCP packet, on the number of members in the session, on 302 the size of source description (RTCP SDES) information sent, and on 303 the amount of congestion control feedback sent in each packet. 305 As a baseline, each RTCP packet will be a compound RTCP packet that 306 contains an aggregate of a compound RTCP packet generated by the 307 video SSRC and a compound RTCP packet generated by the audio SSRC. 308 Since the RTCP reporting group extensions are used, one of these 309 SSRCs will be a reporting SSRC, and the other will delegate its 310 reports to that. 312 The aggregated compound RTCP packet from the non-reporting SSRC will 313 contain an RTCP SR packet, an RTCP SDES packet, and an RTCP RGRS 314 packet. The RTCP SR packet contains the 28 octet header and sender 315 information, but no report blocks (since the reporting is delegated). 316 The RTCP SDES packet will comprise a header (4 octets), originating 317 SSRC (4 octets), a CNAME chunk, a terminating chunk, and any padding. 318 If the CNAME follows [RFC7022] and [I-D.ietf-rtcweb-rtp-usage] it 319 will be 18 octets in size, and will need 1 octet of padding, making 320 the SDES packet 28 octets in size. The RTCP RGRS packet will be 12 321 octets in size. This gives a total of 28 + 28 + 12 = 68 octets. 323 The aggregated compound RTCP packet from the reporting SSRC will 324 contain an RTCP SR packet, an RTCP SDES packet, and an RTCP XR 325 congestion control feedback packet. The RTCP SR packet will contain 326 two report blocks, one for each of the remote SSRCs (the report for 327 the other local SSRC is suppressed by the reporting group extension), 328 for a total of 28 + (2 * 24) = 76 octets. The RTCP SDES packet will 329 comprise a header (4 octets), originating SSRC (4 octets), a CNAME 330 chunk, an RGRP chunk, a terminating chunk, and any padding. If the 331 CNAME follows [RFC7022] and [I-D.ietf-rtcweb-rtp-usage] it will be 18 332 octets in size. The RGRP chunk similarly comprises 18 octets, and 3 333 octets of padding are needed, for a total of 48 octets. The RTCP XR 334 congestion control feedback report comprises an 8 octet XR header, an 335 8 octet RC2F header, then for each of the remote audio and video 336 SSRCs, an 8 octet report header, and 2 octets per packet reported 337 upon, and padding to a 4 octet boundary, if needed; that is 8 + 8 + 8 338 + (2 * Nv) + 8 + (2 * Na) where Nv is the number of video packets per 339 report, and Na is the number of audio packets per report. 341 The complete compound RTCP packet contains the RTCP packets from both 342 the reporting and non-reporting SSRCs, an SRTP authentication tag, 343 and a UDP/IPv4 header. The size of this RTCP packet is therefore: 344 252 + (2 * Nv) + (2 * Na) octets. Since the aggregate RTCP packet 345 contains reports from two SSRCs, the RTCP packet size is halved 346 before use [I-D.ietf-avtcore-rtp-multi-stream]. Accordingly, we 347 define Sc = (252 + (2 * Nv) + (2 * Na))/2 for this scenario. 349 How many packets does the RTCP XR congestion control feedback packet 350 report on? This is obviously highly dependent on the choice of codec 351 and encoding parameters, and might be quite bursty if the codec sends 352 I-frames from which later frames are predicted. For now though, 353 assume constant rate media with an MTU around 1500 octets, with 354 reports for both audio and video being aggregated and sent to align 355 with video frames. This gives the following, assuming Nr =1 and Nnc 356 = 0 (i.e., send a compound RTCP packet for each video frame, and no 357 non-compound packets), and using the calculation from Scenario 1: 358 Brtcp = (n * (Sc + Nnc * Snc))/(Nr * Tf * (1 + Nnc)) 360 +---------+---------+--------------+--------------+-----------------+ 361 | Data | Video | Video | Audio | Required RTCP | 362 | Rate | Frame | Packets per | Packets per | bandwidth: | 363 | (kbps) | Rate | Report: Nv | Report: Na | Brtcp (kbps) | 364 +---------+---------+--------------+--------------+-----------------+ 365 | 100 | 8 | 1 | 6 | 33.3 (33%) | 366 | 200 | 16 | 1 | 3 | 65.0 (33%) | 367 | 350 | 30 | 1 | 2 | 120.1 (35%) | 368 | 700 | 30 | 2 | 2 | 121.9 (17%) | 369 | 700 | 60 | 1 | 1 | 240.0 (34%) | 370 | 1024 | 30 | 3 | 2 | 122.8 (12%) | 371 | 1400 | 60 | 2 | 1 | 241.8 (17%) | 372 | 2048 | 30 | 6 | 2 | 125.6 ( 6%) | 373 | 2048 | 60 | 3 | 1 | 243.8 (12%) | 374 | 4096 | 30 | 12 | 2 | 131.3 ( 3%) | 375 | 4096 | 60 | 6 | 1 | 294.4 ( 6%) | 376 +---------+---------+--------------+--------------+-----------------+ 378 Table 3: Required RTCP bandwidth, reporting on every frame 380 The RTCP bandwidth needed scales inversely with Nr. That is, it is 381 halved if Nr=2 (report on every second packet), is reduced to one- 382 third if Nr=3 (report on every third packet), and so on. 384 The needed RTCP bandwidth scales as a percentage of the data rate 385 following the ratio of the frame rate to the data rate. As can be 386 seen from the table above, the RTCP bandwidth needed is a significant 387 fraction of the media rate, if reporting on every frame for low rate 388 video. This can be solved by reporting less often at lower rates. 389 For example, to report on every frame of 100kbps/8fps video requires 390 the RTCP bandwidth to be 21% of the media rate; reporting every 391 fourth frame (i.e., twice per second) reduces this overhead to 5%. 393 Use of reduced size RTCP [RFC5506] would allow the SR and SDES 394 packets to be omitted from some reports. These "non-compound" 395 (actually, compound but reduced size in this case) RTCP packets would 396 contain an RTCP RGRS packet from the non-reporting SSRC, and an RTCP 397 SDES RGRP packet and a congestion control feedback packet from the 398 reporting SSRC. This will be 12 + 28 + 12 + 8 + 2*Nv + 8 + 2*Na 399 octets, plus UDP/IP header. That is, Snc = (96 + 2*Nv + 2*Na)/2. 400 Repeating the analysis above, but alternating compound and non- 401 compound reports, i.e., setting Nnc = 1, gives: 403 +---------+---------+--------------+--------------+-----------------+ 404 | Data | Video | Video | Audio | Required RTCP | 405 | Rate | Frame | Packets per | Packets per | bandwidth: | 406 | (kbps) | Rate | Report: Nv | Report: Na | Brtcp (kbps) | 407 +---------+---------+--------------+--------------+-----------------+ 408 | 100 | 8 | 1 | 6 | 23.5 (23%) | 409 | 200 | 16 | 1 | 3 | 45.5 (23%) | 410 | 350 | 30 | 1 | 2 | 84.4 (24%) | 411 | 700 | 30 | 2 | 2 | 85.3 (12%) | 412 | 700 | 60 | 1 | 1 | 166.9 (24%) | 413 | 1024 | 30 | 3 | 2 | 86.2 ( 8%) | 414 | 1400 | 60 | 2 | 1 | 168.8 (12%) | 415 | 2048 | 30 | 6 | 2 | 89.1 ( 4%) | 416 | 2048 | 60 | 3 | 1 | 170.6 ( 8%) | 417 | 4096 | 30 | 12 | 2 | 94.7 ( 2%) | 418 | 4096 | 60 | 6 | 1 | 176.3 ( 4%) | 419 +---------+---------+--------------+--------------+-----------------+ 421 Table 4: Required RTCP bandwidth, reporting on every frame, with 422 reduced-size reports 424 The use of reduced-size RTCP gives a noticeable reduction in the 425 needed RTCP bandwidth, and can be combined with reporting every few 426 frames rather than every frames. Overall, it is clear that the RTCP 427 overhead can be reasonable across the range of data and frame rates, 428 if RTCP is configured carefully. 430 3.3. Scenario 3: Group Video Conference 432 (tbd) 434 3.4. Scenario 4: Screen Sharing 436 (tbd) 438 4. Discussion and Conclusions 440 RTCP as it is currently specified cannot be used to send per-packet 441 congestion feedback. RTCP can, however, be used to send congestion 442 feedback on each frame of video sent, provided the session bandwidth 443 exceeds a couple of megabits per second (the exact rate depending on 444 the number of session participants, the RTCP bandwidth fraction, and 445 what RTCP extensions are enabled, and how much detail of feedback is 446 needed). For lower rate sessions, the overhead of reporting on every 447 frame becomes high, but can be reduced to something reasonable by 448 sending reports once per N frames (e.g., every second frame), or by 449 sending non-compound RTCP reports in between the regular reports. 451 If it is desired to use RTCP in something close to it's current form 452 for congestion feedback in WebRTC, the multimedia congestion control 453 algorithm needs be designed to work with feedback sent every few 454 frames, since that fits within the limitations of RTCP. That 455 feedback can be a little more complex than just an acknowledgement, 456 provided care is taken to consider the impact of the extra feedback 457 on the overhead, possibly allowing for a degree of semantic feedback, 458 meaningful to the codec layer as well as the congestion control 459 algorithm. 461 The format described in [I-D.dt-rmcat-feedback-message] seems 462 sufficient for the needs of congestion control feedback. There is 463 little point optimising this format: the main overhead comes from the 464 UDP/IP headers and the other RTCP packets included in the compound 465 packets, and can be lowered by using the [RFC5506] extensions and 466 sending reports less frequently. 468 Further study of the scenarios of interest is needed, to ensure that 469 the analysis presented is applicable to other media topologies, and 470 to sessions with different data rates and sizes of membership. 472 5. Security Considerations 474 An attacker that can modify or spoof RTCP congestion control feedback 475 packets can manipulate the sender behaviour to cause denial of 476 service. This can be prevented by authentication and integrity 477 protection of RTCP packets, for example using the secure RTP profile 478 [RFC3711][RFC5124], or by other means as discussed in [RFC7201]. 480 6. IANA Considerations 482 There are no actions for IANA. 484 7. Acknowledgements 486 Thanks to Magnus Westerlund and the members of the RMCAT feedback 487 design team for their feedback. 489 8. Informative References 491 [I-D.dt-rmcat-feedback-message] 492 Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP 493 Control Protocol (RTCP) Feedback for Congestion Control", 494 draft-dt-rmcat-feedback-message-01 (work in progress), 495 October 2016. 497 [I-D.ietf-avtcore-rtp-multi-stream] 498 Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, 499 "Sending Multiple RTP Streams in a Single RTP Session", 500 draft-ietf-avtcore-rtp-multi-stream-11 (work in progress), 501 December 2015. 503 [I-D.ietf-avtcore-rtp-multi-stream-optimisation] 504 Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, 505 "Sending Multiple RTP Streams in a Single RTP Session: 506 Grouping RTCP Reception Statistics and Other Feedback", 507 draft-ietf-avtcore-rtp-multi-stream-optimisation-12 (work 508 in progress), March 2016. 510 [I-D.ietf-rtcweb-rtp-usage] 511 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 512 Communication (WebRTC): Media Transport and Use of RTP", 513 draft-ietf-rtcweb-rtp-usage-26 (work in progress), March 514 2016. 516 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 517 Jacobson, "RTP: A Transport Protocol for Real-Time 518 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 519 July 2003, . 521 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 522 "RTP Control Protocol Extended Reports (RTCP XR)", 523 RFC 3611, DOI 10.17487/RFC3611, November 2003, 524 . 526 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 527 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 528 RFC 3711, DOI 10.17487/RFC3711, March 2004, 529 . 531 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 532 "Extended RTP Profile for Real-time Transport Control 533 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 534 DOI 10.17487/RFC4585, July 2006, 535 . 537 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 538 Real-time Transport Control Protocol (RTCP)-Based Feedback 539 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 540 2008, . 542 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 543 Real-Time Transport Control Protocol (RTCP): Opportunities 544 and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 545 2009, . 547 [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, 548 "Guidelines for Choosing RTP Control Protocol (RTCP) 549 Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, 550 September 2013, . 552 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 553 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 554 . 556 Author's Address 558 Colin Perkins 559 University of Glasgow 560 School of Computing Science 561 Glasgow G12 8QQ 562 United Kingdom 564 Email: csp@csperkins.org