idnits 2.17.1 draft-ietf-tsvwg-circuit-breaker-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 25, 2014) is 3473 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: 'RFC6040' is defined on line 587, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5405 (Obsoleted by RFC 8085) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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 September 25, 2014 5 Expires: March 29, 2015 7 Network Transport Circuit Breakers 8 draft-ietf-tsvwg-circuit-breaker-00 10 Abstract 12 This note explains what is meant by the term "network transport 13 circuit breaker" (CB). It describes the need for circuit breakers 14 when using network tunnels, and other non-congestion controlled 15 applications. It also defines requirements for building a circuit 16 breaker and the expected outcomes of using a circuit breaker within 17 the Internet. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 29, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Types of Circuit-Breaker . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Design of a Circuit-Breaker (What makes a good circuit 57 breaker?) . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Functional Components . . . . . . . . . . . . . . . . . . 5 59 3.2. Requirements for implementing a CB . . . . . . . . . . . 6 60 4. Examples of Circuit Breakers . . . . . . . . . . . . . . . . 8 61 4.1. A Fast-Trip Circuit Breaker . . . . . . . . . . . . . . . 8 62 4.1.1. A Fast-Trip Circuit Breaker for RTP . . . . . . . . . 8 63 4.2. A Slow-trip Circuit Breaker . . . . . . . . . . . . . . . 9 64 4.3. A Managed Circuit Breaker . . . . . . . . . . . . . . . . 9 65 4.3.1. A Managed Circuit Breaker for SAToP Pseudo-Wires . . 9 66 5. Examples where circuit breakers may not be needed. . . . . . 10 67 5.1. CBs and uni-directional Traffic . . . . . . . . . . . . . 10 68 5.2. CBs over pre-provisioned Capacity . . . . . . . . . . . . 11 69 5.3. CBs with CC Traffic . . . . . . . . . . . . . . . . . . . 11 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 73 9. Revision Notes . . . . . . . . . . . . . . . . . . . . . . . 12 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 76 10.2. Informative References . . . . . . . . . . . . . . . . . 12 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 81 A network transport Circuit Breaker (CB) is an automatic mechanism 82 that is used to estimate congestion caused by a flow, and to 83 terminate (or significantly reduce the rate of) the flow when 84 persistent congestion is detected. This is a safety measure to 85 prevent congestion collapse (starvation of resources available to 86 other flows), essential for an Internet that is heterogeneous and for 87 traffic that is hard to predict in advance. 89 The term "Circuit Breaker" originates in electricity supply, and has 90 nothing to do with network circuits or virtual circuits. In such 91 cases, a CB is intended as a protection mechanism of last resort. 92 Under normal circumstances, a CB should not be triggered; It is 93 designed to protect things when there is overload. Just as people do 94 not expect the electrical circuit-breaker (or fuse) in their home to 95 be triggered, except when there is a wiring fault or a problem with 96 an electrical appliance. 98 In networking, the CB principle can be used as a protection mechanism 99 of last resort to avoid persistent congestion. Persistent congestion 100 (also known as "congestion collapse") was a feature of the early 101 Internet of the 1980s. This resulted in excess traffic starving 102 other connection from access to the Internet. It was countered by 103 the requirement to use congestion control (CC) by the Transmission 104 Control Protocol (TCP) [Jacobsen88] [RFC1112]. These mechanisms 105 operate in Internet hosts to cause TCP connections to "back off" 106 during congestion. The introduction of CC in TCP (currently 107 documented in [RFC5681] ensured the stability of the Internet, 108 because it was able to detect congestion and promptly react. This 109 worked well while TCP was by far the dominant traffic in the 110 Internet, and most TCP flows were long-lived (ensuring that they 111 could detect and respond to congestion before the flows terminated). 112 This is no longer the case, and non-congestion controlled traffic, 113 including many applications of the User Datagram Protocol (UDP) can 114 form a significant proportion of the total traffic traversing a link. 115 The current Internet therefore requires that non-congestion 116 controlled traffic needs to be considered to avoid congestion 117 collapse. 119 There are important differences between a transport circuit-breaker 120 and a congestion-control method. Specifically, congestion control 121 (as implemented in TCP, SCTP, and DCCP) needs to operate on the 122 timescale on the order of a packet round-trip-time (RTT), the time 123 from sender to destination and return. Congestion control methods 124 may react to a single packet loss/marking and reduce the transmission 125 rate for each loss or congestion event. The goal is usually to limit 126 the maximum transmission rate that reflects the available capacity of 127 a network path. These methods typically operate on individual 128 traffic flows (e.g. a 5-tuple). 130 In contrast, CBs are recommended for non-congestion-controlled 131 Internet flows and for traffic aggregates, e.g.traffic sent using a 132 network tunnel. Later sections provide examples of cases where 133 circuit-breakers may or may not be desirable. 135 A CB needs to measure (meter) the traffic to determine if the network 136 is experiencing congestion and must be designed to trigger robustly 137 when there is persistent congestion. This means the trigger needs to 138 operate on a timescale much longer than the path round trip time 139 (e.g. seconds to possibly many tens of seconds). This longer period 140 is needed to provide sufficient time for transports (or applications) 141 to adjust their rate following congestion, and for the network load 142 to stabilise after any adjustment. A CB trigger will often be based 143 on a series of successive sample measurements taken over a reasonably 144 long period of time. This is to ensure that a CB does not 145 accidentally trigger following a single (or even successive) 146 congestion events (congestion events are what triggers congestion 147 control, and are to be regarded as normal on a network link operating 148 near its capacity). Once triggered, a control function needs to 149 remove traffic from the network, either disabling the flow or 150 significantly reducing the level of traffic. This reaction provides 151 the required protection to prevent persistent congestion being 152 experienced by other flows that share the congested part of the 153 network path. 155 1.1. Types of Circuit-Breaker 157 There are various forms of network transport circuit breaker. These 158 are differentiated mainly on the timescale over which they are 159 triggered, but also in the intended protection they offer: 161 o Fast-Trip Circuit Breakers: The relatively short timescale used by 162 this form of circuit breaker is intended to protect a flow or 163 related group of flows. 165 o Slow-Trip Circuit Breakers: This circuit breaker utilises a longer 166 timescale and is designed to protect traffic aggregates. 168 o Managed Circuit Breakers: Utilise the operations and management 169 functions that may be present in a managed service to implement a 170 circuit breaker. 172 Examples of each type of circuit breaker are provided in section 4. 174 2. Terminology 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in [RFC2119]. 180 3. Design of a Circuit-Breaker (What makes a good circuit breaker?) 182 Although circuit breakers have been talked about in the IETF for many 183 years, there has not yet been guidance on the cases where circuit 184 breakers are needed or upon the design of circuit breaker mechanisms. 185 This document seeks to offer advise on these two topics. 187 Section 3.1 describes the functional components of a circuit breaker 188 and section 3.2 defines requirements for implementing a circuit 189 breaker. 191 3.1. Functional Components 193 The basic design of a transport circuit breaker involves 194 communication between an ingress point (a sender) and an egress point 195 (a receiver) of a network flow. A simple picture of CB operation is 196 provided in figure 1. This shows a set of routers (each labelled R) 197 connecting a set of endpoints. A CB is used to control traffic 198 passing through a subset of these routers, acting between an ingress 199 and a egress point. In some cases the ingress and egress may be in 200 one or both endpoints, in other cases they will be in the network, 201 for example one expected use would be at the ingress and egress of a 202 tunnel service. 204 +--------+ +--------+ 205 |Endpoint| |Endpoint| 206 +--+-----+ +--+-----+ 207 | | 208 | +-+ +-+ +---------+ +-+ +-+ +-+ +--------+ +-+ +-+ | 209 +-+R+--+R+--+ Ingress +--+R+--+R+--+R+--+ Egress |--+R+--+R+-+ 210 +++ +-+ +-------+-+ +-+ +-+ +-+ +-----+--+ +++ +-+ 211 | ^ | | | 212 +-+ | | +----+----+ | | +-+ 213 +R+--+ | | Measure +<-------------------+ +--+R+ 214 +++ | +----+----+ +++ 215 | | | | 216 | | +----+----+ | 217 +--+-----+ | | Trigger + +--+-----+ 218 |Endpoint| | +----+----+ |Endpoint| 219 +--------+ | | +--------+ 220 +------+ 221 Reaction 223 Figure 1: A CB controlling the part of the end-to-end path between an 224 ingress point and an egress point. 226 The set of components needed to implement a circuit breaker are: 228 1. An Ingress meter (at the sender or tunnel ingress) records the 229 number of packets/bytes sent in each measurement interval. This 230 measures the offered network load. The measurement interval 231 could be every few seconds. 233 2. An Egress meter (at the receiver or tunnel egress) records the 234 number/bytes received in each measurement interval. This 235 measures the supported load and may utilise other signals to 236 detect the effect of congestion (e.g. loss/marking experienced 237 over the path). 239 3. The measured values at the ingress and egress are communicated to 240 the CB Measurement function. This may use several methods 241 including: Sending return measurement packets from a receiver to 242 a trigger function at the sender; An implementation using 243 Operations, Administration and Management (OAM), or another in- 244 band signalling datagram to send to the trigger function; It 245 could also be implemented purely as a control plane function 246 using a software-defined network controller. 248 4. The Measurement function combines the Ingress and Egress 249 measurements to assess the present level of network congestion. 250 (For example, the loss rate for each measurement interval could 251 be deduced from calculating the difference between counter 252 values. Note that accurate measurement intervals are not 253 typically important, since isolated loss events need to be 254 disregarded.) 256 5. A Trigger function determines if the measurements indicate 257 persistent congestion. This defines an appropriate threshold for 258 determining there is persistent congestion between the ingress 259 and egress (e.g. more than 10% loss, but other methods could also 260 be based on the rate of transmission as well as the loss rate). 261 The transport CB is triggered when the threshold is exceeded in 262 multiple measurement intervals (e.g. 3 successive measurements). 263 This design needs to be robust to single or spurious events 264 triggering a reaction. 266 6. A Reaction that is applied at the Ingress when the CB is 267 triggered. This seeks to automatically remove the traffic 268 causing persistent congestion. 270 7. The CB also triggers when it does not receive both sender and 271 receiver measurements, since this also could indicate a loss of 272 control packets (also a symptom of heavy congestion or inability 273 to control the load). 275 3.2. Requirements for implementing a CB 277 The requirements for implementing a CB are: 279 o There MUST be a control path from the Ingress meter and the Egress 280 meter to the point of measurement. The CB MUST trigger if this 281 control path fails. That is, the feedback indicating a congested 282 period is designed so that the CB is triggered when it fails to 283 receive measurement reports that indicate an absence of 284 congestion, rather than relying on the successful transmission of 285 a "congested" signal back to the sender. (The feedback signal 286 could itself be lost under congestion collapse). 288 o A CB MUST define a measurement period over which the receiver 289 measures the level of congestion. This method does not have to 290 detect individual packet loss, but MUST have a way to know that 291 packets have been lost/marked from the traffic flow. If Explicit 292 Congestion Notification (ECN) is enabled [RFC3168], an egress 293 meter MAY also count the number of ECN congestion marks/event per 294 measurement interval, but even if ECN is used, loss MUST still be 295 measured, since this better reflects the impact of persistent 296 congestion. The type of CB will determine how long this 297 measurement period needs to be. The minimum time must be 298 significantly longer than the time that current CC algorithms need 299 to reduce their rate following detection of congestion (i.e. many 300 path RTTs). 302 o A CB is REQUIRED to define a threshold to determine whether the 303 measured congestion is considered excessive. 305 o A CB is REQUIRED to define a period over which the Trigger uses 306 the collected measurements. 308 o A CB MUST be robust to multiple congestion events. This usually 309 will define a number of measured persistent congestion events per 310 triggering period. For example, a CB may combine the results of 311 several measurement periods to determine if the CB is triggered. 312 (e.g. triggered when persistent congestion is detected in 3 313 measurements within the triggering interval). 315 o A triggered CB MUST react decisively by disabling (or 316 significantly reducing) traffic at the source (e.g. tunnel 317 ingress). The CB SHOULD be constructed so that it does not 318 trigger under light or intermittent congestion, with a default 319 response to a trigger that disables all traffic that contributed 320 to congestion. 322 o Some circuit breaker designs use a reaction that reduces, rather 323 that disables, the flows it control. This response MUST be much 324 more severe than that of a CC algorithm, because the CB reacts to 325 more persistent congestion and operates over longer timescales. A 326 CB that reduces the rate of a flow, MUST continue to monitor the 327 level congestion and MUST further reduce the rate if the CB is 328 again triggered. 330 o The reaction to a triggered CB MUST continue for a period of time 331 of at least the triggering interval. Manual operator intervention 332 will usually be required to restore the flow. If an automated 333 response is needed to reset the trigger, then this MUST NOT be 334 immediate. The design of this release mechanism needs to be 335 sufficiently conservative that it does not adversely interact with 336 other mechanisms (including other CB algorithms that control 337 traffic over a common path. 339 o When a CB is triggered, it SHOULD be regarded as an abnormal 340 network event. As such, this event SHOULD be logged. The 341 measurements that lead to triggering of the CB SHOULD also be 342 logged. 344 4. Examples of Circuit Breakers 346 There are multiple types of CB that may be defined for use in 347 different deployment cases. This section provides examples of 348 different types of circuit breaker: 350 4.1. A Fast-Trip Circuit Breaker 352 A fast-trip circuit breaker is the most responsive form of CB. It 353 has a response time that is only slightly larger than that of the 354 traffic it controls. It is suited to traffic with well-understood 355 characteristics. It is not be suited to arbitrary network traffic, 356 since it may prematurely trigger (e.g. when multiple congestion- 357 controlled flows lead to short-term overload). 359 4.1.1. A Fast-Trip Circuit Breaker for RTP 361 A set of fast-trip CB methods have been specified for use together by 362 a Real-time Transport Protocol (RTP) flow using the RTP/AVP Profile 363 [RTP-CB]. It is expected that, in the absence of severe congestion, 364 all RTP applications running on best-effort IP networks will be able 365 to run without triggering these circuit breakers. A fast-trip RTP CB 366 is therefore implemented as a fail-safe. 368 The sender monitors reception of RTCP Reception Report (RR or XRR) 369 packets that convey reception quality feedback information. This is 370 used to measure (congestion) loss, possibly in combination with ECN 371 [RFC6679]. 373 The CB action (shutdown of the flow) is triggered when any of the 374 following trigger conditions are true: 376 1. An RTP CB triggers on reported lack of progress. 378 2. An RTP CB triggers when no receiver reports messages are 379 received. 381 3. An RTP CB uses a TFRC-style check and set a hard upper limit to 382 the long-term RTP throughput (over many RTTs). 384 4. An RTP CB includes the notion of Media Usability. This circuit 385 breaker is triggered when the quality of the transported media 386 falls below some required minimum acceptable quality. 388 4.2. A Slow-trip Circuit Breaker 390 A slow-trip CB may be implemented in an endpoint or network device. 391 This type of CB is much slower at responding to congestion than a 392 fast-trip CB and is expected to be more common. 394 One example where a slow-trip CB is needed is where flows or traffic- 395 aggregates use a tunnel or encapsulation and the flows within the 396 tunnel do not all support TCP-style congestion control (e.g. TCP, 397 SCTP, TFRC), see [RFC5405] section 3.1.3. A use case is where 398 tunnels are deployed in the general Internet (rather than "controlled 399 environments" within an ISP or Enterprise), especially when the 400 tunnel may need to cross a customer access router. 402 4.3. A Managed Circuit Breaker 404 A managed CB is implemented in the signalling protocol or management 405 plane that relates to the traffic aggregate being controlled. This 406 type of circuit breaker is typically applicable when the deployment 407 is within a "controlled environment". 409 A Circuit Breaker requires more than the ability to determine that a 410 network path is forwarding data, or to measure the rate of a path - 411 which are often normal network operational functions. There is an 412 additional need to determine a metric for congestion on the path and 413 to trigger a reaction when a threshold is crossed that indicates 414 persistent congestion. 416 4.3.1. A Managed Circuit Breaker for SAToP Pseudo-Wires 418 [RFC4553], SAToP Pseudo-Wires (PWE3), section 8 describes an example 419 of a managed circuit breaker for isochronous flows. 421 If such flows were to run over a pre-provisioned (e.g. MPLS) 422 infrastructure, then it may be expected that the Pseudo-Wire (PW) 423 would not experience congestion, because a flow is not expected to 424 either increase (or decrease) their rate. If instead Pseudo-Wire 425 traffic is multiplexed with other traffic over the general Internet, 426 it could experience congestion. [RFC4553] states: "If SAToP PWs run 427 over a PSN providing best-effort service, they SHOULD monitor packet 428 loss in order to detect "severe congestion". The currently 429 recommended measurement period is 1 second, and the trigger operates 430 when there are more than three measured Severely Errored Seconds 431 (SES) within a period. 433 If such a condition is detected, a SAToP PW should shut down 434 bidirectionally for some period of time..." The concept was that when 435 the packet loss ratio (congestion) level increased above a threshold, 436 the PW was by default disabled. This use case considered fixed-rate 437 transmission, where the PW had no reasonable way to shed load. 439 The trigger needs to be set at the rate the PW was likely have a 440 serious problem, possibly making the service non-compliant. At this 441 point triggering the CB would remove the traffic prevent undue impact 442 congestion-responsive traffic (e.g., TCP). Part of the rationale, 443 was that high loss ratios typically indicated that something was 444 "broken" and should have already resulted in operator intervention, 445 and should trigger this intervention. An operator-based response 446 provides opportunity for other action to restore the service quality, 447 e.g. by shedding other loads or assigning additional capacity, or to 448 consciously avoid reacting to the trigger while engineering a 449 solution to the problem. This may require the trigger to be sent to 450 a third location (e.g. a network operations centre, NOC) responsible 451 for operation of the tunnel ingress, rather than the tunnel ingress 452 itself. 454 5. Examples where circuit breakers may not be needed. 456 A CB is not required for a single CC-controlled flow using TCP, SCTP, 457 TFRC, etc. In these cases, the CC methods are designed to prevent 458 congestion collapse. 460 XX NOTE: Comments on this section are particularly welcome to 461 establish clearer understanding of the operational conditions under 462 which circuit breakers should or must be deployed. 464 5.1. CBs and uni-directional Traffic 466 A CB can be used to control uni-directional UDP traffic, providing 467 that there is a control path to connect the functional components at 468 the Ingress and Egress. This control path can exist in networks for 469 which the traffic flow is purely unidirectional (e.g. a multicast 470 stream that sends packets across an Internet path). 472 A one-way physical link may have no associated control path, and 473 therefore cannot be controlled using an automated process. This 474 could be managed by policing traffic to ensure it does not exceed the 475 available capacity. Supporting this type of traffic in the general 476 Internet requires operator monitoring to detect and respond to 477 persistent congestion or the use of dedicated capacity - e.g. Using 478 per-provisioned MPLS services, RSVP, or admission-controlled 479 Differentiated Services. 481 5.2. CBs over pre-provisioned Capacity 483 One common question is whether a CB is needed when a tunnel is 484 deployed in a private network with pre-provisioned capacity? 486 In this case, compliant traffic that does not exceed the provisioned 487 capacity should not result in congestion. A CB will hence only be 488 triggered when there is non-compliant traffic. It could be argued 489 that this event should never happen - but it may also be argued that 490 the CB equally should never be triggered. If a CB were to be 491 implemented, it would provide an appropriate response should this 492 persistent congestion occur in an operational network. 494 5.3. CBs with CC Traffic 496 IP-based traffic is generally assumed to be congestion-controlled, 497 i.e., it is assumed that the transport protocols generating IP-based 498 traffic at the sender already employ mechanisms that are sufficient 499 to address congestion on the path [RFC5405]. A question therefore 500 arises when people deploy a tunnel that is thought to only carry an 501 aggregate of TCP (or some other CC-controlled) traffic: Is there 502 advantage in this case in using a CB? 504 For sure, traffic in a such a tunnel will respond to congestion. 505 However, the answer to the question may not be obvious, because the 506 overall traffic formed by an aggregate of flows that implement a CC 507 mechanism does not necessarily prevent congestion collapse. For 508 instance, most CC mechanisms require long-lived flows to react to 509 reduce the rate of a flow, an aggregate of many short flows may 510 result in many terminating before they experience congestion. It is 511 also often impossible for a tunnel service provider to know that the 512 tunnel only contains CC-controlled traffic (e.g. Inspecting packet 513 headers may not be possible). The important thing to note is that if 514 the aggregate of the traffic does not result in persistent congestion 515 (impacting other flows), then the CB will not trigger. This is the 516 expected case in this context - so implementing a CB will not reduce 517 performance of the tunnel, but offers protection should persistent 518 congestion occur. 520 6. Security Considerations 522 This section will describe security considerations, if any. 524 7. IANA Considerations 526 This document makes no request from IANA. 528 8. Acknowledgments 530 There are many people who have discussed and described the issues 531 that have motivated this draft. Contributions and comments are 532 appreciated, including: Lars Eggert, Colin Perkins, David Black, Matt 533 Mathis. 535 9. Revision Notes 537 RFC-Editor: Please remove this section prior to publication 539 Draft 00 541 This was the first revision. Help and comments are greatly 542 appreciated. 544 Draft 01 546 Contained clarifications and changes in response to received 547 comments, plus addition of diagram and definitions. Comments are 548 welcome. 550 WG Draft 00 552 Approved as a WG work item on 28th Aug 2014. 554 10. References 556 10.1. Normative References 558 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 559 Requirement Levels", BCP 14, RFC 2119, March 1997. 561 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 562 for Application Designers", BCP 145, RFC 5405, November 563 2008. 565 10.2. Informative References 567 [Jacobsen88] 568 European Telecommunication Standards, Institute (ETSI), 569 "Congestion Avoidance and Control", SIGCOMM Symposium 570 proceedings on Communications architectures and 571 protocols", August 1998. 573 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 574 RFC 1112, August 1989. 576 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 577 of Explicit Congestion Notification (ECN) to IP", RFC 578 3168, September 2001. 580 [RFC4553] Vainshtein, A. and YJ. Stein, "Structure-Agnostic Time 581 Division Multiplexing (TDM) over Packet (SAToP)", RFC 582 4553, June 2006. 584 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 585 Control", RFC 5681, September 2009. 587 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 588 Notification", RFC 6040, November 2010. 590 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 591 and K. Carlberg, "Explicit Congestion Notification (ECN) 592 for RTP over UDP", RFC 6679, August 2012. 594 [RTP-CB] Perkins, and Singh, "Multimedia Congestion Control: 595 Circuit Breakers for Unicast RTP Sessions", February 2014. 597 Author's Address 599 Godred Fairhurst 600 University of Aberdeen 601 School of Engineering 602 Fraser Noble Building 603 Aberdeen, Scotland AB24 3UE 604 UK 606 Email: gorry@erg.abdn.ac.uk 607 URI: http://www.erg.abdn.ac.uk