idnits 2.17.1 draft-perkins-rmcat-rtp-cc-feedback-01.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 02, 2014) is 3585 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-avtcore-rtp-multi-stream-optimisation-02 == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-rtp-usage-15 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. S. Perkins 3 Internet-Draft University of Glasgow 4 Intended status: Informational July 02, 2014 5 Expires: January 03, 2015 7 Using RTP Control Protocol (RTCP) Feedback for Unicast Multimedia 8 Congestion Control 9 draft-perkins-rmcat-rtp-cc-feedback-01 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 03, 2015. 35 Copyright Notice 37 Copyright (c) 2014 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. Per-packet Feedback . . . . . . . . . . . . . . . . . . . 4 56 3.2. Per-frame Feedback . . . . . . . . . . . . . . . . . . . 4 57 3.3. Per-RTT Feedback . . . . . . . . . . . . . . . . . . . . 6 58 4. Discussion and Conclusions . . . . . . . . . . . . . . . . . 6 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 62 8. Informative References . . . . . . . . . . . . . . . . . . . 7 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 65 1. Introduction 67 The coming deployment of WebRTC systems raises the prospect that high 68 quality video conferencing will see extremely wide use. To ensure 69 the stability of the network in the face of this use, WebRTC systems 70 will need to use some form of congestion control for their RTP-based 71 media traffic. To develop such congestion control, it is necessary 72 to understand the sort of congestion feedback that can be provided 73 within the framework of RTP [RFC3550] and the RTP Control Protocol 74 (RTCP). It then becomes possible to determine if this is sufficient 75 for congestion control, or if some form of RTP extension is needed. 77 This memo considers the congestion feedback that can be sent using 78 RTCP under the RTP/SAVPF profile [RFC5124] (the secure version of the 79 RTP/AVPF profile [RFC4585]). This profile was chosen as it forms the 80 basis for media transport in WebRTC [I-D.ietf-rtcweb-rtp-usage] 81 systems. Nothing in this memo is specific to the secure version of 82 the profile, or to WebRTC, however. 84 2. Possible Models for RTCP Feedback 86 Several questions need to be answered when providing RTCP reception 87 quality feedback for congestion control purposes. These include: 89 o How often is feedback needed? 91 o How much overhead is acceptable? 93 o How much, and what, data does each report contain? 95 The key question is how often does the receiver need to send feedback 96 on the reception quality it is experiencing, and hence the congestion 97 state of the network? Traditional congestion control protocols, such 98 as TCP, send acknowledgements with every packet (or, at least, every 99 couple of packets). That is straight-forward and low overhead when 100 traffic is bidirectional and acknowledgements can be piggybacked onto 101 return path data packets. It can also be acceptable, and can have 102 reasonable overhead, to send separate acknowledgement packets when 103 those packets are much smaller than data packets. It becomes a 104 problem, however, when there is no return traffic on which to 105 piggyback acknowledgements, and when acknowledgements are similar in 106 size to data packets; this can be the case for some forms of media 107 traffic, especially for voice over IP (VoIP) flows, but less so for 108 video. 110 When considering multimedia traffic, it might make sense to consider 111 less frequent feedback. For example, it might be possible to send a 112 feedback packet once per video frame, or once per network round trip 113 time (RTT). This could still give sufficiently frequent feedback for 114 the congestion control loop to be stable and responsive while keeping 115 the overhead reasonable when the feedback cannot be piggybacked onto 116 returning data. In this case, it is important to note that RTCP can 117 send much more detailed feedback than simple acknowledgements. For 118 example, if it were useful, it could be possible to use an RTCP 119 extended report (XR) packet [RFC3611] to send feedback once per RTT 120 comprising a bitmap of lost and received packets, with reception 121 times, over that RTT. As long as feedback is sent frequently enough 122 that the control loop is stable, and the sender is kept informed when 123 data leaves the network (to provide an equivalent to ACK clocking in 124 TCP), it is not necessary to report on every packet at the instant it 125 is received (indeed, it is unlikely that a video codec can react 126 instantly to a rate change anyway, and there is little point in 127 providing feedback more often than the codec can adapt). 129 The amount of overhead due to congestion control feedback that is 130 considered acceptable has to be determined. RTCP data is sent in 131 separate packets to RTP data, and this has some cost in terms of 132 additional header overhead compared to protocols that piggyback 133 feedback on return path data packets. The RTP standards have long 134 said that a 5% overhead for RTCP traffic generally acceptable, while 135 providing the ability to change this fraction. Is this still the 136 case for congestion control feedback? Or is there a desire to either 137 see more responsive feedback and congestion control, possibility with 138 a higher overhead, or is lower overhead wanted, accepting that this 139 might reduce responsiveness of the congestion control algorithm? 141 Finally, the details of how much, and what, data is to be sent in 142 each report will affect the frequency and/or overhead of feedback. 143 There is a fundamental trade-off that the more frequently feedback 144 packets are sent, the less data can be included in each packet to 145 keep the overhead constant. Does the congestion control need high 146 rate but simple feedback (e.g., like TCP acknowledgements), or is it 147 acceptable to send more complex feedback less often? 149 3. What Feedback is Achievable With RTCP? 151 3.1. Per-packet Feedback 153 RTCP packets are sent as separate packets to RTP media data, and the 154 protocol includes no mechanism for piggybacking an RTCP packet onto 155 an RTP data packet. In addition, the RTCP timing rules are based on 156 the size of the RTP session, the number of active senders, the RTCP 157 packet size, and the configured RTCP bandwidth fraction, with 158 randomisation to prevent synchronisation of reports; accordingly the 159 RTCP packet transmission times are extremely unlikely to line up with 160 RTP packet transmission times. As a result, RTCP cannot be used to 161 send per-packet feedback in it's current form. 163 All of these issues with using RTCP for per-packet feedback could be 164 resolved in an update to the RTP protocol, of course. Such an update 165 could change the RTCP timing rules, and might define a shim layer to 166 allow multiplexing of RTP and RTCP into a single packet, or to extend 167 the RTP header to piggyback feedback data. This sort of change would 168 be a large, and almost certainly backwards incompatible, extension to 169 the RTP protocol, and is unlikely to be completed quickly, but could 170 be done if there was a need. 172 3.2. Per-frame Feedback 174 Consider one of the simplest scenarios for WebRTC: a point to point 175 video call between two end systems. There will be four RTP flows in 176 this scenario, two audio and two video, with all four flows being 177 active for essentially all the time (the audio flows will likely use 178 voice activity detection and comfort noise to reduce the packet rate 179 during silent periods, and does not cause the transmissions to stop). 181 Assume all four flows are sent in a single RTP session, each using a 182 separate SSRC. Further, assume each SSRC sends RTCP reports for all 183 other SSRCs in the session (i.e., the optimisations in 184 [I-D.ietf-avtcore-rtp-multi-stream-optimisation] are not used, giving 185 the worst case for the RTCP overhead). When all members are senders 186 like this, the RTCP timing rules in Sections 6.2 and 6.3 of [RFC3550] 187 and [RFC4585] reduce to: 189 rtcp_interval = avg_rtcp_size * n / rtcp_bw 191 where n is the number of members in the session, the avg_rtcp_size is 192 measured in octets, and the rtcp_bw is the bandwidth available for 193 RTCP, measured in octets per second (this will typically be 5% of the 194 session bandwidth). 196 The average RTCP size will depend on the amount of feedback that is 197 sent in each RTCP packet, on the number of members in the session, 198 and on the size of source description (RTCP SDES) information sent. 199 As a baseline, each RTCP packet will be a compound RTCP packet that 200 contains an RTCP SR and an RTCP SDES packet. In the scenario above, 201 each RTCP SR packet will contain three report blocks, once for each 202 of the other RTP SSRCs sending data, for a total of 100 octets (this 203 is 8 octets header, 20 octets sender info, and 3 * 24 octets report 204 blocks). The RTCP SDES packet will comprise a header (4 octets), an 205 originating SSRC (4 octets), a CNAME chunk, and padding. If the 206 CNAME follows [RFC7022] and [I-D.ietf-rtcweb-rtp-usage] it will be 19 207 octets in size, and require 1 octet of padding. The resulting 208 compound RTCP packet will be 128 octets in size. If sent in UDP/IPv4 209 with no IP options and using Secure RTP, which adds 20 (IPv4) + 8 210 (UDP) + 14 (SRTP with 80 bit Authentication tag), the avg_rtcp_size 211 will therefore be 170 octets, including the header overhead. The 212 value n is this scenario is 4, and the rtcp_bw is assumed to be 5% of 213 the session bandwidth. 215 If it is desired to send RTCP feedback packets on average 30 times 216 per second, to correspond to one RTCP report every frame for 30fps 217 video, one can invert the above rtcp_interval calculation to get an 218 rtcp_bw that gives an interval of 1/30th of a second or lower. This 219 corresponds to an rtcp_bw of 20400 octets per second (since 1/30 = 220 170 * 4 / 20400). This is 163200 bits per second, which if 5% of the 221 session bandwidth, gives a session bandwidth of approximately 3.3Mbps 222 (i.e., 3.3Mbps media rate, plus an additional 5% for RTCP, to give a 223 total data rate of approximately 3.4Mbps). That is, RTCP can report 224 on every frame of video provided the session bandwidth is 3.3Mbps or 225 larger, when every SSRC sends a report for every video frame (due to 226 randomisation inherent in the RTCP timing rules, the actual RTCP 227 transmission intervals will be within the range [0.0135, 0.0406]s, 228 but will maintain an average RTCP transmission interval of 0.033s). 229 This is not out of line with the expected session bandwidth for this 230 type of application, suggesting the RTCP feedback can be used to 231 provide per-frame congestion control feedback for WebRTC-style 232 applications. 234 Note: To achieve the RTCP transmission intervals above the RTP/ 235 SAVPF profile with T_rr_interval=0 is used, since even when using 236 the reduced minimal transmission interval, the RTP/SAVP profile 237 would only allow sending RTCP at most every 0.11s (every third 238 frame of video). Using RTP/SAVPF with T_rr_interval=0 however is 239 capable of fully utilizing the configured 5% RTCP bandwidth 240 fraction. 242 If additional feedback beyond the standard report block is needed, 243 the session bandwidth needed will increase slightly. For example, 244 with an additional 20 octets data being reported in each RTCP packet, 245 the session bandwidth needed increases to 3.5Mbps for every SSRC to 246 be able to report on every frame. 248 The above calculations highlight the baseline feasibility of RTCP 249 congestion control feedback, but might not be the most appropriate 250 usage of the RTCP bandwidth of all applications. Depending on needs, 251 a less frequent usage of regular RTCP compound packets, controlled by 252 T_rr_interval combined with using the reduced size RTCP packets, can 253 achieve more frequent and useful reporting. Also the optimisations 254 defined in [I-D.ietf-avtcore-rtp-multi-stream-optimisation] will 255 reduce the amount of bandwidth consumed for reporting when each 256 endpoint has multiple SSRCs. 258 It might also seem unnecessary to assign the same fraction of the 259 RTCP bandwidth to reporting on the audio and video, since video is 260 much higher rate, and so is presumably more likely to cause 261 congestion. Sending audio and video in separate RTCP sessions with 262 their own RTCP bandwidth fraction would give essentially double the 263 RTCP bandwidth for each video source, since RTCP bandwidth fraction 264 would be shared between two reporting SSRCs, rather than between the 265 four reporting SSRCs in the single session case. This would hence 266 reduce the session bandwidth needed to allow reports on every frame. 267 Extensions to split RTCP bandwidth unequally between participants in 268 a single session could be defined to allow this to work with a single 269 RTP session on a single UDP port, or two standard RTP sessions could 270 be run on a single port, using a demultiplexing shim. RTCP already 271 allows for different bandwidth fractions between senders and 272 receivers, so this is a relatively small change to the protocol. 274 3.3. Per-RTT Feedback 276 The arguments made in Section 3.2 apply to this case as well. The 277 network RTT will usually be larger than the media framing interval, 278 so sending feedback per RTT is less of a load on RTCP than sending 279 feedback per frame. 281 4. Discussion and Conclusions 283 RTCP as it is currently specified cannot be used to send per-packet 284 congestion feedback. RTCP can, however, be used to send congestion 285 feedback on each frame of video sent, provided the session bandwidth 286 exceeds a couple of megabits per second (the exact rate depending on 287 the number of session participants, the RTCP bandwidth fraction, and 288 whether audio and video are sent in one or two RTP sessions). RTCP 289 can likely also be used to send feedback on a per-RTT basis, provided 290 the RTT is not too low. 292 If it is desired to use RTCP in something close to it's current form 293 for congestion feedback in WebRTC, the multimedia congestion control 294 algorithm needs be designed to work with feedback sent roughly each 295 frame or each RTT, rather than per packet, since that fits within the 296 limitations of RTCP. That feedback can be a little more complex than 297 just an acknowledgement, provided care is taken to consider the 298 impact of the extra feedback on the overhead, possibly allowing for a 299 degree of semantic feedback, meaningful to the codec layer as well as 300 the congestion control algorithm. 302 Further study of the scenarios of interest is needed, to ensure that 303 the analysis presented is applicable to other media topologies, and 304 to sessions with different data rates and sizes of membership. 306 5. Security Considerations 308 The security considerations of [RFC3550], [RFC4585], and [RFC5124] 309 apply. 311 6. IANA Considerations 313 There are no actions for IANA. 315 7. Acknowledgements 317 Thanks to Magnus Westerlund for his feedback on Section 3.2. 319 8. Informative References 321 [I-D.ietf-avtcore-rtp-multi-stream-optimisation] 322 Lennox, J., Westerlund, M., Wu, W., and C. Perkins, 323 "Sending Multiple Media Streams in a Single RTP Session: 324 Grouping RTCP Reception Statistics and Other Feedback", 325 draft-ietf-avtcore-rtp-multi-stream-optimisation-02 (work 326 in progress), February 2014. 328 [I-D.ietf-rtcweb-rtp-usage] 329 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 330 Communication (WebRTC): Media Transport and Use of RTP", 331 draft-ietf-rtcweb-rtp-usage-15 (work in progress), May 332 2014. 334 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 335 Jacobson, "RTP: A Transport Protocol for Real-Time 336 Applications", STD 64, RFC 3550, July 2003. 338 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 339 Protocol Extended Reports (RTCP XR)", RFC 3611, November 340 2003. 342 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 343 "Extended RTP Profile for Real-time Transport Control 344 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 345 2006. 347 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 348 Real-time Transport Control Protocol (RTCP)-Based Feedback 349 (RTP/SAVPF)", RFC 5124, February 2008. 351 [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, 352 "Guidelines for Choosing RTP Control Protocol (RTCP) 353 Canonical Names (CNAMEs)", RFC 7022, September 2013. 355 Author's Address 357 Colin Perkins 358 University of Glasgow 359 School of Computing Science 360 Glasgow G12 8QQ 361 United Kingdom 363 Email: csp@csperkins.org