idnits 2.17.1 draft-ietf-tcpm-alternativebackoff-ecn-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 15, 2017) is 2351 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-accurate-ecn-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Khademi 3 Internet-Draft M. Welzl 4 Intended status: Experimental University of Oslo 5 Expires: May 19, 2018 G. Armitage 6 Swinburne University of Technology 7 G. Fairhurst 8 University of Aberdeen 9 November 15, 2017 11 TCP Alternative Backoff with ECN (ABE) 12 draft-ietf-tcpm-alternativebackoff-ecn-04 14 Abstract 16 Recent Active Queue Management (AQM) mechanisms allow for burst 17 tolerance while enforcing short queues to minimise the time that 18 packets spend enqueued at a bottleneck. This can cause noticeable 19 performance degradation for TCP connections traversing such a 20 bottleneck, especially if they are only a few or their bandwidth- 21 delay-product is large. An Explicit Congestion Notification (ECN) 22 signal indicates that an AQM mechanism is used at the bottleneck, and 23 therefore the bottleneck network queue is likely to be short. This 24 document therefore proposes an update to the TCP sender-side ECN 25 reaction in congestion avoidance to reduce the Congestion Window 26 (cwnd) by a smaller amount than the congestion control algorithm's 27 reaction to inferred packet loss. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 19, 2018. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4.1. Why Use ECN to Vary the Degree of Backoff? . . . . . . . 4 68 4.2. Focus on ECN as Defined in RFC3168 . . . . . . . . . . . 5 69 4.3. Choice of ABE Multiplier . . . . . . . . . . . . . . . . 5 70 5. ABE Requirements . . . . . . . . . . . . . . . . . . . . . . 7 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 10. Revision Information . . . . . . . . . . . . . . . . . . . . 9 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 11.2. Informative References . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Definitions 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119 [RFC2119]. 87 2. Introduction 89 Explicit Congestion Notification (ECN) [RFC3168] makes it possible 90 for an Active Queue Management (AQM) mechanism to signal the presence 91 of incipient congestion without incurring packet loss. This lets the 92 network deliver some packets to an application that would have been 93 dropped if the application or transport did not support ECN. This 94 packet loss reduction is the most obvious benefit of ECN, but it is 95 often relatively modest. There are also significant other benefits 96 from deploying ECN [RFC8087], including reduced end-to-end network 97 latency. 99 The rules for ECN were originally written to be very conservative, 100 and required the congestion control algorithms of ECN-capable 101 transport protocols to treat ECN congestion signals exactly the same 102 as they would treat an inferred packet loss [RFC3168]. 104 Research has demonstrated the benefits of reducing network delays 105 that are caused by interaction of loss-based TCP congestion control 106 and excessive buffering [BUFFERBLOAT]. This has led to the creation 107 of new AQM mechanisms like PIE [RFC8033] and CoDel 108 [CODEL2012][I-D.CoDel], which prevent bloated queues that are common 109 with unmanaged and excessively large buffers deployed across the 110 Internet [BUFFERBLOAT]. 112 The AQM mechanisms mentioned above aim to keep a sustained queue 113 short while tolerating transient (short-term) packet bursts. 114 However, currently used loss-based congestion control mechanisms 115 cannot always utilise a bottleneck link well where there are short 116 queues. For example, a TCP sender must be able to store at least an 117 end-to-end bandwidth-delay product (BDP) worth of data at the 118 bottleneck buffer if it is to maintain full path utilisation in the 119 face of loss-induced reduction of cwnd [RFC5681], which effectively 120 doubles the amount of data that can be in flight, the maximum round- 121 trip time (RTT) experience, and the path's effective RTT using the 122 network path. 124 Modern AQM mechanisms can use ECN to signal the early signs of 125 impending queue buildup long before a tail-drop queue would be forced 126 to resort to dropping packets. It is therefore appropriate for the 127 transport protocol congestion control algorithm to have a more 128 measured response when an early-warning signal of congestion is 129 received in the form of an ECN CE-marked packet. Recognizing these 130 changes in modern AQM practices, more recent rules have relaxed the 131 strict requirement that ECN signals be treated identically to 132 inferred packet loss [I-D.ECN-exp]. Following these newer, more 133 flexible rules, this document defines a new sender-side-only 134 congestion control response, called "ABE" (Alternative Backoff with 135 ECN). ABE improves TCP's average throughput when routers use AQM 136 controlled buffers that allow for short queues only. 138 3. Specification 140 This specification describes an update to the congestion control 141 algorithm of an ECN-capable TCP transport protocol. It allows a TCP 142 stack to update the TCP sender response when it receives feedback 143 indicating reception of a CE-marked packet (ECN-signalled congestion 144 hereafter) per Equation 4 of [RFC5681]. It RECOMMENDS that a TCP 145 sender multiplies the slow start threshold (ssthresh) by 0.8 times of 146 the FlightSize (with its minimum value set to 2 * SMSS) and reduces 147 the cwnd in congestion avoidance following reception of a TCP segment 148 that sets the ECN-Echo flag (defined in [RFC3168]). While this 149 specification concerns TCP, other transports also support a per-RTT 150 response to ECN. The method defined in this document is also 151 applicable for such transports. 153 4. Discussion 155 Much of the technical background to ABE can be found in a research 156 paper [ABE2017]. This paper used a mix of experiments, theory and 157 simulations with standard NewReno and CUBIC to evaluate the 158 technique. The technique was shown to present "...significant 159 performance gains in lightly-multiplexed [few concurrent flows] 160 scenarios, without losing the delay-reduction benefits of deploying 161 CoDel or PIE". The performance improvement is achieved when reacting 162 to ECN-Echo in congestion avoidance by multiplying cwnd and ssthresh 163 with a value in the range [0.7,0.85]. 165 4.1. Why Use ECN to Vary the Degree of Backoff? 167 The classic rule-of-thumb dictates that a network path needs to 168 provide a BDP of bottleneck buffering if a TCP connection wishes to 169 optimise path utilisation. A single TCP bulk transfer running 170 through such a bottleneck will have increased its congestion window 171 (cwnd) up to 2*BDP by the time that packet loss occurs. When packet 172 loss is inferred using the retransmission timer and the given packet 173 has not yet been resent by way of the retransmission timer (regarded 174 as a notification of congestion), Standard TCP sets the ssthresh to 175 the maximum of half of the FlightSize and 2*SMSS [RFC5681], which 176 causes the TCP congestion control to go back to allowing only a BDP 177 of packets in flight -- just sufficient to maintain 100% utilisation 178 of the bottleneck on the network path. 180 AQM mechanisms such as CoDel [I-D.CoDel] and PIE [RFC8033] set a 181 delay target in routers and use congestion notifications to constrain 182 the queuing delays experienced by packets, rather than in response to 183 impending or actual bottleneck buffer exhaustion. With current 184 default delay targets, CoDel and PIE both effectively emulate a 185 bottleneck with a short queue (section II, [ABE2017]) while also 186 allowing short traffic bursts into the queue. This provides 187 acceptable performance for TCP connections over a path with a low 188 BDP, or in highly multiplexed scenarios (many concurrent transport 189 flows). However, in a lightly-multiplexed case over a path with a 190 large BDP, conventional TCP backoff leads to gaps in packet 191 transmission and under-utilisation of the path. 193 Instead of discarding packets, an AQM mechanism is allowed to mark 194 ECN-capable packets with an ECN CE-mark. The reception of a CE-mark 195 feedback not only indicates congestion on the network path, it also 196 indicates that an AQM mechanism exists at the bottleneck along the 197 path, and hence the CE-mark likely came from a bottleneck with a 198 controlled short queue. Reacting differently to an ECN-signalled 199 congestion than to an inferred packet loss can then yield the benefit 200 of a reduced back-off when queues are short. Using ECN can also be 201 advantageous for several other reasons [RFC8087]. 203 The idea of reacting differently to inferred packet loss and 204 detection of an ECN-signalled congestion pre-dates this document. 205 For example, previous research proposed using ECN CE-marked feedback 206 to modify TCP congestion control behaviour via a larger 207 multiplicative decrease factor in conjunction with a smaller additive 208 increase factor [ICC2002]. The goal of this former work was to 209 operate across AQM bottlenecks using Random Early Detection (RED) 210 that were not necessarily configured to emulate a short queue 211 ([RFC7567] notes the current status of RED as an AQM method.) 213 4.2. Focus on ECN as Defined in RFC3168 215 Some transport protocol mechanisms rely on ECN semantics that differ 216 from the original ECN definition [RFC3168] -- for example, Congestion 217 Exposure (ConEx) [RFC7713] and Datacenter TCP (DCTCP) 218 [I-D.ietf-tcpm-dctcp] need more accurate ECN information than that 219 offered by the original feedback method. Other mechanisms (e.g., 220 [I-D.ietf-tcpm-accurate-ecn]) allow the sender to adjust the rate 221 more frequently than once each path RTT. Use of these mechanisms is 222 out of scope for this document. 224 4.3. Choice of ABE Multiplier 226 ABE decouples the reaction of a TCP sender to inferred packet loss 227 and ECN-signalled congestion when in the congestion avoidance phase 228 by differentiating the scaling factor used in Equation 4 in 229 Section 3.1 of [RFC5681]. The description respectively uses 230 beta_{loss} and beta_{ecn} to refer to the multiplicative decrease 231 factors applied in response to inferred packet loss, and in response 232 to a receiver indicating ECN-signalled congestion. For non-ECN- 233 enabled TCP connections, only beta_{loss} applies. 235 In other words, in response to inferred packet loss: 237 ssthresh = max (FlightSize * beta_{loss}, 2 * SMSS) 239 and in response to an indication of an ECN-signalled congestion: 241 ssthresh = max (FlightSize * beta_{ecn}, 2 * SMSS) 243 and 245 cwnd = ssthresh 247 where FlightSize is the amount of outstanding data in the network, 248 upper-bounded by the smaller of the sender's cwnd and the receiver's 249 advertised window (rwnd) [RFC5681]. The higher the values of 250 beta_{loss} and beta_{ecn}, the less aggressive the response of any 251 individual backoff event. 253 The appropriate choice for beta_{loss} and beta_{ecn} values is a 254 balancing act between path utilisation and draining the bottleneck 255 queue. More aggressive backoff (smaller beta_*) risks underutilising 256 the path, while less aggressive backoff (larger beta_*) can result in 257 slower draining of the bottleneck queue. 259 The Internet has already been running with at least two different 260 beta_{loss} values for several years: the standard value is 0.5 261 [RFC5681], and the Linux implementation of CUBIC [I-D.CUBIC] has used 262 a multiplier of 0.7 since kernel version 2.6.25 released in 2008. 263 ABE proposes no change to beta_{loss} used by current TCP 264 implementations. 266 beta_{ecn} depends on how the response of a TCP connection to shallow 267 AQM marking thresholds is optimised. beta_{loss} reflects the 268 preferred response of each congestion control algorithm when faced 269 with exhaustion of buffers (of unknown depth) signalled by packet 270 loss. Consequently, for any given TCP congestion control algorithm 271 the choice of beta_{ecn} is likely to be algorithm-specific, rather 272 than a constant multiple of the algorithm's existing beta_{loss}. 273 The recommended beta_{ecn} value in this document is only applicable 274 for Standard TCP congestion control. 276 A range of tests (section IV, [ABE2017]) with NewReno and CUBIC over 277 CoDel and PIE in lightly-multiplexed scenarios have explored this 278 choice of parameter. The results of these tests indicate that CUBIC 279 connections benefit from beta_{ecn} of 0.85 (cf. beta_{loss} = 0.7), 280 and NewReno connections see improvements with beta_{ecn} in the range 281 0.7 to 0.85 (cf. beta_{loss} = 0.5). 283 5. ABE Requirements 285 This update is a sender-side only change. Like other changes to 286 congestion control algorithms, it does not require any change to the 287 TCP receiver or to network devices. It does not require any ABE- 288 specific changes in routers or the use of Accurate ECN feedback 289 [I-D.ietf-tcpm-accurate-ecn] by a receiver. 291 RFC 3168 states that the congestion control response to an ECN- 292 signalled congestion is the same as the response to a dropped packet 293 [RFC3168]. [I-D.ECN-exp] updates this specification to allow systems 294 to provide a different behaviour when they experience ECN-signalled 295 congestion rather than packet loss. The present specification 296 defines such an experiment and has thus been assigned an Experimental 297 status before being proposed as a Standards-Track update. 299 The purpose of the Internet experiment is to collect experience with 300 deployment of ABE, and confirm the safety in deployed networks using 301 this update to TCP congestion control. 303 When used with bottlenecks that do not support ECN-marking the 304 specification does not modify the transport protocol. 306 To evaluate the benefit, this experiment therefore requires support 307 in AQM routers (except to enable an ECN-marking mechanism [RFC3168] 308 [RFC7567]) for ECN-marking of packets carrying the ECN Capable 309 Transport, ECT(0), codepoint [RFC3168]. 311 If the method is only deployed by some senders, and not by others, 312 the senders that use this method can gain some advantage, possibly at 313 the expense of other flows that do not use this updated method. 314 Because this advantage applies only to ECN-marked packets and not to 315 packet loss indications, in the worst-case (e.g., an ABE-compliant 316 TCP sender using beta_{ecn} = 1.0) the ECN-capable bottleneck will 317 still fall back to dropping packets, and the result is no different 318 than if the TCP sender was using traditional loss-based congestion 319 control. 321 The result of this Internet experiment will be reported by 322 presentation to the TCPM WG (or IESG) or an implementation report at 323 the end of the experiment. 325 6. Acknowledgements 327 Authors N. Khademi, M. Welzl and G. Fairhurst were part-funded by 328 the European Community under its Seventh Framework Programme through 329 the Reducing Internet Transport Latency (RITE) project (ICT-317700). 330 The views expressed are solely those of the authors. 332 The authors would like to thank Stuart Cheshire for many suggestions 333 when revising the draft, and the following people for their 334 contributions to [ABE2017]: Chamil Kulatunga, David Ros, Stein 335 Gjessing, Sebastian Zander. Thanks also to (in alphabetical order) 336 Bob Briscoe, Markku Kojo, John Leslie, Dave Taht and the TCPM working 337 group for providing valuable feedback on this document. 339 The authors would finally like to thank everyone who provided 340 feedback on the congestion control behaviour specified in this update 341 received from the IRTF Internet Congestion Control Research Group 342 (ICCRG). 344 7. IANA Considerations 346 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 348 This document includes no request to IANA. 350 8. Implementation Status 352 ABE is implemented as a patch for Linux and FreeBSD. It is meant for 353 research and available for download from 354 http://heim.ifi.uio.no/naeemk/research/ABE/. This code was used to 355 produce the test results that are reported in [ABE2017]. An evolved 356 version of the patch for FreeBSD is currently under review for 357 potential inclusion in the mainline kernel [ABE-FreeBSD]. 359 9. Security Considerations 361 The described method is a sender-side only transport change, and does 362 not change the protocol messages exchanged. The security 363 considerations for ECN [RFC3168] therefore still apply. 365 This is a change to TCP congestion control with ECN that will 366 typically lead to a change in the capacity achieved when flows share 367 a network bottleneck. This could result in some flows receiving more 368 than their fair share of capacity. Similar unfairness in the way 369 that capacity is shared is also exhibited by other congestion control 370 mechanisms that have been in use in the Internet for many years 371 (e.g., CUBIC [I-D.CUBIC]). Unfairness may also be a result of other 372 factors, including the round trip time experienced by a flow. ABE 373 applies only when ECN-marked packets are received, not when packets 374 are lost, hence use of ABE cannot lead to congestion collapse. 376 10. Revision Information 378 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 380 -04. Incorporates review comments from Larence Stewart and the 381 remaining comments from Roland Bless. References are updated. 383 -03. Several review comments from Roland Bless are addressed. 384 Consistent terminology and equations. Clarification on the scope of 385 recommended beta_{ecn} value. 387 -02. Corrected the equations in Section 4.3. Updated the 388 affiliations. Lower bound for cwnd is defined. A recommendation for 389 window-based transport protocols is changed to cover all transport 390 protocols that implement a congestion control reduction to an ECN 391 congestion signal. Added text about ABE's FreeBSD mainline kernel 392 status including a reference to the FreeBSD code review page. 393 References are updated. 395 -01. Text improved, mainly incorporating comments from Stuart 396 Cheshire. The reference to a technical report has been updated to a 397 published version of the tests [ABE2017]. Used "AQM Mechanism" 398 throughout in place of other alternatives, and more consistent use of 399 technical language and clarification on the intended purpose of the 400 experiments required by EXP status. There was no change to the 401 technical content. 403 -00. draft-ietf-tcpm-alternativebackoff-ecn-00 replaces draft- 404 khademi-tcpm-alternativebackoff-ecn-01. Text describing the nature 405 of the experiment was added. 407 Individual draft -01. This I-D now refers to draft-black-tsvwg-ecn- 408 experimentation-02, which replaces draft-khademi-tsvwg-ecn- 409 response-00 to make a broader update to RFC3168 for the sake of 410 allowing experiments. As a result, some of the motivating and 411 discussing text that was moved from draft-khademi-alternativebackoff- 412 ecn-03 to draft-khademi-tsvwg-ecn-response-00 has now been re- 413 inserted here. 415 Individual draft -00. draft-khademi-tsvwg-ecn-response-00 and draft- 416 khademi-tcpm-alternativebackoff-ecn-00 replace draft-khademi- 417 alternativebackoff-ecn-03, following discussion in the TSVWG and TCPM 418 working groups. 420 11. References 422 11.1. Normative References 424 [I-D.ECN-exp] 425 Black, D., "Explicit Congestion Notification (ECN) 426 Experimentation", Internet-draft, IETF work-in-progress 427 draft-ietf-tsvwg-ecn-experimentation-08, November 2017. 429 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 430 Requirement Levels", BCP 14, RFC 2119, 431 DOI 10.17487/RFC2119, March 1997, 432 . 434 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 435 of Explicit Congestion Notification (ECN) to IP", 436 RFC 3168, DOI 10.17487/RFC3168, September 2001, 437 . 439 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 440 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 441 . 443 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 444 Recommendations Regarding Active Queue Management", 445 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 446 . 448 11.2. Informative References 450 [ABE-FreeBSD] 451 "ABE patch review in FreeBSD", 452 . 454 [ABE2017] Khademi, N., Armitage, G., Welzl, M., Fairhurst, G., 455 Zander, S., and D. Ros, "Alternative Backoff: Achieving 456 Low Latency and High Throughput with ECN and AQM", IFIP 457 NETWORKING 2017, Stockholm, Sweden, June 2017. 459 [BUFFERBLOAT] 460 Gettys, J. and K. Nichols, "Bufferbloat: Dark Buffers in 461 the Internet", November 2011. 463 [CODEL2012] 464 Nichols, K. and V. Jacobson, "Controlling Queue Delay", 465 July 2012, . 467 [I-D.CoDel] 468 Nichols, K., Jacobson, V., McGregor, V., and J. Iyengar, 469 "Controlled Delay Active Queue Management", Internet- 470 draft, IETF work-in-progress draft-ietf-aqm-codel-10, 471 October 2017. 473 [I-D.CUBIC] 474 Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and 475 R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", 476 Internet-draft, IETF work-in-progress draft-ietf-tcpm- 477 cubic-07, November 2017. 479 [I-D.ietf-tcpm-accurate-ecn] 480 Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More 481 Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate- 482 ecn-03 (work in progress), May 2017. 484 [I-D.ietf-tcpm-dctcp] 485 Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., 486 and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion 487 Control for Datacenters", draft-ietf-tcpm-dctcp-10 (work 488 in progress), August 2017. 490 [ICC2002] Kwon, M. and S. Fahmy, "TCP Increase/Decrease Behavior 491 with Explicit Congestion Notification (ECN)", IEEE 492 ICC 2002, New York, New York, USA, May 2002, 493 . 495 [RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) 496 Concepts, Abstract Mechanism, and Requirements", RFC 7713, 497 DOI 10.17487/RFC7713, December 2015, 498 . 500 [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, 501 "Proportional Integral Controller Enhanced (PIE): A 502 Lightweight Control Scheme to Address the Bufferbloat 503 Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, 504 . 506 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 507 Explicit Congestion Notification (ECN)", RFC 8087, 508 DOI 10.17487/RFC8087, March 2017, 509 . 511 Authors' Addresses 513 Naeem Khademi 514 University of Oslo 515 PO Box 1080 Blindern 516 Oslo N-0316 517 Norway 519 Email: naeemk@ifi.uio.no 521 Michael Welzl 522 University of Oslo 523 PO Box 1080 Blindern 524 Oslo N-0316 525 Norway 527 Email: michawe@ifi.uio.no 529 Grenville Armitage 530 Internet For Things (I4T) Research Group 531 Swinburne University of Technology 532 PO Box 218 533 John Street, Hawthorn 534 Victoria 3122 535 Australia 537 Email: garmitage@swin.edu.au 539 Godred Fairhurst 540 University of Aberdeen 541 School of Engineering, Fraser Noble Building 542 Aberdeen AB24 3UE 543 UK 545 Email: gorry@erg.abdn.ac.uk