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