idnits 2.17.1 draft-fairhurst-tsvwg-cc-04.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 3, 2019) is 1635 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) == Missing Reference: 'Jacobson88' is mentioned on line 135, but not defined == Unused Reference: 'I-D.ietf-tsvwg-l4s-arch' is defined on line 987, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 3742 ** Downref: Normative reference to an Experimental RFC: RFC 6928 ** Downref: Normative reference to an Experimental RFC: RFC 7661 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-23 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-23 == Outdated reference: A later version (-11) exists of draft-ietf-tcpm-2140bis-00 == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-accurate-ecn-09 == Outdated reference: A later version (-15) exists of draft-ietf-tcpm-rack-06 == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-rfc793bis-14 == Outdated reference: A later version (-25) exists of draft-ietf-tsvwg-aqm-dualq-coupled-10 == Outdated reference: A later version (-20) exists of draft-ietf-tsvwg-l4s-arch-04 == Outdated reference: A later version (-19) exists of draft-irtf-panrg-what-not-to-do-03 -- Obsolete informational reference (is this intentional?): RFC 896 (Obsoleted by RFC 7805) -- Obsolete informational reference (is this intentional?): RFC 2140 (Obsoleted by RFC 9040) -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 8312 (Obsoleted by RFC 9438) Summary: 3 errors (**), 0 flaws (~~), 12 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Fairhurst 3 Internet-Draft University of Aberdeen 4 Intended status: Standards Track November 3, 2019 5 Expires: May 6, 2020 7 Guidelines for Internet Congestion Control at Endpoints 8 draft-fairhurst-tsvwg-cc-04 10 Abstract 12 This document provides guidance on the design of methods to avoid 13 congestion collapse and to provide congestion control. 14 Recommendations and requirements on this topic are distributed across 15 many documents in the RFC series. This therefore seeks to gather and 16 consolidate these recommendations and provide overall guidance. It 17 is intended to provide input to the design of new congestion control 18 methods in protocols, such as the IETF Quick UDP Internet Connections 19 (QUIC) transport. 21 The present document is for discussion and comment by the IETF. If 22 published, it plans to update or replace the Best Current Practice in 23 BCP 41, which currently includes "Congestion Control Principles" 24 provided in RFC2914. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 6, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Best Current Practice in the RFC-Series . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Principles of Congestion Control . . . . . . . . . . . . . . 5 64 3.1. A Diversity of Path Characteristics . . . . . . . . . . . 5 65 3.2. Flow Multiplexing and Congestion . . . . . . . . . . . . 6 66 3.3. Avoiding Congestion Collapse and Flow Starvation . . . . 9 67 4. Guidelines for Performing Congestion Control . . . . . . . . 10 68 4.1. Connection Initialization . . . . . . . . . . . . . . . . 10 69 4.2. Using Path Capacity . . . . . . . . . . . . . . . . . . . 12 70 4.3. Timers and Retransmission . . . . . . . . . . . . . . . . 13 71 4.4. Responding to Potential Congestion . . . . . . . . . . . 15 72 4.5. Using More Capacity . . . . . . . . . . . . . . . . . . . 16 73 4.6. Network Signals . . . . . . . . . . . . . . . . . . . . . 17 74 4.7. Protection of Protocol Mechanisms . . . . . . . . . . . . 18 75 5. IETF Guidelines on Evaluation of Congestion Control . . . . . 18 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 81 9.2. Informative References . . . . . . . . . . . . . . . . . 20 82 Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 25 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 85 1. Introduction 87 The IETF has specified Internet transports (e.g., TCP 88 [I-D.ietf-tcpm-rfc793bis], UDP [RFC0768], UDP-Lite [RFC3828], SCTP 89 [RFC4960], and DCCP [RFC4340]) as well as protocols layered on top of 90 these transports (e.g., RTP [RFC3550], QUIC 91 [I-D.ietf-quic-transport], SCTP/UDP [RFC6951], DCCP/UDP [RFC6773]) 92 and transports that work directly over the IP network layer. These 93 transports are implemented in endpoints (either Internet hosts or 94 routers acting as endpoints), and are designed to detect and react to 95 network congestion. TCP was the first transport to provide this, 96 although the TCP specifications found in RFC 793 predates the 97 inclusion of congestion control and did not contain any discussion of 98 using or managing a congestion window. 100 Recommendations and requirements on this topic are distributed across 101 many documents in the RFC series. This document therefore seeks to 102 gather and consolidate these recommendations and provide overall 103 guidelines. It is intended to provide input to the design of 104 congestion control methods that are implemented protocols. The focus 105 of the present document is upon unicast point-to-point transports, 106 this includes migration from using one path to another path. 108 Some recommendations [RFC5783] and requirements in this document 109 apply to point-to-multipoint transports (e.g., multicast), however 110 this topic extends beyond the current document's scope. [RFC2914] 111 provides additional guidance on the use of multicast. 113 1.1. Best Current Practice in the RFC-Series 115 Like RFC2119, this documents borrows heavily from earlier 116 publications addressing the need for end-to-end congestion control, 117 and this subsection provides an overview of key topics. 119 [RFC2914] provides a general discussion of the principles of 120 congestion control. Section 3 discussed Fairness, stating "The 121 equitable sharing of bandwidth among flows depends on the fact that 122 all flows are running compatible congestion control algorithms". 123 Section 3.1 describes preventing congestion collapse. 125 Congestion collapse was first reported in the mid 1980s [RFC0896], 126 and at that time was largely due to TCP connections unnecessarily 127 retransmitting packets that were either in transit or had already 128 been received at the receiver. We call the congestion collapse that 129 results from the unnecessary retransmission of packets classical 130 congestion collapse. Classical congestion collapse is a stable 131 condition that can result in throughput that is a small fraction of 132 normal [RFC0896]. Problems with classical congestion collapse have 133 generally been corrected by improvements to timer and congestion 134 control mechanisms, implemented in modern implementations of TCP 135 [Jacobson88]. This classical congestion collapse was a key focus of 136 [RFC2309]. 138 A second form of congestion collapse occurs due to undelivered 139 packets, where Section 5 of [RFC2914] notes: "Congestion collapse 140 from undelivered packets arises when bandwidth is wasted by 141 delivering packets through the network that are dropped before 142 reaching their ultimate destination. This is probably the largest 143 unresolved danger with respect to congestion collapse in the Internet 144 today. Different scenarios can result in different degrees of 145 congestion collapse, in terms of the fraction of the congested links' 146 bandwidth used for productive work. The danger of congestion 147 collapse from undelivered packets is due primarily to the increasing 148 deployment of open-loop applications not using end-to-end congestion 149 control. Even more destructive would be best-effort applications 150 that *increase* their sending rate in response to an increased packet 151 drop rate (e.g., automatically using an increased level of FEC 152 (Forward Error Correction))." 154 Section 3.3 of [RFC2914] notes: "In addition to the prevention of 155 congestion collapse and concerns about fairness, a third reason for a 156 flow to use end-to-end congestion control can be to optimize its own 157 performance regarding throughput, delay, and loss. In some 158 circumstances, for example in environments with high statistical 159 multiplexing, the delay and loss rate experienced by a flow are 160 largely independent of its own sending rate. However, in 161 environments with lower levels of statistical multiplexing or with 162 per-flow scheduling, the delay and loss rate experienced by a flow is 163 in part a function of the flow's own sending rate. Thus, a flow can 164 use end-to-end congestion control to limit the delay or loss 165 experienced by its own packets. We would note, however, that in an 166 environment like the current best-effort Internet, concerns regarding 167 congestion collapse and fairness with competing flows limit the range 168 of congestion control behaviors available to a flow." 170 In addition to the prevention of congestion collapse and concerns 171 about fairness, a flow using end-to-end congestion control can 172 optimize its own performance regarding throughput, delay, and loss 173 [RFC2914]. 175 The standardization of congestion control in new transports can avoid 176 a congestion control "arms race" among competing protocols [RFC2914]. 177 That is, avoid designs of transports that could compete for Internet 178 resource in a way that significantly reduces the ability of other 179 flows to use the Internet. The use of standard methods is therefore 180 encouraged. 182 The popularity of the Internet has led to a proliferation in the 183 number of TCP implementations [RFC2914]. A variety of non-TCP 184 transports have also being deployed. Some transport implementations 185 fail to use standardised congestion avoidance mechanisms correctly 186 because of poor implementation [RFC2525]. However, this is not the 187 only reason fro not using standard methods. Some transports have 188 chosen mechanisms that are not presently standardised, or have 189 adopted approaches to their design that differ from present 190 standards. Guidance is needed therefore not only for future 191 standardisation, but to ensure safe and appropriate evolution of 192 transports that have not presently been submitted for 193 standardisation. 195 2. Terminology 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 199 document are to be interpreted as described in [RFC2119]. 201 The path between endpoints (sometimes called "Internet Hosts" or 202 source and destination nodes in IPv6) consists of the endpoint 203 protocol stack at the sender and the receiver (which together 204 implement the transport service), and a succession of links and 205 network devices (routers or middleboxes) that provide connectivity 206 across the network. The set of network devices forming the path is 207 not usually fixed, and it should generally be assumed that this set 208 can change over arbitrary lengths of time. 210 [RFC5783] defines congestion control as "the feedback-based 211 adjustment of the rate at which data is sent into the network. 212 Congestion control is an indispensable set of principles and 213 mechanisms for maintaining the stability of the Internet." [RFC5783] 214 also provides an informational snapshot taken by the IRTF's Internet 215 Congestion Control Research Group (ICCRG) from October 2008. 217 Other terminology is directly copied from the cited RFCs. 219 3. Principles of Congestion Control 221 This section summarises the principles for providing congestion 222 control, and provides the background forSection 4. 224 3.1. A Diversity of Path Characteristics 226 Internet transports can reserve capacity at routers or on the links 227 being used, but most uses do not rely upon prior reservation of 228 capacity along the path they use. In the absence of such a 229 reservation, endpoints are unable to determine a safe rate at which 230 to start or continue their transmission. The use of an Internet path 231 therefore requires a combination of end-to-end transport mechanisms 232 to detect and then respond to changes in the capacity that it 233 discovers is available across the network path. Buffering (an 234 increase in latency) or congestion loss (discard of a packet) arises 235 when the traffic arriving at a link or network exceeds the resources 236 available. Loss can also occur for other reasons, but it is usually 237 not possible for an endpoint to reliably disambiguate the cause of 238 packet loss (e.g., loss could be due to link corruption, receiver 239 overrun, etc. [RFC3819]). A network device that does not support 240 Active Queue Management (AQM) [RFC7567] typically uses a drop-tail 241 policy to drop excess IP packets when its queue(s) becomes full. 243 When a transport uses a path to send packets (i.e. a flow), this 244 impacts any other Internet flows (possibly from or to other 245 endpoints) that share the capacity of any common network device or 246 link (i.e., are multiplexed) along the path. As with loss, latency 247 can also be incurred for other reasons [RFC3819] (Quality of Service 248 link scheduling, link radio resource management/bandwidth on demand, 249 transient outages, link retransmission, and connection/resource setup 250 below the IP layer, etc). 252 When choosing an appropriate sending rate, packet loss needs to be 253 considered. Although losses are not always due to congestion, 254 endpoint congestion control needs to conservatively react to loss as 255 a potential signal of reduced available capacity and reduce the 256 sending rate. Many designs place the responsibility of rate-adaption 257 at the sender (source) endpoint, utilising feedback information 258 provided by the remote endpoint (receiver). Congestion control can 259 also be implemented by determining an appropriate rate limit at the 260 receiver and using this limit to control the maximum transport rate 261 (e.g., using methods such as [RFC5348] and [RFC4828]). 263 Principles include: 265 o A transport design is REQUIRED be robust to a change in the set of 266 devices forming the network path. A reconfiguration, reset or 267 other event could interrupt this path or trigger a change in the 268 set of network devices forming the path. 270 o Transports are REQUIRED to operate safely over the wide range of 271 path characteristics presented by Internet paths. 273 o The path characteristics can change over relatively short 274 intervals of time (i.e., characteristics discovered do not 275 necessarily remain valid for multiple Round Trip Times, RTTs). In 276 particular, the transport SHOULD measure and adapt to the 277 characteristics of the path(s) being used. 279 3.2. Flow Multiplexing and Congestion 281 It is normal to observe some perturbation in latency and/or loss when 282 flows shares a common network bottleneck with other traffic. This 283 impact needs to be considered and Internet flows ought to implement 284 appropriate safeguards to avoid inappropriate impact on other flows 285 that share the resources along a path. Congestion control methods 286 satisfy this requirement and therefore can help avoid congestion 287 collapse. 289 "This raises the issue of the appropriate granularity of a "flow", 290 where we define a `flow' as the level of granularity appropriate for 291 the application of both fairness and congestion control. [RFC2309] 292 states: "There are a few `natural' answers: 1) a TCP or UDP 293 connection (source address/port, destination address/port); 2) a 294 source/destination host pair; 3) a given source host or a given 295 destination host. We would guess that the source/destination host 296 pair gives the most appropriate granularity in many circumstances. 297 The granularity of flows for congestion management is, at least in 298 part, a policy question that needs to be addressed in the wider IETF 299 community." [RFC2914] 301 Internet transports need to react to avoid congestion that impacts 302 other flows sharing a path. The Requirements for Internet Hosts 303 [RFC1122] formally mandates that endpoints perform congestion 304 control. "Because congestion control is critical to the stable 305 operation of the Internet, applications and other protocols that 306 choose to use UDP as an Internet transport must employ mechanisms to 307 prevent congestion collapse and to establish some degree of fairness 308 with concurrent traffic [RFC2914]. Additional mechanisms are, in 309 some cases, needed in the upper layer protocol for an application 310 that sends datagrams (e.g., using UDP) [RFC8085]. 312 Endpoints can send more than one flow. "The specific issue of a 313 browser opening multiple connections to the same destination has been 314 addressed by [RFC2616]. Section 8.1.4 states that "Clients that use 315 persistent connections SHOULD limit the number of simultaneous 316 connections that they maintain to a given server. A single-user 317 client SHOULD NOT maintain more than 2 connections with any server or 318 proxy." [RFC2140]. This suggests that there are opportunities for 319 transport connections between the same endpoints (from the same or 320 differing applications) might share some information, including their 321 congestion control state, if they are known to share the same path. 322 [RFC8085] adds "An application that forks multiple worker processes 323 or otherwise uses multiple sockets to generate UDP datagrams SHOULD 324 perform congestion control over the aggregate traffic." 326 An endpoint can become aware of congestion by various means 327 (including packet loss Section 3.1). A signal that indicates 328 congestion on the end-to-end network path, needs to result in a 329 congestion control reaction by the transport to reduce the maximum 330 rate permitted by the sending endpoint[RFC8087]). 332 The general recommendation in the UDP Guidelines [RFC8085] is that 333 applications SHOULD leverage existing congestion control techniques, 334 such as those defined for TCP [RFC5681], TCP-Friendly Rate Control 335 (TFRC) [RFC5348], SCTP [RFC4960], and other IETF-defined transports. 336 This is because there are many trade offs and details that can have a 337 serious impact on the performance of congestion control for the 338 application they support and other traffic that seeks to share the 339 resources along the path over which they communicate. 341 Network devices can be configured to isolate the queuing of packets 342 for different flows, or aggregates of flows, and thereby assist in 343 reducing the impact of flow multiplexing on other flows. This could 344 include methods seeking to equally distribute resources between 345 sharing flows, but this is explicitly not a requirement for a network 346 device [Flow-Rate-Fairness]. Endpoints can not rely on the presence 347 and correct configuration of these methods, and therefore even when a 348 path is expected to support such methods, also need to employ methods 349 that work end-to-end. 351 Experience has shown that successful protocols developed in a 352 specific context or for a particular application tend to also become 353 used in a wider range of contexts. Therefore, IETF specifications by 354 default target deployment on the general Internet, or need to be 355 defined for use only within a controlled environment. 357 Principles include: 359 o Endpoints MUST perform congestion control [RFC1122] and SHOULD 360 leverage existing congestion control techniques [RFC8085]. 362 o If an application or protocol chooses not to use a congestion- 363 controlled transport protocol, it SHOULD control the rate at which 364 it sends datagrams to a destination host, in order to fulfil the 365 requirements of [RFC2914], as stated in [RFC8085]. 367 o Transports SHOULD control the aggregate traffic they send on a 368 path [RFC8085]. They ought not to use multiple congestion- 369 controlled flows between the same endpoints to gain a performance 370 advantage. 372 o Transports that do not target Internet deployment need to be 373 constrained to only operate in a controlled environment (e.g., see 374 Section 3.6 of [RFC8085]) and provide appropriate mechanisms to 375 prevent traffic accidentally leaving the controlled environment 376 [RFC8084]. 378 o Although network devices can be configured to reduce the impact of 379 flow multiplexing on other flows, endpoints MUST NOT rely solely 380 on the presence and correct configuration of these methods, except 381 when constrained to operate in a controlled environment. 383 3.3. Avoiding Congestion Collapse and Flow Starvation 385 A significant pathology can arise when a poorly designed transport 386 creates congestion. This can result in severe service degradation or 387 "Internet meltdown". This phenomenon was first observed during the 388 early growth phase of the Internet in the mid 1980s [RFC0896] 389 [RFC0970]. It is technically called "Congestion Collapse". 390 [RFC2914] notes that informally, "congestion collapse occurs when an 391 increase in the network load results in a decrease in the useful work 392 done by the network." 394 Transports need to be specifically designed with measures to avoid 395 starving other flows of capacity (e.g., [RFC7567]). [RFC2309] also 396 discussed the dangers of congestion-unresponsive flows, and states 397 that "all UDP-based streaming applications should incorporate 398 effective congestion avoidance mechanisms." [RFC7567] and [RFC8085] 399 both reaffirm this, encouraging development of methods to prevent 400 starvation. 402 Principles include: 404 o Transports MUST avoid inducing flow starvation to other flows that 405 share resources along the path they use. 407 o Endpoints MUST treat a loss of all feedback (e.g., expiry of a 408 retransmission time out, RTO) as an indication of persistent 409 congestion (i.e., an indication of potential congestion collapse). 411 o When an endpoint detects persistent congestion, it MUST reduce the 412 maximum rate (e.g., reduce its congestion window). This normally 413 involves the use of protocol timers to detect a lack of 414 acknowledgment for transmitted data (Section 4.3). 416 o Protocol timers (e.g., used for retransmission or to detect 417 persistent congestion) need to be appropriately initialised. A 418 transport SHOULD adapt its protocol timers to follow the measured 419 the path Round Trip Rime (RTT) (e.g., Section 3.1.1 of [RFC8085]). 421 o A transport MUST employ exponential backoff each time persistent 422 congestion is detected [RFC1122], until the path characteristics 423 can again be confirmed. 425 o Network devices MAY provide mechanisms to mitigate the impact of 426 congestion collapse by transport flows (e.g., priority forwarding 427 of control information, and starvation detection), and SHOULD 428 mitigate the impact of non-conformant and malicious flows 429 [RFC7567]). These mechanisms complement, but do not replace, the 430 endpoint congestion avoidance mechanisms. 432 4. Guidelines for Performing Congestion Control 434 This section provides guidance for designers of a new transport 435 protocol that decide to implement congestion control and its 436 associated mechanisms. 438 The text draws on language used in the specifications of TCP and 439 other IETF transports. For example, a protocol timer is generally 440 needed to detect persistent congestion, and this document uses the 441 term Retransmission Timeout (RTO) to refer to the operation of this 442 timer. Similarly, the document refers to a congestion window as the 443 variable that controls the rate of transmission by the congestion 444 controller. The use of these terms does not imply that endpoints 445 need to implement functions in the way that TCP currently does. Each 446 new transport needs to make its own design decisions about how to 447 meet the recommendations and requirements for congestion control. 449 4.1. Connection Initialization 451 When a connection or flow to a new destination is established, the 452 endpoints have little information about the characteristics of the 453 network path they will use. This section describes how a flow starts 454 transmission over such a path. 456 Flow Start: A new flow between two endpoints needs to initialise a 457 congestion controller for the path it will use. It cannot assume 458 that capacity is available at the start of the flow, unless it 459 uses a mechanism to explicitly reserve capacity. In the absence 460 of a capacity signal, a flow MUST therefore start slowly. 462 The TCP slow-start algorithm is the accepted standard for flow 463 startup [RFC5681]. TCP uses the notion of an Initial Window (IW) 464 [RFC3390], updated by [RFC6928]) to define the initial volume of 465 data that can be sent on a path. This is not the smallest burst, 466 or the smallest window, but it is considered a safe starting point 467 for a path that is not suffering persistent congestion, and is 468 applicable until feedback about the path is received. The initial 469 sending rate (e.g., determined by the IW) needs to be viewed as 470 tentative until the capacity is confirmed to be available. 472 Initial RTO Interval: When a flow sends the first packet, it 473 typically has no way to know the actual RTT of the path it will 474 use. An initial value needs to be used to initialise the 475 principal retransmission timer, which will be used to detect lack 476 of responsiveness from the remote endpoint. In TCP, this is the 477 starting value of the RTO. The selection of a safe initial value 478 is a trade off that has important consequences on the overall 479 Internet stability [RFC6928] [RFC8085]. In the absence of any 480 knowledge about the latency of a path (including the initial 481 value), the RTO MUST be conservatively set to no less than 1 482 second. Values shorter than 1 second can be problematic (see the 483 appendix of [RFC6298]). (Note: Linux TCP has deployed a smaller 484 initial RTO value). 486 [[Author note: It could be useful to discuss cached values]]. 488 Initial RTO Expiry: If the RTO timer expires while awaiting 489 completion of a connection setup, or handshake (e.g., the three- 490 way handshake in TCP, the ACK of a SYN segment), and the 491 implementation is using an RTO less than 3 seconds, the local 492 endpoint can resend the connection setup. [[Author note: It would 493 be useful to discuss how the timer is managed to protect from 494 multiple handshake failure]]. 496 The RTO MUST then be re-initialized to increase it to 3 seconds 497 when data transmission begins (i.e., after the handshake 498 completes) [RFC6298] [RFC8085]. This conservative increase is 499 necessary to avoid congestion collapse when many flows retransmit 500 across a shared bottleneck with restricted capacity. 502 Initial Measured RTO: Once an RTT measurement is available (e.g., 503 through reception of an acknowledgement), the timeout value must 504 be adjusted. This adjustment MUST take into account the RTT 505 variance. For the first sample, this variance cannot be 506 determined, and a local endpoint MUST therefore initialise the 507 variance to RTT/2 (see equation 2.2 of [RFC6928] and related text 508 for UDP in section 3.1.1 of [RFC8085]). 510 Current State: A congestion controller MAY assume that recently used 511 capacity between a pair of endpoints is an indication of future 512 capacity available in the next RTT between the same endpoints. It 513 MUST react (reduce its rate) if this is not (later) confirmed to 514 be true. [[Author note: do we need to bound this]]. 516 Cached State: A congestion controller that recently used a specific 517 path could use additional state that lets a flow take-over the 518 capacity that was previously consumed by another flow (e.g., in 519 the last RTT) which it understands is using the same path and no 520 will longer use the capacity it recently used. In TCP, this 521 mechanism is referred to as TCP Control Block (TCB) sharing 522 [RFC2140] [I-D.ietf-tcpm-2140bis]. The capacity and other 523 information can be used to suggest a faster initial sending rate, 524 but this information MUST be viewed as tentative until the path 525 capacity is confirmed by receiving a confirmation that actual 526 traffic has been sent across the path. (i.e., the new flow needs 527 to either use or loose the capacity that has been tentatively 528 offered to it). A sender MUST reduce its rate if this capacity is 529 not confirmed within the current RTO interval. 531 4.2. Using Path Capacity 533 This section describes how a sender needs to regulate the maximum 534 volume of data in flight over the interval of the current RTT, and 535 how it manages transmission of the capacity that it perceives is 536 available. 538 Congestion Management: The capacity available to a flow could be 539 expressed as the number of bytes in flight, the sending rate or a 540 limit on the number of unacknowledged segments. When determining 541 the capacity used, all data sent by a sender needs to be 542 accounted, this includes any additional overhead or data generated 543 by the transport. A transport performing congestion management 544 will usually optimise performance for its application by avoiding 545 excessive loss or delay and maintain a congestion window. In 546 steady-state this congestion window reflects a safe limit to the 547 sending rate that has not resulted in persistent congestion. A 548 congestion controller for a flow that uses packet Forward Error 549 Correction (FEC) encoding (e.g., [RFC6363]) needs to consider all 550 additional overhead introduced by packet FEC when setting and 551 managing its congestion window. 553 One common model views the path between two endpoints as a "pipe". 554 New packets enter the pipe at the sending endpoint, older ones 555 leave the pipe at the receiving endpoint. Congestion and other 556 forms of loss result in "leakage" from this pipe. Received data 557 (leaving the network path at the remote endpoint) is usually 558 acknowledged to the congestion controller. 560 The rate that data leaves the pipe indicates the share of the 561 capacity that has been utilised by the flow. If, on average (over 562 an RTT), the sending rate equals the receiving rate, this 563 indicates the path capacity. This capacity can be safely used 564 again in the next RTT. If the average receiving rate is less than 565 the sending rate, then the path is either queuing packets, the 566 RTT/path has changed, or there is packet loss. 568 Transient Path: Unless managed by a resource reservation protocol, 569 path capacity information is transient. A sender that does not 570 use capacity has no understanding whether previously used capacity 571 remains available to use, or whether that capacity has disappeared 572 (e.g., a change in the path that causes a flow to experience a 573 smaller bottleneck, or when more traffic emerges that consumes 574 previously available capacity resulting in a new bottleneck). For 575 this reason, a transport that is limited by the volume of data 576 available to send MUST NOT continue to grow its congestion window 577 when the current congestion window is more than twice the volume 578 of data acknowledged in the last RTT. 580 Validating the congestion window Standard TCP states that a TCP 581 sender "SHOULD set the congestion window to no more than the 582 Restart Window (R)" before beginning transmission, if the sender 583 has not sent data in an interval that exceeds the current 584 retransmission timeout, i.e., when an application becomes idle 585 [RFC5681]. An experimental specification [RFC7661] permits TCP 586 senders to tentatively maintain a congestion window larger than 587 the path supported in the last RTT when application-limited, 588 provided that they appropriately and rapidly collapse the 589 congestion window when potential congestion is detected. This 590 mechanism is called Congestion Window Validation (CWV). 592 Burst Mitigation: Even in the absence of congestion, statistical 593 multiplexing of flows can result in transient effects for flows 594 sharing common resources. A sender therefore SHOULD avoid 595 inducing excessive congestion to other flows (collateral damage). 597 While a congestion controller ought to limit sending at the 598 granularity of the current RTT, this can be insufficient to 599 satisfy the goals of preventing starvation and mitigating 600 collateral damage. This requires moderating the burst rate of the 601 sender to avoid significant periods where a flow(s) consume all 602 buffer capacity at the path bottleneck, which would otherwise 603 prevent other flows from gaining a reasonable share. 605 Endpoints SHOULD provide mechanisms to regulate the bursts of 606 transmission that the application/protocol sends to the network 607 (section 3.1.6 of [RFC8085]). ACK-Clocking [RFC5681] can help 608 mitigate bursts for protocols that receive continuous feedback of 609 reception (such as TCP). Sender pacing can mitigate this 610 [RFC8085], (See Section 4.6 of [RFC3449]), and has been 611 recommended for TCP in conditions where ACK-Clocking is not 612 effective, (e.g., [RFC3742], [RFC7661]). SCTP [RFC4960] defines a 613 maximum burst length (Max.Burst) with a recommended value of 4 614 segments to limit the SCTP burst size. 616 4.3. Timers and Retransmission 618 This section describes mechanisms to detect and provide 619 retransmission, and to protect the network in the absence of timely 620 feedback. 622 Loss Detection: Loss detection occurs after a sender determines 623 there is no delivery confirmation within an expected period of 624 time (e.g., by observing the time-ordering of the reception of 625 ACKs, as in TCP DupACK) or by utilising a timer to detect loss 626 (e.g., a transmission timer with a period less than the RTO, 627 [RFC8085] [I-D.ietf-tcpm-rack]) or a combination of using a timer 628 and ordering information to trigger retransmission of data. 630 Retransmission: Retransmission of lost packets or messages is a 631 common reliability mechanism. When loss is detected, the sender 632 can choose to retransmit the lost data, ignore the loss, or send 633 other data (e.g., [RFC8085] [I-D.ietf-quic-recovery]), depending 634 on the reliability model provided by the transport service. Any 635 transmission consumes network capacity, therefore retransmissions 636 MUST NOT increase the network load in response to congestion loss 637 (which worsens that congestion) [RFC8085]. Any method that sends 638 additional data following loss is therefore responsible for 639 congestion control of the retransmissions (and any other packets 640 sent, including FEC information) as well as the original traffic. 642 Measuring the RTT: Once an endpoint has started communicating with 643 its peer, the RTT be MUST adjusted by measuring the actual path 644 RTT. This adjustment MUST include adapting to the measured RTT 645 variance (see equation 2.3 of [RFC6928]). 647 Maintaining the RTO: The RTO SHOULD be set based on recent RTT 648 observations (including the RTT variance) [RFC8085]. 650 RTO Expiry: Persistent lack of feedback (e.g., detected by an RTO 651 timer, or other means) MUST be treated an indication of potential 652 congestion collapse. A failure to receive any specific response 653 within a RTO interval could potentially be a result of a RTT 654 change, change of path, excessive loss, or even congestion 655 collapse. If there is no response within the RTO interval, TCP 656 collapses the congestion window to one segment [RFC5681]. Other 657 transports MUST similarly respond when they detect loss of 658 feedback. 660 An endpoint needs to exponentially backoff the RTO interval 661 [RFC8085] each time the RTO expires. That is, the RTO interval 662 MUST be set to at least the RTO * 2 [RFC6298] [RFC8085]. 664 Maximum RTO: A maximum value MAY be placed on the RTO interval. 665 This maximum limit to the RTO interval MUST NOT be less than 60 666 seconds [RFC6298]. 668 [[ Author Note: These recommendations should be re-evaluated in 669 lite of the current chartered work in the TCPM WG. ]] 671 4.4. Responding to Potential Congestion 673 Internet flows SHOULD implement appropriate safeguards to avoid 674 inappropriate impact on other flows that share the resources along a 675 path. The safety and responsiveness of new proposals need to be 676 evaluated [RFC5166]. In determining an appropriate congestion 677 response, designs could take into consideration the size of the 678 packets that experience congestion [RFC4828]. 680 Congestion Response: An endpoint MUST promptly reduce the rate of 681 transmission when it receive or detects an indication of 682 congestion (e.g., loss) [RFC2914]. 684 TCP Reno established a method that relies on multiplicative- 685 decrease to halve the sending rate while congestion is detected. 686 This response to congestion indications is considered sufficient 687 for safe Internet operation, but other decrease factors have also 688 been published in the RFC Series [RFC8312]. 690 ECN Response: A congestion control design should provide the 691 necessary mechanisms to support Explicit Congestion Notification 692 (ECN) [RFC3168] [RFC6679], as described in section 3.1.7 of 693 [RFC8085]. This can help determine an appropriate congestion 694 window when supported by routers on the path [RFC7567] to enable 695 rapid early indication of incipient congestion. 697 The early detection of incipient congestion justifies a different 698 reaction to an explicit congestion signal compared to the reaction 699 to detected packet loss [RFC8311] [RFC8087]. Simple feedback of 700 received Congestion Experienced (CE) marks [RFC3168], relies only 701 on an indication that congestion has been experienced within the 702 last RTT. This style of response is appropriate when a flow uses 703 ECT(0). The reaction to reception of this indication was modified 704 in TCP ABE [RFC8511]. Further detail about the received CE- 705 marking can be obtained by using more accurate receiver feedback 706 (e.g., [I-D.ietf-tcpm-accurate-ecn] and extended RTP feedback). 707 The more detailed feedback provides an opportunity for a finer- 708 granularity of congestion response. 710 Current work-in-progress [I-D.ietf-tsvwg-l4s-arch]defines a 711 reaction for packets marked with ECT(1), building on the style of 712 detailed feedback provided by [I-D.ietf-tcpm-accurate-ecn] and a 713 modified marking system [I-D.ietf-tsvwg-aqm-dualq-coupled]. 715 Robustness to Path Change: The detection of congestion and the 716 resulting reduction MUST NOT solely depend upon reception of a 717 signal from the remote endpoint, because congestion indications 718 could themselves be lost under persistent congestion. 720 The only way to surely confirm that a sending endpoint has 721 successfully communicated with a remote endpoint is to utilise a 722 timer (seeSection 4.3) to detect a lack of response that could 723 result from a change in the path or the path characteristics 724 (usually called the RTO). Congestion controllers that are unable 725 to react after one (or at most a few) RTTs after receiving a 726 congestion indication should observe the guidance in section 3.3 727 of the UDP Guidelines [RFC8085]. 729 Persistent Congestion: Persistent congestion can result in 730 congestion collapse, which MUST be aggressively avoided [RFC2914]. 731 Endpoints that experience persistent congestion and have already 732 exponentially reduced their congestion window to the restart 733 window (e.g., one packet), MUST further reduce the rate if the RTO 734 timer continues to expire. For example, TFRC [RFC5348] continues 735 to reduce its sending rate under persistent congestion to one 736 packet per RT, and then exponentially backs off the time between 737 single packet transmissions if the congestion continues to persist 738 [RFC2914]. 740 [RFC8085] provides guidelines for a sender that does not, or is 741 unable to, adapt the congestion window. 743 4.5. Using More Capacity 745 In the absence of persistent congestion, an endpoint is permitted to 746 increase its congestion window and hence the sending rate. An 747 increase should only occur when there is additional data available to 748 send across the path (i.e., the sender will utilise the additional 749 capacity in the next RTT). 751 TCP Reno [RFC5681] defines an algorithm, known as the Additive- 752 Increase/ Multiplicative-Decrease (AIMD) algorithm, which allows a 753 sender to exponentially increase the congestion window each RTT from 754 the initial window to the first detected congestion event. This is 755 designed to allow new flows to rapidly acquire a suitable congestion 756 window. Where the bandwidth delay product (BDP) is large, it can 757 take many RTT periods to determine a suitable share of the path 758 capacity. Such high BDP paths benefit from methods that more rapidly 759 increase the congestion window, but in compensation these need to be 760 designed to also react rapidly to any detected congestion (e.g., TCP 761 Cubic [RFC8312]). 763 Increasing Congestion Window: A sender MUST NOT continue to increase 764 its rate for more than an RTT after a congestion indication is 765 received. The transport SHOULD stop increasing its congestion 766 window as soon as it receives indication of congestion to avoid 767 excessive "overshoot". 769 While the sender is increasing the congestion window, a sender 770 will transmit faster than the last known safe rate. Any increase 771 above the last confirmed rate needs to be regarded as tentative 772 and the sender reduce their rate below the last confirmed safe 773 rate when congestion is experienced (a congestion event). 775 Congestion: An endpoint MUST utilise a method that assures the 776 sender will keep the rate below the previously confirmed safe rate 777 for multiple RTT periods after an observed congestion event. In 778 TCP, this is performed by using a linear increase from a slow 779 start threshold that is re-initialised when congestion is 780 experienced. 782 Avoiding Overshoot: Overshoot of the congestion window beyond the 783 point of congestion can significantly impact other flows sharing 784 resources along a path. It is important to note that as endpoints 785 experience more paths with a large BDP and a wider range of 786 potential path RTT, that variability or changes in the path can 787 have very significant constraints on appropriate dynamics for 788 increasing the congestion window (see also burst mitigation, 789 Section 4.2). 791 4.6. Network Signals 793 An endpoint can utilise signals from the network to help determine 794 how to regulate the traffic it sends. 796 Network Signals: Mechanisms MUST NOT solely rely on transport 797 messages or specific signalling messages to perform safely. (See 798 section 5.2 of [RFC8085] describing use of ICMP messages). They 799 need to be designed so that they safely operate when path 800 characteristics change at any time. Transport mechanisms MUST 801 robust to potential black-holing of any signals (i.e., need to be 802 robust to loss or modification of packets, noting that this can 803 occur even after successful first use of a signal by a flow, as 804 occurs when the path changes, see Section 3.1). 806 A mechanism that utilises signals originating in the network 807 (e.g., RSVP, NSIS, Quick-Start, ECN), MUST assume that the set of 808 network devices on the path can change. This motivates the use of 809 soft-state when designing protocols that interact with signals 810 originating from network devices [I-D.irtf-panrg-what-not-to-do] 811 (e.g., ECN). This can include context-sensitive treatment of 812 "soft" signals provided to the endpoint [RFC5164]. 814 4.7. Protection of Protocol Mechanisms 816 An endpoint needs to provide protection from attacks on the traffic 817 it generates, or attacks that seek to increase the capacity it 818 consumes (impacting other traffic that shared a bottleneck). 820 Off Path Attack: A design MUST protect from off-path attack to the 821 protocol [RFC8085] (i.e., one by an attacker that is unable to see 822 the contents of packets exchanged across the path). An attack on 823 the congestion control can lead to a Denial of Service (DoS) 824 vulnerability for the flow being controlled and/or other flows 825 that share network resources along the path. 827 Validation of Signals: Network signalling and control messages 828 (e.g., ICMP [RFC0792]) MUST be validated before they are used to 829 protect from malicious abuse. This MUST at least include 830 protection from off-path attack [RFC8085]. 832 On Path Attack: A protocol can be designed to protect from on-path 833 attacks, but this requires more complexity and the use of 834 encryption/authentication mechanisms (e.g., IPsec [RFC4301], QUIC 835 [I-D.ietf-quic-transport]). 837 5. IETF Guidelines on Evaluation of Congestion Control 839 The IETF has provided guidance [RFC5033] for considering alternate 840 congestion control algorithms. 842 The IRTF has also described a set of metrics and related trade-off 843 between metrics that can be used to compare, contrast, and evaluate 844 congestion control techniques [RFC5166]. [RFC5783] provides a 845 snapshot of congestion-control research in 2008. 847 6. Acknowledgements 849 This document owes much to the insight offered by Sally Floyd, both 850 at the time of writing of RFC2914 and her help and review in the many 851 years that followed this. 853 Nicholas Kuhn helped develop the first draft of these guidelines. 854 Tom Jones and Ana Custura reviewed the first version of this draft. 855 The University of Aberdeen received funding to support this work from 856 the European Space Agency. 858 7. IANA Considerations 860 This memo includes no request to IANA. 862 RFC Editor Note: If there are no requirements for IANA, the section 863 will be removed during conversion into an RFC by the RFC Editor. 865 8. Security Considerations 867 This document introduces no new security considerations. Each RFC 868 listed in this document discusses the security considerations of the 869 specification it contains. The security considerations for the use 870 of transports are provided in the references section of the cited 871 RFCs. Security guidance for applications using UDP is provided in 872 the UDP Usage Guidelines [RFC8085]. 874 Section 4.7 describes general requirements relating to the design of 875 safe protocols and their protection from on and off path attack. 877 Section 4.6 follows current best practice to validate ICMP messages 878 prior to use. 880 9. References 882 9.1. Normative References 884 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 885 Communication Layers", STD 3, RFC 1122, 886 DOI 10.17487/RFC1122, October 1989, 887 . 889 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 890 Requirement Levels", BCP 14, RFC 2119, 891 DOI 10.17487/RFC2119, March 1997, 892 . 894 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 895 RFC 2914, DOI 10.17487/RFC2914, September 2000, 896 . 898 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 899 of Explicit Congestion Notification (ECN) to IP", 900 RFC 3168, DOI 10.17487/RFC3168, September 2001, 901 . 903 [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's 904 Initial Window", RFC 3390, DOI 10.17487/RFC3390, October 905 2002, . 907 [RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large 908 Congestion Windows", RFC 3742, DOI 10.17487/RFC3742, March 909 2004, . 911 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 912 Friendly Rate Control (TFRC): Protocol Specification", 913 RFC 5348, DOI 10.17487/RFC5348, September 2008, 914 . 916 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 917 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 918 . 920 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 921 "Computing TCP's Retransmission Timer", RFC 6298, 922 DOI 10.17487/RFC6298, June 2011, 923 . 925 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 926 "Increasing TCP's Initial Window", RFC 6928, 927 DOI 10.17487/RFC6928, April 2013, 928 . 930 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 931 Recommendations Regarding Active Queue Management", 932 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 933 . 935 [RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating 936 TCP to Support Rate-Limited Traffic", RFC 7661, 937 DOI 10.17487/RFC7661, October 2015, 938 . 940 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 941 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 942 March 2017, . 944 9.2. Informative References 946 [Flow-Rate-Fairness] 947 Briscoe, Bob., "Flow Rate Fairness: Dismantling a 948 Religion, ACM Computer Communication Review 37(2):63-74", 949 April 2007. 951 [I-D.ietf-quic-recovery] 952 Iyengar, J. and I. Swett, "QUIC Loss Detection and 953 Congestion Control", draft-ietf-quic-recovery-23 (work in 954 progress), September 2019. 956 [I-D.ietf-quic-transport] 957 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 958 and Secure Transport", draft-ietf-quic-transport-23 (work 959 in progress), September 2019. 961 [I-D.ietf-tcpm-2140bis] 962 Touch, J., Welzl, M., and S. Islam, "TCP Control Block 963 Interdependence", draft-ietf-tcpm-2140bis-00 (work in 964 progress), April 2019. 966 [I-D.ietf-tcpm-accurate-ecn] 967 Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More 968 Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate- 969 ecn-09 (work in progress), July 2019. 971 [I-D.ietf-tcpm-rack] 972 Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "RACK: 973 a time-based fast loss detection algorithm for TCP", 974 draft-ietf-tcpm-rack-06 (work in progress), November 2019. 976 [I-D.ietf-tcpm-rfc793bis] 977 Eddy, W., "Transmission Control Protocol Specification", 978 draft-ietf-tcpm-rfc793bis-14 (work in progress), July 979 2019. 981 [I-D.ietf-tsvwg-aqm-dualq-coupled] 982 Schepper, K., Briscoe, B., and G. White, "DualQ Coupled 983 AQMs for Low Latency, Low Loss and Scalable Throughput 984 (L4S)", draft-ietf-tsvwg-aqm-dualq-coupled-10 (work in 985 progress), July 2019. 987 [I-D.ietf-tsvwg-l4s-arch] 988 Briscoe, B., Schepper, K., Bagnulo, M., and G. White, "Low 989 Latency, Low Loss, Scalable Throughput (L4S) Internet 990 Service: Architecture", draft-ietf-tsvwg-l4s-arch-04 (work 991 in progress), July 2019. 993 [I-D.irtf-panrg-what-not-to-do] 994 Dawkins, S., "Path Aware Networking: Obstacles to 995 Deployment (A Bestiary of Roads Not Taken)", draft-irtf- 996 panrg-what-not-to-do-03 (work in progress), May 2019. 998 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 999 DOI 10.17487/RFC0768, August 1980, 1000 . 1002 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1003 RFC 792, DOI 10.17487/RFC0792, September 1981, 1004 . 1006 [RFC0896] Nagle, J., "Congestion Control in IP/TCP Internetworks", 1007 RFC 896, DOI 10.17487/RFC0896, January 1984, 1008 . 1010 [RFC0970] Nagle, J., "On Packet Switches With Infinite Storage", 1011 RFC 970, DOI 10.17487/RFC0970, December 1985, 1012 . 1014 [RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, 1015 DOI 10.17487/RFC2140, April 1997, 1016 . 1018 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 1019 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 1020 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 1021 S., Wroclawski, J., and L. Zhang, "Recommendations on 1022 Queue Management and Congestion Avoidance in the 1023 Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, 1024 . 1026 [RFC2525] Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner, 1027 J., Heavens, I., Lahey, K., Semke, J., and B. Volz, "Known 1028 TCP Implementation Problems", RFC 2525, 1029 DOI 10.17487/RFC2525, March 1999, 1030 . 1032 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1033 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1034 Transfer Protocol -- HTTP/1.1", RFC 2616, 1035 DOI 10.17487/RFC2616, June 1999, 1036 . 1038 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. 1039 Sooriyabandara, "TCP Performance Implications of Network 1040 Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, 1041 December 2002, . 1043 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1044 Jacobson, "RTP: A Transport Protocol for Real-Time 1045 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1046 July 2003, . 1048 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 1049 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1050 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1051 RFC 3819, DOI 10.17487/RFC3819, July 2004, 1052 . 1054 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., 1055 and G. Fairhurst, Ed., "The Lightweight User Datagram 1056 Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 1057 2004, . 1059 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1060 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1061 December 2005, . 1063 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1064 Congestion Control Protocol (DCCP)", RFC 4340, 1065 DOI 10.17487/RFC4340, March 2006, 1066 . 1068 [RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control 1069 (TFRC): The Small-Packet (SP) Variant", RFC 4828, 1070 DOI 10.17487/RFC4828, April 2007, 1071 . 1073 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1074 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1075 . 1077 [RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion 1078 Control Algorithms", BCP 133, RFC 5033, 1079 DOI 10.17487/RFC5033, August 2007, 1080 . 1082 [RFC5164] Melia, T., Ed., "Mobility Services Transport: Problem 1083 Statement", RFC 5164, DOI 10.17487/RFC5164, March 2008, 1084 . 1086 [RFC5166] Floyd, S., Ed., "Metrics for the Evaluation of Congestion 1087 Control Mechanisms", RFC 5166, DOI 10.17487/RFC5166, March 1088 2008, . 1090 [RFC5783] Welzl, M. and W. Eddy, "Congestion Control in the RFC 1091 Series", RFC 5783, DOI 10.17487/RFC5783, February 2010, 1092 . 1094 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 1095 Correction (FEC) Framework", RFC 6363, 1096 DOI 10.17487/RFC6363, October 2011, 1097 . 1099 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 1100 and K. Carlberg, "Explicit Congestion Notification (ECN) 1101 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 1102 2012, . 1104 [RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A 1105 Datagram Congestion Control Protocol UDP Encapsulation for 1106 NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November 1107 2012, . 1109 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 1110 Control Transmission Protocol (SCTP) Packets for End-Host 1111 to End-Host Communication", RFC 6951, 1112 DOI 10.17487/RFC6951, May 2013, 1113 . 1115 [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", 1116 BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, 1117 . 1119 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 1120 Explicit Congestion Notification (ECN)", RFC 8087, 1121 DOI 10.17487/RFC8087, March 2017, 1122 . 1124 [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion 1125 Notification (ECN) Experimentation", RFC 8311, 1126 DOI 10.17487/RFC8311, January 2018, 1127 . 1129 [RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and 1130 R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", 1131 RFC 8312, DOI 10.17487/RFC8312, February 2018, 1132 . 1134 [RFC8511] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 1135 "TCP Alternative Backoff with ECN (ABE)", RFC 8511, 1136 DOI 10.17487/RFC8511, December 2018, 1137 . 1139 Appendix A. Revision Notes 1141 Note to RFC-Editor: please remove this entire section prior to 1142 publication. 1144 Individual draft -00: 1146 o Comments and corrections are welcome directly to the authors or 1147 via the IETF TSVWG, working group mailing list. 1149 IndivRFC896 idual draft -01: 1151 o This update is proposed for initial WG comments. 1153 o If there is interest in progressing this document, the next 1154 version will include more complee referencing to citred material. 1156 Individual draft -02: 1158 o Correction of typos. 1160 Individual draft -03: 1162 o Added section 1.1 with text on current BCP status with additional 1163 alignment and updates to RFC2914 on Congestion Control Principles 1164 (after question from M. Scharf). 1166 o Edits to consolidate starvation text. 1168 o Added text that multicast currently noting that this is out of 1169 scope. 1171 o Revised sender-based CC text after comment from C. Perkins 1172 (Section 3.1,3.3 and other places). 1174 o Added more about FEC after comment from C. Perkins. 1176 o Added an explicit reference to RFC 5783 and updated this text 1177 (after question from M. Scharf). 1179 o To avoid doubt, added a para about "Each new transport needs to 1180 make its own design decisions about how to meet the 1181 recommendations and requirements for congestion control." 1183 o Upated references. 1185 Individual draft -04: 1187 o Correction of NiTs. Further clarifications. 1189 o This draft does not attempt to address further alignment with 1190 draft-ietf-tcpm-rto-consider. This will form part of a future 1191 revision. 1193 Author's Address 1195 Godred Fairhurst 1196 University of Aberdeen 1197 School of Engineering 1198 Fraser Noble Building 1199 Aberdeen AB24 3U 1200 UK 1202 Email: gorry@erg.abdn.ac.uk