idnits 2.17.1 draft-ietf-tsvwg-circuit-breaker-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 18, 2015) is 3083 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1112' is defined on line 1060, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG Working Group G. Fairhurst 3 Internet-Draft University of Aberdeen 4 Intended status: Best Current Practice November 18, 2015 5 Expires: May 21, 2016 7 Network Transport Circuit Breakers 8 draft-ietf-tsvwg-circuit-breaker-09 10 Abstract 12 This document explains what is meant by the term "network transport 13 Circuit Breaker" (CB). It describes the need for circuit breakers 14 for network tunnels and applications when using non-congestion 15 controlled traffic, and explains where circuit breakers are, and are 16 not, needed. It also defines requirements for building a circuit 17 breaker and the expected outcomes of using a circuit breaker within 18 the Internet. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 21, 2016. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Types of Circuit Breaker . . . . . . . . . . . . . . . . 5 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3. Design of a Circuit-Breaker (What makes a good circuit 58 breaker?) . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.1. Functional Components . . . . . . . . . . . . . . . . . . 6 60 4. Requirements for a Network Transport Circuit Breaker . . . . 9 61 5. Other network topologies . . . . . . . . . . . . . . . . . . 12 62 5.1. Use with a multicast control/routing protocol . . . . . . 12 63 5.2. Use with control protocols supporting pre-provisioned 64 capacity . . . . . . . . . . . . . . . . . . . . . . . . 14 65 5.3. Unidirectional Circuit Breakers over Controlled Paths . . 14 66 6. Examples of Circuit Breakers . . . . . . . . . . . . . . . . 15 67 6.1. A Fast-Trip Circuit Breaker . . . . . . . . . . . . . . . 15 68 6.1.1. A Fast-Trip Circuit Breaker for RTP . . . . . . . . . 15 69 6.2. A Slow-trip Circuit Breaker . . . . . . . . . . . . . . . 16 70 6.3. A Managed Circuit Breaker . . . . . . . . . . . . . . . . 16 71 6.3.1. A Managed Circuit Breaker for SAToP Pseudo-Wires . . 17 72 6.3.2. A Managed Circuit Breaker for Pseudowires (PWs) . . . 17 73 7. Examples where circuit breakers may not be needed. . . . . . 18 74 7.1. CBs over pre-provisioned Capacity . . . . . . . . . . . . 18 75 7.2. CBs with tunnels carrying Congestion-Controlled Traffic . 19 76 7.3. CBs with Uni-directional Traffic and no Control Path . . 19 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 79 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 80 11. Revision Notes . . . . . . . . . . . . . . . . . . . . . . . 21 81 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 82 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 83 12.2. Informative References . . . . . . . . . . . . . . . . . 23 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24 86 1. Introduction 88 [RFC2309] discusses the dangers of congestion-unresponsive flows and 89 also states that "all UDP-based streaming applications should 90 incorporate effective congestion avoidance mechanisms". All 91 applications ought to use a full-featured transport (TCP, SCTP, 92 DCCP), and if not, an application (e.g., those using UDP and its UDP- 93 Lite variant) needs to provide appropriate congestion avoidance. 94 Guidance for applications that do not use congestion-controlled 95 transports is provided in [ID-ietf-tsvwg-RFC5405.bis]. Such 96 mechanisms can be designed to react on much shorter timescales than a 97 Circuit Breaker, that only observes a traffic envelope. Congestion- 98 control mechanisms can also interact with an application to more 99 effectively control its sending rate. However, not all traffic is 100 known to respond to the onset of congestion. 102 A network transport Circuit Breaker (CB) is an automatic mechanism 103 that is used to continuously monitor a flow or aggregate set of flows 104 to detect when the flow(s) experience persistent excessive 105 congestion. When this is detected the Circuit Breaker terminates (or 106 significantly reduces the rate of) the flow(s). This is a safety 107 measure to prevent starvation of network resources denying other 108 flows from access to the Internet, such measures are essential for an 109 Internet that is heterogeneous and for traffic that is hard to 110 predict in advance. 112 The term "Circuit Breaker" originates in electricity supply, and has 113 nothing to do with network circuits or virtual circuits. In 114 electricity supply, a Circuit Breaker is intended as a protection 115 mechanism of last resort. Under normal circumstances, a Circuit 116 Breaker ought not to be triggered; it is designed to protect the 117 supply network and attached equipment when there is overload. Just 118 as people do not expect the electrical circuit breaker (or fuse) in 119 their home to be triggered, except when there is a wiring fault or a 120 problem with an electrical appliance. 122 In networking, the Circuit Breaker principle can be used as a 123 protection mechanism of last resort to avoid persistent excessive 124 congestion impacting other flows that share network capacity. 125 Persistent excessive congestion was a feature of the early Internet 126 of the 1980s. This resulted in excess traffic starving another 127 connection from access to the Internet. It was countered by the 128 requirement to use congestion control (CC) by the Transmission 129 Control Protocol (TCP) [Jacobsen88]. These mechanisms operate in 130 Internet hosts to cause TCP connections to "back off" during 131 congestion. The introduction of a congest control in TCP (currently 132 documented in [RFC5681] ensured the stability of the Internet, 133 because it was able to detect congestion and promptly react. This 134 worked well while TCP was by far the dominant traffic in the 135 Internet, and most TCP flows were long-lived (ensuring that they 136 could detect and respond to congestion before the flows terminated). 137 This is no longer the case, and non-congestion-controlled traffic 138 (including many applications of the User Datagram Protocol, UDP) can 139 form a significant proportion of the total traffic traversing a link. 140 The current Internet therefore requires non-congestion-controlled 141 traffic to be considered to avoid persistent excessive congestion 142 impacting other flows. This is expected to also help reduce the 143 potential for "Congestion Collapse" [RFC2914]. 145 In contrast, Circuit Breakers are recommended for non-congestion- 146 controlled Internet flows and for traffic aggregates, e.g., traffic 147 sent using a network tunnel. They operate on timescales much longer 148 than the packet RTT, and trigger under situations of abnormal 149 excessive congestion. People have been implementing what this draft 150 characterizes as Circuit Breakers on an ad hoc basis to protect 151 Internet traffic, this draft therefore provides guidance on how to 152 deploy and use these mechanisms. Later sections provide examples of 153 cases where Circuit Breakers may or may not be desirable. 155 A Circuit Breaker needs to measure (meter) the traffic to determine 156 if the network is experiencing congestion and needs to be designed to 157 trigger robustly when there is persistent excessive congestion. 159 A Circuit Breaker trigger will often utilize a series of successive 160 sample measurements metered at an ingress point and an egress point 161 (either of which could be a transport endpoint). The trigger needs 162 to operate on a timescale much longer than the path round trip time 163 (e.g., seconds to possibly many tens of seconds). This longer period 164 is needed to provide sufficient time for transports (or applications) 165 to adjust their rate following congestion, and for the network load 166 to stabilize after any adjustment. This is to ensure that a Circuit 167 Breaker does not accidentally trigger following a single (or even 168 successive) congestion events (congestion events are what triggers 169 congestion control, and are to be regarded as normal on a network 170 link operating near its capacity). Once triggered, a control 171 function needs to remove traffic from the network, either by 172 disabling the flow or by significantly reducing the level of traffic. 173 This reaction provides the required protection to prevent persistent 174 excessive congestion being experienced by other flows that share the 175 congested part of the network path. 177 Section 4 defines requirements for building a Circuit Breaker. 179 The operational conditions that cause a Circuit Breaker to trigger 180 should be regarded as abnormal. Examples of situations that could 181 trigger a Circuit Breaker include: 183 o anomalous traffic that exceeds the provisioned capacity (or whose 184 traffic characteristics exceed the threshold configured for the 185 Circuit Breaker); 187 o traffic generated by an application at a time when the provisioned 188 network capacity is being utilised for other purposes; 190 o routing changes that cause additional traffic to start using the 191 path monitored by the Circuit Breaker; 193 o misconfiguration of a service/network device where the capacity 194 available is insufficient to support the current traffic 195 aggregate; 197 o misconfiguration of an admission controller or traffic policer 198 that allows more traffic than expected across the path monitored 199 by the Circuit Breaker. 201 In many cases the reason for triggering a Circuit Breaker will not be 202 evident to the source of the traffic (user, application, endpoint, 203 etc). In contrast, an application that uses congestion control will 204 generate elastic traffic that may be expected to regulate the load it 205 introduces under congestion. This will therefore often be a 206 preferred solution for applications that can respond to congestion 207 signals or that can use a congestion-controlled transport. 209 A Circuit Breaker can be used to limit traffic from applications that 210 are unable, or choose not, to use congestion control, or where the 211 congestion control properties of their traffic cannot be relied upon 212 (e.g., traffic carried over a network tunnel). In such 213 circumstances, it is all but impossible for the Circuit Breaker to 214 signal back to the impacted applications, and it may further be the 215 case that applications may have some difficulty determining that a 216 Circuit Breaker has in fact been tripped, and where in the network 217 this happened. Application developers are advised to avoid these 218 circumstances, where possible, by deploying appropriate congestion 219 control mechanisms. 221 1.1. Types of Circuit Breaker 223 There are various forms of network transport Circuit Breaker. These 224 are differentiated mainly on the timescale over which they are 225 triggered, but also in the intended protection they offer: 227 o Fast-Trip Circuit Breakers: The relatively short timescale used by 228 this form of Circuit Breaker is intended to provide protection for 229 network traffic of a single non-responsive flow or related group 230 of non-responsive flows. 232 o Slow-Trip Circuit Breakers: This Circuit Breaker utilizes a longer 233 timescale and is designed to protect network traffic from 234 congestion by non-responsive traffic aggregates. 236 o Managed Circuit Breakers: Utilize the operations and management 237 functions that might be present in a managed service to implement 238 a Circuit Breaker. 240 Examples of each type of Circuit Breaker are provided in section 4. 242 2. Terminology 244 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 245 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 246 document are to be interpreted as described in [RFC2119]. 248 3. Design of a Circuit-Breaker (What makes a good circuit breaker?) 250 Although Circuit Breakers have been talked about in the IETF for many 251 years, there has not yet been guidance on the cases where Circuit 252 Breakers are needed or upon the design of Circuit Breaker mechanisms. 253 This document seeks to offer advice on these two topics. 255 Circuit Breakers are RECOMMENDED for IETF protocols and tunnels that 256 carry non-congestion-controlled Internet flows and for traffic 257 aggregates. This includes traffic sent using a network tunnel. 258 Designers of other protocols and tunnel encapsulations also ought to 259 consider the use of these techniques as a last resort to protect 260 traffic that shares the network path being used. 262 This document defines the requirements for design of a Circuit 263 Breaker and provides examples of how a Circuit Breaker can be 264 constructed. The specifications of individual protocols and tunnel 265 encapsulations need to detail the protocol mechanisms needed to 266 implement a Circuit Breaker. 268 Section 3.1 describes the functional components of a Circuit Breaker 269 and section 3.2 defines requirements for implementing a Circuit 270 Breaker. 272 3.1. Functional Components 274 The basic design of a transport Circuit Breaker involves 275 communication between an ingress point (a sender) and an egress point 276 (a receiver) of a network flow or set of flows. A simple picture of 277 Circuit Breaker operation is provided in figure 1. This shows a set 278 of routers (each labelled R) connecting a set of endpoints. 280 In this example, a Circuit Breaker is used to control traffic passing 281 through a subset of these routers, acting between the ingress and a 282 egress point network devices. The path between the ingress and 283 egress could be provided by a tunnel or other network-layer 284 technique. One expected use would be at the ingress and egress of a 285 service, where all traffic being considered terminates beyond the 286 egress point, and hence the ingress and egress carry the same set of 287 flows. 289 +--------+ +--------+ 290 |Endpoint| |Endpoint| 291 +--+-----+ >>> Circuit Breaker traffic >>> +--+-----+ 292 | | 293 | +-+ +-+ +---------+ +-+ +-+ +-+ +--------+ +-+ +-+ | 294 +-+R+--+R+->+ Ingress +--+R+--+R+--+R+--+ Egress |--+R+--+R+-+ 295 +++ +-+ +------+--+ +-+ +-+ +-+ +-----+--+ +++ +-+ 296 | ^ | | | 297 | | +--+------+ +------+--+ | 298 | | | Ingress | | Egress | | 299 | | | Meter | | Meter | | 300 | | +----+----+ +----+----+ | 301 | | | | | 302 +-+ | | +----+----+ | | +-+ 303 |R+--+ | | Measure +<----------------+ +--+R| 304 +++ | +----+----+ Reported +++ 305 | | | Egress | 306 | | +----+----+ Measurement | 307 +--+-----+ | | Trigger + +--+-----+ 308 |Endpoint| | +----+----+ |Endpoint| 309 +--------+ | | +--------+ 310 +---<---+ 311 Reaction 313 Figure 1: A CB controlling the part of the end-to-end path between an 314 ingress point and an egress point. (Note: In some cases, the trigger 315 and measure functions could alternatively be located at other 316 locations (e.g., at a network operations centre.) 318 In the context of a Circuit Breaker, the ingress and egress functions 319 could be implemented in different places. For example, they could be 320 located in network devices at a tunnel ingress and at the tunnel 321 egress. In some cases, they could be located at one or both network 322 endpoints (see figure 2), e.g., implemented as components within a 323 transport protocol. 325 +----------+ +----------+ 326 | Ingress | +-+ +-+ +-+ | Egress | 327 | Endpoint +->+R+--+R+--+R+--+ Endpoint | 328 +--+----+--+ +-+ +-+ +-+ +----+-----+ 329 ^ | | 330 | +--+------+ +----+----+ 331 | | Ingress | | Egress | 332 | | Meter | | Meter | 333 | +----+----+ +----+----+ 334 | | | 335 | +--- +----+ | 336 | | Measure +<-----------------+ 337 | +----+----+ Reported 338 | | Egress 339 | +----+----+ Measurement 340 | | Trigger | 341 | +----+----+ 342 | | 343 +---<--+ 344 Reaction 346 Figure 2: An endpoint CB implemented at the sender (ingress) and 347 receiver (egress). 349 The set of components needed to implement a Circuit Breaker are: 351 1. An ingress meter (at the sender or tunnel ingress) records the 352 number of packets/bytes sent in each measurement interval. This 353 measures the offered network load for a flow or set of flows. 354 For example, the measurement interval could be many seconds (or 355 every few tens of seconds or a series of successive shorter 356 measurements that are combined by the Circuit Breaker Measurement 357 function). 359 2. An egress meter (at the receiver or tunnel egress) records the 360 number/bytes received in each measurement interval. This 361 measures the supported load for the flow or set of flows, and 362 could utilize other signals to detect the effect of congestion 363 (e.g., loss/marking experienced over the path). The measurements 364 at the egress could be synchronised (including an offset for the 365 time of flight of the data, or referencing the measurements to a 366 particular packet) to ensure any counters refer to the same span 367 of packets. 369 3. The measured values (measurements) at the ingress and egress are 370 communicated to the Circuit Breaker Measurement function. This 371 could use several methods including: Sending return measurement 372 packets from a receiver to a trigger function at the sender; An 373 implementation using Operations, Administration and Management 374 (OAM); or be sending another in-band signalling datagram to the 375 trigger function. This could also be implemented purely as a 376 control plane function, e.g., using a software-defined network 377 controller. 379 4. The measurement function combines the ingress and egress 380 measurements to assess the present level of network congestion. 381 (For example, the loss rate for each measurement interval could 382 be deduced from calculating the difference between ingress and 383 egress counter values.) Note that methods do not require high 384 accuracy for the period of the measurement interval (or therefore 385 the measured value), since isolated and/or infrequent loss events 386 need to be disregarded. 388 5. A trigger function determines whether the measurements indicate 389 persistent excessive congestion. This function defines an 390 appropriate trigger interval and threshold for determining that 391 there is persistent excessive congestion between the ingress and 392 egress. This preferably considers a rate or ratio, rather than 393 an absolute value (e.g., more than 10% loss, but other methods 394 could also be based on the rate of transmission as well as the 395 loss rate). The transport Circuit Breaker is triggered when the 396 threshold is exceeded in multiple measurement intervals (e.g., 3 397 measurements within the triggering interval [RFC4553]). Designs 398 need to be robust so that single or spurious events do not 399 trigger a reaction. 401 6. A reaction that is applied at the Ingress when the Circuit 402 Breaker is triggered. This seeks to automatically remove the 403 traffic causing persistent excessive congestion. 405 7. A method for control communication control between the components 406 that provides appropriate security and is robust when ingress and 407 egress measurements are not available. 409 4. Requirements for a Network Transport Circuit Breaker 411 The requirements for implementing a Circuit Breaker are: 413 o A Circuit Breaker REQUIRED to define a measurement function to 414 measure the level of congestion or loss. This does not have to 415 detect individual packet loss, but MUST specify a way to know that 416 packets have been lost/marked from the traffic flow. If Explicit 417 Congestion Notification (ECN) is enabled [RFC3168], an egress 418 meter MAY also count the number of ECN congestion marks/event per 419 measurement interval, but even if ECN is used, loss MUST still be 420 measured, since this better reflects the impact of persistent 421 excessive congestion. In this context, loss represents a reliable 422 indication of congestion, as opposed to the finer-grain marking of 423 incipient congestion that can be provided via ECN. 425 o A Circuit Breaker is REQUIRED to define the period over each 426 measurement is made by the Circuit Breaker measurement function. 427 The measurement period MUST be longer than the time that current 428 congestion control mechanisms need to reduce their rate following 429 detection of congestion. This is important because end-to-end 430 congestion control mechanisms require at least one RTT to notify 431 and adjust the traffic to experienced congestion, and congestion 432 bottlenecks can share traffic with a diverse range of RTTs. A 433 sufficiently long period is needed to avoid additionally 434 penalizing flows with a long path RTT. The type of Circuit 435 Breaker will determine how long this measurement period needs to 436 be, but it needs to be significantly longer than the RTT 437 experienced by the Circuit Breaker itself. 439 o If necessary, the measurement period MAY combine successive 440 individual meter samples from the ingress and egress to ensure 441 observation over a sufficiently long interval. (Note when meter 442 samples need to be combined, the combination needs to reflect the 443 sum of the individual sample counts divided by the total time/ 444 volume over which the samples were measured. Individual samples 445 over different intervals can not be directly combined to generate 446 an average value.) 448 o A Circuit Breaker is REQUIRED to define the triggering interval. 449 This is the period over which the trigger uses the collected 450 measurements. 452 o A Circuit Breaker is REQUIRED to define a threshold to determine 453 whether the measurements indicate that congestion is excessive. 454 This SHOULD be constructed so that it does not trigger under light 455 or intermittent congestion and MUST be robust to multiple 456 congestion events per triggering period. For example, a Circuit 457 Breaker is expected to monitor over several measurement periods to 458 determine whether the Circuit Breaker is to be triggered. (e.g., 459 triggered when persistent excessive congestion is detected in at 460 least 3 of the measurement periods within the triggering 461 interval). 463 o Once triggered, the Circuit Breaker MUST react decisively by 464 disabling or significantly reducing traffic at the source (e.g., 465 ingress). The reaction needs to be much more severe than that of 466 a congestion control mechanism (such as TCP's congestion control 467 [RFC5681] or TCP-Friendly Rate Control, TFRC [RFC5348]), because 468 the Circuit Breaker reacts to more persistent excessive congestion 469 and operates over longer timescales (i.e., the overload condition 470 will have persisted for a longer time before the Circuit Breaker 471 is triggered). 473 o The default response to a trigger SHOULD cause the ingress to 474 disable all of the traffic flows managed by the Circuit Breaker. 476 o A reaction that instead results in a reduction SHOULD reduce the 477 traffic by at least an order of magnitude. A response that 478 achieves the reduction by terminating flows, rather than 479 uniformally dropping packets across multiple flows, will often be 480 more desirable to users of the service. A Circuit Breaker that 481 reduces the rate of a flow, MUST continue to monitor the level of 482 congestion and MUST further react to reduce the rate if the 483 Circuit Breaker is again triggered. 485 o The reaction to a triggered Circuit Breaker MUST continue for a 486 period that is at least the triggering interval. Operator 487 intervention will usually be required to restore a flow. If an 488 automated response is needed to reset the trigger, then this needs 489 to not be immediate. The design of an automated reset mechanism 490 needs to be sufficiently conservative that it does not adversely 491 interact with other mechanisms (including other Circuit Breaker 492 mechanisms that control traffic over a common path). It SHOULD 493 NOT perform an automated reset when there is evidence of continued 494 congestion. 496 o When a Circuit Breaker is triggered, it SHOULD be regarded as an 497 abnormal network event. As such, this event SHOULD be logged. 498 The measurements that lead to triggering of the Circuit Breaker 499 SHOULD also be logged. 501 o A Circuit Breaker needs a communication path for control between 502 the ingress and the egress meters and other components. The 503 source and integrity of control information (measurements and 504 triggers) MUST be protected from off-path attacks (Section 8). 505 When there is a risk of on-path attack, a cryptographic 506 authentication mechanism for all control/measurement messages is 507 RECOMMENDED (Section 8). 509 o Control communication can be in-band or out-of-band. In-band 510 communication is RECOMMENDED when either design would be possible. 511 If this traffic is sent over a shared path, it is RECOMMENDED that 512 this control traffic is prioritized to reduce the probability of 513 loss under congestion. 515 in-Band: An in-band control method SHOULD assume that loss of 516 control messages is an indication of potential congestion on 517 the path, and repeated loss (e.g., failure to receive 518 measurement reports) ought to cause the Circuit Breaker to be 519 triggered. (Because the feedback signal could itself be lost 520 under congestion, this needs to confirm the absence of 521 congestion, rather than relying on the successful transmission 522 of a "congested" signal back to the sender.) This design has 523 the advantage that it provides fate-sharing of the traffic 524 flow(s) and the control communications. 526 Out-of-Band: An out-of-band control method SHOULD NOT trigger 527 Circuit Breaker reaction when there is loss of control messages 528 (e.g., a loss of measurement reports). This avoids failure 529 amplification/propagation when the measurement and data paths 530 fail independently. A failure of an out-of-band communication 531 path SHOULD be regarded as abnormal network event and be 532 handled as appropriate for the network, e.g., this event SHOULD 533 be logged, and additional network operator action might be 534 appropriate, depending on the network and the traffic involved. 536 o The Circuit Breaker MUST be designed to be robust to loss of 537 control messages that can also be experienced during congestion/ 538 overload. This does not imply that it is desirable to provide 539 reliable delivery (e.g., over TCP), since this can incur 540 additional delay in responding to congestion. Appropriate 541 mechanisms could duplicate control messages over time to provide 542 increased robustness to loss, or/and to regard a lack of control 543 traffic as an indication that excessive congestion may be being 544 experienced [ID-ietf-tsvwg-RFC5405.bis]. 546 o The volume of control traffic ought to be considered when 547 provisioning a network that uses a Circuit Breaker. 549 5. Other network topologies 551 A Circuit Breaker can be deployed in networks with topologies 552 different to that presented in figure 2. This section describes 553 examples of such usage, and possible places where functions may be 554 implemented. 556 5.1. Use with a multicast control/routing protocol 557 +----------+ +--------+ +----------+ 558 | Ingress | +-+ +-+ +-+ | Egress | | Egress | 559 | Endpoint +->+R+--+R+--+R+--+ Router |--+ Endpoint +->+ 560 +----+-----+ +-+ +-+ +-+ +---+--+-+ +----+-----+ | 561 ^ ^ ^ ^ | ^ | | 562 | | | | | | | | 563 +----+----+ + - - - < - - - - + | +----+----+ | Reported 564 | Ingress | multicast Prune | | Egress | | Ingress 565 | Meter | | | Meter | | Measurement 566 +---------+ | +----+----+ | 567 | | | 568 | +----+----+ | 569 | | Measure +<--+ 570 | +----+----+ 571 | | 572 | +----+----+ 573 multicast | | Trigger | 574 Leave | +----+----+ 575 Message | | 576 +----<----+ 578 Figure 3: An example of a multicast CB controlling the end-to-end 579 path between an ingress endpoint and an egress endpoint. 581 Figure 3 shows one example of how a multicast Circuit Breaker could 582 be implemented at a pair of multicast endpoints (e.g., to implement a 583 Fast-Trip Circuit Breaker, Section 6.1). The ingress endpoint (the 584 sender that sources the multicast traffic) meters the ingress load, 585 generating an ingress measurement (e.g., recording timestamped packet 586 counts), and sends this measurement to the multicast group together 587 with the traffic it has measured. 589 Routers along a multicast path forward the multicast traffic 590 (including the ingress measurement) to all active endpoint receivers. 591 Each last hop (egress) router forwards the traffic to one or more 592 egress endpoint(s). 594 In this figure, each endpoint includes a meter that performs a local 595 egress load measurement. An endpoint also extracts the received 596 ingress measurement from the traffic, and compares the ingress and 597 egress measurements to determine if the Circuit Breaker ought to be 598 triggered. This measurement has to be robust to loss (see previous 599 section). If the Circuit Breaker is triggered, it generates a 600 multicast leave message for the egress (e.g., an IGMP or MLD message 601 sent to the last hop multicast router), which causes the upstream 602 multicast router to cease forwarding traffic to the egress endpoint. 604 Any multicast router that has no active receivers for a particular 605 multicast group will prune traffic for that group, sending a prune 606 message to its upstream router. This starts the process of releasing 607 the capacity used by the traffic and is a standard multicast routing 608 function (e.g., using the PIM-SM routing protocol). Each egress 609 operates autonomously, and the Circuit Breaker reaction is executed 610 by the multicast control plane (e.g., by the PIM multicast routing 611 protocol), requiring no explicit signalling by the Circuit Breaker 612 along the communication path used for the control messages. Note: In 613 this example, there is no direct communication back to the Ingress, 614 and hence a triggered Circuit Breaker only controls traffic 615 downstream of the first hop router. It does not stop traffic flowing 616 from the sender to the first hop router; this is however the common 617 practice for multicast deployment. 619 The method could also be used with a multicast tunnel or subnetwork 620 (e.g., Section 6.2, Section 6.3), where a meter at the ingress 621 generates additional control messages to carry the measurement data 622 towards the point where the egress metering is implemented. 624 5.2. Use with control protocols supporting pre-provisioned capacity 626 Some network paths are provisioned using a control protocol, e.g., 627 flows provisioned using the Multi-Protocol Label Switching (MPLS) 628 services, path provisioned using the Resource reservation protocol 629 (RSVP), networks utilizing Software Defined Network (SDN) functions, 630 or admission-controlled Differentiated Services. 632 Figure 1 shows one expected use case, where in this usage a separate 633 device could perform the measurement and trigger functions. The 634 reaction generated by the trigger could take the form of a network 635 control message sent to the ingress and/or other network elements 636 causing these elements to react to the Circuit Breaker. Examples of 637 this type of use are provided in section Section 6.3. 639 5.3. Unidirectional Circuit Breakers over Controlled Paths 641 A Circuit Breaker can be used to control uni-directional traffic 642 where the traffic does not itself provide congestion control (e.g., 643 there is no feedback of congestion information at the transport or 644 higher layers), providing that there is a communication path that can 645 be used for control messages to connect the functional components at 646 the Ingress and Egress. This communication path for the control 647 messages can exist in networks for which the traffic flow is purely 648 unidirectional. For example, a multicast stream that sends packets 649 across an Internet path and can use multicast routing to prune flows 650 to shed network load. Some other types of subnetwork also utilize 651 control protocols that can be used to control traffic flows. 653 6. Examples of Circuit Breakers 655 There are multiple types of Circuit Breaker that could be defined for 656 use in different deployment cases. This section provides examples of 657 different types of Circuit Breaker: 659 6.1. A Fast-Trip Circuit Breaker 661 A fast-trip Circuit Breaker is the most responsive form of Circuit 662 Breaker. It has a response time that is only slightly larger than 663 that of the traffic that it controls. It is suited to traffic with 664 well-understood characteristics (and could include one or more 665 trigger functions specifically tailored the type of traffic for which 666 it is designed). It is not suited to arbitrary network traffic and 667 may be unsuitable for traffic aggregates, since it could prematurely 668 trigger (e.g., when multiple congestion-controlled flows lead to 669 short-term overload). 671 Although the mechanisms can be implemented in a RTP-aware network 672 devices, these mechanisms are also suitable for implementation in 673 endpoints (e.g., as a part of the transport system), where they can 674 also compliment end-to-end congestion control mechanism. A shorter 675 response time enables these mechanisms to triggers before other forms 676 of Circuit Breaker (e.g., Circuit Breakers operating on traffic 677 aggregates at a point along the network path). 679 6.1.1. A Fast-Trip Circuit Breaker for RTP 681 A set of fast-trip Circuit Breaker methods have been specified for 682 use together by a Real-time Transport Protocol (RTP) flow using the 683 RTP/AVP Profile [RTP-CB]. It is expected that, in the absence of 684 severe congestion, all RTP applications running on best-effort IP 685 networks will be able to run without triggering these Circuit 686 Breakers. A fast-trip RTP Circuit Breaker is therefore implemented 687 as a fail-safe that when triggered will terminate RTP traffic. 689 The sending endpoint monitors reception of in-band RTP Control 690 Protocol (RTCP) reception report blocks, as contained in SR or RR 691 packets, that convey reception quality feedback information. This is 692 used to measure (congestion) loss, possibly in combination with ECN 693 [RFC6679]. 695 The Circuit Breaker reaction (shutdown of the flow) is triggered when 696 any of the following trigger conditions are true: 698 1. An RTP Circuit Breaker triggers on reported lack of progress. 700 2. An RTP Circuit Breaker triggers when no receiver reports messages 701 are received. 703 3. An RTP Circuit Breaker uses a TFRC-style check and sets a hard 704 upper limit to the long-term RTP throughput (over many RTTs). 706 4. An RTP Circuit Breaker includes the notion of Media Usability. 707 This Circuit Breaker is triggered when the quality of the 708 transported media falls below some required minimum acceptable 709 quality. 711 6.2. A Slow-trip Circuit Breaker 713 A slow-trip Circuit Breaker could be implemented in an endpoint or 714 network device. This type of Circuit Breaker is much slower at 715 responding to congestion than a fast-trip Circuit Breaker and is 716 expected to be more common. 718 One example where a slow-trip Circuit Breaker is needed is where 719 flows or traffic-aggregates use a tunnel or encapsulation and the 720 flows within the tunnel do not all support TCP-style congestion 721 control (e.g., TCP, SCTP, TFRC), see [ID-ietf-tsvwg-RFC5405.bis] 722 section 3.1.3. A use case is where tunnels are deployed in the 723 general Internet (rather than "controlled environments" within an 724 Internet service provider or enterprise network), especially when the 725 tunnel could need to cross a customer access router. 727 6.3. A Managed Circuit Breaker 729 A managed Circuit Breaker is implemented in the signalling protocol 730 or management plane that relates to the traffic aggregate being 731 controlled. This type of Circuit Breaker is typically applicable 732 when the deployment is within a "controlled environment". 734 A Circuit Breaker requires more than the ability to determine that a 735 network path is forwarding data, or to measure the rate of a path - 736 which are often normal network operational functions. There is an 737 additional need to determine a metric for congestion on the path and 738 to trigger a reaction when a threshold is crossed that indicates 739 persistent excessive congestion. 741 The control messages can use either in-band or out-of-band 742 communications. 744 6.3.1. A Managed Circuit Breaker for SAToP Pseudo-Wires 746 [RFC4553], SAToP Pseudo-Wires (PWE3), section 8 describes an example 747 of a managed Circuit Breaker for isochronous flows. 749 If such flows were to run over a pre-provisioned (e.g., Multi- 750 Protocol Label Switching, MPLS) infrastructure, then it could be 751 expected that the Pseudowire (PW) would not experience congestion, 752 because a flow is not expected to either increase (or decrease) their 753 rate. If instead Pseudo-Wire traffic is multiplexed with other 754 traffic over the general Internet, it could experience congestion. 755 [RFC4553] states: "If SAToP PWs run over a PSN providing best-effort 756 service, they SHOULD monitor packet loss in order to detect "severe 757 congestion". The currently recommended measurement period is 1 758 second, and the trigger operates when there are more than three 759 measured Severely Errored Seconds (SES) within a period. If such a 760 condition is detected, a SAToP PW ought to shut down bidirectionally 761 for some period of time...". 763 The concept was that when the packet loss ratio (congestion) level 764 increased above a threshold, the PW was by default disabled. This 765 use case considered fixed-rate transmission, where the PW had no 766 reasonable way to shed load. 768 The trigger needs to be set at the rate that the PW was likely to 769 experience a serious problem, possibly making the service non- 770 compliant. At this point, triggering the Circuit Breaker would 771 remove the traffic preventing undue impact on congestion-responsive 772 traffic (e.g., TCP). Part of the rationale, was that high loss 773 ratios typically indicated that something was "broken" and ought to 774 have already resulted in operator intervention, and therefore need to 775 trigger this intervention. 777 An operator-based response provides opportunity for other action to 778 restore the service quality, e.g., by shedding other loads or 779 assigning additional capacity, or to consciously avoid reacting to 780 the trigger while engineering a solution to the problem. This could 781 require the trigger to be sent to a third location (e.g., a network 782 operations centre, NOC) responsible for operation of the tunnel 783 ingress, rather than the tunnel ingress itself. 785 6.3.2. A Managed Circuit Breaker for Pseudowires (PWs) 787 Pseudowires (PWs) [RFC3985] have become a common mechanism for 788 tunneling traffic, and may compete for network resources both with 789 other PWs and with non-PW traffic, such as TCP/IP flows. 791 [ID-ietf-pals-congcons] discusses congestion conditions that can 792 arise when PWs compete with elastic (i.e., congestion responsive) 793 network traffic (e.g, TCP traffic). Elastic PWs carrying IP traffic 794 (see [RFC4488]) do not raise major concerns because all of the 795 traffic involved responds, reducing the transmission rate when 796 network congestion is detected. 798 In contrast, inelastic PWs (e.g., a fixed bandwidth Time Division 799 Multiplex, TDM) [RFC4553] [RFC5086] [RFC5087]) have the potential to 800 harm congestion responsive traffic or to contribute to excessive 801 congestion because inelastic PWs do not adjust their transmission 802 rate in response to congestion. [ID-ietf-pals-congcons] analyses TDM 803 PWs, with an initial conclusion that a TDM PW operating with a degree 804 of loss that may result in congestion-related problems is also 805 operating with a degree of loss that results in an unacceptable TDM 806 service. For that reason, the draft suggests that a managed Circuit 807 Breaker that shuts down a PW when it persistently fails to deliver 808 acceptable TDM service is a useful means for addressing these 809 congestion concerns. 811 7. Examples where circuit breakers may not be needed. 813 A Circuit Breaker is not required for a single congestion-controlled 814 flow using TCP, SCTP, TFRC, etc. In these cases, the congestion 815 control mechanisms are already designed to prevent persistent 816 excessive congestion. 818 7.1. CBs over pre-provisioned Capacity 820 One common question is whether a Circuit Breaker is needed when a 821 tunnel is deployed in a private network with pre-provisioned 822 capacity. 824 In this case, compliant traffic that does not exceed the provisioned 825 capacity ought not to result in persistent excessive congestion. A 826 Circuit Breaker will hence only be triggered when there is non- 827 compliant traffic. It could be argued that this event ought never to 828 happen - but it could also be argued that the Circuit Breaker equally 829 ought never to be triggered. If a Circuit Breaker were to be 830 implemented, it will provide an appropriate response if persistent 831 excessive congestion occurs in an operational network. 833 Implementing a Circuit Breaker will not reduce the performance of the 834 flows, but in the event that persistent excessive congestion occurs, 835 it protects network traffic that shares network capacity with these 836 flows. A Circuit Breaker also could be used to protect other sharing 837 network traffic from a failure that causes the Circuit Breaker 838 traffic to be routed over a non-pre-provisioned path. 840 7.2. CBs with tunnels carrying Congestion-Controlled Traffic 842 IP-based traffic is generally assumed to be congestion-controlled, 843 i.e., it is assumed that the transport protocols generating IP-based 844 traffic at the sender already employ mechanisms that are sufficient 845 to address congestion on the path [ID-ietf-tsvwg-RFC5405.bis]. A 846 question therefore arises when people deploy a tunnel that is thought 847 to only carry an aggregate of TCP (or some other congestion control) 848 traffic: Is there advantage in this case in using a Circuit Breaker? 850 For sure, traffic in a such a tunnel will respond to congestion. 851 However, the answer to the question is not always obvious, because 852 the overall traffic formed by an aggregate of flows that implement a 853 congestion control mechanism does not necessarily prevent persistent 854 excessive congestion. For instance, most congestion control 855 mechanisms require long-lived flows to react to reduce the rate of a 856 flow, an aggregate of many short flows could result in many 857 terminating before they experience congestion. It is also often 858 impossible for a tunnel service provider to know that the tunnel only 859 contains congestion-controlled traffic (e.g., Inspecting packet 860 headers could not be possible). The important thing to note is that 861 if the aggregate of the traffic does not result in persistent 862 excessive congestion (impacting other flows), then the Circuit 863 Breaker will not trigger. This is the expected case in this context 864 - so implementing an appropriately configured Circuit Breaker will 865 not reduce performance of the tunnel, but in the event that 866 persistent excessive congestion occurs this protects other network 867 traffic that shares capacity with the tunnel traffic. 869 7.3. CBs with Uni-directional Traffic and no Control Path 871 A one-way forwarding path could have no associated communication path 872 for sending control messages, and therefore cannot be controlled 873 using an automated process. This service could be provided using a 874 path that has dedicated capacity and does not share this capacity 875 with other elastic Internet flows (i.e., flows that vary their rate 876 and respond to congestion indications). 878 A way to mitigate the impact on other flows when capacity could be 879 shared is to manage the traffic envelope by using ingress policing.S. 881 Supporting this type of traffic in the general Internet requires 882 operator monitoring to detect and respond to persistent excessive 883 congestion. 885 8. Security Considerations 887 All Circuit Breaker mechanisms rely upon coordination between the 888 ingress and egress meters and communication with the trigger 889 function. This is usually achieved by passing network control 890 information (or protocol messages) across the network. Timely 891 operation of a Circuit Breaker depends on the choice of measurement 892 period. If the receiver has an interval that is overly long, then 893 the responsiveness of the Circuit Breaker decreases. This impacts 894 the ability of the Circuit Breaker to detect and react to congestion. 896 A Circuit Breaker could potentially be exploited by an attacker to 897 mount a Denial of Service (DoS) attack against the traffic being 898 measured. Mechanisms therefore need to be implemented to prevent 899 attacks on the network control information that would result in DoS. 900 The source and integrity of control information (measurements and 901 triggers) MUST be protected from off-path attacks. Without 902 protection, it could be trivial for an attacker to inject fake or 903 modified control/measurement messages (e.g., indicating high packet 904 loss rates) causing a Circuit Breaker to trigger and to therefore 905 mount a DoS attack that disrupts a flow. 907 Simple protection can be provided by using a randomized source port, 908 or equivalent field in the packet header (such as the RTP SSRC value 909 and the RTP sequence number) expected not to be known to an off-path 910 attacker. Stronger protection can be achieved using a secure 911 authentication protocol. This attack is relatively easy for an on- 912 path attacker when the messages are neither encrypted nor 913 authenticated. When there is a risk of on-path attack, a 914 cryptographic authentication mechanism for all control/measurement 915 messages is RECOMMENDED to mitigate this concern. There is a design 916 trade-off between the cost of introducing cryptographic security for 917 control messages and the desire to protect control communication. 918 For some deployment scenarios the value of additional protection from 919 DoS attack will therefore lead to a requirement to authenticate all 920 control messages. 922 Transmission of network control information consumes network 923 capacity. This control traffic needs to be considered in the design 924 of a Circuit Breaker and could potentially add to network congestion. 925 If this traffic is sent over a shared path, it is RECOMMENDED that 926 this control traffic is prioritized to reduce the probability of loss 927 under congestion. Control traffic also needs to be considered when 928 provisioning a network that uses a Circuit Breaker. 930 The Circuit Breaker MUST be designed to be robust to packet loss that 931 can also be experienced during congestion/overload. Loss of control 932 messages could be a side-effect of a congested network, but also 933 could arise from other causes Section 4. 935 The security implications depend on the design of the mechanisms, the 936 type of traffic being controlled and the intended deployment 937 scenario. Each design of a Circuit Breaker MUST therefore evaluate 938 whether the particular Circuit Breaker mechanism has new security 939 implications. 941 9. IANA Considerations 943 This document makes no request from IANA. 945 10. Acknowledgments 947 There are many people who have discussed and described the issues 948 that have motivated this draft. Contributions and comments included: 949 Lars Eggert, Colin Perkins, David Black, Matt Mathis, Andrew 950 McGregor, Bob Briscoe and Eliot Lear. This work was part-funded by 951 the European Community under its Seventh Framework Programme through 952 the Reducing Internet Transport Latency (RITE) project (ICT-317700). 954 11. Revision Notes 956 XXX RFC-Editor: Please remove this section prior to publication XXX 958 Draft 00 960 This was the first revision. Help and comments are greatly 961 appreciated. 963 Draft 01 965 Contained clarifications and changes in response to received 966 comments, plus addition of diagram and definitions. Comments are 967 welcome. 969 WG Draft 00 971 Approved as a WG work item on 28th Aug 2014. 973 WG Draft 01 975 Incorporates feedback after Dallas IETF TSVWG meeting. This version 976 is thought ready for WGLC comments. Definitions of abbreviations. 978 WG Draft 02 979 Minor fixes for typos. Rewritten security considerations section. 981 WG Draft 03 983 Updates following WGLC comments (see TSV mailing list). Comments 984 from C Perkins; D Black and off-list feedback. 986 A clear recommendation of intended scope. 988 Changes include: Improvement of language on timescales and minimum 989 measurement period; clearer articulation of endpoint and multicast 990 examples - with new diagrams; separation of the controlled network 991 case; updated text on position of trigger function; corrections to 992 RTP-CB text; clarification of loss v ECN metrics; checks against 993 submission checklist 9use of keywords, added meters to diagrams). 995 WG Draft 04 997 Added section on PW CB for TDM - a newly adopted draft (D. Black). 999 WG Draft 05 1001 Added clarifications requested during AD review. 1003 WG Draft 06 1005 Fixed some remaining typos. 1007 Update following detailed review by Bob Briscoe, and comments by D. 1008 Black. 1010 WG Draft 07 1012 Additional update following review by Bob Briscoe. 1014 WG Draft 08 1016 Updated text on the response to lack of meter measurements with 1017 managed Circuit Breakers. Additional comments from Eliot Lear (APPs 1018 area). 1020 WG Draft 09 1022 Updated text on applications from Eliot Lear. Additional feedback 1023 from Bob Briscoe. Comments from David Black and Mirja Kuehlewind. 1024 Resulted in change of terminology to describe this as reacting to 1025 "persistent excessive congestion", and more consistent use of 1026 "congestion control mechanisms". The requirements section was 1027 reordered and repetition removed to ease reading. Moved text on 1028 value of CC to front of document. 1030 12. References 1032 12.1. Normative References 1034 [ID-ietf-tsvwg-RFC5405.bis] 1035 Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1036 Guidelines (Work-in-Progress)", 2015. 1038 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1039 Requirement Levels", BCP 14, RFC 2119, 1040 DOI 10.17487/RFC2119, March 1997, 1041 . 1043 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1044 of Explicit Congestion Notification (ECN) to IP", 1045 RFC 3168, DOI 10.17487/RFC3168, September 2001, 1046 . 1048 12.2. Informative References 1050 [ID-ietf-pals-congcons] 1051 Stein, YJ., Black, D., and B. Briscoe, "Pseudowire 1052 Congestion Considerations (Work-in-Progress)", 2015. 1054 [Jacobsen88] 1055 European Telecommunication Standards, Institute (ETSI), 1056 "Congestion Avoidance and Control", SIGCOMM Symposium 1057 proceedings on Communications architectures and 1058 protocols", August 1998. 1060 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1061 RFC 1112, DOI 10.17487/RFC1112, August 1989, 1062 . 1064 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 1065 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 1066 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 1067 S., Wroclawski, J., and L. Zhang, "Recommendations on 1068 Queue Management and Congestion Avoidance in the 1069 Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, 1070 . 1072 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 1073 RFC 2914, DOI 10.17487/RFC2914, September 2000, 1074 . 1076 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 1077 Edge-to-Edge (PWE3) Architecture", RFC 3985, 1078 DOI 10.17487/RFC3985, March 2005, 1079 . 1081 [RFC4488] Levin, O., "Suppression of Session Initiation Protocol 1082 (SIP) REFER Method Implicit Subscription", RFC 4488, 1083 DOI 10.17487/RFC4488, May 2006, 1084 . 1086 [RFC4553] Vainshtein, A., Ed. and YJ. Stein, Ed., "Structure- 1087 Agnostic Time Division Multiplexing (TDM) over Packet 1088 (SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006, 1089 . 1091 [RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and 1092 P. Pate, "Structure-Aware Time Division Multiplexed (TDM) 1093 Circuit Emulation Service over Packet Switched Network 1094 (CESoPSN)", RFC 5086, DOI 10.17487/RFC5086, December 2007, 1095 . 1097 [RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, 1098 "Time Division Multiplexing over IP (TDMoIP)", RFC 5087, 1099 DOI 10.17487/RFC5087, December 2007, 1100 . 1102 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 1103 Friendly Rate Control (TFRC): Protocol Specification", 1104 RFC 5348, DOI 10.17487/RFC5348, September 2008, 1105 . 1107 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 1108 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 1109 . 1111 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 1112 and K. Carlberg, "Explicit Congestion Notification (ECN) 1113 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 1114 2012, . 1116 [RTP-CB] Perkins, and Singh, "Multimedia Congestion Control: 1117 Circuit Breakers for Unicast RTP Sessions", February 2014. 1119 Author's Address 1120 Godred Fairhurst 1121 University of Aberdeen 1122 School of Engineering 1123 Fraser Noble Building 1124 Aberdeen, Scotland AB24 3UE 1125 UK 1127 Email: gorry@erg.abdn.ac.uk 1128 URI: http://www.erg.abdn.ac.uk