idnits 2.17.1 draft-morton-tsvwg-sce-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 : ---------------------------------------------------------------------------- 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 (4 November 2019) is 1633 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-grimes-tcpm-tcpsce-00 == Outdated reference: A later version (-01) exists of draft-morton-tsvwg-cheap-nasty-queueing-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Working Group J. Morton 3 Internet-Draft R.W. Grimes, Ed. 4 Updates3168, 8311 (if approved) 4 November 2019 5 Intended status: Experimental 6 Expires: 7 May 2020 8 The Some Congestion Experienced ECN Codepoint 9 draft-morton-tsvwg-sce-01 11 Abstract 13 This memo reclassifies ECT(1) to be an early notification of 14 congestion on ECT(0) marked packets, which can be used by AQM 15 algorithms and transports as an earlier signal of congestion than CE. 16 It is a simple, transparent, and backward compatible upgrade to 17 existing IETF-approved AQMs, RFC3168, and nearly all congestion 18 control algorithms. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 7 May 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Some Congestion Experienced . . . . . . . . . . . . . . . . . 4 57 5. Examples of use . . . . . . . . . . . . . . . . . . . . . . . 6 58 5.1. Codel-type AQMs . . . . . . . . . . . . . . . . . . . . . 6 59 5.2. RED-type AQMs (including PIE) . . . . . . . . . . . . . . 7 60 5.3. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 5.4. Other . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 8 63 6.1. Existing ECN & AQM Deployments . . . . . . . . . . . . . 8 64 6.2. L4S . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 7. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 9 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 69 11. Normative References . . . . . . . . . . . . . . . . . . . . 10 70 12. Informative References . . . . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 73 1. Terminology 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 77 "OPTIONAL" in this document are to be interpreted as described in 78 [RFC2119] and [RFC8174] when, and only when, they appear in all 79 capitals, as shown here. 81 2. Introduction 83 Traditional TCP congestion control exhibits a "sawtooth" pattern 84 which, in the most favourable cases, oscillates around the optimum 85 operating point of maximum throughput and minimum delay, which exists 86 at the point where the congestion window equals path BDP. The term 87 "sawtooth" brings to mind the straight-edged graphs of TCP Reno, but 88 the equally common TCP CUBIC is essentially similar in character, as 89 are other AIMD-derived algorithms. 91 A number of proposals have sought to improve this, but introduce 92 various other tradoffs in return. TCP Vegas is consistently 93 outcompeted by standard TCPs, DCTCP proved to be too aggressive for 94 deployment in the public Internet, and while BBR appears to have 95 avoided both of these problems, its complexity makes it difficult to 96 implement correctly. Each of these proposals is characterised by 97 primarily changing only the endpoints, not the network nodes on the 98 path between them; though DCTCP is intended for use with a specific 99 style of AQM, it can work with standard AQMs as long as there is no 100 competing non-DCTCP traffic. 102 Some other proposals have attempted to convey information about the 103 network path explicitly, by having network nodes inject data about 104 link capacity and/or utilisation into passing traffic. These 105 proposals have generally been unsuccessful due to the complex slow- 106 path processing required in network nodes, and are not widely 107 deployed. The only successful proposal of this type is Explicit 108 Congestion Notification [RFC3168] which allows an AQM to signal 109 congestion by marking packets with (essentially) a one-bit signal in 110 preference to dropping them. 112 ECN defines a two-bit field supporting four codepoints, of which 113 three are in active use and the fourth is a semantic duplicate. It 114 was explicitly suggested during ECN's development that new meaning 115 could be given to this spare codepoint, including as a lesser 116 indication of congestion. With an alternative use of this codepoint 117 having fallen out of favour, the time is right to revisit this 118 suggestion and propose a workable method of applying it. 120 In so doing, care must be taken that backwards compatibility is 121 maintained with existing traffic, endpoints and network nodes that 122 are known or suspected to have been deployed. Keeping the changes to 123 on-wire protocols minimal, and the complexity of implementation low, 124 are also highly desirable. 126 This memo reclassifies ECT(1) to be an early notification of 127 congestion on ECT(0) marked packets, which can be used by AQM 128 algorithms and transports as an earlier signal of congestion than CE 129 ("Congestion Experienced"). 131 This memo also briefly discusses how transports should respond to 132 ECT(1) marked packets. Detailed specifications of this behaviour are 133 left to transport-specific memos. 135 3. Background 137 [RFC3168] defines the lower two bits of the (former) TOS byte in the 138 IPv4/6 header as the ECN field. This may take four values: Not-ECT, 139 ECT(0), ECT(1) or CE. 141 Binary Keyword References 143 ------------------------------------------------------------ 144 00 Not-ECT (Not ECN-Capable Transport) [RFC3168] 145 01 ECT(1) (ECN-Capable Transport(1)) [RFC3168] 146 10 ECT(0) (ECN-Capable Transport(0)) [RFC3168] 147 11 CE (Congestion Experienced) [RFC3168] 149 Research has shown that the ECT(1) codepoint goes essentially unused, 150 with the "Nonce Sum" extension to ECN having not been implemented in 151 practice and thus subsequently obsoleted by [RFC8311] (section 3). 152 Additionally, known [RFC3168] compliant senders do not emit ECT(1), 153 and compliant middleboxes do not alter the field to ECT(1), while 154 compliant receivers all interpret ECT(1) identically to ECT(0). 155 These are useful properties which represent an opportunity for 156 improvement. 158 Experience gained with 7 years of [RFC8290] deployment in the field 159 suggests that it remains difficult to maintain the desired 100% link 160 utilisation, whilst simultaneously strictly minimising induced delay 161 due to excess queue depth - irrespective of whether ECN is in use. 162 This leads to a reluctance amongst hardware vendors to implement the 163 most effective AQM schemes because their headline benchmarks are 164 throughput-based. 166 The underlying cause is the very sharp "multiplicative decrease" 167 reaction required of transport protocols to congestion signalling 168 (whether that be packet loss or CE marks), which tends to leave the 169 congestion window significantly smaller than the ideal BDP when 170 triggered at only slightly above the ideal value. The availability 171 of this sharp response is required to assure network stability (AIMD 172 principle), but there is presently no standardised and backwards- 173 compatible means of providing a less drastic signal. 175 4. Some Congestion Experienced 177 As consensus has arisen that some form of ECN signaling should be an 178 earlier signal than drop, this memo changes the meaning of ECT(1) to 179 SCE, meaning "Some Congestion Experienced". Since there is no longer 180 ambiguity between two ECT codepoints, ECT(0) is referred to as ECT. 181 The ECN-field codepoint table then becomes: 183 Binary Keyword References 185 ------------------------------------------------------------ 187 00 Not-ECT (Not ECN-Capable Transport) [RFC3168] 188 01 SCE (Some Congestion Experienced) [This Internet-draft] 189 10 ECT (ECN-Capable Transport) [RFC3168] 190 11 CE (Congestion Experienced) [RFC3168] 192 This permits middleboxes implementing AQM to signal incipient 193 congestion, below the threshold required to justify setting CE, by 194 converting some proportion of ECT codepoints to SCE ("SCE marking"). 195 Existing [RFC3168] compliant receivers MUST transparently ignore this 196 new signal with respect to congestion control, and both existing and 197 SCE-aware middleboxes SHOULD convert SCE to CE in the same 198 circumstances as for ECT, thus ensuring backwards compatibility with 199 [RFC3168] ECN endpoints. 201 Permitted ECN codepoint packet transitions by middleboxes are: 203 Not-ECT -> Not-ECT (or drop) 204 ECT -> ECT or SCE or CE 205 SCE -> SCE or CE 206 CE -> CE 208 In other words, for ECN-aware flows, the ECN marking of an individual 209 packet MAY be increased by a middlebox to signal congestion, but MUST 210 NOT be decreased, and packets SHALL NOT be altered to appear to be 211 ECN-aware if they were not originally, nor vice versa. Note however 212 that SCE is numerically less than ECT, but semantically greater, and 213 the latter definition applies for this rule. 215 Receivers and transport protocols conforming to this specification 216 SHALL continue to apply the [RFC3168] interpretation of the CE 217 codepoint, that is, to signal the sender to back off send rate to the 218 same extent as if a packet loss were detected. This maintains 219 compatibility with existing middleboxes, senders and receivers. 221 New SCE-aware receivers and transport protocols SHOULD interpret the 222 SCE codepoint as an indication of mild congestion, and respond 223 accordingly by applying send rates intermediate between those 224 resulting from a continuous sequence of ECT codepoints, and those 225 resulting from a CE codepoint. The ratio of ECT and SCE codepoints 226 received indicates the relative severity of such congestion, with a 227 higher proportion of SCE codepoints indicating more congestion. 229 The intent of SCE marking is a "cruise control" signal which permits 230 middleboxes to request relatively small reductions in send rate, or 231 merely a slowing of send rate growth. Accordingly, SCE marks SHOULD 232 progressively trigger exit from exponential slow-start growth, then 233 reduction to Reno-linear growth (for congestion control algorithms 234 which support higher growth rates in congestion-avoidance phase), 235 then a halt to send rate growth, then a gradual reduction of send 236 rate. For immediate large reductions of send rate, the CE mark MUST 237 retain its original Multiplicative Decrease power as per [RFC8511], 238 and compliant AQMs SHOULD retain the ability to employ it where 239 appropriate. 241 Details of how to implement SCE awareness at the transport layer will 242 be left to additional Internet Drafts yet to be submitted. To ensure 243 RTT-fair convergence with single-queue SCE AQMs, transports SHOULD 244 stabilise at lower SCE-mark ratios for higher BDPs, and MAY reduce 245 their response to CE marks IFF they are responding to SCE signals 246 received at around the same time (eg. within 1-2 RTTs) in the same 247 flow. 249 To maximise the benefit of SCE, middleboxes SHOULD begin to produce 250 SCE marks at lower congestion levels than they begin to produce CE 251 marks. This will usually ensure that SCE-aware flows avoid receiving 252 CE marks. When a single-queue AQM is upgraded to SCE awareness, this 253 will tend to cause SCE flows to give way to non-SCE flows; to avoid 254 this behaviour, single-queue AQMs MAY be left as RFC-3168 compliant 255 without SCE support. 257 For the avoidance of doubt, a decision to mark CE or to drop a packet 258 always takes precedence over SCE marking. 260 5. Examples of use 262 5.1. Codel-type AQMs 264 A simple and natural way to implement SCE in a Codel-type AQM is to 265 mark all ECT packets as SCE if they are over half the Codel target 266 sojourn time, and not marked CE by Codel itself. This threshold 267 function does not necessarily produce the best performance, but is 268 very easy to implement and provides useful information to SCE-aware 269 flows, often sufficient to avoid receiving CE marks whilst still 270 efficiently using available capacity. 272 For a more sophisticated approach avoiding even small-scale 273 oscillation, a stochastic ramp function may be implemented with 100% 274 marking at the Codel target, falling to 0% marking at or above zero 275 sojourn time. The lower point of the ramp should be chosen so that 276 SCE is not accidentally signalled due to CPU scheduling latencies or 277 serialisation delays of single packets. Absent rigorous analysis of 278 these factors, setting the lower limit at half the Codel target 279 should be safe in many cases. 281 The default configuration of Codel is 100ms interval, 5ms target. A 282 typical ramp function for these parameters might cease marking below 283 2.5ms sojourn time, increase marking probability linearly to 100% at 284 5ms, and mark at 100% for sojourn times above 5ms (in which CE 285 marking is also possible). 287 In single-queue AQMs, the above strategy will result in SCE flows 288 yielding to pressure from non-SCE flows, since CE marks do not occur 289 until SCE marking has reached 100%. A balance between smooth SCE 290 behaviour and fairness versus non-SCE traffic can be found by having 291 the marking ramp cross the Codel target at some lower SCE marking 292 rate, perhaps even 0%. A two-part ramp, reaching 1/sqrt(X) at the 293 Codel target (for some chosen X, a cwnd at which the crossover 294 between smoothness and fairness occurs) and ramping up more steeply 295 thereafter, has been implemented successfully for experimentation. 297 The CNQ algorithm [I-D.morton-tsvwg-cheap-nasty-queueing] offers a 298 relatively simple way to limit this yielding behaviour and ensure 299 that, even in competition with non-SCE flows, SCE flows maintain a 300 reasonable minimum throughput capability. This may be sufficient to 301 avoid the need for the two-part ramp described above. 303 Flow-isolating AQMs, including especially CNQ and DRR++ based 304 algorithms, should avoid signalling SCE to flows classified as 305 "sparse", in order to encourage the fastest possible convergence to 306 the fair share. 308 5.2. RED-type AQMs (including PIE) 310 There are several reasonable methods of producing SCE signals in a 311 RED-type AQM. 313 The simplest would be a threshold function, giving a hard boundary in 314 queue depth between 0% and 100% SCE marking. This could be a 315 sensible option for limited hardware implementations. The threshold 316 should be set below the point at which a growing queue might trigger 317 CE marking or packet drops. 319 Another option would be to implement a second marking probability 320 function, occupying a queue-depth space just below that occupied by 321 the main marking probability function. This should be arranged so 322 that high marking rates (ideally 100%) are achieved at or before the 323 point at which CE marking or packet drops begin. 325 For PIE specifically, a second marking probability function could be 326 added with the same parameters as the main marking probability 327 function, except for a lower QDELAY_REF value. This would result in 328 the SCE marking probability remaining strictly higher than the CE 329 marking probability for ECT flows. 331 5.3. TCP 333 Some mechanism should be defined to feed back SCE signals to the 334 sender explicitly. Details of this are left to 335 [I-D.grimes-tcpm-tcpsce]; use could be made of the redundant NS bit 336 in the TCP header, which was formerly associated with ECT(1) in the 337 Nonce Sum specification. 339 The recommended response to each single segment marked with SCE is to 340 reduce cwnd by an amortised 1/sqrt(cwnd) segments. Other responses, 341 such as the 1/cwnd from DCTCP, are also acceptable but may perform 342 less well. 344 5.4. Other 346 New transports under development, such as QUIC, may implement a fine- 347 grained signal back to the sender based on SCE. QUIC itself appears 348 to have this sort of feedback already (counting ECT(0), ECT(1) and CE 349 packets received), and the data should be made available for 350 congestion control. 352 6. Compatibility 354 6.1. Existing ECN & AQM Deployments 356 SCE explicitly retains [RFC8511] compliant Multiplicative Decrease 357 responses to CE marks, and conventional Multiplicative Decrease 358 responses to packet loss. SCE senders' behaviour is thus naturally 359 compliant with existing specifications when running over existing 360 networks. 362 Existing endpoints, supporting Not-ECT or [RFC3168] compliant 363 congestion control, are required to treat SCE marks (that is, ECT(1)) 364 as identical to ECT(0), and will thus transparently ignore SCE marks. 365 This is allowed for in SCE's design, and allows SCE middleboxes to be 366 deployed into a heterogeneous network. 368 Hence the incremental deployability of SCE endpoints and middleboxes 369 is good. 371 6.2. L4S 373 L4S also claims the ECT(1) codepoint, with significantly different 374 semantic meaning than SCE. In the L4S system, ECT(1) is used to 375 identify L4S flows, to distinguish them from [RFC3168] flows - 376 necessary since in L4S, the semantic meaning of CE marks is also 377 changed. 379 Since L4S connections are explicitly negotiated through support of 380 AccECN, and AccECN doesn't support SCE, there is no ambiguity 381 regarding the mode of the connection as far as endpoints are 382 concerned. 384 SCE middleboxes will treat L4S flows in the same way as [RFC3168] 385 does. 387 L4S middleboxes may interpret ECT packets which have received SCE 388 markings at some other SCE-aware middlebox as though they were L4S 389 traffic. This may result in a higher CE marking rate and/or 390 different queuing behaviour. Though undesirable, this appears to be 391 safe from SCE's point of view. Since the steady-state rate of SCE 392 marking is likely to be low, the impact on L4S is also likely to be 393 tolerable. 395 Accordingly, it appears as though the two experiments can coexist. 397 However, there is a secondary concern brought about by the L4S use of 398 ECT(1) as a traffic identifier. If, as presently seems likely, it is 399 found necessary to firewall L4S traffic off from the general 400 Internet, then SCE-marked packets are also likely to be dropped at 401 this boundary. This could have a significantly detrimental effect on 402 ECT traffic traversing both an SCE and an L4S enabled network, even 403 if the endpoints are not explicitly SCE aware. 405 7. Related Work 407 [RFC8087][RFC7567][RFC7928][RFC8290][RFC8289][RFC8033][RFC8034] 409 8. IANA Considerations 411 There are no IANA considerations. 413 9. Security Considerations 415 An adversary could inappropriately set SCE marks at middleboxes he 416 controls to slow down SCE-aware flows, eventually reaching a minimum 417 congestion window. However, the same threat already exists with 418 respect to inappropriately setting CE marks on normal ECN flows, and 419 this would have a greater impact per mark. Therefore no new threat 420 is exposed by SCE in practice. 422 An adversary could also simply ignore SCE marks at the receiver, or 423 ignore SCE information fed back from the receiver to the sender, in 424 an attempt to gain some advantage in throughput. Again, the same 425 could be said about ignoring CE marks, so no truly new threat is 426 exposed. Additionally, correctly implemented SCE detection may 427 actually improve long-term goodput compared to ignoring SCE. 429 An adversary could erase congestion information by converting SCE 430 marks to ECT or Not-ECT codepoints, thus hiding it from the receiver. 431 This has equivalent effects to ignoring SCE signals at the receiver. 432 An identical threat already exists for erasing congestion information 433 from CE marked packets, and may be mitigated by AQMs switching to 434 dropping packets from flows observed to be non-responsive to CE. 436 An adversary could drop SCE-marked packets, believing them to be 437 bogons (see also L4S Compatibility, above). Endpoints should be able 438 to recover from this through retransmission and a reduction of cwnd. 439 However, it is possible for this to lead to a significant denial of 440 service. A workaround is to disable ECN for connections over the 441 affected path. 443 10. Acknowledgements 445 Thanks to Dave Taht for his contributions to the SCE effort, and his 446 work on writing the original draft-morton-taht-sce-00 that was 447 submitted for IETF/104 on which this draft is based. 449 Many thanks to John Gilmore, the members of the ecn-sane project and 450 the cake@lists.bufferbloat.net mailing list, and the former IETF AQM 451 working group. 453 11. Normative References 455 [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion 456 Notification (ECN) Experimentation", RFC 8311, 457 DOI 10.17487/RFC8311, January 2018, 458 . 460 12. Informative References 462 [I-D.grimes-tcpm-tcpsce] 463 Grimes, R. and P. Heist, "Some Congestion Experienced in 464 TCP", draft-grimes-tcpm-tcpsce-00 (work in progress), 8 465 July 2019, 466 . 469 [I-D.morton-tsvwg-cheap-nasty-queueing] 470 Morton, J. and P. Heist, "Cheap Nasty Queueing", draft- 471 morton-tsvwg-cheap-nasty-queueing-00 (work in progress), 472 22 July 2019, 473 . 476 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 477 Requirement Levels", BCP 14, RFC 2119, 478 DOI 10.17487/RFC2119, March 1997, 479 . 481 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 482 of Explicit Congestion Notification (ECN) to IP", 483 RFC 3168, DOI 10.17487/RFC3168, September 2001, 484 . 486 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 487 Recommendations Regarding Active Queue Management", 488 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 489 . 491 [RFC7928] Kuhn, N., Ed., Natarajan, P., Ed., Khademi, N., Ed., and 492 D. Ros, "Characterization Guidelines for Active Queue 493 Management (AQM)", RFC 7928, DOI 10.17487/RFC7928, July 494 2016, . 496 [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, 497 "Proportional Integral Controller Enhanced (PIE): A 498 Lightweight Control Scheme to Address the Bufferbloat 499 Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, 500 . 502 [RFC8034] White, G. and R. Pan, "Active Queue Management (AQM) Based 503 on Proportional Integral Controller Enhanced PIE) for 504 Data-Over-Cable Service Interface Specifications (DOCSIS) 505 Cable Modems", RFC 8034, DOI 10.17487/RFC8034, February 506 2017, . 508 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 509 Explicit Congestion Notification (ECN)", RFC 8087, 510 DOI 10.17487/RFC8087, March 2017, 511 . 513 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 514 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 515 May 2017, . 517 [RFC8289] Nichols, K., Jacobson, V., McGregor, A., Ed., and J. 518 Iyengar, Ed., "Controlled Delay Active Queue Management", 519 RFC 8289, DOI 10.17487/RFC8289, January 2018, 520 . 522 [RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, 523 J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler 524 and Active Queue Management Algorithm", RFC 8290, 525 DOI 10.17487/RFC8290, January 2018, 526 . 528 [RFC8511] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 529 "TCP Alternative Backoff with ECN (ABE)", RFC 8511, 530 DOI 10.17487/RFC8511, December 2018, 531 . 533 Authors' Addresses 535 Jonathan Morton 536 Kokkonranta 21 537 FI-31520 Pitkajarvi 538 Finland 540 Phone: +358 44 927 2377 541 Email: chromatix99@gmail.com 543 Rodney W. Grimes (editor) 544 Redacted 545 Portland, OR 97217 546 United States 548 Email: rgrimes@freebsd.org