idnits 2.17.1 draft-khademi-tsvwg-ecn-response-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4774, but the abstract doesn't seem to directly say this. It does mention RFC4774 though, so this could be OK. -- The draft header indicates that this document updates RFC3168, but the abstract doesn't seem to directly say this. It does mention RFC3168 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (Using the creation date from RFC3168, updated by this document, for RFC5378 checks: 2000-11-17) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 20, 2016) is 2837 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.bagnulo-tsvwg-generalized-ecn' is defined on line 457, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-khademi-tcpm-alternativebackoff-ecn-00 == Outdated reference: A later version (-07) exists of draft-ietf-tcpm-cubic-01 == Outdated reference: A later version (-10) exists of draft-ietf-aqm-codel-03 == Outdated reference: A later version (-10) exists of draft-ietf-aqm-pie-07 == Outdated reference: A later version (-02) exists of draft-briscoe-tsvwg-ecn-l4s-id-01 == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-accurate-ecn-00 == Outdated reference: A later version (-10) exists of draft-ietf-tcpm-dctcp-01 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). 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 Updates: 3168,4774 (if approved) University of Oslo 5 Intended status: Standards Track G. Armitage 6 Expires: January 21, 2017 Swinburne University of 7 Technology 8 G. Fairhurst 9 University of Aberdeen 10 July 20, 2016 12 Updating the Explicit Congestion Notification (ECN) Specification to 13 Allow IETF Experimentation 14 draft-khademi-tsvwg-ecn-response-01 16 Abstract 18 This document relaxes recommendations and prescriptions from RFC3168 19 and RFC4774 that get in the way of experimentation with different ECN 20 strategies. First, RFC3168 and RFC4774 state that, upon the receipt 21 by an ECN-Capable transport of a single CE packet, the congestion 22 control algorithms followed at the end-systems MUST be essentially 23 the same as the congestion control response to a single dropped 24 packet. This document relaxes this rule in order to encourage 25 experimentation with different backoff strategies. Second, this 26 document allows future IETF specifications to use the ECT(1) 27 codepoint in ways that are currently prohibited by RFC3168. Third, 28 this document allows future IETF experiments to use the ECT(0) or 29 ECT(1) codepoint on any TCP segment. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 21, 2017. 48 Copyright Notice 49 Copyright (c) 2016 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 (http://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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Differently reacting to ECN-marks and loss . . . . . . . . 3 66 1.1.1. Discussion: Why Use ECN to Vary the Degree of 67 Backoff? . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.2. Senders setting the ECT(1) codepoint . . . . . . . . . . . 5 69 1.3. ECT(0) and ECT(1) on control packets . . . . . . . . . . . 5 70 2. Updating RFC3168 and RFC4774 . . . . . . . . . . . . . . . . . 5 71 2.1. RFC 2119 . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 2.2. Scope of this update . . . . . . . . . . . . . . . . . . . 6 73 2.3. Changes to the meaning of a CE-Mark codepoint . . . . . . 6 74 2.4. Setting ECT(0) and ECT(1) Codepoints . . . . . . . . . . . 7 75 2.5. Clarification to the usage of the ECT(1) Codepoint . . . . 7 76 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 79 6. Revision Information . . . . . . . . . . . . . . . . . . . . . 9 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 82 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 85 1. Introduction 87 This document relaxes three limitations that are due to specific text 88 in [RFC3168] and, in one case, also [RFC4774]. 90 1.1. Differently reacting to ECN-marks and loss 92 Explicit Congestion Notification (ECN) as specified in [RFC3168] 93 allows a network device that uses Active Queue Management (AQM) to 94 set the Congestion Experienced (CE) codepoint in the ECN field of the 95 IP packet header, rather than to drop ECN-capable packets when 96 incipient congestion is detected. When an ECN-capable transport is 97 used over a path that supports ECN, this provides the opportunity for 98 flows to improve their performance in the presence of incipient 99 congestion [I-D.AQM-ECN-benefits]. 101 [RFC3168] not only specifies the router use of the ECN field, it also 102 specifies a TCP procedure for using ECN. This states that a TCP 103 sender should treat the ECN indication of congestion in the same way 104 as that of a non-ECN-Capable TCP flow experiencing loss, by halving 105 the congestion window "cwnd" and by reducing the slow start threshold 106 "ssthresh". [RFC5681] stipulates that TCP congestion control sets 107 "ssthresh" to max(FlightSize / 2, 2*SMSS) in response to packet loss. 108 This corresponds to a backoff multiplier of 0.5 (halving cwnd and 109 sshthresh after packet loss). Consequently, a standard TCP flow 110 using this reaction needs significant network queue space: it can 111 only fully utilise a bottleneck when the length of the link queue (or 112 the AQM dropping threshold) is at least the bandwidth-delay product 113 (BDP) of the flow. 115 A backoff multiplier of 0.5 is not the only available strategy. As 116 defined in [I-D.CUBIC], CUBIC multiplies the current cwnd by 0.7 in 117 response to loss ( the Linux implementation of CUBIC has used a 118 multiplier of 0.7 since kernel version 2.6.25 released in 2008). 119 Consequently, CUBIC utilises paths well even when the bottleneck 120 queue is shorter than the bandwidth-delay product of the flow. 121 However, in the case of a DropTail (FIFO) queue without AQM, such 122 less-aggressive backoff increases the risk of creating a standing 123 queue [CODEL2012]. 125 Devices implementing AQM are likely to be the dominant (and possibly 126 only) source of ECN CE-marking for packets from ECN-capable senders. 127 AQM mechanisms typically strive to maintain a small average queue 128 length, regardless of the bandwidth-delay product of flows passing 129 through them. Receipt of an ECN CE-mark might therefore reasonably 130 be taken to indicate that a small bottleneck queue exists in the 131 path, and hence the TCP flow would benefit from using a less 132 aggressive backoff multiplier. Such behavior is however prohibited 133 by the rules in [RFC3168]. 135 ECN has seen little deployment so far. Apple recently announced 136 their intention to enable ECN in iOS 9 and OS X 10.11 devices 137 [WWDC2015]. By 2014, server-side ECN negotiation was observed to be 138 provided by the majority of the top million web servers [PAM2015], 139 and only 0.5% of websites incurred additional connection setup 140 latency using RFC3168-compliant ECN-fallback mechanisms. [RFC7567] 141 states that "deployed AQM algorithms SHOULD support Explicit 142 Congestion Notification (ECN) as well as loss to signal congestion to 143 endpoints" and [I-D.AQM-ECN-benefits] encourages this deployment. 144 However, the limitation of [RFC3168] restricts a sender to react to 145 notification of a CE-mark in the same way as if a packet was lost. 146 This prohibits experimentation with ECN mechanisms that could yield 147 greater benefits. This specification therefore relaxes this 148 constraint. 150 1.1.1. Discussion: Why Use ECN to Vary the Degree of Backoff? 152 The classic rule-of-thumb dictates that a transport provides a BDP of 153 bottleneck buffering if a TCP connection wishes to optimise path 154 utilisation. A single TCP connection running through such a 155 bottleneck will have opened cwnd up to 2*BDP by the time packet loss 156 occurs. [RFC5681]'s halving of cwnd and ssthresh pushes the TCP 157 connection back to allowing only a BDP of packets in flight -- just 158 sufficient to maintain 100% utilisation of the network path. 160 AQM schemes like CoDel [I-D.CoDel] and PIE [I-D.PIE] use congestion 161 notifications to constrain the queuing delays experienced by packets, 162 rather than in response to impending or actual bottleneck buffer 163 exhaustion. With current default delay targets, CoDel and PIE both 164 effectively emulate a shallow buffered bottleneck (section II, 165 [ABE2015]) while allowing short traffic bursts into the queue. This 166 interacts acceptably for TCP connections over low BDP paths, or 167 highly multiplexed scenarios (many concurrent TCP connections). 168 However, it interacts badly with lightly-multiplexed cases (few 169 concurrent connections) over a high BDP path. Conventional TCP 170 backoff in such cases leads to gaps in packet transmission and under- 171 utilisation of the path. 173 The idea to react differently to loss upon detecting an ECN CE-mark 174 pre-dates [ABE2015]. [ICC2002] also proposed using ECN CE-marks to 175 modify TCP congestion control behaviour, using a larger 176 multiplicative decrease factor in conjunction with a smaller additive 177 increase factor to work with RED-based bottlenecks that were not 178 necessarily configured to emulate a shallow queue. 180 This update to [RFC3168] that enables the IETF to specify experiments 181 with a different backoff behavior in response to a CE-mark than in 182 response to packet loss is utilized by an experiment called 183 "Alternative Backoff with ECN" (ABE). ABE is based upon [ABE2015] 184 and defined in [I-D.ABE]. 186 1.2. Senders setting the ECT(1) codepoint 188 Future IETF experiments may require setting the ECT(0) or ECT(1) 189 codepoints differently from what [RFC3168] recommends or requires. 191 [NOTE: This usage was also specified in ECN-NONCE.] 193 This update may also allow the iETF to specify future mechanisms that 194 associate alternate ECN semantics with this codepoint. An experiment 195 called "L4S" proposes to use the ECT(1) codepoint to indicate in 196 which of two queues a packet should be placed 197 [I-D.briscoe-tsvwg-ecn-l4s-id]. 199 1.3. ECT(0) and ECT(1) on control packets 201 Diverging from recommendations or requirements in [RFC3168], future 202 IETF experiments may be specified to use the ECT(0) or ECT(1) 203 codepoint. This choice of codepoint can be used to signal 204 alternative ECN semantics. This supersedes the rationale in Section 205 20 of [RFC3168] that argued against the use of ECT(1) to specify 206 alternate ECN semantics, instead arguing for attaching specific ECN 207 semantics to a Differentiated Services Code Point (DSCP). 209 This update may also allow the iETF to specify future updates to 210 transport protocol use of ECN. A 211 proposal,[I-D.bagnulo-tsvwg-generalized-ecn], provides arguments for 212 using the ECT(0) or ECT(1) codepoint on a broader range of TCP 213 packets for which such usage is precluded by [RFC3168]: SYNs, pure 214 ACKs, retransmitted packets and window probe packets. 216 2. Updating RFC3168 and RFC4774 218 This section specifies updates to [RFC3168] (and corresponding text 219 in [RFC4774]) and refers to experiments that are possible within the 220 framework provided by the update. 222 2.1. RFC 2119 224 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 225 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 226 document are to be interpreted as described in [RFC2119]. 228 2.2. Scope of this update 230 Internet deployment of new mechanisms enabled by this update REQUIRE 231 IETF specification in an Experimental or a Standards Track RFC 232 approved by the IESG. 234 Some mechanisms rely on ECN semantics that differ from the 235 definitions in [RFC3168] -- for example, Congestion Exposure (ConEx) 236 [RFC7713] and DCTCP [I-D.ietf-tcpm-dctcp] need more accurate ECN 237 information than the feedback mechanism in [RFC3168] offers (defined 238 in [I-D.ietf-tcpm-accurate-ecn]). Such mechanisms allow a sending 239 rate adjustment more frequent than each RTT. These mechanisms are 240 out of the scope of the current document. 242 The remainder of this section lists a set of changes to [RFC3168] 243 that are not specific replacements of text passages. 245 2.3. Changes to the meaning of a CE-Mark codepoint 247 This document specifies an update to the TCP sender reaction that 248 follows when the TCP receiver signals that ECN CE-marked packets have 249 been received. 251 [RFC3168] and [RFC4774] contain the following text: 253 "Upon the receipt by an ECN-Capable transport of a single CE packet, 254 the congestion control algorithms followed at the end-systems MUST be 255 essentially the same as the congestion control response to a *single* 256 dropped packet. For example, for ECN-Capable TCP the source TCP is 257 required to halve its congestion window for any window of data 258 containing either a packet drop or an ECN indication." 260 This memo updates the preceding text by replacing it with the 261 following text: 263 "Upon the receipt by an ECN-Capable transport of a single CE-Marked 264 packet, the congestion control algorithms followed at the endpoints 265 MUST make a congestion control response as specified in [RFC3168] or 266 its updates. For example, an ECN-Capable TCP sender could halve its 267 congestion window for any window of data containing either a packet 268 drop or an ECN indication." 270 The first paragraph of Section 6.1.2, "The TCP Sender", in [RFC3168] 271 contains the following text: 273 "If the sender receives an ECN-Echo (ECE) ACK packet (that is, an ACK 274 packet with the ECN-Echo flag set in the TCP header), then the sender 275 knows that congestion was encountered in the network on the path from 276 the sender to the receiver. The indication of congestion should be 277 treated just as a congestion loss in non-ECN-Capable TCP. That is, 278 the TCP source halves the congestion window "cwnd" and reduces the 279 slow start threshold "ssthresh"." 281 This memo updates the preceding text by replacing it with the 282 following text: 284 "If a TCP sender receives an indication of a receibed ECN-Echo (ECE) 285 ACK packet (that is, an ACK packet with the ECN-Echo flag set in the 286 TCP header), then the sender knows that congestion was encountered in 287 the network on the path from the sender to the receiver. An 288 indication of congestion, signalled by reception of the ECN-Echo flag 289 (with the semantics defined in [RFC3168]) MUST produce a rate 290 reduction of at least 15%, so that flows sharing the same bottleneck 291 can increase their share of the capacity. The indication of 292 congestion could be treated in the same way as if the flow had 293 experienced loss, but future congestion control methods are allowed 294 to specify a reduction that is less than the reduction for congestion 295 loss. 297 An ECN-capable network device cannot eliminate the possibility of 298 packet loss. A drop may still occur due to a traffic burst exceeding 299 the instantaneous available capacity of a network buffer or as a 300 result of the AQM algorithm (overload protection mechanisms, etc 301 [RFC7567]). Whatever the cause of loss, detection of a missing 302 packet needs to trigger the standard loss-based congestion control 303 response". This update explicitly does not change the use of 304 standard protocol mechanisms following loss, as required in 305 [RFC3168]. 307 2.4. Setting ECT(0) and ECT(1) Codepoints 309 New IETF specifications MAY permit a sender to set the ECT(0) or 310 ECT(1) codepoint on a protocol control packet (including TCP segments 311 for which [RFC3168] does not allow or recommend setting these 312 codepoints.) 314 [AUTHORS' NOTE: Future versions of this document may take the form of 315 such explicit text replacements.] 317 2.5. Clarification to the usage of the ECT(1) Codepoint 319 [RFC3168] notes that a router may treat and mark/drop packets 320 differently depending on whether they observe the ECT(0) or ECT(1) 321 codepoint. This specification permits new IETF specifications to set 322 or read the ECT(1) codepeoint. It clarifies that these 323 specifications do not necessarily treat ECT(1) as equivalent to 324 ECT(0). 326 Network devices using IETF-defined DSCPs MUST NOT re-mark packets to 327 the ECT(1) codepoint. Specifically, the methods described in earlier 328 ECN implementations using this codepoint as a congestion mark 329 (described in Section 11.2.1 of [RFC3168]) are NOT RECOMMENDED for 330 deployment in the current Internet. 332 3. Acknowledgements 334 The authors N. Khademi, M. Welzl and G. Fairhurst were part-funded by 335 the European Community under its Seventh Framework Programme through 336 the Reducing Internet Transport Latency (RITE) project (ICT-317700). 337 The views expressed are solely those of the authors. 339 4. IANA Considerations 341 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 343 This memo includes no request to IANA. 345 5. Security Considerations 347 The described method is a sender-side only transport change, and does 348 not change the protocol messages exchanged. The security 349 considerations of [RFC3168] therefore still apply. 351 A congestion control backoff that is less in response to ECN than the 352 response to a packet loss can lead to a change in the capacity 353 achieved when flows share a network bottleneck. This can result in 354 redistribution of capacity between sharing flows, potentially 355 resulting in unfairness in the way that capacity is shared. This 356 potential gain applies only to ECN-marked packets using the updated 357 method (and not to detected packet loss). Similar unfairness can be 358 exhibited by congestion control mechanisms that have been used in the 359 Internet for many years (e.g., CUBIC [I-D.CUBIC]). Unfairness may 360 also be a result of other factors, including the round trip time 361 experienced by a flow. 363 Packet loss can be expected from an AQM algorithm experiencing 364 persistent queuing, but could also imply the presence of faulty 365 equipment or media in a path, or it may imply the presence of 366 congestion [RFC7567]. The update does not change the congestion 367 control response to packet loss, and will therefore not lead to 368 congestion collapse. 370 [AUTHORS' NOTE: Security considerations of the more relaxed rules of 371 using ECT(0) vs. ECT(1) and usage of these ECT codepoints on any TCP 372 segments will be included in the next version of this document.] 374 6. Revision Information 376 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 378 -01. Broadened the scope to also cover ECT(0) vs. ECT(1) usage and 379 using ECT(0) or ECT(1) codepoints on any TCP segments. 381 -00. draft-khademi-tsvwg-ecn-response-00 and 382 draft-khademi-tcpm-alternativebackoff-ecn-00 replace 383 draft-khademi-alternativebackoff-ecn-03, following discussion in the 384 TSVWG and TCPM working groups. 386 7. References 388 7.1. Normative References 390 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 391 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 392 RFC2119, March 1997, 393 . 395 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 396 of Explicit Congestion Notification (ECN) to IP", 397 RFC 3168, DOI 10.17487/RFC3168, September 2001, 398 . 400 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 401 Explicit Congestion Notification (ECN) Field", BCP 124, 402 RFC 4774, DOI 10.17487/RFC4774, November 2006, 403 . 405 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 406 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 407 . 409 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 410 Recommendations Regarding Active Queue Management", 411 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 412 . 414 7.2. Informative References 416 [ABE2015] Khademi, N., Welzl, M., Armitage, G., Kulatunga, C., Ros, 417 D., Fairhurst, G., Gjessing, S., and S. Zander, 418 "Alternative Backoff: Achieving Low Latency and High 419 Throughput with ECN and AQM", CAIA Technical Report CAIA- 420 TR-150710A, Swinburne University of Technology, July 2015, 421 . 424 [CODEL2012] 425 Nichols, K. and V. Jacobson, "Controlling Queue Delay", 426 July 2012, . 428 [I-D.ABE] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 429 "TCP Alternative Backoff with ECN (ABE)", Internet-draft, 430 IETF work-in-progress draft-khademi-tcpm- 431 alternativebackoff-ecn-00, May 2016. 433 [I-D.AQM-ECN-benefits] 434 Fairhurst, G. and M. Welzl, "The Benefits of using 435 Explicit Congestion Notification (ECN)", Internet-draft, 436 IETF work-in-progress draft-ietf-aqm-ecn-benefits-08, 437 November 2015. 439 [I-D.CUBIC] 440 Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and 441 R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", 442 Internet-draft, IETF 443 work-in-progress draft-ietf-tcpm-cubic-01, January 2016. 445 [I-D.CoDel] 446 Nichols, K., Jacobson, V., McGregor, V., and J. Iyengar, 447 "Controlled Delay Active Queue Management", Internet- 448 draft, IETF work-in-progress draft-ietf-aqm-codel-03, 449 March 2016. 451 [I-D.PIE] Pan, R., Natarajan, P., Baker, F., White, G., VerSteeg, 452 B., Prabhu, M., Piglione, C., and V. Subramanian, "PIE: A 453 Lightweight Control Scheme To Address the Bufferbloat 454 Problem", Internet-draft, IETF 455 work-in-progress draft-ietf-aqm-pie-07, April 2016. 457 [I-D.bagnulo-tsvwg-generalized-ecn] 458 Bagnulo, M. and B. Briscoe, "Adding Explicit Congestion 459 Notification (ECN) to TCP control packets", 460 draft-bagnulo-tsvwg-generalized-ecn-01 (work in progress), 461 July 2016. 463 [I-D.briscoe-tsvwg-ecn-l4s-id] 464 Schepper, K., Briscoe, B., and I. Tsang, "Identifying 465 Modified Explicit Congestion Notification (ECN) Semantics 466 for Ultra-Low Queuing Delay", 467 draft-briscoe-tsvwg-ecn-l4s-id-01 (work in progress), 468 March 2016. 470 [I-D.ietf-tcpm-accurate-ecn] 471 Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More 472 Accurate ECN Feedback in TCP", 473 draft-ietf-tcpm-accurate-ecn-00 (work in progress), 474 December 2015. 476 [I-D.ietf-tcpm-dctcp] 477 Bensley, S., Eggert, L., Thaler, D., Balasubramanian, P., 478 and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion 479 Control for Datacenters", draft-ietf-tcpm-dctcp-01 (work 480 in progress), November 2015. 482 [ICC2002] Kwon, M. and S. Fahmy, "TCP Increase/Decrease Behavior 483 with Explicit Congestion Notification (ECN)", IEEE 484 ICC 2002, New York, New York, USA, May 2002, 485 . 487 [PAM2015] Trammell, B., Kuhlewind, M., Boppart, D., Learmonth, I., 488 Fairhurst, G., and R. Scheffenegger, "Enabling Internet- 489 wide Deployment of Explicit Congestion Notification", 490 Proceedings of the 2015 Passive and Active Measurement 491 Conference, New York, March 2015, 492 . 494 [RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) 495 Concepts, Abstract Mechanism, and Requirements", RFC 7713, 496 DOI 10.17487/RFC7713, December 2015, 497 . 499 [WWDC2015] 500 Lakhera, P. and S. Cheshire, "Your App and Next Generation 501 Networks", Apple Worldwide Developers Conference 2015, San 502 Francisco, USA, June 2015, 503 . 505 Authors' Addresses 507 Naeem Khademi 508 University of Oslo 509 PO Box 1080 Blindern 510 Oslo, N-0316 511 Norway 513 Email: naeemk@ifi.uio.no 515 Michael Welzl 516 University of Oslo 517 PO Box 1080 Blindern 518 Oslo, N-0316 519 Norway 521 Email: michawe@ifi.uio.no 523 Grenville Armitage 524 Centre for Advanced Internet Architectures 525 Swinburne University of Technology 526 PO Box 218 527 John Street, Hawthorn 528 Victoria, 3122 529 Australia 531 Email: garmitage@swin.edu.au 533 Godred Fairhurst 534 University of Aberdeen 535 School of Engineering, Fraser Noble Building 536 Aberdeen, AB24 3UE 537 UK 539 Email: gorry@erg.abdn.ac.uk