idnits 2.17.1 draft-ietf-avtcore-rtp-circuit-breakers-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 (October 22, 2012) is 4194 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3448 (Obsoleted by RFC 5348) == Outdated reference: A later version (-14) exists of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-06 == Outdated reference: A later version (-12) exists of draft-ietf-xrblock-rtcp-xr-burst-gap-loss-04 == Outdated reference: A later version (-12) exists of draft-ietf-xrblock-rtcp-xr-delay-10 == Outdated reference: A later version (-15) exists of draft-ietf-xrblock-rtcp-xr-discard-09 == Outdated reference: A later version (-09) exists of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-04 Summary: 1 error (**), 0 flaws (~~), 6 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: Standards Track V. Singh 5 Expires: April 25, 2013 Aalto University 6 October 22, 2012 8 RTP Congestion Control: Circuit Breakers for Unicast Sessions 9 draft-ietf-avtcore-rtp-circuit-breakers-01 11 Abstract 13 The Real-time Transport Protocol (RTP) is widely used in telephony, 14 video conferencing, and telepresence applications. Such applications 15 are often run on best-effort UDP/IP networks. If congestion control 16 is not implemented in the applications, then network congestion will 17 deteriorate the user's multimedia experience. This document does not 18 propose a congestion control algorithm; rather, it defines a minimal 19 set of "circuit-breakers". Circuit-breakers are conditions under 20 which an RTP flow is expected to stop transmitting media to protect 21 the network from excessive congestion. It is expected that all RTP 22 applications running on best-effort networks will be able to run 23 without triggering these circuit breakers in normal operation. Any 24 future RTP congestion control specification is expected to operate 25 within the envelope defined by these circuit breakers. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 25, 2013. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. RTP Circuit Breakers for Systems Using the RTP/AVP Profile . . 6 65 4.1. RTP/AVP Circuit Breaker #1: Media Timeout . . . . . . . . 7 66 4.2. RTP/AVP Circuit Breaker #2: RTCP Timeout . . . . . . . . . 8 67 4.3. RTP/AVP Circuit Breaker #3: Congestion . . . . . . . . . . 9 68 5. RTP Circuit Breakers for Systems Using the RTP/AVPF Profile . 11 69 6. Impact of RTCP XR . . . . . . . . . . . . . . . . . . . . . . 12 70 7. Impact of Explicit Congestion Notification (ECN) . . . . . . . 12 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 76 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Introduction 81 The Real-time Transport Protocol (RTP) [RFC3550] is widely used in 82 voice-over-IP, video teleconferencing, and telepresence systems. 83 Many of these systems run over best-effort UDP/IP networks, and can 84 suffer from packet loss and increased latency if network congestion 85 occurs. Designing effective RTP congestion control algorithms, to 86 adapt the transmission of RTP-based media to match the available 87 network capacity, while also maintaining the user experience, is a 88 difficult but important problem. Many such congestion control and 89 media adaptation algorithms have been proposed, but to date there is 90 no consensus on the correct approach, or even that a single standard 91 algorithm is desirable. 93 This memo does not attempt to propose a new RTP congestion control 94 algorithm. Rather, it proposes a minimal set of "circuit breakers"; 95 conditions under which there is general agreement that an RTP flow is 96 causing serious congestion, and ought to cease transmission. It is 97 expected that future standards-track congestion control algorithms 98 for RTP will operate within the envelope defined by this memo. 100 2. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 This interpretation of these key words applies only when written in 106 ALL CAPS. Mixed- or lower-case uses of these key words are not to be 107 interpreted as carrying special significance in this memo. 109 3. Background 111 We consider congestion control for unicast RTP traffic flows. This 112 is the problem of adapting the transmission of an audio/visual data 113 flow, encapsulated within an RTP transport session, from one sender 114 to one receiver, so that it matches the available network bandwidth. 115 Such adaptation needs to be done in a way that limits the disruption 116 to the user experience caused by both packet loss and excessive rate 117 changes. Congestion control for multicast flows is outside the scope 118 of this memo. 120 Congestion control for unicast RTP traffic can be implemented in one 121 of two places in the protocol stack. One approach is to run the RTP 122 traffic over a congestion controlled transport protocol, for example 123 over TCP, and to adapt the media encoding to match the dictates of 124 the transport-layer congestion control algorithm. This is safe for 125 the network, but can be suboptimal for the media quality unless the 126 transport protocol is designed to support real-time media flows. We 127 do not consider this class of applications further in this memo, as 128 their network safety is guaranteed by the underlying transport. 130 Alternatively, RTP flows can be run over a non-congestion controlled 131 transport protocol, for example UDP, performing rate adaptation at 132 the application layer based on RTP Control Protocol (RTCP) feedback. 133 With a well-designed, network-aware, application, this allows highly 134 effective media quality adaptation, but there is potential to disrupt 135 the network's operation if the application does not adapt its sending 136 rate in a timely and effective manner. We consider this class of 137 applications in this memo. 139 Congestion control relies on monitoring the delivery of a media flow, 140 and responding to adapt the transmission of that flow when there are 141 signs that the network path is congested. Network congestion can be 142 detected in one of three ways: 1) a receiver can infer the onset of 143 congestion by observing an increase in one-way delay caused by queue 144 build-up within the network; 2) if Explicit Congestion Notification 145 (ECN) [RFC3168] is supported, the network can signal the presence of 146 congestion by marking packets using ECN Congestion Experienced (CE) 147 marks; or 3) in the extreme case, congestion will cause packet loss 148 that can be detected by observing a gap in the received RTP sequence 149 numbers. Once the onset of congestion is observed, the receiver has 150 to send feedback to the sender to indicate that the transmission rate 151 needs to be reduced. How the sender reduces the transmission rate is 152 highly dependent on the media codec being used, and is outside the 153 scope of this memo. 155 There are several ways in which a receiver can send feedback to a 156 media sender within the RTP framework: 158 o The base RTP specification [RFC3550] defines RTCP Reception Report 159 (RR) packets to convey reception quality feedback information, and 160 Sender Report (SR) packets to convey information about the media 161 transmission. RTCP SR packets contain data that can be used to 162 reconstruct media timing at a receiver, along with a count of the 163 total number of octets and packets sent. RTCP RR packets report 164 on the fraction of packets lost in the last reporting interval, 165 the cumulative number of packets lost, the highest sequence number 166 received, and the inter-arrival jitter. The RTCP RR packets also 167 contain timing information that allows the sender to estimate the 168 network round trip time (RTT) to the receivers. RTCP reports are 169 sent periodically, with the reporting interval being determined by 170 the number of participants in the session and a configured session 171 bandwidth estimate. The interval between reports sent from each 172 receiver tends to be on the order of a few seconds on average, and 173 it is randomised to avoid synchronisation of reports from multiple 174 receivers. RTCP RR packets allow a receiver to report ongoing 175 network congestion to the sender. However, if a receiver detects 176 the onset of congestion partway through a reporting interval, the 177 base RTP specification contains no provision for sending the RTCP 178 RR packet early, and the receiver has to wait until the next 179 scheduled reporting interval. 181 o The RTCP Extended Reports (XR) [RFC3611] allow reporting of more 182 complex and sophisticated reception quality metrics, but do not 183 change the RTCP timing rules. RTCP extended reports of potential 184 interest for congestion control purposes are the extended packet 185 loss, discard, and burst metrics [RFC3611], 186 [I-D.ietf-xrblock-rtcp-xr-discard], 187 [I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics], 188 [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard], 189 [I-D.ietf-xrblock-rtcp-xr-burst-gap-loss]; and the extended delay 190 metrics [I-D.ietf-xrblock-rtcp-xr-delay], 191 [I-D.ietf-xrblock-rtcp-xr-pdv]. Other RTCP Extended Reports that 192 could be helpful for congestion control purposes might be 193 developed in future. 195 o Rapid feedback about the occurrence of congestion events can be 196 achieved using the Extended RTP Profile for RTCP-Based Feedback 197 (RTP/AVPF) [RFC4585] in place of the more common RTP/AVP profile 198 [RFC3551]. This modifies the RTCP timing rules to allow RTCP 199 reports to be sent early, in some cases immediately, provided the 200 average RTCP reporting interval remains unchanged. It also 201 defines new transport-layer feedback messages, including negative 202 acknowledgements (NACKs), that can be used to report on specific 203 congestion events. The use of the RTP/AVPF profile is dependent 204 on signalling, but is otherwise generally backwards compatible, as 205 it keeps the same average RTCP reporting interval as the base RTP 206 specification. The RTP Codec Control Messages [RFC5104] extend 207 the RTP/AVPF profile with additional feedback messages that can be 208 used to influence that way in which rate adaptation occurs. The 209 dynamics of how rapidly feedback can be sent are unchanged. 211 o Finally, Explicit Congestion Notification (ECN) for RTP over UDP 212 [RFC6679] can be used to provide feedback on the number of packets 213 that received an ECN Congestion Experienced (CE) mark. This RTCP 214 extension builds on the RTP/AVPF profile to allow rapid congestion 215 feedback when ECN is supported. 217 In addition to these mechanisms for providing feedback, the sender 218 can include an RTP header extension in each packet to record packet 219 transmission times. There are two methods: [RFC5450] represents the 220 transmission time in terms of a time-offset from the RTP timestamp of 221 the packet, while [RFC6051] includes an explicit NTP-format sending 222 timestamp (potentially more accurate, but a higher header overhead). 223 Accurate sending timestamps can be helpful for estimating queuing 224 delays, to get an early indication of the onset of congestion. 226 Taken together, these various mechanisms allow receivers to provide 227 feedback on the senders when congestion events occur, with varying 228 degrees of timeliness and accuracy. The key distinction is between 229 systems that use only the basic RTCP mechanisms, without RTP/AVPF 230 rapid feedback, and those that use the RTP/AVPF extensions to respond 231 to congestion more rapidly. 233 4. RTP Circuit Breakers for Systems Using the RTP/AVP Profile 235 The feedback mechanisms defined in [RFC3550] and available under the 236 RTP/AVP profile [RFC3551] are the minimum that can be assumed for a 237 baseline circuit breaker mechanism that is suitable for all unicast 238 applications of RTP. Accordingly, for an RTP circuit breaker to be 239 useful, it needs to be able to detect that an RTP flow is causing 240 excessive congestion using only basic RTCP features, without needing 241 RTCP XR feedback or the RTP/AVPF profile for rapid RTCP reports. 243 Three potential congestion signals are available from the basic RTCP 244 SR/RR packets and are reported for each synchronisation source (SSRC) 245 in the RTP session: 247 1. The sender can estimate the network round-trip time once per RTCP 248 reporting interval, based on the contents and timing of RTCP SR 249 and RR packets. 251 2. Receivers report a jitter estimate (the statistical variance of 252 the RTP data packet inter-arrival time) calculated over the RTCP 253 reporting interval. Due to the nature of the jitter calculation 254 ([RFC3550], section 6.4.4), the jitter is only meaningful for RTP 255 flows that send a single data packet for each RTP timestamp value 256 (i.e., audio flows, or video flows where each frame comprises one 257 RTP packet). 259 3. Receivers report the fraction of RTP data packets lost during the 260 RTCP reporting interval, and the cumulative number of RTP packets 261 lost over the entire RTP session. 263 These congestion signals limit the possible circuit breakers, since 264 they give only limited visibility into the behaviour of the network. 266 RTT estimates are widely used in congestion control algorithms, as a 267 proxy for queuing delay measures in delay-based congestion control or 268 to determine connection timeouts. RTT estimates derived from RTCP SR 269 and RR packets sent according to the RTP/AVP timing rules are far too 270 infrequent to be useful though, and don't give enough information to 271 distinguish a delay change due to routing updates from queuing delay 272 caused by congestion. Accordingly, we cannot use the RTT estimate 273 alone as an RTP circuit breaker. 275 Increased jitter can be a signal of transient network congestion, but 276 in the highly aggregated form reported in RTCP RR packets, it offers 277 insufficient information to estimate the extent or persistence of 278 congestion. Jitter reports are a useful early warning of potential 279 network congestion, but provide an insufficiently strong signal to be 280 used as a circuit breaker. 282 The remaining congestion signals are the packet loss fraction and the 283 cumulative number of packets lost. These are robust indicators of 284 congestion in a network where packet loss is primarily due to queue 285 overflows, although less accurate in networks where losses can be 286 caused by non-congestive packet corruption. TCP uses packet loss as 287 a congestion signal. 289 Two packet loss regimes can be observed: 1) RTCP RR packets show a 290 non-zero packet loss fraction, while the extended highest sequence 291 number received continues to increment; and 2) RR packets show a loss 292 fraction of zero, but the extended highest sequence number received 293 does not increment even though the sender has been transmitting RTP 294 data packets. The former corresponds to the TCP congestion avoidance 295 state, and indicates a congested path that is still delivering data; 296 the latter corresponds to a TCP timeout, and is most likely due to a 297 path failure. We derive circuit breaker conditions for these two 298 loss regimes in the following. 300 4.1. RTP/AVP Circuit Breaker #1: Media Timeout 302 If RTP data packets are being sent while the corresponding RTCP RR 303 packets report a non-increasing extended highest sequence number 304 received, this is an indication that those RTP data packets are not 305 reaching the receiver. This could be a short-term issue affecting 306 only a few packets, perhaps caused by a slow-to-open firewall or a 307 transient connectivity problem, but if the issue persists, it is a 308 sign of a more ongoing and significant problem. Accordingly, if a 309 sender of RTP data packets receives two or more consecutive RTCP RR 310 packets from the same receiver that correspond to its transmission, 311 and have a non-increasing extended highest sequence number received 312 field (i.e., at least three RTCP RR packets that report the same 313 value in the extended highest sequence number received field, when 314 the sender has sent data packets that would have caused an increase 315 in the reported value of the extended highest sequence number 316 received if they had reached the receiver), then that sender SHOULD 317 cease transmission. What it means to cease transmission depends on 318 the application, but the intention is that the application will stop 319 sending RTP data packets until the user makes an explicit attempt to 320 restart the call (RTP flows halted by the circuit breaker SHOULD NOT 321 be restarted automatically unless the sender has received information 322 that the congestion has dissipated). 324 Systems that usually send at a high data rate, but that can reduce 325 their data rate significantly (i.e., by at least a factor of ten), 326 MAY first reduce their sending rate to this lower value to see if 327 this resolves the congestion, but MUST then cease transmission if the 328 problem does not resolve itself within a further two RTCP reporting 329 intervals. An example of this might be a video conferencing system 330 that backs off to sending audio only, before completely dropping the 331 call. If such a reduction in sending rate resolves the congestion 332 problem, the sender MAY gradually increase the rate at which it sends 333 data after a reasonable amount of time has passed, provided it takes 334 care not to cause the problem to recur ("reasonable" is intentionally 335 not defined here). 337 The choice of two RTCP reporting intervals is to give enough time for 338 transient problems to resolve themselves, but to stop problem flows 339 quickly enough to avoid causing serious ongoing network congestion. 340 A single RTCP report showing no reception could be caused by numerous 341 transient faults, and so will not cease transmission. Waiting for 342 more than two RTCP reports before stopping a flow might avoid some 343 false positives, but would lead to problematic flows running for a 344 long time before being cut off. 346 4.2. RTP/AVP Circuit Breaker #2: RTCP Timeout 348 In addition to media timeouts, as were discussed in Section 4.1, an 349 RTP session has the possibility of an RTCP timeout. This can occur 350 when RTP data packets are being sent, but there are no RTCP reports 351 returned from the receiver. This is either due to a failure of the 352 receiver to send RTCP reports, or a failure of the return path that 353 is preventing those RTCP reporting from being delivered. 355 According to RFC 3550 [RFC3550], any participant that has not sent an 356 RTCP packet within the last two RTCP intervals is removed from the 357 sender list. Therefore, an RTP sender SHOULD cease transmission if 358 it does not receive a single RTCP RR packet and during this period 359 has sent 3 RTCP SR packets to the RTP receiver. Similarly, the same 360 circuit breaker rule applies to an RTCP receiver which has not 361 received a single SR packet, and in the corresponding period it has 362 sent 3 RTCP RR packets. What it means to cease transmission depends 363 on the application, but the intention is that the application will 364 stop sending RTP data packets until the user makes an explicit 365 attempt to restart the call (RTP flows halted by the circuit breaker 366 SHOULD NOT be restarted automatically unless the sender has received 367 information that the congestion has dissipated). 369 4.3. RTP/AVP Circuit Breaker #3: Congestion 371 If RTP data packets are being sent, and the corresponding RTCP RR 372 packets show non-zero packet loss fraction and increasing extended 373 highest sequence number received, then those RTP data packets are 374 arriving at the receiver, but some degree of congestion is occurring. 375 The RTP/AVP profile [RFC3551] states that: 377 If best-effort service is being used, RTP receivers SHOULD monitor 378 packet loss to ensure that the packet loss rate is within 379 acceptable parameters. Packet loss is considered acceptable if a 380 TCP flow across the same network path and experiencing the same 381 network conditions would achieve an average throughput, measured 382 on a reasonable time scale, that is not less than the RTP flow is 383 achieving. This condition can be satisfied by implementing 384 congestion control mechanisms to adapt the transmission rate (or 385 the number of layers subscribed for a layered multicast session), 386 or by arranging for a receiver to leave the session if the loss 387 rate is unacceptably high. 389 The comparison to TCP cannot be specified exactly, but is intended 390 as an "order-of-magnitude" comparison in time scale and 391 throughput. The time scale on which TCP throughput is measured is 392 the round-trip time of the connection. In essence, this 393 requirement states that it is not acceptable to deploy an 394 application (using RTP or any other transport protocol) on the 395 best-effort Internet which consumes bandwidth arbitrarily and does 396 not compete fairly with TCP within an order of magnitude. 398 The phase "order of magnitude" in the above means within a factor of 399 ten, approximately. In order to implement this, it is necessary to 400 estimate the throughput a TCP connection would achieve over the path. 401 For a long-lived TCP Reno connection, Padhye et al. [Padhye] showed 402 that the throughput can be estimated using the following equation: 404 s 405 X = -------------------------------------------------------------- 406 R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p^2))) 408 where: 410 X is the transmit rate in bytes/second. 412 s is the packet size in bytes. If data packets vary in size, then 413 the average size is to be used. 415 R is the round trip time in seconds. 417 p is the loss event rate, between 0 and 1.0, of the number of loss 418 events as a fraction of the number of packets transmitted. 420 t_RTO is the TCP retransmission timeout value in seconds, 421 approximated by setting t_RTO = 4*R. 423 b is the number of packets acknowledged by a single TCP 424 acknowledgement ([RFC3448] recommends the use of b=1 since many 425 TCP implementations do not use delayed acknowledgements). 427 This is the same approach to estimated TCP throughput that is used in 428 [RFC3448]. Under conditions of low packet loss, this formula can be 429 approximated as follows with reasonable accuracy: 431 s 432 X = --------------- 433 R * sqrt(p*2/3) 435 It is RECOMMENDED that this simplified throughout equation be used, 436 since the reduction in accuracy is small, and it is much simpler to 437 calculate than the full equation. 439 Given this TCP equation, two parameters need to be estimated and 440 reported to the sender in order to calculate the throughput: the 441 round trip time, R, and the loss event rate, p (the packet size, s, 442 is known to the sender). The round trip time can be estimated from 443 RTCP SR and RR packets. This is done too infrequently for accurate 444 statistics, but is the best that can be done with the standard RTCP 445 mechanisms. 447 RTCP RR packets contain the packet loss fraction, rather than the 448 loss event rate, so p cannot be reported (TCP typically treats the 449 loss of multiple packets within a single RTT as one loss event, but 450 RTCP RR packets report the overall fraction of packets lost, not 451 caring about when the losses occurred). Using the loss fraction in 452 place of the loss event rate can overestimate the loss. We believe 453 that this overestimate will not be significant, given that we are 454 only interested in order of magnitude comparison ([Floyd] section 455 3.2.1 shows that the difference is small for steady-state conditions 456 and random loss, but using the loss fraction is more conservative in 457 the case of bursty loss). 459 The congestion circuit breaker is therefore: when RTCP RR packets are 460 received, estimate the TCP throughput using the simplified equation 461 above, and the measured R, p (approximated by the loss fraction), and 462 s. Compare this with the actual sending rate. If the actual sending 463 rate is more than ten times the estimated sending rate derived from 464 the TCP throughput equation for two consecutive RTCP reporting 465 intervals, the sender SHOULD cease transmission. What it means to 466 cease transmission depends on the application, but the intention is 467 that the application will stop sending RTP data packets until the 468 user makes an explicit attempt to restart the call (RTP flows halted 469 by the circuit breaker SHOULD NOT be restarted automatically unless 470 the sender has received information that the congestion has 471 dissipated). 473 Systems that usually send at a high data rate, but that can reduce 474 their data rate significantly (i.e., by at least a factor of ten), 475 MAY first reduce their sending rate to this lower value to see if 476 this resolves the congestion, but MUST then cease transmission if the 477 problem does not resolve itself within a further two RTCP reporting 478 intervals. An example of this might be a video conferencing system 479 that backs off to sending audio only, before completely dropping the 480 call. If such a reduction in sending rate resolves the congestion 481 problem, the sender MAY gradually increase the rate at which it sends 482 data after a reasonable amount of time has passed, provided it takes 483 care not to cause the problem to recur ("reasonable" is intentionally 484 not defined here). 486 As in Section 4.1, we use two reporting intervals to avoid triggering 487 the circuit breaker on transient failures. This circuit breaker is a 488 worst-case condition, and congestion control needs to be performed to 489 keep well within this bound. It is expected that the circuit breaker 490 will only be triggered if the usual congestion control fails for some 491 reason. 493 5. RTP Circuit Breakers for Systems Using the RTP/AVPF Profile 495 Use of the Extended RTP Profile for RTCP-based Feedback (RTP/AVPF) 496 [RFC4585] allows receivers to send early RTCP reports in some cases, 497 to inform the sender about particular events in the media stream. 498 There are several use cases for such early RTCP reports, including 499 providing rapid feedback to a sender about the onset of congestion. 501 Receiving rapid feedback about congestion events potentially allows 502 congestion control algorithms to be more responsive, and to better 503 adapt the media transmission to the limitations of the network. It 504 is expected that many RTP congestion control algorithms will adopt 505 the RTP/AVPF profile for this reason, defining new transport layer 506 feedback reports that suit their requirements. Since these reports 507 are not yet defined, and likely very specific to the details of the 508 congestion control algorithm chosen, they cannot be used as part of 509 the generic RTP circuit breaker. 511 If the extension for Reduced-Size RTCP [RFC5506] is not used, early 512 RTCP feedback packets sent according to the RTP/AVPF profile will be 513 compound RTCP packets that include an RTCP SR/RR packet. That RTCP 514 SR/RR packet MUST be processed as if it were sent as a regular RTCP 515 report and counted towards the circuit breaker conditions specified 516 in Section 4.1 and Section 4.3 of this memo. This will potentially 517 make the RTP circuit breaker fire earlier than it would if the RTP/ 518 AVPF profile was not used. 520 Reduced-size RTCP reports sent under to the RTP/AVPF early feedback 521 rules that do not contain an RTCP SR or RR packet MUST be ignored by 522 the RTP circuit breaker (they do not contain the information used by 523 the circuit breaker algorithm). In this case, the circuit breaker 524 will only use the information contained in the periodic RTCP SR/RR 525 packets. This allows the use of low-overhead early RTP/AVPF feedback 526 without triggering the RTP circuit breaker, and so is suitable for 527 RTP congestion control algorithms that need to quickly report loss 528 events in between regular RTCP reports. 530 6. Impact of RTCP XR 532 RTCP Extended Report (XR) blocks provide additional reception quality 533 metrics, but do not change the RTCP timing rules. Some of the RTCP 534 XR blocks provide information that might be useful for congestion 535 control purposes, others provided non-congestion-related metrics. 536 The presence of RTCP XR blocks in a compound RTCP packet does not 537 affect the RTP circuit breaker algorithm; for consistency and ease of 538 implementation, only the reception report blocks contained in RTCP SR 539 or RR packets are used by the RTP circuit breaker algorithm. 541 7. Impact of Explicit Congestion Notification (ECN) 543 ECN-CE marked packets SHOULD be treated as if it were lost for the 544 purposes of congestion control, when determining the optimal media 545 sending rate for an RTP flow. If an RTP sender has negotiated ECN 546 support for an RTP session, and has successfully initiated ECN use on 547 the path to the receiver [RFC6679], then ECN-CE marked packets SHOULD 548 be treated as if they were lost when calculating if the congestion- 549 based RTP circuit breaker (Section 4.3) has been met. 551 The use of ECN for RTP flows does not affect the media timeout RTP 552 circuit breaker (Section 4.1) or the RTCP timeout circuit breaker 553 (Section 4.2), since these are both connectivity checks that simply 554 determinate if any packets are being received. 556 8. Security Considerations 558 The security considerations of [RFC3550] apply. 560 If the RTP/AVPF profile is used to provide rapid RTCP feedback, the 561 security considerations of [RFC4585] apply. If ECN feedback for RTP 562 over UDP/IP is used, the security considerations of [RFC6679] apply. 564 If non-authenticated RTCP reports are used, an on-path attacker can 565 trivially generate fake RTCP packets that indicate high packet loss 566 rates, causing the circuit breaker to trigger and disrupting an RTP 567 session. This is somewhat more difficult for an off-path attacker, 568 due to the need to guess the randomly chosen RTP SSRC value and the 569 RTP sequence number. This attack can be avoided if RTCP packets are 570 authenticated, for example using the Secure RTP profile [RFC3711]. 572 9. IANA Considerations 574 There are no actions for IANA. 576 10. Acknowledgements 578 The authors would like to thank Harald Alvestrand, Randell Jesup, 579 Matt Mathis, and Abheek Saha for their valuable feedback. 581 11. References 583 11.1. Normative References 585 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 586 Requirement Levels", BCP 14, RFC 2119, March 1997. 588 [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP 589 Friendly Rate Control (TFRC): Protocol Specification", 590 RFC 3448, January 2003. 592 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 593 Jacobson, "RTP: A Transport Protocol for Real-Time 594 Applications", STD 64, RFC 3550, July 2003. 596 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 597 Video Conferences with Minimal Control", STD 65, RFC 3551, 598 July 2003. 600 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 601 Protocol Extended Reports (RTCP XR)", RFC 3611, 602 November 2003. 604 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 605 "Extended RTP Profile for Real-time Transport Control 606 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 607 July 2006. 609 11.2. Informative References 611 [Floyd] Floyd, S., Handley, M., Padhye, J., and J. Widmer, 612 "Equation-Based Congestion Control for Unicast 613 Applications", Proc. ACM SIGCOMM 2000, DOI 10.1145/ 614 347059.347397, August 2000. 616 [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard] 617 Clark, A., Huang, R., and W. Wu, "RTP Control 618 Protocol(RTCP) Extended Report (XR) Block for Discard 619 Count metric Reporting", 620 draft-ietf-xrblock-rtcp-xr-burst-gap-discard-06 (work in 621 progress), October 2012. 623 [I-D.ietf-xrblock-rtcp-xr-burst-gap-loss] 624 Clark, A., Zhang, S., Zhao, J., and W. Wu, "RTP Control 625 Protocol (RTCP) Extended Report (XR) Block for Burst/Gap 626 Loss metric Reporting", 627 draft-ietf-xrblock-rtcp-xr-burst-gap-loss-04 (work in 628 progress), October 2012. 630 [I-D.ietf-xrblock-rtcp-xr-delay] 631 Clark, A., Gross, K., and W. Wu, "RTP Control Protocol 632 (RTCP) Extended Report (XR) Block for Delay metric 633 Reporting", draft-ietf-xrblock-rtcp-xr-delay-10 (work in 634 progress), October 2012. 636 [I-D.ietf-xrblock-rtcp-xr-discard] 637 Clark, A., Zorn, G., and W. Wu, "RTP Control Protocol 638 (RTCP) Extended Report (XR) Block for Discard Count metric 639 Reporting", draft-ietf-xrblock-rtcp-xr-discard-09 (work in 640 progress), October 2012. 642 [I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics] 643 Ott, J., Singh, V., and I. Curcio, "RTP Control Protocol 644 (RTCP) Extended Reports (XR) for Run Length Encoding (RLE) 645 of Discarded Packets", 646 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-04 (work in 647 progress), July 2012. 649 [I-D.ietf-xrblock-rtcp-xr-pdv] 650 Clark, A. and W. Wu, "RTP Control Protocol (RTCP) Extended 651 Report (XR) Block for Packet Delay Variation Metric 652 Reporting", draft-ietf-xrblock-rtcp-xr-pdv-08 (work in 653 progress), September 2012. 655 [Padhye] Padhye, J., Firoiu, V., Towsley, D., and J. Kurose, 656 "Modeling TCP Throughput: A Simple Model and its Empirical 657 Validation", Proc. ACM SIGCOMM 1998, DOI 10.1145/ 658 285237.285291, August 1998. 660 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 661 of Explicit Congestion Notification (ECN) to IP", 662 RFC 3168, September 2001. 664 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 665 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 666 RFC 3711, March 2004. 668 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 669 "Codec Control Messages in the RTP Audio-Visual Profile 670 with Feedback (AVPF)", RFC 5104, February 2008. 672 [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in 673 RTP Streams", RFC 5450, March 2009. 675 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 676 Real-Time Transport Control Protocol (RTCP): Opportunities 677 and Consequences", RFC 5506, April 2009. 679 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 680 Flows", RFC 6051, November 2010. 682 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 683 and K. Carlberg, "Explicit Congestion Notification (ECN) 684 for RTP over UDP", RFC 6679, August 2012. 686 Authors' Addresses 688 Colin Perkins 689 University of Glasgow 690 School of Computing Science 691 Glasgow G12 8QQ 692 United Kingdom 694 Email: csp@csperkins.org 696 Varun Singh 697 Aalto University 698 School of Electrical Engineering 699 Otakaari 5 A 700 Espoo, FIN 02150 701 Finland 703 Email: varun@comnet.tkk.fi 704 URI: http://www.netlab.tkk.fi/~varun/