idnits 2.17.1 draft-ietf-tcpm-alternativebackoff-ecn-05.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 (December 11, 2017) is 2327 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 (~~), 2 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: June 14, 2018 G. Armitage 6 Swinburne University of Technology 7 G. Fairhurst 8 University of Aberdeen 9 December 11, 2017 11 TCP Alternative Backoff with ECN (ABE) 12 draft-ietf-tcpm-alternativebackoff-ecn-05 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 there are only a few flows or their 21 bandwidth-delay-product is large. An Explicit Congestion 22 Notification (ECN) signal indicates that an AQM mechanism is used at 23 the bottleneck, and therefore the bottleneck network queue is likely 24 to be short. This document therefore proposes an update to RFC3168, 25 which changes the TCP sender-side ECN reaction in congestion 26 avoidance to reduce the Congestion Window (cwnd) by a smaller amount 27 than the congestion control algorithm's reaction to inferred packet 28 loss. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on June 14, 2018. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 3 67 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4.1. Why Use ECN to Vary the Degree of Backoff? . . . . . . . 4 69 4.2. Focus on ECN as Defined in RFC3168 . . . . . . . . . . . 5 70 4.3. Choice of ABE Multiplier . . . . . . . . . . . . . . . . 5 71 5. ABE Requirements . . . . . . . . . . . . . . . . . . . . . . 7 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 10. Revision Information . . . . . . . . . . . . . . . . . . . . 9 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 11.2. Informative References . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Definitions 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119 [RFC2119]. 88 2. Introduction 90 Explicit Congestion Notification (ECN) [RFC3168] makes it possible 91 for an Active Queue Management (AQM) mechanism to signal the presence 92 of incipient congestion without incurring packet loss. This lets the 93 network deliver some packets to an application that would have been 94 dropped if the application or transport did not support ECN. This 95 packet loss reduction is the most obvious benefit of ECN, but it is 96 often relatively modest. Other benefits of deploying ECN have been 97 documented in RFC8087 [RFC8087]. 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 updates the congestion control algorithm of an 141 ECN-Capable TCP transport protocol by changing the TCP sender 142 response to feedback from the TCP receiver that indicates reception 143 of a CE-marked packet, i.e., receipt of a packet with the ECN-Echo 144 flag (defined in [RFC3168]) set. 146 It updates the following text in section 6.1.2 of the ECN 147 specification [RFC3168] : 149 The indication of congestion should be treated just as a 150 congestion loss in non-ECN-Capable TCP. That is, the TCP source 151 halves the congestion window "cwnd" and reduces the slow start 152 threshold "ssthresh". 154 Replacing this with: 156 Receipt of a packet with the ECN-Echo flag SHOULD trigger the TCP 157 source to set the slow start threshold (ssthresh) to 0.8 times the 158 FlightSize, with a lower bound of 2 * SMSS applied to the result. 159 As in [RFC5681], the TCP sender also reduces the cwnd value to 160 that new ssthresh value. 162 4. Discussion 164 Much of the technical background to ABE can be found in a research 165 paper [ABE2017]. This paper used a mix of experiments, theory and 166 simulations with NewReno [RFC5681] and CUBIC [I-D.CUBIC] to evaluate 167 the technique. The technique was shown to present "...significant 168 performance gains in lightly-multiplexed [few concurrent flows] 169 scenarios, without losing the delay-reduction benefits of deploying 170 CoDel or PIE". The performance improvement is achieved when reacting 171 to ECN-Echo in congestion avoidance by multiplying cwnd and ssthresh 172 with a value in the range [0.7,0.85]. 174 4.1. Why Use ECN to Vary the Degree of Backoff? 176 The classic rule-of-thumb dictates that a network path needs to 177 provide a BDP of bottleneck buffering if a TCP connection wishes to 178 optimise path utilisation. A single TCP bulk transfer running 179 through such a bottleneck will have increased its congestion window 180 (cwnd) up to 2*BDP by the time that packet loss occurs. When packet 181 loss is inferred using the retransmission timer and the given packet 182 has not yet been resent by way of the retransmission timer (regarded 183 as a notification of congestion), Standard TCP sets the ssthresh to 184 the maximum of half of the FlightSize and 2*SMSS [RFC5681], which 185 causes the TCP congestion control to go back to allowing only a BDP 186 of packets in flight -- just sufficient to maintain 100% utilisation 187 of the bottleneck on the network path. 189 AQM mechanisms such as CoDel [I-D.CoDel] and PIE [RFC8033] set a 190 delay target in routers and use congestion notifications to constrain 191 the queuing delays experienced by packets, rather than in response to 192 impending or actual bottleneck buffer exhaustion. With current 193 default delay targets, CoDel and PIE both effectively emulate a 194 bottleneck with a short queue (section II, [ABE2017]) while also 195 allowing short traffic bursts into the queue. This provides 196 acceptable performance for TCP connections over a path with a low 197 BDP, or in highly multiplexed scenarios (many concurrent transport 198 flows). However, in a lightly-multiplexed case over a path with a 199 large BDP, conventional TCP backoff leads to gaps in packet 200 transmission and under-utilisation of the path. 202 Instead of discarding packets, an AQM mechanism is allowed to mark 203 ECN-Capable packets with an ECN CE-mark. The reception of a CE-mark 204 feedback not only indicates congestion on the network path, it also 205 indicates that an AQM mechanism exists at the bottleneck along the 206 path, and hence the CE-mark likely came from a bottleneck with a 207 controlled short queue. Reacting differently to an ECN-signalled 208 congestion than to an inferred packet loss can then yield the benefit 209 of a reduced back-off when queues are short. Using ECN can also be 210 advantageous for several other reasons [RFC8087]. 212 The idea of reacting differently to inferred packet loss and 213 detection of an ECN-signalled congestion pre-dates this document. 214 For example, previous research proposed using ECN CE-marked feedback 215 to modify TCP congestion control behaviour via a larger 216 multiplicative decrease factor in conjunction with a smaller additive 217 increase factor [ICC2002]. The goal of this former work was to 218 operate across AQM bottlenecks using Random Early Detection (RED) 219 that were not necessarily configured to emulate a short queue (The 220 current usage of RED as an Internet AQM method is limited [RFC7567]). 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 scope for this document. 233 4.3. Choice of ABE Multiplier 235 ABE decouples the reaction of a TCP sender to inferred packet loss 236 and ECN-signalled congestion when in the congestion avoidance phase 237 by differentiating the scaling factor used in Equation 4 in 238 Section 3.1 of [RFC5681]. The description respectively uses 239 beta_{loss} and beta_{ecn} to refer to the multiplicative decrease 240 factors applied in response to inferred packet loss, and in response 241 to a receiver indicating ECN-signalled congestion. For non-ECN- 242 enabled TCP connections, only beta_{loss} applies. 244 In other words, in response to inferred packet loss: 246 ssthresh = max (FlightSize * beta_{loss}, 2 * SMSS) 248 and in response to an indication of an ECN-signalled congestion: 250 ssthresh = max (FlightSize * beta_{ecn}, 2 * SMSS) 252 and 254 cwnd = ssthresh 256 where FlightSize is the amount of outstanding data in the network, 257 upper-bounded by the smaller of the sender's cwnd and the receiver's 258 advertised window (rwnd) [RFC5681]. The higher the values of 259 beta_{loss} and beta_{ecn}, the less aggressive the response of any 260 individual backoff event. 262 The appropriate choice for beta_{loss} and beta_{ecn} values is a 263 balancing act between path utilisation and draining the bottleneck 264 queue. More aggressive backoff (smaller beta_*) risks underutilising 265 the path, while less aggressive backoff (larger beta_*) can result in 266 slower draining of the bottleneck queue. 268 The Internet has already been running with at least two different 269 beta_{loss} values for several years: the standard value is 0.5 270 [RFC5681], and the Linux implementation of CUBIC [I-D.CUBIC] has used 271 a multiplier of 0.7 since kernel version 2.6.25 released in 2008. 272 ABE proposes no change to beta_{loss} used by current TCP 273 implementations. 275 beta_{ecn} depends on how the response of a TCP connection to shallow 276 AQM marking thresholds is optimised. beta_{loss} reflects the 277 preferred response of each congestion control algorithm when faced 278 with exhaustion of buffers (of unknown depth) signalled by packet 279 loss. Consequently, for any given TCP congestion control algorithm 280 the choice of beta_{ecn} is likely to be algorithm-specific, rather 281 than a constant multiple of the algorithm's existing beta_{loss}. The 282 recommended beta_{ecn} value in this document is only applicable for 283 Standard TCP congestion control. 285 A range of tests (section IV, [ABE2017]) with NewReno and CUBIC over 286 CoDel and PIE in lightly-multiplexed scenarios have explored this 287 choice of parameter. The results of these tests indicate that CUBIC 288 connections benefit from beta_{ecn} of 0.85 (cf. beta_{loss} = 0.7), 289 and NewReno connections see improvements with beta_{ecn} in the range 290 0.7 to 0.85 (cf. beta_{loss} = 0.5). 292 5. ABE Requirements 294 This update is a sender-side only change. Like other changes to 295 congestion control algorithms, it does not require any change to the 296 TCP receiver or to network devices. It does not require any ABE- 297 specific changes in routers or the use of Accurate ECN feedback 298 [I-D.ietf-tcpm-accurate-ecn] by a receiver. 300 RFC3168 states that the congestion control response to an ECN- 301 signalled congestion is the same as the response to a dropped packet 302 [RFC3168]. [I-D.ECN-exp] updates this specification to allow systems 303 to provide a different behaviour when they experience ECN-signalled 304 congestion rather than packet loss. The present specification 305 defines such an experiment and has thus been assigned an Experimental 306 status before being proposed as a Standards-Track update. 308 The purpose of the Internet experiment is to collect experience with 309 deployment of ABE, and confirm the safety in deployed networks using 310 this update to TCP congestion control. 312 When used with bottlenecks that do not support ECN-marking the 313 specification does not modify the transport protocol. 315 To evaluate the benefit, this experiment therefore requires support 316 in AQM routers for ECN-marking of packets carrying the ECN-Capable 317 Transport, ECT(0), codepoint [RFC3168]. 319 If the method is only deployed by some senders, and not by others, 320 the senders that use this method can gain some advantage, possibly at 321 the expense of other flows that do not use this updated method. 322 Because this advantage applies only to ECN-marked packets and not to 323 packet loss indications, in the worst case (e.g., an ABE-compliant 324 TCP sender using beta_{ecn} = 1.0) the ECN-Capable bottleneck will 325 still fall back to dropping packets, and the result is no different 326 than if the TCP sender was using traditional loss-based congestion 327 control. 329 A TCP sender reacts to loss or ECN marks only once per round-trip 330 time. Hence, if a sender would first be notified of an ECN mark and 331 then learn about loss in the same round-trip, it would only react to 332 the first notification (ECN) but not to the second (loss). RFC3168 333 specified a reaction to ECN that was equal to the reaction to loss 334 [RFC3168]. 336 ABE also makes one congestion-response each RTT that congestion is 337 signalled, and therefore there is no response to loss within the same 338 round-trip time, since ABE has already made a reduction of the 339 congestion window. ABE will however respond for each round-trip time 340 that congestion continues to be signaled. This consecutive reduction 341 can protect the network against long-standing unfairness in the case 342 of AQM algorithms that do not keep a small average queue length. 344 The result of this Internet experiment will include an investigation 345 of cases such as the ones listed above, and be reported by 346 presentation to the TCPM WG (or IESG) or an implementation report at 347 the end of the experiment. 349 6. Acknowledgements 351 Authors N. Khademi, M. Welzl and G. Fairhurst were part-funded by 352 the European Community under its Seventh Framework Programme through 353 the Reducing Internet Transport Latency (RITE) project (ICT-317700). 354 The views expressed are solely those of the authors. 356 The authors would like to thank Stuart Cheshire for many suggestions 357 when revising the draft, and the following people for their 358 contributions to [ABE2017]: Chamil Kulatunga, David Ros, Stein 359 Gjessing, Sebastian Zander. Thanks also to (in alphabetical order) 360 Roland Bless, Bob Briscoe, David Black, Markku Kojo, John Leslie, 361 Lawrence Stewart, Dave Taht and the TCPM working group for providing 362 valuable feedback on this document. 364 The authors would finally like to thank everyone who provided 365 feedback on the congestion control behaviour specified in this update 366 received from the IRTF Internet Congestion Control Research Group 367 (ICCRG). 369 7. IANA Considerations 371 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 373 This document includes no request to IANA. 375 8. Implementation Status 377 ABE is implemented as a patch for Linux and FreeBSD. It is meant for 378 research and available for download from 379 http://heim.ifi.uio.no/naeemk/research/ABE/. This code was used to 380 produce the test results that are reported in [ABE2017]. An evolved 381 version of the patch for FreeBSD is currently under review for 382 potential inclusion in the mainline kernel [ABE-FreeBSD]. 384 9. Security Considerations 386 The described method is a sender-side only transport change, and does 387 not change the protocol messages exchanged. The security 388 considerations for ECN [RFC3168] therefore still apply. 390 This is a change to TCP congestion control with ECN that will 391 typically lead to a change in the capacity achieved when flows share 392 a network bottleneck. This could result in some flows receiving more 393 than their fair share of capacity. Similar unfairness in the way 394 that capacity is shared is also exhibited by other congestion control 395 mechanisms that have been in use in the Internet for many years 396 (e.g., CUBIC [I-D.CUBIC]). Unfairness may also be a result of other 397 factors, including the round trip time experienced by a flow. ABE 398 applies only when ECN-marked packets are received, not when packets 399 are lost, hence use of ABE cannot lead to congestion collapse. 401 10. Revision Information 403 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 405 -05. Refined the description of the experiment based on feedback at 406 IETF-100. Incorporated comments from David Black. 408 -04. Incorporates review comments from Lawrence Stewart and the 409 remaining comments from Roland Bless. References are updated. 411 -03. Several review comments from Roland Bless are addressed. 412 Consistent terminology and equations. Clarification on the scope of 413 recommended beta_{ecn} value. 415 -02. Corrected the equations in Section 4.3. Updated the 416 affiliations. Lower bound for cwnd is defined. A recommendation for 417 window-based transport protocols is changed to cover all transport 418 protocols that implement a congestion control reduction to an ECN 419 congestion signal. Added text about ABE's FreeBSD mainline kernel 420 status including a reference to the FreeBSD code review page. 421 References are updated. 423 -01. Text improved, mainly incorporating comments from Stuart 424 Cheshire. The reference to a technical report has been updated to a 425 published version of the tests [ABE2017]. Used "AQM Mechanism" 426 throughout in place of other alternatives, and more consistent use of 427 technical language and clarification on the intended purpose of the 428 experiments required by EXP status. There was no change to the 429 technical content. 431 -00. draft-ietf-tcpm-alternativebackoff-ecn-00 replaces draft- 432 khademi-tcpm-alternativebackoff-ecn-01. Text describing the nature 433 of the experiment was added. 435 Individual draft -01. This I-D now refers to draft-black-tsvwg-ecn- 436 experimentation-02, which replaces draft-khademi-tsvwg-ecn- 437 response-00 to make a broader update to RFC3168 for the sake of 438 allowing experiments. As a result, some of the motivating and 439 discussing text that was moved from draft-khademi-alternativebackoff- 440 ecn-03 to draft-khademi-tsvwg-ecn-response-00 has now been re- 441 inserted here. 443 Individual draft -00. draft-khademi-tsvwg-ecn-response-00 and draft- 444 khademi-tcpm-alternativebackoff-ecn-00 replace draft-khademi- 445 alternativebackoff-ecn-03, following discussion in the TSVWG and TCPM 446 working groups. 448 11. References 450 11.1. Normative References 452 [I-D.ECN-exp] 453 Black, D., "Explicit Congestion Notification (ECN) 454 Experimentation", Internet-draft, IETF work-in-progress 455 draft-ietf-tsvwg-ecn-experimentation-08, November 2017. 457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 458 Requirement Levels", BCP 14, RFC 2119, 459 DOI 10.17487/RFC2119, March 1997, 460 . 462 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 463 of Explicit Congestion Notification (ECN) to IP", 464 RFC 3168, DOI 10.17487/RFC3168, September 2001, 465 . 467 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 468 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 469 . 471 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 472 Recommendations Regarding Active Queue Management", 473 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 474 . 476 11.2. Informative References 478 [ABE-FreeBSD] 479 "ABE patch review in FreeBSD", 480 . 482 [ABE2017] Khademi, N., Armitage, G., Welzl, M., Fairhurst, G., 483 Zander, S., and D. Ros, "Alternative Backoff: Achieving 484 Low Latency and High Throughput with ECN and AQM", IFIP 485 NETWORKING 2017, Stockholm, Sweden, June 2017. 487 [BUFFERBLOAT] 488 Gettys, J. and K. Nichols, "Bufferbloat: Dark Buffers in 489 the Internet", November 2011. 491 [CODEL2012] 492 Nichols, K. and V. Jacobson, "Controlling Queue Delay", 493 July 2012, . 495 [I-D.CoDel] 496 Nichols, K., Jacobson, V., McGregor, V., and J. Iyengar, 497 "Controlled Delay Active Queue Management", Internet- 498 draft, IETF work-in-progress draft-ietf-aqm-codel-10, 499 October 2017. 501 [I-D.CUBIC] 502 Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and 503 R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", 504 Internet-draft, IETF work-in-progress draft-ietf-tcpm- 505 cubic-07, November 2017. 507 [I-D.ietf-tcpm-accurate-ecn] 508 Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More 509 Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate- 510 ecn-03 (work in progress), May 2017. 512 [I-D.ietf-tcpm-dctcp] 513 Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., 514 and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion 515 Control for Datacenters", draft-ietf-tcpm-dctcp-10 (work 516 in progress), August 2017. 518 [ICC2002] Kwon, M. and S. Fahmy, "TCP Increase/Decrease Behavior 519 with Explicit Congestion Notification (ECN)", IEEE 520 ICC 2002, New York, New York, USA, May 2002, 521 . 523 [RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) 524 Concepts, Abstract Mechanism, and Requirements", RFC 7713, 525 DOI 10.17487/RFC7713, December 2015, 526 . 528 [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, 529 "Proportional Integral Controller Enhanced (PIE): A 530 Lightweight Control Scheme to Address the Bufferbloat 531 Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, 532 . 534 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 535 Explicit Congestion Notification (ECN)", RFC 8087, 536 DOI 10.17487/RFC8087, March 2017, 537 . 539 Authors' Addresses 541 Naeem Khademi 542 University of Oslo 543 PO Box 1080 Blindern 544 Oslo N-0316 545 Norway 547 Email: naeemk@ifi.uio.no 549 Michael Welzl 550 University of Oslo 551 PO Box 1080 Blindern 552 Oslo N-0316 553 Norway 555 Email: michawe@ifi.uio.no 557 Grenville Armitage 558 Internet For Things (I4T) Research Group 559 Swinburne University of Technology 560 PO Box 218 561 John Street, Hawthorn 562 Victoria 3122 563 Australia 565 Email: garmitage@swin.edu.au 566 Godred Fairhurst 567 University of Aberdeen 568 School of Engineering, Fraser Noble Building 569 Aberdeen AB24 3UE 570 UK 572 Email: gorry@erg.abdn.ac.uk