idnits 2.17.1 draft-ietf-avtcore-rtp-circuit-breakers-10.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3550, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3550, updated by this document, for RFC5378 checks: 1998-04-07) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 23, 2015) is 3312 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 (-12) exists of draft-ietf-avtcore-rtp-multi-stream-optimisation-05 == Outdated reference: A later version (-11) exists of draft-ietf-avtcore-rtp-multi-stream-07 == Outdated reference: A later version (-15) exists of draft-ietf-tsvwg-circuit-breaker-00 -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVTCORE Working Group C. S. Perkins 3 Internet-Draft University of Glasgow 4 Updates: 3550 (if approved) V. Singh 5 Intended status: Standards Track Aalto University 6 Expires: September 24, 2015 March 23, 2015 8 Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions 9 draft-ietf-avtcore-rtp-circuit-breakers-10 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; instead, it defines a minimal 19 set of RTP "circuit-breakers". Circuit-breakers are conditions under 20 which an RTP sender needs to stop transmitting media data in order to 21 protect the network from excessive congestion. It is expected that, 22 in the absence of severe congestion, all RTP applications running on 23 best-effort IP networks will be able to run without triggering these 24 circuit breakers. Any future RTP congestion control specification 25 will be expected to operate within the constraints defined by these 26 circuit breakers. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 24, 2015. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. RTP Circuit Breakers for Systems Using the RTP/AVP Profile . 6 66 4.1. RTP/AVP Circuit Breaker #1: Media Timeout . . . . . . . . 7 67 4.2. RTP/AVP Circuit Breaker #2: RTCP Timeout . . . . . . . . 8 68 4.3. RTP/AVP Circuit Breaker #3: Congestion . . . . . . . . . 9 69 4.4. RTP/AVP Circuit Breaker #4: Media Usability . . . . . . . 13 70 4.5. Choice of Circuit Breaker Interval . . . . . . . . . . . 14 71 4.6. Ceasing Transmission . . . . . . . . . . . . . . . . . . 15 72 5. RTP Circuit Breakers and the RTP/AVPF and RTP/SAVPF Profiles 16 73 6. Impact of RTCP Extended Reports (XR) . . . . . . . . . . . . 17 74 7. Impact of RTCP Reporting Groups . . . . . . . . . . . . . . . 17 75 8. Impact of Explicit Congestion Notification (ECN) . . . . . . 18 76 9. Impact of Bundled Media and Layered Coding . . . . . . . . . 18 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 78 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 79 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 80 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 13.1. Normative References . . . . . . . . . . . . . . . . . . 19 82 13.2. Informative References . . . . . . . . . . . . . . . . . 20 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 85 1. Introduction 87 The Real-time Transport Protocol (RTP) [RFC3550] is widely used in 88 voice-over-IP, video teleconferencing, and telepresence systems. 89 Many of these systems run over best-effort UDP/IP networks, and can 90 suffer from packet loss and increased latency if network congestion 91 occurs. Designing effective RTP congestion control algorithms, to 92 adapt the transmission of RTP-based media to match the available 93 network capacity, while also maintaining the user experience, is a 94 difficult but important problem. Many such congestion control and 95 media adaptation algorithms have been proposed, but to date there is 96 no consensus on the correct approach, or even that a single standard 97 algorithm is desirable. 99 This memo does not attempt to propose a new RTP congestion control 100 algorithm. Rather, it proposes a minimal set of "RTP circuit 101 breakers"; conditions under which there is general agreement that an 102 RTP flow is causing serious congestion, and ought to cease 103 transmission. The RTP circuit breakers proposed in this memo are a 104 specific instance of the general class of network transport circuit 105 breakers [I-D.ietf-tsvwg-circuit-breaker], designed to act as a 106 protection mechanism of last resort to avoid persistent congestion. 107 It is expected that future standards-track congestion control 108 algorithms for RTP will operate within the envelope defined by this 109 memo. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 This interpretation of these key words applies only when written in 117 ALL CAPS. Mixed- or lower-case uses of these key words are not to be 118 interpreted as carrying special significance in this memo. 120 3. Background 122 We consider congestion control for unicast RTP traffic flows. This 123 is the problem of adapting the transmission of an audio/visual data 124 flow, encapsulated within an RTP transport session, from one sender 125 to one receiver, so that it matches the available network bandwidth. 126 Such adaptation needs to be done in a way that limits the disruption 127 to the user experience caused by both packet loss and excessive rate 128 changes. Congestion control for multicast flows is outside the scope 129 of this memo. Multicast traffic needs different solutions, since the 130 available bandwidth estimator for a group of receivers will differ 131 from that for a single receiver, and because multicast congestion 132 control has to consider issues of fairness across groups of receivers 133 that do not apply to unicast flows. 135 Congestion control for unicast RTP traffic can be implemented in one 136 of two places in the protocol stack. One approach is to run the RTP 137 traffic over a congestion controlled transport protocol, for example 138 over TCP, and to adapt the media encoding to match the dictates of 139 the transport-layer congestion control algorithm. This is safe for 140 the network, but can be suboptimal for the media quality unless the 141 transport protocol is designed to support real-time media flows. We 142 do not consider this class of applications further in this memo, as 143 their network safety is guaranteed by the underlying transport. 145 Alternatively, RTP flows can be run over a non-congestion controlled 146 transport protocol, for example UDP, performing rate adaptation at 147 the application layer based on RTP Control Protocol (RTCP) feedback. 148 With a well-designed, network-aware, application, this allows highly 149 effective media quality adaptation, but there is potential to disrupt 150 the network's operation if the application does not adapt its sending 151 rate in a timely and effective manner. We consider this class of 152 applications in this memo. 154 Congestion control relies on monitoring the delivery of a media flow, 155 and responding to adapt the transmission of that flow when there are 156 signs that the network path is congested. Network congestion can be 157 detected in one of three ways: 1) a receiver can infer the onset of 158 congestion by observing an increase in one-way delay caused by queue 159 build-up within the network; 2) if Explicit Congestion Notification 160 (ECN) [RFC3168] is supported, the network can signal the presence of 161 congestion by marking packets using ECN Congestion Experienced (CE) 162 marks; or 3) in the extreme case, congestion will cause packet loss 163 that can be detected by observing a gap in the received RTP sequence 164 numbers. Once the onset of congestion is observed, the receiver has 165 to send feedback to the sender to indicate that the transmission rate 166 needs to be reduced. How the sender reduces the transmission rate is 167 highly dependent on the media codec being used, and is outside the 168 scope of this memo. 170 There are several ways in which a receiver can send feedback to a 171 media sender within the RTP framework: 173 o The base RTP specification [RFC3550] defines RTCP Reception Report 174 (RR) packets to convey reception quality feedback information, and 175 Sender Report (SR) packets to convey information about the media 176 transmission. RTCP SR packets contain data that can be used to 177 reconstruct media timing at a receiver, along with a count of the 178 total number of octets and packets sent. RTCP RR packets report 179 on the fraction of packets lost in the last reporting interval, 180 the cumulative number of packets lost, the highest sequence number 181 received, and the inter-arrival jitter. The RTCP RR packets also 182 contain timing information that allows the sender to estimate the 183 network round trip time (RTT) to the receivers. RTCP reports are 184 sent periodically, with the reporting interval being determined by 185 the number of SSRCs used in the session and a configured session 186 bandwidth estimate (the number of SSRCs used is usually two in a 187 unicast session, one for each participant, but can be greater if 188 the participants send multiple media streams). The interval 189 between reports sent from each receiver tends to be on the order 190 of a few seconds on average, although it varies with the session 191 bandwidth, and sub-second reporting intervals are possible in high 192 bandwidth sessions, and it is randomised to avoid synchronisation 193 of reports from multiple receivers. RTCP RR packets allow a 194 receiver to report ongoing network congestion to the sender. 196 However, if a receiver detects the onset of congestion part way 197 through a reporting interval, the base RTP specification contains 198 no provision for sending the RTCP RR packet early, and the 199 receiver has to wait until the next scheduled reporting interval. 201 o The RTCP Extended Reports (XR) [RFC3611] allow reporting of more 202 complex and sophisticated reception quality metrics, but do not 203 change the RTCP timing rules. RTCP extended reports of potential 204 interest for congestion control purposes are the extended packet 205 loss, discard, and burst metrics [RFC3611], [RFC7002], [RFC7097], 206 [RFC7003], [RFC6958]; and the extended delay metrics [RFC6843], 207 [RFC6798]. Other RTCP Extended Reports that could be helpful for 208 congestion control purposes might be developed in future. 210 o Rapid feedback about the occurrence of congestion events can be 211 achieved using the Extended RTP Profile for RTCP-Based Feedback 212 (RTP/AVPF) [RFC4585] (or its secure variant, RTP/SAVPF [RFC5124]) 213 in place of the RTP/AVP profile [RFC3551]. This modifies the RTCP 214 timing rules to allow RTCP reports to be sent early, in some cases 215 immediately, provided the RTCP transmission rate keeps within its 216 bandwidth allocation. It also defines transport-layer feedback 217 messages, including negative acknowledgements (NACKs), that can be 218 used to report on specific congestion events. RTP Codec Control 219 Messages [RFC5104] extend the RTP/AVPF profile with additional 220 feedback messages that can be used to influence that way in which 221 rate adaptation occurs, but do not further change the dynamics of 222 how rapidly feedback can be sent. Use of the RTP/AVPF profile is 223 dependent on signalling. 225 o Finally, Explicit Congestion Notification (ECN) for RTP over UDP 226 [RFC6679] can be used to provide feedback on the number of packets 227 that received an ECN Congestion Experienced (CE) mark. This RTCP 228 extension builds on the RTP/AVPF profile to allow rapid congestion 229 feedback when ECN is supported. 231 In addition to these mechanisms for providing feedback, the sender 232 can include an RTP header extension in each packet to record packet 233 transmission times. There are two methods: [RFC5450] represents the 234 transmission time in terms of a time-offset from the RTP timestamp of 235 the packet, while [RFC6051] includes an explicit NTP-format sending 236 timestamp (potentially more accurate, but a higher header overhead). 237 Accurate sending timestamps can be helpful for estimating queuing 238 delays, to get an early indication of the onset of congestion. 240 Taken together, these various mechanisms allow receivers to provide 241 feedback on the senders when congestion events occur, with varying 242 degrees of timeliness and accuracy. The key distinction is between 243 systems that use only the basic RTCP mechanisms, without RTP/AVPF 244 rapid feedback, and those that use the RTP/AVPF extensions to respond 245 to congestion more rapidly. 247 4. RTP Circuit Breakers for Systems Using the RTP/AVP Profile 249 The feedback mechanisms defined in [RFC3550] and available under the 250 RTP/AVP profile [RFC3551] are the minimum that can be assumed for a 251 baseline circuit breaker mechanism that is suitable for all unicast 252 applications of RTP. Accordingly, for an RTP circuit breaker to be 253 useful, it needs to be able to detect that an RTP flow is causing 254 excessive congestion using only basic RTCP features, without needing 255 RTCP XR feedback or the RTP/AVPF profile for rapid RTCP reports. 257 RTCP is a fundamental part of the RTP protocol, and the mechanisms 258 described here rely on the implementation of RTCP. Implementations 259 that claim to support RTP, but that do not implement RTCP, cannot use 260 the circuit breaker mechanisms described in this memo. Such 261 implementations SHOULD NOT be used on networks that might be subject 262 to congestion unless equivalent mechanisms are defined using some 263 non-RTCP feedback channel to report congestion and signal circuit 264 breaker conditions. 266 Three potential congestion signals are available from the basic RTCP 267 SR/RR packets and are reported for each synchronisation source (SSRC) 268 in the RTP session: 270 1. The sender can estimate the network round-trip time once per RTCP 271 reporting interval, based on the contents and timing of RTCP SR 272 and RR packets. 274 2. Receivers report a jitter estimate (the statistical variance of 275 the RTP data packet inter-arrival time) calculated over the RTCP 276 reporting interval. Due to the nature of the jitter calculation 277 ([RFC3550], section 6.4.4), the jitter is only meaningful for RTP 278 flows that send a single data packet for each RTP timestamp value 279 (i.e., audio flows, or video flows where each packet comprises 280 one video frame). 282 3. Receivers report the fraction of RTP data packets lost during the 283 RTCP reporting interval, and the cumulative number of RTP packets 284 lost over the entire RTP session. 286 These congestion signals limit the possible circuit breakers, since 287 they give only limited visibility into the behaviour of the network. 289 RTT estimates are widely used in congestion control algorithms, as a 290 proxy for queuing delay measures in delay-based congestion control or 291 to determine connection timeouts. RTT estimates derived from RTCP SR 292 and RR packets sent according to the RTP/AVP timing rules are too 293 infrequent to be useful though, and don't give enough information to 294 distinguish a delay change due to routing updates from queuing delay 295 caused by congestion. Accordingly, we cannot use the RTT estimate 296 alone as an RTP circuit breaker. 298 Increased jitter can be a signal of transient network congestion, but 299 in the highly aggregated form reported in RTCP RR packets, it offers 300 insufficient information to estimate the extent or persistence of 301 congestion. Jitter reports are a useful early warning of potential 302 network congestion, but provide an insufficiently strong signal to be 303 used as a circuit breaker. 305 The remaining congestion signals are the packet loss fraction and the 306 cumulative number of packets lost. If considered carefully, these 307 can be effective indicators that congestion is occurring in networks 308 where packet loss is primarily due to queue overflows, although loss 309 caused by non-congestive packet corruption can distort the result in 310 some networks. TCP congestion control [RFC5681] intentionally tries 311 to fill the router queues, and uses the resulting packet loss as 312 congestion feedback. An RTP flow competing with TCP traffic will 313 therefore expect to see a non-zero packet loss fraction that has to 314 be related to TCP dynamics to estimate available capacity. This 315 behaviour of TCP is reflected in the congestion circuit breaker 316 below, and will affect the design of any RTP congestion control 317 protocol. 319 Two packet loss regimes can be observed: 1) RTCP RR packets show a 320 non-zero packet loss fraction, while the extended highest sequence 321 number received continues to increment; and 2) RR packets show a loss 322 fraction of zero, but the extended highest sequence number received 323 does not increment even though the sender has been transmitting RTP 324 data packets. The former corresponds to the TCP congestion avoidance 325 state, and indicates a congested path that is still delivering data; 326 the latter corresponds to a TCP timeout, and is most likely due to a 327 path failure. A third condition is that data is being sent but no 328 RTCP feedback is received at all, corresponding to a failure of the 329 reverse path. We derive circuit breaker conditions for these loss 330 regimes in the following. 332 4.1. RTP/AVP Circuit Breaker #1: Media Timeout 334 If RTP data packets are being sent, but the RTCP SR or RR packets 335 reporting on that SSRC indicate a non-increasing extended highest 336 sequence number received, this is an indication that those RTP data 337 packets are not reaching the receiver. This could be a short-term 338 issue affecting only a few packets, perhaps caused by a slow-to-open 339 firewall or a transient connectivity problem, but if the issue 340 persists, it is a sign of a more ongoing and significant problem. 341 Accordingly, if a sender of RTP data packets receives CB_INTERVAL or 342 more consecutive RTCP SR or RR packets from the same receiver (see 343 Section 4.5), and those packets correspond to its transmission and 344 have a non-increasing extended highest sequence number received 345 field, then that sender SHOULD cease transmission (see Section 4.6). 346 The extended highest sequence number received field is non-increasing 347 if the sender receives at least CB_INTERVAL consecutive RTCP SR or RR 348 packets that report the same value for this field, but it has sent 349 RTP data packets, at a rate of at least one per RTT, that would have 350 caused an increase in the reported value if they had reached the 351 receiver. 353 The rationale for waiting for CB_INTERVAL or more consecutive RTCP 354 packets with a non-increasing extended highest sequence number is to 355 give enough time for transient reception problems to resolve 356 themselves, but to stop problem flows quickly enough to avoid causing 357 serious ongoing network congestion. A single RTCP report showing no 358 reception could be caused by a transient fault, and so will not cease 359 transmission. Waiting for more than CB_INTERVAL consecutive RTCP 360 reports before stopping a flow might avoid some false positives, but 361 could lead to problematic flows running for a long time period 362 (potentially tens of seconds, depending on the RTCP reporting 363 interval) before being cut off. Equally, an application that sends 364 few packets when the packet loss rate is high runs the risk that the 365 media timeout circuit breaker triggers inadvertently. The chosen 366 timeout interval is a trade-off between these extremes. 368 The rationale for enforcing a minimum sending rate below which the 369 media timeout circuit breaker will not trigger is to avoid spurious 370 circuit breaker triggers when the number of packets sent per RTCP 371 reporting interval is small (e.g., a telephony application sends only 372 two RTP comfort noise packets during a five second RTCP reporting 373 interval, and both are lost; this is 100% packet loss, but it seems 374 extreme to terminate the RTP session). The one packet per RTT bound 375 derives from [RFC5405]. 377 4.2. RTP/AVP Circuit Breaker #2: RTCP Timeout 379 In addition to media timeouts, as were discussed in Section 4.1, an 380 RTP session has the possibility of an RTCP timeout. This can occur 381 when RTP data packets are being sent, but there are no RTCP reports 382 returned from the receiver. This is either due to a failure of the 383 receiver to send RTCP reports, or a failure of the return path that 384 is preventing those RTCP reporting from being delivered. In either 385 case, it is not safe to continue transmission, since the sender has 386 no way of knowing if it is causing congestion. Accordingly, an RTP 387 sender that has not received any RTCP SR or RTCP RR packets reporting 388 on the SSRC it is using for three or more of its RTCP reporting 389 intervals SHOULD cease transmission (see Section 4.6). When 390 calculating the timeout, the deterministic RTCP reporting interval, 391 Td, without the randomization factor, and using the fixed minimum 392 interval of Tmin=5 seconds, MUST be used. The rationale for this 393 choice of timeout is as described in Section 6.2 of [RFC3550] ("so 394 that implementations which do not use the reduced value for 395 transmitting RTCP packets are not timed out by other participants 396 prematurely"), as updated by Section 6.1.4 of 397 [I-D.ietf-avtcore-rtp-multi-stream] to account for the use of the RTP 398 /AVPF profile [RFC4585] or the RTP/SAVPF profile [RFC5124]. 400 To reduce the risk of premature timeout, implementations SHOULD NOT 401 configure the RTCP bandwidth such that Td is larger than 5 seconds. 402 Similarly, implementations that use the RTP/AVPF profile [RFC4585] or 403 the RTP/SAVPF profile [RFC5124] SHOULD NOT configure T_rr_interval to 404 values larger than 4 seconds (the reduced limit for T_rr_interval 405 follows Section 6.1.3 of [I-D.ietf-avtcore-rtp-multi-stream]). 407 The choice of three RTCP reporting intervals as the timeout is made 408 following Section 6.3.5 of RFC 3550 [RFC3550]. This specifies that 409 participants in an RTP session will timeout and remove an RTP sender 410 from the list of active RTP senders if no RTP data packets have been 411 received from that RTP sender within the last two RTCP reporting 412 intervals. Using a timeout of three RTCP reporting intervals is 413 therefore large enough that the other participants will have timed 414 out the sender if a network problem stops the data packets it is 415 sending from reaching the receivers, even allowing for loss of some 416 RTCP packets. 418 If a sender is transmitting a large number of RTP media streams, such 419 that the corresponding RTCP SR or RR packets are too large to fit 420 into the network MTU, the receiver will generate RTCP SR or RR 421 packets in a round-robin manner. In this case, the sender SHOULD 422 treat receipt of an RTCP SR or RR packet corresponding to any SSRC it 423 sent on the same 5-tuple of source and destination IP address, port, 424 and protocol, as an indication that the receiver and return path are 425 working, preventing the RTCP timeout circuit breaker from triggering. 427 4.3. RTP/AVP Circuit Breaker #3: Congestion 429 If RTP data packets are being sent, and the corresponding RTCP SR or 430 RR packets show non-zero packet loss fraction and increasing extended 431 highest sequence number received, then those RTP data packets are 432 arriving at the receiver, but some degree of congestion is occurring. 433 The RTP/AVP profile [RFC3551] states that: 435 If best-effort service is being used, RTP receivers SHOULD monitor 436 packet loss to ensure that the packet loss rate is within 437 acceptable parameters. Packet loss is considered acceptable if a 438 TCP flow across the same network path and experiencing the same 439 network conditions would achieve an average throughput, measured 440 on a reasonable time scale, that is not less than the RTP flow is 441 achieving. This condition can be satisfied by implementing 442 congestion control mechanisms to adapt the transmission rate (or 443 the number of layers subscribed for a layered multicast session), 444 or by arranging for a receiver to leave the session if the loss 445 rate is unacceptably high. 447 The comparison to TCP cannot be specified exactly, but is intended 448 as an "order-of-magnitude" comparison in time scale and 449 throughput. The time scale on which TCP throughput is measured is 450 the round-trip time of the connection. In essence, this 451 requirement states that it is not acceptable to deploy an 452 application (using RTP or any other transport protocol) on the 453 best-effort Internet which consumes bandwidth arbitrarily and does 454 not compete fairly with TCP within an order of magnitude. 456 The phase "order of magnitude" in the above means within a factor of 457 ten, approximately. In order to implement this, it is necessary to 458 estimate the throughput a TCP connection would achieve over the path. 459 For a long-lived TCP Reno connection, it has been shown that the TCP 460 throughput can be estimated using the following equation [Padhye]: 462 s 463 X = -------------------------------------------------------------- 464 R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p^2))) 466 where: 468 X is the transmit rate in bytes/second. 470 s is the packet size in bytes. If data packets vary in size, then 471 the average size is to be used. 473 R is the round trip time in seconds. 475 p is the loss event rate, between 0 and 1.0, of the number of loss 476 events as a fraction of the number of packets transmitted. 478 t_RTO is the TCP retransmission timeout value in seconds, generally 479 approximated by setting t_RTO = 4*R. 481 b is the number of packets that are acknowledged by a single TCP 482 acknowledgement; [RFC3448] recommends the use of b=1 since many 483 TCP implementations do not use delayed acknowledgements. 485 This is the same approach to estimated TCP throughput that is used in 486 [RFC3448]. Under conditions of low packet loss the second term on 487 the denominator is small, so this formula can be approximated with 488 reasonable accuracy as follows [Mathis]: 490 s 491 X = ----------------- 492 R * sqrt(2*b*p/3) 494 It is RECOMMENDED that this simplified throughout equation be used, 495 since the reduction in accuracy is small, and it is much simpler to 496 calculate than the full equation. Measurements have shown that the 497 simplified TCP throughput equation is effective as an RTP circuit 498 breaker for multimedia flows sent to hosts on residential networks 499 using ADSL and cable modem links [Singh]. The data shows that the 500 full TCP throughput equation tends to be more sensitive to packet 501 loss and triggers the RTP circuit breaker earlier than the simplified 502 equation. Implementations that desire this extra sensitivity MAY use 503 the full TCP throughput equation in the RTP circuit breaker. Initial 504 measurements in LTE networks have shown that the extra sensitivity is 505 helpful in that environment, with the full TCP throughput equation 506 giving a more balanced circuit breaker response than the simplified 507 TCP equation [Sarker]; other networks might see similar behaviour. 509 No matter what TCP throughput equation is chosen, two parameters need 510 to be estimated and reported to the sender in order to calculate the 511 throughput: the round trip time, R, and the loss event rate, p (the 512 packet size, s, is known to the sender). The round trip time can be 513 estimated from RTCP SR and RR packets. This is done too infrequently 514 for accurate statistics, but is the best that can be done with the 515 standard RTCP mechanisms. 517 Report blocks in RTCP SR or RR packets contain the packet loss 518 fraction, rather than the loss event rate, so p cannot be reported 519 (TCP typically treats the loss of multiple packets within a single 520 RTT as one loss event, but RTCP RR packets report the overall 521 fraction of packets lost, and does not report when the packet losses 522 occurred). Using the loss fraction in place of the loss event rate 523 can overestimate the loss. We believe that this overestimate will 524 not be significant, given that we are only interested in order of 525 magnitude comparison ([Floyd] section 3.2.1 shows that the difference 526 is small for steady-state conditions and random loss, but using the 527 loss fraction is more conservative in the case of bursty loss). 529 The congestion circuit breaker is therefore: when a sender that is 530 transmitting more than one RTP packet per RTT receives an RTCP SR or 531 RR packet that contains a report block for an SSRC it is using, the 532 sender MUST record the value of the fraction lost field in the report 533 block and the time since the last report block was received for that 534 SSRC. If more than CB_INTERVAL (see Section 4.5) report blocks have 535 been received for that SSRC, the sender MUST calculate the average 536 fraction lost over the last CB_INTERVAL reporting intervals, and then 537 estimate the TCP throughput that would be achieved over the path 538 using the chosen TCP throughput equation and the measured values of 539 the round-trip time, R, the loss event rate, p (as approximated by 540 the average fraction lost), and the packet size, s. This estimate of 541 the TCP throughput is then compared with the actual sending rate. If 542 the actual sending rate is more than ten times the TCP throughput 543 estimate, then the congestion circuit breaker is triggered. 545 The average fraction lost is calculated based on the sum, over the 546 last CB_INTERVAL reporting intervals, of the fraction lost in each 547 reporting interval multiplied by the duration of the corresponding 548 reporting interval, divided by the total duration of the last 549 CB_INTERVAL reporting intervals. 551 The rationale for enforcing a minimum sending rate below which the 552 congestion circuit breaker will not trigger is to avoid spurious 553 circuit breaker triggers when the number of packets sent per RTCP 554 reporting interval is small, and hence the fraction lost samples are 555 subject to measurement artefacts. The one packet per RTT bound 556 derives from [RFC5405]. 558 When the congestion circuit breaker is triggered, the sender SHOULD 559 cease transmission (see Section 4.6). However, if the sender is able 560 to reduce its sending rate by a factor of (approximately) ten, then 561 it MAY first reduce its sending rate by this factor (or some larger 562 amount) to see if that resolves the congestion. If the sending rate 563 is reduced in this way and the congestion circuit breaker triggers 564 again after the next CB_INTERVAL RTCP reporting intervals, the sender 565 MUST then cease transmission. An example of such a rate reduction 566 might be a video conferencing system that backs off to sending audio 567 only, before completely dropping the call. If such a reduction in 568 sending rate resolves the congestion problem, the sender MAY 569 gradually increase the rate at which it sends data after a reasonable 570 amount of time has passed, provided it takes care not to cause the 571 problem to recur ("reasonable" is intentionally not defined here). 573 The RTCP reporting interval of the media sender does not affect how 574 quickly congestion circuit breaker can trigger. The timing is based 575 on the RTCP reporting interval of the receiver that generates the SR/ 576 RR packets from which the loss rate and RTT estimate are derived 577 (note that RTCP requires all participants in a session to have 578 similar reporting intervals, else the participant timeout rules in 579 [RFC3550] will not work, so this interval is likely similar to that 580 of the sender). If the incoming RTCP SR or RR packets are using a 581 reduced minimum RTCP reporting interval (as specified in Section 6.2 582 of RFC 3550 [RFC3550] or the RTP/AVPF profile [RFC4585]), then that 583 reduced RTCP reporting interval is used when determining if the 584 circuit breaker is triggered. 586 As in Section 4.1 and Section 4.2, we use CB_INTERVAL reporting 587 intervals to avoid triggering the circuit breaker on transient 588 failures. This circuit breaker is a worst-case condition, and 589 congestion control needs to be performed to keep well within this 590 bound. It is expected that the circuit breaker will only be 591 triggered if the usual congestion control fails for some reason. 593 If there are more media streams that can be reported in a single RTCP 594 SR or RR packet, or if the size of a complete RTCP SR or RR packet 595 exceeds the network MTU, then the receiver will report on a subset of 596 sources in each reporting interval, with the subsets selected round- 597 robin across multiple intervals so that all sources are eventually 598 reported [RFC3550]. When generating such round-robin RTCP reports, 599 priority SHOULD be given to reports on sources that have high packet 600 loss rates, to ensure that senders are aware of network congestion 601 they are causing (this is an update to [RFC3550]). 603 4.4. RTP/AVP Circuit Breaker #4: Media Usability 605 Applications that use RTP are generally tolerant to some amount of 606 packet loss. How much packet loss can be tolerated will depend on 607 the application, media codec, and the amount of error correction and 608 packet loss concealment that is applied. There is an upper bound on 609 the amount of loss can be corrected, however, beyond which the media 610 becomes unusable. Similarly, many applications have some upper bound 611 on the media capture to play-out latency that can be tolerated before 612 the application becomes unusable. The latency bound will depend on 613 the application, but typical values can range from the order of a few 614 hundred milliseconds for voice telephony and interactive conferencing 615 applications, up to several seconds for some video-on-demand systems. 617 As a final circuit breaker, RTP senders SHOULD monitor the reported 618 packet loss and delay to estimate whether the media is likely to be 619 suitable for the intended purpose. If the packet loss rate and/or 620 latency is such that the media has become unusable, and has remained 621 unusable for a significant time period, then the application SHOULD 622 cease transmission. Similarly, receivers SHOULD monitor the quality 623 of the media they receive, and if the quality is unusable for a 624 significant time period, they SHOULD terminate the session. This 625 memo intentionally does not define a bound on the packet loss rate or 626 latency that will result in unusable media, nor does it specify what 627 time period is deemed significant, as these are highly application 628 dependent. 630 Sending media that suffers from such high packet loss or latency that 631 it is unusable at the receiver is both wasteful of resources, and of 632 no benefit to the user of the application. It also is highly likely 633 to be congesting the network, and disrupting other applications. As 634 such, the congestion circuit breaker will almost certainly trigger to 635 stop flows where the media would be unusable due to high packet loss 636 or latency. However, in pathological scenarios where the congestion 637 circuit breaker does not stop the flow, it is desirable that the RTP 638 application cease sending useless traffic. The role of the media 639 usability circuit breaker is to protect the network in such cases. 641 4.5. Choice of Circuit Breaker Interval 643 The CB_INTERVAL parameter determines the number of consecutive RTCP 644 reporting intervals that need to suffer congestion before the media 645 timeout circuit breaker (see Section 4.1) or the congestion circuit 646 breaker (see Section 4.3) triggers. It determines the sensitivity 647 and responsiveness of these circuit breakers. 649 The CB_INTERVAL parameter is set to min(floor(3+(2.5/Td)), 30) RTCP 650 reporting intervals, where Td is the deterministic calculated RTCP 651 interval described in section 6.3.1 of [RFC3550]. This expression 652 gives an CB_INTERVAL that varies as follows: 654 Td | CB_INTERVAL | Time to trigger 655 --------------+------------------------------+----------------- 656 0.016 seconds | 30 RTCP reporting intervals | 0.48 seconds 657 0.033 seconds | 30 RTCP reporting intervals | 0.99 seconds 658 0.100 seconds | 28 RTCP reporting intervals | 2.80 seconds 659 0.500 seconds | 8 RTCP reporting intervals | 4.00 seconds 660 1.000 seconds | 5 RTCP reporting intervals | 5.00 seconds 661 2.000 seconds | 4 RTCP reporting intervals | 8.00 seconds 662 5.000 seconds | 3 RTCP reporting intervals | 15.00 seconds 663 10.000 seconds | 3 RTCP reporting intervals | 30.00 seconds 665 If the RTP/AVPF profile [RFC4585] or the RTP/SAVPF [RFC5124] is used, 666 and the T_rr_interval parameter is used to reduce the frequency of 667 regular RTCP reports, then the value Td in the above expression for 668 the CB_INTERVAL parameter MUST be replaced by max(T_rr_interval, Td). 670 The CB_INTERVAL parameter is calculated on joining the session, and 671 recalculated on receipt of each RTCP packet, after checking whether 672 the media timeout circuit breaker or the congestion circuit breaker 673 has been triggered. 675 To ensure a timely response to persistent congestion, implementations 676 SHOULD NOT configure the RTCP bandwidth such that Td is larger than 5 677 seconds. Similarly, implementations that use the RTP/AVPF profile 678 [RFC4585] or the RTP/SAVPF profile [RFC5124] SHOULD NOT configure 679 T_rr_interval to values larger than 4 seconds (the reduced limit for 680 T_rr_interval follows Section 6.1.3 of 681 [I-D.ietf-avtcore-rtp-multi-stream]). 683 Rationale: If the CB_INTERVAL was always set to the same number of 684 RTCP reporting intervals, this would cause higher rate RTP sessions 685 to trigger the RTP circuit breaker after a shorter time interval than 686 lower rate sessions, because the RTCP reporting interval scales based 687 on the RTP session bandwidth. This is felt to penalise high rate RTP 688 sessions too aggressively. Conversely, scaling CB_INTERVAL according 689 to the inverse of the RTCP reporting interval, so the RTP circuit 690 breaker triggers after a constant time interval, doesn't sufficiently 691 protect the network from congestion caused by high-rate flows. The 692 chosen expression for CB_INTERVAL seeks a balance between these two 693 extremes. It causes higher rate RTP sessions subject to persistent 694 congestion to trigger the RTP circuit breaker after a shorter time 695 interval than do lower rate RTP sessions, while also making the RTP 696 circuit breaker for such sessions less sensitive by requiring the 697 congestion to persist for longer numbers of RTCP reporting intervals. 699 4.6. Ceasing Transmission 701 What it means to cease transmission depends on the application, but 702 the intention is that the application will stop sending RTP data 703 packets to a particular destination 3-tuple (transport protocol, 704 destination port, IP address), until the user makes an explicit 705 attempt to restart the call. It is important that a human user is 706 involved in the decision to try to restart the call, since that user 707 will eventually give up if the calls repeatedly trigger the circuit 708 breaker. This will help avoid problems with automatic redial systems 709 from congesting the network. Accordingly, RTP flows halted by the 710 circuit breaker SHOULD NOT be restarted automatically unless the 711 sender has received information that the congestion has dissipated. 713 It is recognised that the RTP implementation in some systems might 714 not be able to determine if a call set-up request was initiated by a 715 human user, or automatically by some scripted higher-level component 716 of the system. These implementations SHOULD rate limit attempts to 717 restart a call to the same destination 3-tuple as used by a previous 718 call that was recently halted by the circuit breaker. The chosen 719 rate limit ought to not exceed the rate at which an annoyed human 720 caller might redial a misbehaving phone. 722 5. RTP Circuit Breakers and the RTP/AVPF and RTP/SAVPF Profiles 724 Use of the Extended RTP Profile for RTCP-based Feedback (RTP/AVPF) 725 [RFC4585] allows receivers to send early RTCP reports in some cases, 726 to inform the sender about particular events in the media stream. 727 There are several use cases for such early RTCP reports, including 728 providing rapid feedback to a sender about the onset of congestion. 729 The RTP/SAVPF Profile [RFC5124] is a secure variant of the RTP/AVPF 730 profile, that is treated the same in the context of the RTP circuit 731 breaker. These feedback profiles are often used with non-compound 732 RTCP reports [RFC5506] to reduce the reporting overhead. 734 Receiving rapid feedback about congestion events potentially allows 735 congestion control algorithms to be more responsive, and to better 736 adapt the media transmission to the limitations of the network. It 737 is expected that many RTP congestion control algorithms will adopt 738 the RTP/AVPF profile or the RTP/SAVPF profile for this reason, 739 defining new transport layer feedback reports that suit their 740 requirements. Since these reports are not yet defined, and likely 741 very specific to the details of the congestion control algorithm 742 chosen, they cannot be used as part of the generic RTP circuit 743 breaker. 745 Reduced-size RTCP reports sent under the RTP/AVPF early feedback 746 rules that do not contain an RTCP SR or RR packet MUST be ignored by 747 the congestion circuit breaker (they do not contain the information 748 needed by the congestion circuit breaker algorithm), but MUST be 749 counted as received packets for the RTCP timeout circuit breaker. 750 Reduced-size RTCP reports sent under the RTP/AVPF early feedback 751 rules that contain RTCP SR or RR packets MUST be processed by the 752 congestion circuit breaker as if they were sent as regular RTCP 753 reports, and counted towards the circuit breaker conditions specified 754 in Section 4 of this memo. This will potentially make the RTP 755 circuit breaker trigger earlier than it would if the RTP/AVPF profile 756 was not used. 758 When using ECN with RTP (see Section 8), early RTCP feedback packets 759 can contain ECN feedback reports. The count of ECN-CE marked packets 760 contained in those ECN feedback reports is counted towards the number 761 of lost packets reported if the ECN Feedback Report report is sent in 762 an compound RTCP packet along with an RTCP SR/RR report packet. 763 Reports of ECN-CE packets sent as reduced-size RTCP ECN feedback 764 packets without an RTCP SR/RR packet MUST be ignored. 766 These rules are intended to allow the use of low-overhead RTP/AVPF 767 feedback for generic NACK messages without triggering the RTP circuit 768 breaker. This is expected to make such feedback suitable for RTP 769 congestion control algorithms that need to quickly report loss events 770 in between regular RTCP reports. The reaction to reduced-size RTCP 771 SR/RR packets is to allow such algorithms to send feedback that can 772 trigger the circuit breaker, when desired. 774 The RTP/AVPF and RTP/SAVPF profiles include the T_rr_interval 775 parameter that can be used to adjust the regular RTCP reporting 776 interval. The use of the T_rr_interval parameter changes the 777 behaviour of the RTP circuit breaker, as described in Section 4. 779 6. Impact of RTCP Extended Reports (XR) 781 RTCP Extended Report (XR) blocks provide additional reception quality 782 metrics, but do not change the RTCP timing rules. Some of the RTCP 783 XR blocks provide information that might be useful for congestion 784 control purposes, others provided non-congestion-related metrics. 785 With the exception of RTCP XR ECN Summary Reports (see Section 8), 786 the presence of RTCP XR blocks in a compound RTCP packet does not 787 affect the RTP circuit breaker algorithm. For consistency and ease 788 of implementation, only the reception report blocks contained in RTCP 789 SR packets, RTCP RR packets, or RTCP XR ECN Summary Report packets, 790 are used by the RTP circuit breaker algorithm. 792 7. Impact of RTCP Reporting Groups 794 An optimisation for grouping RTCP reception statistics and other 795 feedback in RTP sessions with large numbers of participants is given 796 in [I-D.ietf-avtcore-rtp-multi-stream-optimisation]. This allows one 797 SSRC to act as a representative that sends reports on behalf of other 798 SSRCs that are co-located in the same endpoint and see identical 799 reception quality. When running the circuit breaker algorithms, an 800 endpoint MUST treat a reception report from the representative of the 801 reporting group as if a reception report was received from all 802 members of that group. 804 8. Impact of Explicit Congestion Notification (ECN) 806 The use of ECN for RTP flows does not affect the media timeout RTP 807 circuit breaker (Section 4.1) or the RTCP timeout circuit breaker 808 (Section 4.2), since these are both connectivity checks that simply 809 determinate if any packets are being received. 811 ECN-CE marked packets SHOULD be treated as if it were lost for the 812 purposes of congestion control, when determining the optimal media 813 sending rate for an RTP flow. If an RTP sender has negotiated ECN 814 support for an RTP session, and has successfully initiated ECN use on 815 the path to the receiver [RFC6679], then ECN-CE marked packets SHOULD 816 be treated as if they were lost when calculating if the congestion- 817 based RTP circuit breaker (Section 4.3) has been met. The count of 818 ECN-CE marked RTP packets is returned in RTCP XR ECN summary report 819 packets if support for ECN has been initiated for an RTP session. 821 9. Impact of Bundled Media and Layered Coding 823 The RTP circuit breaker operates on a per-RTP session basis. An RTP 824 sender that participates in several RTP sessions MUST treat each RTP 825 session independently with regards to the RTP circuit breaker. 827 An RTP sender can generate several media streams within a single RTP 828 session, with each stream using a different SSRC. This can happen if 829 bundled media are in use, when using simulcast, or when using layered 830 media coding. By default, each SSRC will be treated independently by 831 the RTP circuit breaker. However, the sender MAY choose to treat the 832 flows (or a subset thereof) as a group, such that a circuit breaker 833 trigger for one flow applies to the group of flows as a whole, and 834 either causes the entire group to cease transmission, or the sending 835 rate of the group to reduce by a factor of ten, depending on the RTP 836 circuit breaker triggered. Grouping flows in this way is expected to 837 be especially useful for layered flows sent using multiple SSRCs, as 838 it allows the layered flow to react as a whole, ceasing transmission 839 on the enhancement layers first to reduce sending rate if necessary, 840 rather than treating each layer independently. 842 10. Security Considerations 844 The security considerations of [RFC3550] apply. 846 If the RTP/AVPF profile is used to provide rapid RTCP feedback, the 847 security considerations of [RFC4585] apply. If ECN feedback for RTP 848 over UDP/IP is used, the security considerations of [RFC6679] apply. 850 If non-authenticated RTCP reports are used, an on-path attacker can 851 trivially generate fake RTCP packets that indicate high packet loss 852 rates, causing the circuit breaker to trigger and disrupting an RTP 853 session. This is somewhat more difficult for an off-path attacker, 854 due to the need to guess the randomly chosen RTP SSRC value and the 855 RTP sequence number. This attack can be avoided if RTCP packets are 856 authenticated; authentication options are discussed in [RFC7201]. 858 Timely operation of the RTP circuit breaker depends on the choice of 859 RTCP reporting interval. If the receiver has a reporting interval 860 that is overly long, then the responsiveness of the circuit breaker 861 decreases. In the limit, the RTP circuit breaker can be disabled for 862 all practical purposes by configuring an RTCP reporting interval that 863 is many minutes duration. This issue is not specific to the circuit 864 breaker: long RTCP reporting intervals also prevent reception quality 865 reports, feedback messages, codec control messages, etc., from being 866 used. Implementations are expected to impose an upper limit on the 867 RTCP reporting interval they are willing to negotiate (based on the 868 session bandwidth and RTCP bandwidth fraction) when using the RTP 869 circuit breaker, as discussed in Section 4.5. 871 11. IANA Considerations 873 There are no actions for IANA. 875 12. Acknowledgements 877 The authors would like to thank Bernard Aboba, Harald Alvestrand, 878 Gorry Fairhurst, Nazila Fough, Kevin Gross, Cullen Jennings, Randell 879 Jesup, Jonathan Lennox, Matt Mathis, Stephen McQuistin, Eric 880 Rescorla, Abheek Saha, Fabio Verdicchio, and Magnus Westerlund for 881 their valuable feedback. 883 13. References 885 13.1. Normative References 887 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 888 Requirement Levels", BCP 14, RFC 2119, March 1997. 890 [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP 891 Friendly Rate Control (TFRC): Protocol Specification", RFC 892 3448, January 2003. 894 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 895 Jacobson, "RTP: A Transport Protocol for Real-Time 896 Applications", STD 64, RFC 3550, July 2003. 898 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 899 Video Conferences with Minimal Control", STD 65, RFC 3551, 900 July 2003. 902 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 903 Protocol Extended Reports (RTCP XR)", RFC 3611, November 904 2003. 906 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 907 "Extended RTP Profile for Real-time Transport Control 908 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 909 2006. 911 13.2. Informative References 913 [Floyd] Floyd, S., Handley, M., Padhye, J., and J. Widmer, 914 "Equation-Based Congestion Control for Unicast 915 Applications", Proceedings of the ACM SIGCOMM conference, 916 2000, DOI 10.1145/347059.347397, August 2000. 918 [I-D.ietf-avtcore-rtp-multi-stream-optimisation] 919 Lennox, J., Westerlund, M., Wu, W., and C. Perkins, 920 "Sending Multiple Media Streams in a Single RTP Session: 921 Grouping RTCP Reception Statistics and Other Feedback", 922 draft-ietf-avtcore-rtp-multi-stream-optimisation-05 (work 923 in progress), February 2015. 925 [I-D.ietf-avtcore-rtp-multi-stream] 926 Lennox, J., Westerlund, M., Wu, W., and C. Perkins, 927 "Sending Multiple Media Streams in a Single RTP Session", 928 draft-ietf-avtcore-rtp-multi-stream-07 (work in progress), 929 March 2015. 931 [I-D.ietf-tsvwg-circuit-breaker] 932 Fairhurst, G., "Network Transport Circuit Breakers", 933 draft-ietf-tsvwg-circuit-breaker-00 (work in progress), 934 September 2014. 936 [Mathis] Mathis, M., Semke, J., Mahdavi, J., and T. Ott, "The 937 macroscopic behavior of the TCP congestion avoidance 938 algorithm", ACM SIGCOMM Computer Communication Review 939 27(3), DOI 10.1145/263932.264023, July 1997. 941 [Padhye] Padhye, J., Firoiu, V., Towsley, D., and J. Kurose, 942 "Modeling TCP Throughput: A Simple Model and its Empirical 943 Validation", Proceedings of the ACM SIGCOMM conference, 944 1998, DOI 10.1145/285237.285291, August 1998. 946 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 947 of Explicit Congestion Notification (ECN) to IP", RFC 948 3168, September 2001. 950 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 951 "Codec Control Messages in the RTP Audio-Visual Profile 952 with Feedback (AVPF)", RFC 5104, February 2008. 954 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 955 Real-time Transport Control Protocol (RTCP)-Based Feedback 956 (RTP/SAVPF)", RFC 5124, February 2008. 958 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 959 for Application Designers", BCP 145, RFC 5405, November 960 2008. 962 [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in 963 RTP Streams", RFC 5450, March 2009. 965 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 966 Real-Time Transport Control Protocol (RTCP): Opportunities 967 and Consequences", RFC 5506, April 2009. 969 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 970 Control", RFC 5681, September 2009. 972 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 973 Flows", RFC 6051, November 2010. 975 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 976 and K. Carlberg, "Explicit Congestion Notification (ECN) 977 for RTP over UDP", RFC 6679, August 2012. 979 [RFC6798] Clark, A. and Q. Wu, "RTP Control Protocol (RTCP) Extended 980 Report (XR) Block for Packet Delay Variation Metric 981 Reporting", RFC 6798, November 2012. 983 [RFC6843] Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol 984 (RTCP) Extended Report (XR) Block for Delay Metric 985 Reporting", RFC 6843, January 2013. 987 [RFC6958] Clark, A., Zhang, S., Zhao, J., and Q. Wu, "RTP Control 988 Protocol (RTCP) Extended Report (XR) Block for Burst/Gap 989 Loss Metric Reporting", RFC 6958, May 2013. 991 [RFC7002] Clark, A., Zorn, G., and Q. Wu, "RTP Control Protocol 992 (RTCP) Extended Report (XR) Block for Discard Count Metric 993 Reporting", RFC 7002, September 2013. 995 [RFC7003] Clark, A., Huang, R., and Q. Wu, "RTP Control Protocol 996 (RTCP) Extended Report (XR) Block for Burst/Gap Discard 997 Metric Reporting", RFC 7003, September 2013. 999 [RFC7097] Ott, J., Singh, V., and I. Curcio, "RTP Control Protocol 1000 (RTCP) Extended Report (XR) for RLE of Discarded Packets", 1001 RFC 7097, January 2014. 1003 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 1004 Sessions", RFC 7201, April 2014. 1006 [Sarker] Sarker, Z., Singh, V., and C.S. Perkins, "An Evaluation of 1007 RTP Circuit Breaker Performance on LTE Networks", 1008 Proceedings of the IEEE Infocom workshop on Communication 1009 and Networking Techniques for Contemporary Video, 2014, 1010 April 2014. 1012 [Singh] Singh, V., McQuistin, S., Ellis, M., and C.S. Perkins, 1013 "Circuit Breakers for Multimedia Congestion Control", 1014 Proceedings of the International Packet Video Workshop, 1015 2013, DOI 10.1109/PV.2013.6691439, December 2013. 1017 Authors' Addresses 1019 Colin Perkins 1020 University of Glasgow 1021 School of Computing Science 1022 Glasgow G12 8QQ 1023 United Kingdom 1025 Email: csp@csperkins.org 1027 Varun Singh 1028 Aalto University 1029 School of Electrical Engineering 1030 Otakaari 5 A 1031 Espoo, FIN 02150 1032 Finland 1034 Email: varun@comnet.tkk.fi 1035 URI: http://www.netlab.tkk.fi/~varun/