idnits 2.17.1 draft-perkins-rmcat-rtp-cc-feedback-00.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 (February 18, 2013) is 4084 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-avtcore-6222bis-00 == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-rtp-usage-05 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. Perkins 3 Internet-Draft University of Glasgow 4 Intended status: Informational February 18, 2013 5 Expires: August 22, 2013 7 On the Use of RTP Control Protocol (RTCP) Feedback for Unicast 8 Multimedia Congestion Control 9 draft-perkins-rmcat-rtp-cc-feedback-00 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 August 22, 2013. 35 Copyright Notice 37 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Possible Models for RTCP Feedback . . . . . . . . . . . . . . . 3 54 3. What Feedback is Achievable With RTCP? . . . . . . . . . . . . 4 55 3.1. Per-packet Feedback . . . . . . . . . . . . . . . . . . . . 4 56 3.2. Per-frame Feedback . . . . . . . . . . . . . . . . . . . . 5 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. Informative References . . . . . . . . . . . . . . . . . . . . 7 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 1. Introduction 66 The coming deployment of WebRTC systems raises the prospect that high 67 quality video conferencing will see extremely wide use. To ensure 68 the stability of the network in the face of this use, WebRTC systems 69 will need to use some form of congestion control for their RTP-based 70 media traffic. To develop such congestion control, it is necessary 71 to understand the sort of congestion feedback that can be provided 72 within the framework of RTP [RFC3550] and the RTP Control Protocol 73 (RTCP). It then becomes possible to determine if this is sufficient 74 for congestion control, or if some form of RTP extension is needed. 76 This memo considers the congestion feedback that can be sent using 77 RTCP under the RTP/SAVPF profile [RFC5124] (the secure version of the 78 RTP/AVPF profile [RFC4585]). This profile was chosen as it forms the 79 basis for media transport in WebRTC [I-D.ietf-rtcweb-rtp-usage] 80 systems. Nothing in this memo is specific to the secure version of 81 the profile, or to WebRTC, however. 83 2. Possible Models for RTCP Feedback 85 Several questions need to be answered when providing RTCP reception 86 quality feedback for congestion control purposes. These include: 88 o How often is feedback needed? 90 o How much overhead is acceptable? 92 o How much, and what, data does each report contain? 94 The key question is how often does the receiver need to send feedback 95 on the reception quality it is experiencing, and hence the congestion 96 state of the network? Traditional congestion control protocols, such 97 as TCP, send acknowledgements with every packet (or, at least, every 98 couple of packets). That is straight-forward and low overhead when 99 traffic is bidirectional and acknowledgements can be piggybacked onto 100 return path data packets. It can also be acceptable, and can have 101 reasonable overhead, to send separate acknowledgement packets when 102 those packets are much smaller than data packets. It becomes a 103 problem, however, when there is no return traffic on which to 104 piggyback acknowledgements, and when acknowledgements are similar in 105 size to data packets; this can be the case for some forms of media 106 traffic, especially for voice over IP (VoIP) flows, but less so for 107 video. 109 When considering multimedia traffic, it might make sense to consider 110 less frequent feedback. For example, it might be possible to send a 111 feedback packet once per video frame, or once per network round trip 112 time (RTT). This could still give sufficiently frequent feedback for 113 the congestion control loop to be stable and responsive while keeping 114 the overhead reasonable when the feedback cannot be piggybacked onto 115 returning data. In this case, it is important to note that RTCP can 116 send much more detailed feedback than simple acknowledgements. For 117 example, if it were useful, it could be possible to use an RTCP 118 extended report (XR) packet [RFC3611] to send feedback once per RTT 119 comprising a bitmap of lost and received packets, with reception 120 times, over that RTT. As long as feedback is sent frequently enough 121 that the control loop is stable, and the sender is kept informed when 122 data leaves the network (to provide an equivalent to ACK clocking in 123 TCP), it is not necessary to report on every packet at the instant it 124 is received (indeed, it is unlikely that a video codec can react 125 instantly to a rate change anyway, and there is little point in 126 providing feedback more often than the codec can adapt). 128 The amount of overhead due to congestion control feedback that is 129 considered acceptable has to be determined. RTCP data is sent in 130 separate packets to RTP data, and this has some cost in terms of 131 additional header overhead compared to protocols that piggyback 132 feedback on return path data packets. The RTP standards have long 133 said that a 5% overhead for RTCP traffic generally acceptable, while 134 providing the ability to change this fraction. Is this still the 135 case for congestion control feedback? Or is there a desire to either 136 see more responsive feedback and congestion control, possibility with 137 a higher overhead, or is lower overhead wanted, accepting that this 138 might reduce responsiveness of the congestion control algorithm? 140 Finally, the details of how much, and what, data is to be sent in 141 each report will affect the frequency and/or overhead of feedback. 142 There is a fundamental trade-off that the more frequently feedback 143 packets are sent, the less data can be included in each packet to 144 keep the overhead constant. Does the congestion control need high 145 rate but simple feedback (e.g., like TCP acknowledgements), or is it 146 acceptable to send more complex feedback less often? 148 3. What Feedback is Achievable With RTCP? 150 3.1. Per-packet Feedback 152 RTCP packets are sent as separate packets to RTP media data, and the 153 protocol includes no mechanism for piggybacking an RTCP packet onto 154 an RTP data packet. In addition, the RTCP timing rules are based on 155 the size of the RTP session, the number of active senders, the RTCP 156 packet size, and the configured RTCP bandwidth fraction, with 157 randomisation to prevent synchronisation of reports; accordingly the 158 RTCP packet transmission times are extremely unlikely to line up with 159 RTP packet transmission times. As a result, RTCP cannot be used to 160 send per-packet feedback in it's current form. 162 All of these issues with using RTCP for per-packet feedback could be 163 resolved in an update to the RTP protocol, of course. Such an update 164 could change the RTCP timing rules, and might define a shim layer to 165 allow multiplexing of RTP and RTCP into a single packet, or to extend 166 the RTP header to piggyback feedback data. This sort of change would 167 be a large, and almost certainly backwards incompatible, extension to 168 the RTP protocol, and is unlikely to be completed quickly, but could 169 be done if there was a need. 171 3.2. Per-frame Feedback 173 Consider one of the simplest scenarios for WebRTC: a point to point 174 video call between two end systems. There will be four RTP flows in 175 this scenario, two audio and two video, with all four flows being 176 active for essentially all the time (the audio flows will likely use 177 voice activity detection and comfort noise to reduce the packet rate 178 during silent periods, and does not cause the transmissions to stop). 180 Assume all four flows are sent in a single RTP session, each using a 181 separate SSRC. Further, assume each SSRC sends RTCP reports for all 182 other SSRCs in the session (this gives the worst case for the RTCP 183 overhead). When all members are senders like this, the RTCP timing 184 rules in Sections 6.2 and 6.3 of [RFC3550] and [RFC4585] reduce to: 186 rtcp_interval = avg_rtcp_size * n / rtcp_bw 188 where avg_rtcp_size is measured in octets, and the rtcp_bw is the 189 bandwidth available for RTCP, measured in octets per second (this 190 will typically be 5% of the session bandwidth). 192 The average RTCP size will depend on the amount of feedback that is 193 sent in each RTCP packet, on the number of members in the session, 194 and on the size of source description (RTCP SDES) information sent. 195 As a minimum, each RTCP packet will be a compound RTCP packet that 196 contains an RTCP SR and an RTCP SDES packet. In the scenario above, 197 each RTCP SR packet will contain three report blocks, once for each 198 of the other RTP SSRCs sending data, for a total of 100 octets (this 199 is 8 octets header, 20 octets sender info, and 3 * 24 octets report 200 blocks). The RTCP SDES packet will comprise a header (4 octets), an 201 SSRC (4 octets), a CNAME chunk, and padding. If the CNAME follows 202 [I-D.ietf-avtcore-6222bis] and [I-D.ietf-rtcweb-rtp-usage] it will be 203 19 octets in size, and require 1 octet of padding. The resulting 204 compound RTCP packet will be 128 octets in size. If sent in UDP/IPv4 205 with no IP options, the avg_rtcp_size will therefore be 156 octets, 206 including the header overhead. The value n is this scenario is 4, 207 and the rtcp_bw is assumed to be 5% of the session bandwidth. 209 If it is desired to send RTCP feedback packets on average 30 times 210 per second, to correspond to one RTCP report every frame for 30fps 211 video, we can invert the above rtcp_interval calculation to get an 212 rtcp_bw that gives an interval of 1/30th of a second or lower. This 213 corresponds to an rtcp_bw of 18,720 octets per second (since 1/30 = 214 156 * 4 / 18,720). This is 149,760 bits per second, which if 5% of 215 the session bandwidth, gives a session bandwidth of approximately 216 2.8Mbps. That is, RTCP can report on every frame of video provided 217 the session bandwidth is 2.8Mbps or larger, when every SSRC sends a 218 report for every video frame. 220 If additional feedback beyond the standard report block is needed, 221 the session bandwidth needed will increase. For example, with an 222 additional 20 octets data being reported in each RTCP packet, the 223 session bandwidth needed increases to 3.2Mbps for every SSRC to be 224 able to report on every frame. 226 It might seem unnecessary to assign the same fraction of the RTCP 227 bandwidth to reporting on the audio and video, since video is much 228 higher rate, and so is presumably more likely to cause congestion. 229 Sending audio and video in separate RTCP sessions with their own RTCP 230 bandwidth fraction would give essentially double the RTCP bandwidth 231 for each video source, since 5% of the video session bandwidth would 232 be shared between two reporting SSRCs, rather than between the four 233 reporting SSRCs in the single session case. This would hence reduce 234 the session bandwidth to around 1.4Mbps or larger to allow reports on 235 every frame. Extensions to split RTCP bandwidth unequally between 236 participants in a single session could be defined to allow this to 237 work with a single RTP session on a single UDP port, or two standard 238 RTP sessions could be run on a single port, using a demultiplexing 239 shim. RTCP already allows for different bandwidth fractions between 240 senders and receivers, so this is a relatively small change to the 241 protocol. 243 3.3. Per-RTT Feedback 245 The arguments made in Section 3.2 apply to this case as well. The 246 network RTT will usually be larger than the media framing interval, 247 so sending feedback per RTT is less of a load on RTCP than sending 248 feedback per frame. 250 4. Discussion and Conclusions 252 RTCP as it is currently specified cannot be used to send per-packet 253 congestion feedback. RTCP can, however, be used to send congestion 254 feedback on each frame of video sent, provided the session bandwidth 255 exceeds a couple of megabits per second (the exact rate depending on 256 the number of session participants, the RTCP bandwidth fraction, and 257 whether audio and video are sent in one or two RTP sessions). RTCP 258 can likely also be used to send feedback on a per-RTT basis, provided 259 the RTT is not too low. 261 If it is desired to use RTCP in something close to it's current form 262 for congestion feedback in WebRTC, the multimedia congestion control 263 algorithm ought be designed to work with feedback sent roughly each 264 frame or each RTT, rather than per packet, since that fits within the 265 limitations of RTCP. That feedback can be a little more complex than 266 just an acknowledgement, provided care is taken to consider the 267 impact of the extra feedback on the overhead, possibly allowing for a 268 degree of semantic feedback, meaningful to the codec layer as well as 269 the congestion control algorithm. 271 Further study of the scenarios of interest is needed, to ensure that 272 the analysis presented is applicable to other media topologies, and 273 to sessions with different data rates and sizes of membership. 275 5. Security Considerations 277 The security considerations of [RFC3550], [RFC4585], and [RFC5124] 278 apply. 280 6. IANA Considerations 282 There are no actions for IANA. 284 7. Informative References 286 [I-D.ietf-avtcore-6222bis] 287 Rescorla, E. and A. Begen, "Guidelines for Choosing RTP 288 Control Protocol (RTCP) Canonical Names (CNAMEs)", 289 draft-ietf-avtcore-6222bis-00 (work in progress), 290 December 2012. 292 [I-D.ietf-rtcweb-rtp-usage] 293 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 294 Communication (WebRTC): Media Transport and Use of RTP", 295 draft-ietf-rtcweb-rtp-usage-05 (work in progress), 296 October 2012. 298 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 299 Jacobson, "RTP: A Transport Protocol for Real-Time 300 Applications", STD 64, RFC 3550, July 2003. 302 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 303 Protocol Extended Reports (RTCP XR)", RFC 3611, 304 November 2003. 306 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 307 "Extended RTP Profile for Real-time Transport Control 308 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 309 July 2006. 311 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 312 Real-time Transport Control Protocol (RTCP)-Based Feedback 313 (RTP/SAVPF)", RFC 5124, February 2008. 315 Author's Address 317 Colin Perkins 318 University of Glasgow 319 School of Computing Science 320 Glasgow G12 8QQ 321 United Kingdom 323 Email: csp@csperkins.org