idnits 2.17.1 draft-ietf-tcpm-alternativebackoff-ecn-06.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 (February 14, 2018) is 2235 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: August 18, 2018 G. Armitage 6 Swinburne University of Technology 7 G. Fairhurst 8 University of Aberdeen 9 February 14, 2018 11 TCP Alternative Backoff with ECN (ABE) 12 draft-ietf-tcpm-alternativebackoff-ecn-06 14 Abstract 16 Active Queue Management (AQM) mechanisms allow for burst tolerance 17 while enforcing short queues to minimise the time that packets spend 18 enqueued at a bottleneck. This can cause noticeable performance 19 degradation for TCP connections traversing such a bottleneck, 20 especially if there are only a few flows or their bandwidth-delay- 21 product is large. An Explicit Congestion Notification (ECN) signal 22 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 RFC3168, which changes the 25 TCP sender-side ECN reaction in congestion avoidance to reduce the 26 Congestion Window (cwnd) by a smaller amount than the congestion 27 control algorithm's 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 August 18, 2018. 46 Copyright Notice 48 Copyright (c) 2018 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 3 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 Deployment Requirements . . . . . . . . . . . . . . . . . 7 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 10. Revision Information . . . . . . . . . . . . . . . . . . . . 9 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 11.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 Explicit Congestion Notification (ECN) [RFC3168] makes it possible 84 for an Active Queue Management (AQM) mechanism to signal the presence 85 of incipient congestion without incurring packet loss. This lets the 86 network deliver some packets to an application that would have been 87 dropped if the application or transport did not support ECN. This 88 packet loss reduction is the most obvious benefit of ECN, but it is 89 often relatively modest. Other benefits of deploying ECN have been 90 documented in RFC8087 [RFC8087]. 92 The rules for ECN were originally written to be very conservative, 93 and required the congestion control algorithms of ECN-Capable 94 transport protocols to treat ECN congestion signals exactly the same 95 as they would treat an inferred packet loss [RFC3168]. 97 Research has demonstrated the benefits of reducing network delays 98 that are caused by interaction of loss-based TCP congestion control 99 and excessive buffering [BUFFERBLOAT]. This has led to the creation 100 of new AQM mechanisms like PIE [RFC8033] and CoDel 101 [CODEL2012][I-D.CoDel], which prevent bloated queues that are common 102 with unmanaged and excessively large buffers deployed across the 103 Internet [BUFFERBLOAT]. 105 The AQM mechanisms mentioned above aim to keep a sustained queue 106 short while tolerating transient (short-term) packet bursts. 107 However, currently used loss-based congestion control mechanisms 108 cannot always utilise a bottleneck link well where there are short 109 queues. For example, a TCP sender must be able to store at least an 110 end-to-end bandwidth-delay product (BDP) worth of data at the 111 bottleneck buffer if it is to maintain full path utilisation in the 112 face of loss-induced reduction of cwnd [RFC5681], which effectively 113 doubles the amount of data that can be in flight, the maximum round- 114 trip time (RTT) experience, and the path's effective RTT using the 115 network path. 117 Modern AQM mechanisms can use ECN to signal the early signs of 118 impending queue buildup long before a tail-drop queue would be forced 119 to resort to dropping packets. It is therefore appropriate for the 120 transport protocol congestion control algorithm to have a more 121 measured response when an early-warning signal of congestion is 122 received in the form of an ECN CE-marked packet. Recognizing these 123 changes in modern AQM practices, more recent rules have relaxed the 124 strict requirement that ECN signals be treated identically to 125 inferred packet loss [I-D.ECN-exp]. Following these newer, more 126 flexible rules, this document defines a new sender-side-only 127 congestion control response, called "ABE" (Alternative Backoff with 128 ECN). ABE improves TCP's average throughput when routers use AQM 129 controlled buffers that allow for short queues only. 131 2. Definitions 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [RFC2119]. 137 3. Specification 139 This specification updates the congestion control algorithm of an 140 ECN-Capable TCP transport protocol by changing the TCP sender 141 response to feedback from the TCP receiver that indicates reception 142 of a CE-marked packet, i.e., receipt of a packet with the ECN-Echo 143 flag (defined in [RFC3168]) set. 145 It updates the following text in section 6.1.2 of the ECN 146 specification [RFC3168] : 148 The indication of congestion should be treated just as a 149 congestion loss in non-ECN-Capable TCP. That is, the TCP source 150 halves the congestion window "cwnd" and reduces the slow start 151 threshold "ssthresh". 153 Replacing this with: 155 Receipt of a packet with the ECN-Echo flag SHOULD trigger the TCP 156 source to set the slow start threshold (ssthresh) to 0.8 times the 157 FlightSize, with a lower bound of 2 * SMSS applied to the result. 158 As in [RFC5681], the TCP sender also reduces the cwnd value to no 159 more than the new ssthresh value. 161 4. Discussion 163 Much of the technical background to ABE can be found in a research 164 paper [ABE2017]. This paper used a mix of experiments, theory and 165 simulations with NewReno [RFC5681] and CUBIC [I-D.CUBIC] to evaluate 166 the technique. The technique was shown to present "...significant 167 performance gains in lightly-multiplexed [few concurrent flows] 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. According to 180 [RFC5681], when a TCP sender detects segment loss using the 181 retransmission timer and the given segment has not yet been resent by 182 way of the retransmission timer, the value of ssthresh must be set to 183 no more of the maximum of half of the FlightSize and 2*SMSS. The 184 same equation is also used during Fast Retransmit/Fast Recovery 185 [RFC5681]. As a result, the TCP congestion control only allows one 186 BDP of packets in flight. This is just sufficient to maintain 100% 187 utilisation 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 instance, Accurate 226 ECN [I-D.ietf-tcpm-accurate-ecn] permits more frequent and detailed 227 feedback. Use of mechanisms (such as Accurate ECN, Datacenter TCP 228 (DCTCP) [RFC8257], or Congestion Exposure (ConEx) [RFC7713]) is out 229 of scope for this document. This specification focuses on ECN as 230 defined in [RFC3168]. 232 4.3. Choice of ABE Multiplier 234 ABE decouples the reaction of a TCP sender to inferred packet loss 235 and ECN-signalled congestion in the congestion avoidance phase. To 236 achieve this, ABE uses different the scaling factor in Equation 4 in 237 Section 3.1 of [RFC5681]. The description respectively uses 238 beta_{loss} and beta_{ecn} to refer to the multiplicative decrease 239 factors applied in response to inferred packet loss, and in response 240 to a receiver indicating ECN-signalled congestion. For non-ECN- 241 enabled TCP connections, only beta_{loss} applies. 243 In other words, in response to inferred packet loss: 245 ssthresh = max (FlightSize * beta_{loss}, 2 * SMSS) 247 and in response to an indication of an ECN-signalled congestion: 249 ssthresh = max (FlightSize * beta_{ecn}, 2 * SMSS) 251 and 253 cwnd = ssthresh 255 where FlightSize is the amount of outstanding data in the network, 256 upper-bounded by the smaller of the sender's cwnd and the receiver's 257 advertised window (rwnd) [RFC5681]. The higher the values of 258 beta_{loss} and beta_{ecn}, the less aggressive the response of any 259 individual backoff event. 261 The appropriate choice for beta_{loss} and beta_{ecn} values is a 262 balancing act between path utilisation and draining the bottleneck 263 queue. More aggressive backoff (smaller beta_*) risks underutilising 264 the path, while less aggressive backoff (larger beta_*) can result in 265 slower draining of the bottleneck queue. 267 The Internet has already been running with at least two different 268 beta_{loss} values for several years: the standard value is 0.5 269 [RFC5681], and the Linux implementation of CUBIC [I-D.CUBIC] has used 270 a multiplier of 0.7 since kernel version 2.6.25 released in 2008. 271 ABE proposes no change to beta_{loss} used by current TCP 272 implementations. 274 The recommendation in Section 3 in this document corresponds to a 275 value of beta_{ecn}=0.8. This recommended beta_{ecn} value is only 276 applicable for the standard TCP congestion control [RFC5681]. The 277 selection of beta_{ecn} enables tuning the response of a TCP 278 connection to shallow AQM marking thresholds. beta_{loss} 279 characterizes the response of a congestion control algorithm to 280 packet loss, i.e., exhaustion of buffers (of unknown depth). 281 Different values for beta_{loss} have been suggested for TCP 282 congestion control algorithms. Consequently, beta_{ecn} is likely to 283 be an algorithm-specific parameter rather than a constant multiple of 284 the algorithm's existing beta_{loss}. 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 Deployment 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 RFC3168 states that the congestion control response to an ECN- 302 signalled congestion is the same as the response to a dropped packet 303 [RFC3168]. [I-D.ECN-exp] updates this specification to allow systems 304 to provide a different behaviour when they experience ECN-signalled 305 congestion rather than packet loss. The present specification 306 defines such an experiment and has thus been assigned an Experimental 307 status 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 for ECN-marking of packets carrying the ECN-Capable 318 Transport, ECT(0), codepoint [RFC3168]. 320 If the method is only deployed by some senders, and not by others, 321 the senders that use this method can gain some advantage, possibly at 322 the expense of other flows that do not use this updated method. 323 Because this advantage applies only to ECN-marked packets and not to 324 packet loss indications, an ECN-Capable bottleneck will still fall 325 back to dropping packets if an TCP sender using ABE is too 326 aggressive, and the result is no different than if the TCP sender was 327 using traditional loss-based congestion 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 responds to congestion once per RTT, and therefore it does 337 not respond to further loss within the same RTT, since ABE has 338 already reduced the congestion window. If congestion persists after 339 such reduction, ABE continues to reduce the congestion window in each 340 consecutive RTT. This consecutive reduction can protect the network 341 against long-standing unfairness in the case of AQM algorithms that 342 do not keep a small average queue length. 344 The result of this Internet experiment ought to include an 345 investigation of the implications of experiencing an ECN-CE mark 346 followed by loss within the same RTT. At the end of the experiment, 347 this will be reported to the TCPM WG (or IESG). 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 -06. Addressed Michael Scharf's comments. 407 -05. Refined the description of the experiment based on feedback at 408 IETF-100. Incorporated comments from David Black. 410 -04. Incorporates review comments from Lawrence Stewart and the 411 remaining comments from Roland Bless. References are updated. 413 -03. Several review comments from Roland Bless are addressed. 414 Consistent terminology and equations. Clarification on the scope of 415 recommended beta_{ecn} value. 417 -02. Corrected the equations in Section 4.3. Updated the 418 affiliations. Lower bound for cwnd is defined. A recommendation for 419 window-based transport protocols is changed to cover all transport 420 protocols that implement a congestion control reduction to an ECN 421 congestion signal. Added text about ABE's FreeBSD mainline kernel 422 status including a reference to the FreeBSD code review page. 423 References are updated. 425 -01. Text improved, mainly incorporating comments from Stuart 426 Cheshire. The reference to a technical report has been updated to a 427 published version of the tests [ABE2017]. Used "AQM Mechanism" 428 throughout in place of other alternatives, and more consistent use of 429 technical language and clarification on the intended purpose of the 430 experiments required by EXP status. There was no change to the 431 technical content. 433 -00. draft-ietf-tcpm-alternativebackoff-ecn-00 replaces draft- 434 khademi-tcpm-alternativebackoff-ecn-01. Text describing the nature 435 of the experiment was added. 437 Individual draft -01. This I-D now refers to draft-black-tsvwg-ecn- 438 experimentation-02, which replaces draft-khademi-tsvwg-ecn- 439 response-00 to make a broader update to RFC3168 for the sake of 440 allowing experiments. As a result, some of the motivating and 441 discussing text that was moved from draft-khademi-alternativebackoff- 442 ecn-03 to draft-khademi-tsvwg-ecn-response-00 has now been re- 443 inserted here. 445 Individual draft -00. draft-khademi-tsvwg-ecn-response-00 and draft- 446 khademi-tcpm-alternativebackoff-ecn-00 replace draft-khademi- 447 alternativebackoff-ecn-03, following discussion in the TSVWG and TCPM 448 working groups. 450 11. References 452 11.1. Normative References 454 [I-D.ECN-exp] 455 Black, D., "Explicit Congestion Notification (ECN) 456 Experimentation", Internet-draft, IETF work-in-progress 457 draft-ietf-tsvwg-ecn-experimentation-08, November 2017. 459 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 460 Requirement Levels", BCP 14, RFC 2119, 461 DOI 10.17487/RFC2119, March 1997, 462 . 464 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 465 of Explicit Congestion Notification (ECN) to IP", 466 RFC 3168, DOI 10.17487/RFC3168, September 2001, 467 . 469 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 470 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 471 . 473 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 474 Recommendations Regarding Active Queue Management", 475 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 476 . 478 [RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., 479 and G. Judd, "Data Center TCP (DCTCP): TCP Congestion 480 Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257, 481 October 2017, . 483 11.2. Informative References 485 [ABE-FreeBSD] 486 "ABE patch review in FreeBSD", 487 . 489 [ABE2017] Khademi, N., Armitage, G., Welzl, M., Fairhurst, G., 490 Zander, S., and D. Ros, "Alternative Backoff: Achieving 491 Low Latency and High Throughput with ECN and AQM", IFIP 492 NETWORKING 2017, Stockholm, Sweden, June 2017. 494 [BUFFERBLOAT] 495 Gettys, J. and K. Nichols, "Bufferbloat: Dark Buffers in 496 the Internet", November 2011. 498 [CODEL2012] 499 Nichols, K. and V. Jacobson, "Controlling Queue Delay", 500 July 2012, . 502 [I-D.CoDel] 503 Nichols, K., Jacobson, V., McGregor, V., and J. Iyengar, 504 "Controlled Delay Active Queue Management", Internet- 505 draft, IETF work-in-progress draft-ietf-aqm-codel-10, 506 October 2017. 508 [I-D.CUBIC] 509 Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and 510 R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", 511 Internet-draft, IETF work-in-progress draft-ietf-tcpm- 512 cubic-07, November 2017. 514 [I-D.ietf-tcpm-accurate-ecn] 515 Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More 516 Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate- 517 ecn-03 (work in progress), May 2017. 519 [ICC2002] Kwon, M. and S. Fahmy, "TCP Increase/Decrease Behavior 520 with Explicit Congestion Notification (ECN)", IEEE 521 ICC 2002, New York, New York, USA, May 2002, 522 . 524 [RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) 525 Concepts, Abstract Mechanism, and Requirements", RFC 7713, 526 DOI 10.17487/RFC7713, December 2015, 527 . 529 [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, 530 "Proportional Integral Controller Enhanced (PIE): A 531 Lightweight Control Scheme to Address the Bufferbloat 532 Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, 533 . 535 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 536 Explicit Congestion Notification (ECN)", RFC 8087, 537 DOI 10.17487/RFC8087, March 2017, 538 . 540 Authors' Addresses 542 Naeem Khademi 543 University of Oslo 544 PO Box 1080 Blindern 545 Oslo N-0316 546 Norway 548 Email: naeemk@ifi.uio.no 550 Michael Welzl 551 University of Oslo 552 PO Box 1080 Blindern 553 Oslo N-0316 554 Norway 556 Email: michawe@ifi.uio.no 558 Grenville Armitage 559 Internet For Things (I4T) Research Group 560 Swinburne University of Technology 561 PO Box 218 562 John Street, Hawthorn 563 Victoria 3122 564 Australia 566 Email: garmitage@swin.edu.au 567 Godred Fairhurst 568 University of Aberdeen 569 School of Engineering, Fraser Noble Building 570 Aberdeen AB24 3UE 571 UK 573 Email: gorry@erg.abdn.ac.uk