idnits 2.17.1 draft-ietf-tcpm-alternativebackoff-ecn-03.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 (October 30, 2017) is 2369 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-tsvwg-ecn-experimentation-06 == Outdated reference: A later version (-10) exists of draft-ietf-aqm-codel-09 == Outdated reference: A later version (-07) exists of draft-ietf-tcpm-cubic-06 == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-accurate-ecn-03 Summary: 0 errors (**), 0 flaws (~~), 6 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 3, 2018 G. Armitage 6 Swinburne University of Technology 7 G. Fairhurst 8 University of Aberdeen 9 October 30, 2017 11 TCP Alternative Backoff with ECN (ABE) 12 draft-ietf-tcpm-alternativebackoff-ecn-03 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 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 3, 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 . . . . . . . . . . . . . . . . 6 70 5. ABE Requirements . . . . . . . . . . . . . . . . . . . . . . 7 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 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 a 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]. There are two main approaches 107 to reduce such delay: (1) to use a congestion control mechanism that 108 reacts to the changes in end-to-end delay (i.e. delay-based) instead 109 of or in addition to loss or ECN signal (2) or to use AQM mechanisms 110 like PIE [RFC8033] and CoDel [CODEL2012] [I-D.CoDel], which avoid 111 causing bloated queues that are common with a simple tail-drop 112 behaviour (also known as a First-In First-Out, FIFO, queue). The 113 delay-based approach suffers from poor performance when competing 114 with flows using loss-based TCP congestion control mechanisms and is 115 out of scope of this document. 117 The AQM mechanisms mentioned above aim to keep a sustained queue 118 short while tolerating transient (short-term) packet bursts. 119 However, currently used loss-based congestion control mechanisms 120 cannot always utilise a bottleneck link well where there are short 121 queues. For example, to allow a single TCP connection to fully 122 utilise a network path, the queue at the bottleneck link must be able 123 to compensate for TCP reducing the "cwnd" and "ssthresh" variables in 124 response to a lost packet [RFC5681]. This requires the bottleneck 125 buffer to be able to store at least an end-to-end bandwidth-delay 126 product (BDP) of data, which effectively doubles both the amount of 127 data that can be in flight and the maximum round-trip time (RTT) 128 experience using the network path. 130 Modern AQM mechanisms can use ECN to signal the early signs of 131 impending queue buildup long before a tail-drop queue would be forced 132 to resort to dropping packets. It is therefore appropriate for the 133 transport protocol congestion control algorithm to have a more 134 measured response when an early-warning signal of congestion is 135 received in the form of an ECN CE-marked packet. Recognizing these 136 changes in modern AQM practices, more recent rules have relaxed the 137 strict requirement that ECN signals be treated identically to packet 138 loss [I-D.ECN-exp]. Following these newer, more flexible rules, this 139 document defines a new sender-side-only congestion control response, 140 called "ABE" (Alternative Backoff with ECN). ABE improves the 141 performance when routers use AQM controlled buffers that allow for 142 short queues only. 144 3. Specification 146 This specification describes an update to the congestion control 147 algorithm of an ECN-capable TCP transport protocol. It allows a TCP 148 stack to update the TCP sender response when it receives feedback 149 indicating reception of a CE-marked packet. It RECOMMENDS that a TCP 150 sender multiplies the slow start threshold (ssthresh) by 0.8 times of 151 the FlightSize (with its minimum value set to 2 * SMSS) and reduces 152 the cwnd in congestion avoidance following reception of a TCP segment 153 that sets the ECN-Echo flag (defined in [RFC3168]). While this 154 specification concerns TCP, other transports also support a per-RTT 155 response to ECN. The method defined in this document is also 156 applicable for such transports. 158 4. Discussion 160 Much of the technical background to this congestion control response 161 can be found in a research paper [ABE2017]. This paper used a mix of 162 experiments, theory and simulations with standard NewReno and CUBIC 163 to evaluate the technique. It examined the impact of enabling ECN 164 and letting individual TCP senders back off by a reduced amount in 165 reaction to the receiver that reports ECN CE-marks from AQM-enabled 166 bottlenecks. The technique was shown to present "...significant 167 performance gains in lightly-multiplexed [few concurrent connections] 168 scenarios, without losing the delay-reduction benefits of deploying 169 CoDel or PIE". The performance improvement is achieved when reacting 170 to ECN-Echo in congestion avoidance by multiplying cwnd and ssthresh 171 with a value in the range [0.7..0.85]. 173 4.1. Why Use ECN to Vary the Degree of Backoff? 175 The classic rule-of-thumb dictates that a network path needs to 176 provide a BDP of bottleneck buffering if a TCP connection wishes to 177 optimise path utilisation. A single TCP bulk transfer running 178 through such a bottleneck will have increased its congestion window 179 (cwnd) up to 2*BDP by the time that packet loss occurs. When packet 180 loss is detected using the retransmission timer and the given packet 181 has not yet been resent by way of the retransmission timer (regarded 182 as a notification of congestion), Standard TCP sets the ssthresh to 183 the maximum of half of the FlightSize and 2*SMSS [RFC5681], which 184 causes the TCP congestion control to go back to allowing only a BDP 185 of packets in flight -- just sufficient to maintain 100% utilisation 186 of the bottleneck on the network path. 188 AQM mechanisms such as CoDel [I-D.CoDel] and PIE [RFC8033] set a 189 delay target in routers and use congestion notifications to constrain 190 the queuing delays experienced by packets, rather than in response to 191 impending or actual bottleneck buffer exhaustion. With current 192 default delay targets, CoDel and PIE both effectively emulate a 193 bottleneck with a short queue (section II, [ABE2017]) while also 194 allowing short traffic bursts into the queue. This provides 195 acceptable performance for TCP connections over a path with a low 196 BDP, or in highly multiplexed scenarios (many concurrent transport 197 connections). However, in a lightly-multiplexed case over a path 198 with a large BDP, conventional TCP backoff leads to gaps in packet 199 transmission and under-utilisation of the path. 201 Instead of discarding packets, an AQM mechanism is allowed to mark 202 ECN-capable packets with an ECN CE-mark. The reception of a CE-mark 203 not only indicates congestion on the network path, it also indicates 204 that an AQM mechanism exists at the bottleneck along the path, and 205 hence the CE-mark likely came from a bottleneck with a controlled 206 short queue. Reacting differently to an ECN CE-mark than to packet 207 loss can then yield the benefit of a reduced back-off, as with CUBIC 208 [I-D.CUBIC], when queues are short, yet it can avoid generating 209 excessive delay when queues are long. Using ECN can also be 210 advantageous for several other reasons [RFC8087]. 212 The idea of reacting differently to loss and detection of an ECN CE- 213 mark pre-dates this document. For example, previous research 214 proposed using ECN CE-marks to modify TCP congestion control 215 behaviour via a larger multiplicative decrease factor in conjunction 216 with a smaller additive increase factor [ICC2002]. The goal of this 217 former work was to operate across AQM bottlenecks using Random Early 218 Detection (RED) that were not necessarily configured to emulate a 219 short queue ([RFC7567] notes the current status of RED as an AQM 220 method.) 222 4.2. Focus on ECN as Defined in RFC3168 224 Some transport protocol mechanisms rely on ECN semantics that differ 225 from the original ECN definition [RFC3168] -- for example, Congestion 226 Exposure (ConEx) [RFC7713] and Datacenter TCP (DCTCP) 227 [I-D.ietf-tcpm-dctcp] need more accurate ECN information than that 228 offered by the original feedback method. Other mechanisms (e.g., 229 [I-D.ietf-tcpm-accurate-ecn]) allow the sender to adjust the rate 230 more frequently than once each path RTT. Use of these mechanisms is 231 out of the scope of the current document. 233 4.3. Choice of ABE Multiplier 235 ABE decouples the reaction of a TCP sender to loss and ECN CE-marks 236 when in the congestion avoidance phase by differentiating the scaling 237 factor used in Equation 4 in Section 3.1 of [RFC5681]. The 238 description respectively uses beta_{loss} and beta_{ecn} to refer to 239 the multiplicative decrease factors applied in response to packet 240 loss, and in response to a receiver indicating that an ECN CE-mark 241 was received on an ECN-enabled TCP connection. For non-ECN-enabled 242 TCP connections, no ECN CE-marks are received and only beta_{loss} 243 applies. 245 In other words, in response to detected loss: 247 ssthresh = max (FlightSize * beta_{loss}, 2 * SMSS) 249 and in response to an indication of a received ECN CE-mark: 251 ssthresh = max (FlightSize * beta_{ecn}, 2 * SMSS) 253 and 255 cwnd = ssthresh 257 where FlightSize is the amount of outstanding data in the network, 258 upper-bounded by the sender's cwnd and the receiver's advertised 259 window (rwnd) [RFC5681]. The higher the values of beta_{loss} and 260 beta_{ecn}, the less aggressive the response of any individual 261 backoff event. 263 The appropriate choice for beta_{loss} and beta_{ecn} values is a 264 balancing act between path utilisation and draining the bottleneck 265 queue. More aggressive backoff (smaller beta_*) risks underutilising 266 the path, while less aggressive backoff (larger beta_*) can result in 267 slower draining of the bottleneck queue. 269 The Internet has already been running with at least two different 270 beta_{loss} values for several years: the standard value is 0.5 271 [RFC5681], and the Linux implementation of CUBIC [I-D.CUBIC] has used 272 a multiplier of 0.7 since kernel version 2.6.25 released in 2008. 273 ABE proposes no change to beta_{loss} used by current TCP 274 implementations. 276 beta_{ecn} depends on how the response of a TCP connection to shallow 277 AQM marking thresholds is optimised. beta_{loss} reflects the 278 preferred response of each congestion control algorithm when faced 279 with exhaustion of buffers (of unknown depth) signalled by packet 280 loss. Consequently, for any given TCP congestion control algorithm 281 the choice of beta_{ecn} is likely to be algorithm-specific, rather 282 than a constant multiple of the algorithm's existing beta_{loss}. 283 The recommended beta_{ecn} value in this document is only applicable 284 for Standard TCP congestion control. 286 A range of tests (section IV, [ABE2017]) with NewReno and CUBIC over 287 CoDel and PIE in lightly-multiplexed scenarios have explored this 288 choice of parameter. The results of these tests indicate that CUBIC 289 connections benefit from beta_{ecn} of 0.85 (cf. beta_{loss} = 0.7), 290 and NewReno connections see improvements with beta_{ecn} in the range 291 0.7 to 0.85 (cf. beta_{loss} = 0.5). 293 5. ABE Requirements 295 This update is a sender-side only change. Like other changes to 296 congestion control algorithms, it does not require any change to the 297 TCP receiver or to network devices. It does not require any ABE- 298 specific changes in routers or the use of Accurate ECN feedback 299 [I-D.ietf-tcpm-accurate-ecn] by a receiver. 301 The currently published ECN specification requires that the 302 congestion control response to a CE-marked packet is the same as the 303 response to a dropped packet [RFC3168]. The specification is 304 currently being updated to allow for specifications that do not 305 follow this rule [I-D.ECN-exp]. The present specification defines 306 such an experiment and has thus been assigned an Experimental status 307 before being proposed as a Standards-Track update. 309 The purpose of the Internet experiment is to collect experience with 310 deployment of ABE, and confirm the safety in deployed networks using 311 this update to TCP congestion control. 313 When used with bottlenecks that do not support ECN-marking the 314 specification does not modify the transport protocol. 316 To evaluate the benefit, this experiment therefore requires support 317 in AQM routers (except to enable an ECN-marking mechanism [RFC3168] 318 [RFC7567]) for ECN-marking of packets carrying the ECN Capable 319 Transport, ECT(0), codepoint [RFC3168]. 321 If the method is only deployed by some senders, and not by others, 322 the senders that use this method can gain some advantage, possibly at 323 the expense of other flows that do not use this updated method. 324 Because this advantage applies only to ECN-marked packets and not to 325 loss indications, the new method cannot lead to congestion collapse. 327 The result of this Internet experiment will be reported by 328 presentation to the TCPM WG (or IESG) or an implementation report at 329 the end of the experiment. 331 6. Acknowledgements 333 Authors N. Khademi, M. Welzl and G. Fairhurst were part-funded by 334 the European Community under its Seventh Framework Programme through 335 the Reducing Internet Transport Latency (RITE) project (ICT-317700). 336 The views expressed are solely those of the authors. 338 The authors would like to thank Stuart Cheshire for many suggestions 339 when revising the draft, and the following people for their 340 contributions to [ABE2017]: Chamil Kulatunga, David Ros, Stein 341 Gjessing, Sebastian Zander. Thanks also to (in alphabetical order) 342 Bob Briscoe, Markku Kojo, John Leslie, Dave Taht and the TCPM working 343 group for providing valuable feedback on this document. 345 The authors would finally like to thank everyone who provided 346 feedback on the congestion control behaviour specified in this update 347 received from the IRTF Internet Congestion Control Research Group 348 (ICCRG). 350 7. IANA Considerations 352 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 354 This document includes no request to IANA. 356 8. Implementation Status 358 ABE is implemented as a patch for Linux and FreeBSD. It is meant for 359 research and available for download from 360 http://heim.ifi.uio.no/naeemk/research/ABE/. This code was used to 361 produce the test results that are reported in [ABE2017]. An evolved 362 version of the patch for FreeBSD is currently under review for 363 potential inclusion in the mainline kernel [ABE-FreeBSD]. 365 9. Security Considerations 367 The described method is a sender-side only transport change, and does 368 not change the protocol messages exchanged. The security 369 considerations for ECN [RFC3168] therefore still apply. 371 This is a change to TCP congestion control with ECN that will 372 typically lead to a change in the capacity achieved when flows share 373 a network bottleneck. This could result in some flows receiving more 374 than their fair share of capacity. Similar unfairness in the way 375 that capacity is shared is also exhibited by other congestion control 376 mechanisms that have been in use in the Internet for many years 377 (e.g., CUBIC [I-D.CUBIC]). Unfairness may also be a result of other 378 factors, including the round trip time experienced by a flow. ABE 379 applies only when ECN-marked packets are received, not when packets 380 are lost, hence use of ABE cannot lead to congestion collapse. 382 10. Revision Information 384 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 386 -03. Several review comments from Roland Bless are addressed. 387 Consistent terminology and equations. Clarification on the scope of 388 recommended beta_{ecn} value. 390 -02. Corrected the equations in Section 4.3. Updated the 391 affiliations. Lower bound for cwnd is defined. A recommendation for 392 window-based transport protocols is changed to cover all transport 393 protocols that implement a congestion control reduction to an ECN 394 congestion signal. Added text about ABE's FreeBSD mainline kernel 395 status including a reference to the FreeBSD code review page. 396 References are updated. 398 -01. Text improved, mainly incorporating comments from Stuart 399 Cheshire. The reference to a technical report has been updated to a 400 published version of the tests [ABE2017]. Used "AQM Mechanism" 401 throughout in place of other alternatives, and more consistent use of 402 technical language and clarification on the intended purpose of the 403 experiments required by EXP status. There was no change to the 404 technical content. 406 -00. draft-ietf-tcpm-alternativebackoff-ecn-00 replaces draft- 407 khademi-tcpm-alternativebackoff-ecn-01. Text describing the nature 408 of the experiment was added. 410 Individual draft -01. This I-D now refers to draft-black-tsvwg-ecn- 411 experimentation-02, which replaces draft-khademi-tsvwg-ecn- 412 response-00 to make a broader update to RFC3168 for the sake of 413 allowing experiments. As a result, some of the motivating and 414 discussing text that was moved from draft-khademi-alternativebackoff- 415 ecn-03 to draft-khademi-tsvwg-ecn-response-00 has now been re- 416 inserted here. 418 Individual draft -00. draft-khademi-tsvwg-ecn-response-00 and draft- 419 khademi-tcpm-alternativebackoff-ecn-00 replace draft-khademi- 420 alternativebackoff-ecn-03, following discussion in the TSVWG and TCPM 421 working groups. 423 11. References 425 11.1. Normative References 427 [I-D.ECN-exp] 428 Black, D., "Explicit Congestion Notification (ECN) 429 Experimentation", Internet-draft, IETF work-in-progress 430 draft-ietf-tsvwg-ecn-experimentation-06, September 2017. 432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, 434 DOI 10.17487/RFC2119, March 1997, 435 . 437 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 438 of Explicit Congestion Notification (ECN) to IP", 439 RFC 3168, DOI 10.17487/RFC3168, September 2001, 440 . 442 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 443 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 444 . 446 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 447 Recommendations Regarding Active Queue Management", 448 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 449 . 451 11.2. Informative References 453 [ABE-FreeBSD] 454 "ABE patch review in FreeBSD", 455 . 457 [ABE2017] Khademi, N., Armitage, G., Welzl, M., Fairhurst, G., 458 Zander, S., and D. Ros, "Alternative Backoff: Achieving 459 Low Latency and High Throughput with ECN and AQM", IFIP 460 NETWORKING 2017, Stockholm, Sweden, June 2017. 462 [BUFFERBLOAT] 463 "Bufferbloat project", 464 . 467 [CODEL2012] 468 Nichols, K. and V. Jacobson, "Controlling Queue Delay", 469 July 2012, . 471 [I-D.CoDel] 472 Nichols, K., Jacobson, V., McGregor, V., and J. Iyengar, 473 "Controlled Delay Active Queue Management", Internet- 474 draft, IETF work-in-progress draft-ietf-aqm-codel-09, 475 September 2017. 477 [I-D.CUBIC] 478 Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and 479 R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", 480 Internet-draft, IETF work-in-progress draft-ietf-tcpm- 481 cubic-06, September 2017. 483 [I-D.ietf-tcpm-accurate-ecn] 484 Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More 485 Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate- 486 ecn-03 (work in progress), May 2017. 488 [I-D.ietf-tcpm-dctcp] 489 Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., 490 and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion 491 Control for Datacenters", draft-ietf-tcpm-dctcp-10 (work 492 in progress), August 2017. 494 [ICC2002] Kwon, M. and S. Fahmy, "TCP Increase/Decrease Behavior 495 with Explicit Congestion Notification (ECN)", IEEE 496 ICC 2002, New York, New York, USA, May 2002, 497 . 499 [RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) 500 Concepts, Abstract Mechanism, and Requirements", RFC 7713, 501 DOI 10.17487/RFC7713, December 2015, 502 . 504 [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, 505 "Proportional Integral Controller Enhanced (PIE): A 506 Lightweight Control Scheme to Address the Bufferbloat 507 Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, 508 . 510 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 511 Explicit Congestion Notification (ECN)", RFC 8087, 512 DOI 10.17487/RFC8087, March 2017, 513 . 515 Authors' Addresses 517 Naeem Khademi 518 University of Oslo 519 PO Box 1080 Blindern 520 Oslo N-0316 521 Norway 523 Email: naeemk@ifi.uio.no 525 Michael Welzl 526 University of Oslo 527 PO Box 1080 Blindern 528 Oslo N-0316 529 Norway 531 Email: michawe@ifi.uio.no 533 Grenville Armitage 534 Internet For Things (I4T) Research Group 535 Swinburne University of Technology 536 PO Box 218 537 John Street, Hawthorn 538 Victoria 3122 539 Australia 541 Email: garmitage@swin.edu.au 543 Godred Fairhurst 544 University of Aberdeen 545 School of Engineering, Fraser Noble Building 546 Aberdeen AB24 3UE 547 UK 549 Email: gorry@erg.abdn.ac.uk