idnits 2.17.1 draft-ietf-aqm-ecn-benefits-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 date (April 02, 2015) is 3311 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5405 (Obsoleted by RFC 8085) -- Obsolete informational reference (is this intentional?): RFC 1349 (Obsoleted by RFC 2474) == Outdated reference: A later version (-07) exists of draft-stewart-tsvwg-sctpecn-05 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Fairhurst 3 Internet-Draft University of Aberdeen 4 Intended status: Informational M. Welzl 5 Expires: October 4, 2015 University of Oslo 6 April 02, 2015 8 The Benefits of using Explicit Congestion Notification (ECN) 9 draft-ietf-aqm-ecn-benefits-03 11 Abstract 13 This document describes the potential benefits when applications 14 enable Explicit Congestion Notification (ECN). It outlines the 15 principal gains in terms of increased throughput, reduced delay and 16 other benefits when ECN is used over network paths that include 17 equipment that supports ECN-marking. It also identifies some 18 potential problems that might occur when ECN is used. The document 19 does not propose new algorithms that may be able to use ECN or 20 describe the details of implementation of ECN in endpoint devices, 21 routers and other network devices. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 4, 2015. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 1. Introduction 57 Internet Transports (such as TCP and SCTP) have two ways to detect 58 congestion: the loss of a packet and, if Explicit Congestion 59 Notification (ECN) [RFC3168] is enabled, by reception of a packet 60 with a Congestion Experienced (CE)-marking in the IP header. Both of 61 these are treated by transports as indications of (potential) 62 congestion. ECN may also be enabled by other transports: UDP 63 applications that provide congestion control may enable ECN when they 64 are able to correctly process the ECN signals [RFC5405] (e.g., ECN 65 with RTP [RFC6679]). 67 Active Queue Management (AQM) is a class of techniques that can be 68 used by network devices to manage the size of queues that build in 69 network buffers. A network device (router, middlebox, or other 70 device that forwards packets through the network) that does not 71 support AQM, typically uses a drop-tail policy to drop excess IP 72 packets when its queue becomes full. The discard of packets serves 73 as a signal to the end-to-end transport that there may be congestion 74 on the network path being used. This triggers a congestion control 75 reaction to reduce the maximum rate permitted by the sending 76 endpoint. 78 When an application uses a transport that enables the use of ECN, the 79 transport layer sets the ECT(0) or ECT(1) codepoint in the IP header 80 of packets that it sends. This indicates to network devices that 81 they may mark, rather than drop, packets as the network queue builds. 82 This can allow a network device to signal at a point before a 83 transport experiences congestion loss or additional queuing delay. 84 The marking is generally performed as the result of various AQM 85 algorithms, where the exact combination of AQM/ECN algorithms does 86 not need to be known by the transport endpoints. 88 Since ECN makes it possible for the network to signal the presence of 89 incipient congestion (network queueing) without incurring packet 90 loss, it lets the network deliver some packets to an application that 91 would otherwise have been dropped if the application or transport did 92 not support ECN. This packet loss reduction is the most obvious 93 benefit of ECN, but it is often relatively modest. However, enabling 94 ECN can also result in a number of beneficial side-effects, some of 95 which may be much more significant than the immediate packet loss 96 reduction from ECN-marking instead of dropping packets. Several of 97 these benefits have to do with reducing latency in some way (e.g., 98 reduced Head-of-Line Blocking and potentially smaller queuing delay, 99 depending on the marking rules in network devices). The remainder of 100 this document discusses the potential for ECN to positively benefit 101 an application without making specific assumptions about 102 configuration or implementation. 104 [RFC3168] describes a method in which a network device sets the CE 105 codepoint of an ECN-Capable packet at the time that the router would 106 otherwise have dropped the packet. While it has often been assumed 107 that network devices should CE-mark packets at the same level of 108 congestion at which they would otherwise have dropped them, separate 109 configuration of the drop and mark thresholds is known to be 110 supported in some network devices and this is recommended 111 [RFC2309.bis]. Some benefits of ECN that are discussed rely upon 112 network devices marking packets at a lower level of congestion, 113 before they would otherwise drop packets from queue overflow [KH13]. 115 The focus of this document is on usage of ECN by transport and 116 application layer flows, not its implementation in hosts, routers and 117 other network devices. 119 2. ECN Deployment 121 For an application to use ECN requires that the endpoint first 122 enables ECN within the transport. 124 The ability to use ECN requires network devices along the path to at 125 least forward IP packets with any ECN codepoint (i.e., packets with 126 ECT(0), ECT(1), or with a CE-mark). Network devices must not drop 127 packets solely because these codepoints are used [RFC2309.bis]. This 128 is further explained in (Section 2.2). 130 For an application to gain benefit from using a transport that 131 enables ECN, network devices need to enable ECN marking. However, 132 not all network devices along the path need to enable ECN. Any 133 network device that does not mark an ECN-enabled packet with a CE- 134 codepoint can be expected to drop packets under congestion. 135 Applications that experience congestion in these network devices do 136 not see any benefit from using ECN, but would see benefit if the 137 congestion were to occur within a network device that did support 138 ECN. 140 IETF-specified AQM algorithms need to be designed to work with 141 network paths that may experience multiple bottlenecks. Transports 142 can therefore experience dropped or CE-marked packets from more than 143 one network device related to the same network flow. 145 ECN can be deployed both in the general Internet and in controlled 146 environments: 148 o ECN can be incrementally deployed in the general Internet. The 149 IETF has provided guidance on configuration and usage in 150 [RFC2309.bis]. A recent survey reported growing support for ECN 151 on common network paths [TR15]. 153 o ECN may also be deployed within a controlled environment, for 154 example within a data centre or within a well-managed private 155 network. In this case, the use of ECN may be tuned to the 156 specific use-case. An example is Datacenter TCP (DCTCP) [AL10]. 158 Some mechanisms that can assist in using ECN across paths that only 159 partially supports ECN are noted in Section 4. Applications and 160 transports (such as TCP or SCTP) can be designed to fall-back to not 161 using ECN when they discover they are using a path that does not 162 allow use of ECN (e.g., a firewall or other network device configured 163 to drop the ECN codepoint) Section 4.1. 165 2.1. Enabling ECN in Network Devices 167 The ECN behaviour of a network device should be configurable 168 [RFC2309.bis]. An AQM algorithm that supports ECN needs to define 169 the threshold and algorithm for ECN-marking. 171 Network deployment needs also to consider the requirements for 172 processing ECN at tunnel endpoints of network tunnels, and guidance 173 on the treatment of ECN is provided in [RFC6040]. Further guidance 174 on the encapsulation and use of ECN by non-IP network devices is 175 provided in [ID.ECN-Encap]. 177 2.2. Bleaching and Middlebox Requirements to deploy ECN 179 Cases have been noted where a sending endpoint marks a packet with a 180 non-zero ECN mark, but the packet is received with a zero ECN value 181 by the remote endpoint. 183 The current IPv4 and IPv6 specifications assign usage of 2 bits in 184 the IP header to carry the ECN codepoint. This 2-bit field was 185 reserved in [RFC2474] and assigned in [RFC3168]. A previous usage 186 assigned these bits as a part of the now deprecated Type of Service 187 (ToS) field [RFC1349]. Network devices that conform to this older 188 specification may still remark or erase the ECN codepoints, and such 189 equipment needs to be updated to the current specifications to 190 support ECN. This remarking has also been called "ECN bleaching". 192 Some networks have been observed to implement a policy that erases or 193 "bleaches" the ECN marks at a network edge (resetting these to zero). 194 This may be implemented for various reasons (including normalising 195 packets to hide which equipment supports ECN). This policy prevents 196 use of ECN by applications. A network device should therefore not 197 remark an ECT(0) or ECT(1) mark to zero [RFC2309.bis]. A network 198 device must also not set the CE-mark in a packet except to signal 199 incipient congestion, since this will be interpreted as incipient 200 congestion by the transport endpoints. 202 A network device must not change a packet with a CE mark to a zero 203 codepoint (if the CE marking is not propagated, the packet must be 204 discarded) [RFC2309.bis]. Such a packet has already received ECN 205 treatment in the network, and remarking it would then hide the 206 congestion signal from the endpoints. 208 Some networks may use ECN internally or tunnel ECN for traffic 209 engineering or security. Guidance on the correct use of ECN in this 210 case is provided in [RFC6040]. 212 3. Benefit of using ECN to avoid Congestion loss 214 When a non-ECN capable packet would be discarded as a result of 215 incipient congestion, an ECN-enabled router may be expected to CE- 216 mark, rather than drop an ECN-enabled packet [RFC2309.bis]. An 217 application can benefit from this marking in several ways: 219 3.1. Improved Throughput 221 ECN can improve the throughput of an application, although this 222 increase in throughput offered by ECN is often not the most 223 significant gain. 225 When an application uses a light to moderately loaded network path, 226 the number of packets that are dropped due to congestion is small. 227 Using an example from Table 1 of [RFC3649], for a standard TCP sender 228 with a Round Trip Time, RTT, of 0.1 seconds, a packet size of 1500 229 bytes and an average throughput of 1 Mbps, the average packet drop 230 ratio is 0.02. This translates into an approximate 2% throughput 231 gain if ECN is enabled. In heavy congestion, packet loss may be 232 unavoidable with, or without, ECN. 234 3.2. Reduced Head-of-Line Blocking 236 Many transports provide in-order delivery of received data segments 237 to the applications they support. This requires that the transport 238 stalls (or waits) for all data that was sent ahead of a particular 239 segment to be correctly received before it can forward any later 240 data. This is the usual requirement for TCP and SCTP. PR-SCTP 241 [RFC3758], UDP [RFC0768][RFC5405], and DCCP [RFC4340] provide a 242 transport that does not have this requirement. 244 Delaying data to provide in-order transmission to an application 245 results in additional latency when segments are dropped as 246 indications of congestion. The congestive loss creates a delay of at 247 least one RTT for a loss event before data can be delivered to an 248 application. We call this Head-of-Line (HOL) blocking. 250 In contrast, using ECN can remove the resulting delay following a 251 loss that was a result of congestion: 253 o First, the application receives the data normally. This also 254 avoids the inefficiency of dropping data that has already made it 255 across at least part of the network path. It also avoids the 256 additional delay of waiting for recovery of the lost segment. 258 o Second, the transport receiver notes that it has received CE- 259 marked packets, and then requests the sender to make an 260 appropriate congestion-response to reduce the maximum transmission 261 rate for future traffic. 263 3.3. Reduced Probability of RTO Expiry 265 In some situations, ECN can help reduce the probability of a 266 transport retransmission timer expiring (e.g., expiry of the TCP or 267 SCTP retransmission timeout, RTO [RFC5681]). When an application 268 sends a burst of segments and then becomes idle (either because the 269 application has no further data to send or the network prevents 270 sending further data - e.g., flow or congestion control at the 271 transport layer), the last segment of the burst may be lost. It is 272 often not possible to recover this last segment (or last few 273 segments) using standard methods such as Fast Recovery [RFC5681], 274 since the receiver generates no feedback because it is unaware that 275 the lost segments were actually sent [Fla13]. 277 In addition to avoiding HOL blocking, this allows the transport to 278 avoid the consequent loss of state about the network path it is 279 using, which would have arisen had there been a retransmission 280 timeout. Typical impacts of a transport timeout are to reset path 281 estimates such as the RTT, the congestion window, and possibly other 282 transport state that can reduce the performance of the transport 283 until it again adapts to the path. 285 Avoiding timeouts can hence improve the throughput of the 286 application. This benefits applications that send intermittent 287 bursts of data, and rely upon timer-based recovery of packet loss. 289 It can be especially significant when ECN is used on TCP SYN/ACK 290 packets [RFC5562] where the RTO interval may be large because in this 291 case TCP cannot base the timeout period on prior RTT measurements 292 from the same connection. 294 3.4. Applications that do not Retransmit Lost Packets 296 Some latency-critical applications do not retransmit lost packets, 297 yet they may be able to adjust the sending rate in the presence of 298 incipient congestion. Examples of such applications include UDP- 299 based services that carry Voice over IP (VoIP), interactive video or 300 real-time data. The performance of many such applications degrades 301 rapidly with increasing packet loss, and many therefore employ loss- 302 hiding mechanisms (e.g., packet forward error correction, or data 303 duplication) to mitigate the effect of congestion loss on the 304 application. However, such mechanisms add complexity and can 305 themselves consume additional network capacity reducing the available 306 capacity for application data and contributing to the path latency 307 when congestion is experienced. 309 By decoupling congestion control from loss, ECN can allow the 310 transports supporting these applications to reduce their rate before 311 the application experiences loss from congestion. Because this 312 reduces the negative impact of using loss-hiding mechanisms, ECN can 313 have a direct positive impact on the quality experienced by the users 314 of these applications. 316 3.5. Making Incipient Congestion Visible 318 A characteristic of using ECN is that it exposes the presence of 319 congestion on a network path to the transport and network layers. 320 This information can be used for monitoring performance of the path, 321 and could be used to directly meter the amount of congestion that has 322 been encountered upstream on a path; metering packet loss is harder. 323 ECN measurements are used by Congestion Exposure (ConEx) [RFC6789]. 325 A network flow that only experiences CE-marks and no loss implies 326 that the sending endpoint is experiencing only congestion and not 327 other sources of packet loss (e.g., link corruption or loss in 328 middleboxes). The converse is not true - a flow may experience a 329 mixture of ECN-marks and loss when there is only congestion or when 330 there is a combination of packet loss and congestion [RFC2309.bis]. 331 Recording the presence of CE-marked packets can therefore provide 332 information about the performance of the network path. 334 3.6. Opportunities for new Transport Mechanisms 336 CE-marked packets carry an indication that network queues are 337 filling, without incurring loss. This has the possibility to provide 338 richer feedback (more frequent and fine-grained indications) to 339 transports. This may utilise new thresholds and algorithms for ECN- 340 marking. Supporting ECN therefore provides a mechanism that can 341 benefit evolution of transport protocols. 343 3.6.1. Other forms of ECN-Marking/Reactions 345 ECN requires a definition of both how network devices CE-mark packets 346 and how applications/transports need to react to reception of these 347 CE-marked packets. ECN-capable receiving endpoints need to provide 348 feedback indicating that CE-marks were received. An endpoint may 349 provide more detailed feedback describing the set of received ECN 350 codepoints using Accurate ECN Feedback [ID.Acc.ECN]. This can 351 provide more information to a sending endpoint's congestion control 352 mechanism. 354 Precise feedback about the number of packet marks encountered is 355 supported by the Real Time Protocol (RTP) when used over UDP 356 [RFC6679] and proposed for SCTP [ST14] and TCP [ID.Acc.ECN]. 358 Benefit has been noted when packets are CE-marked earlier using an 359 instantaneous queue, and if the receiver provides precise feedback 360 about the number of packet marks encountered, a better sender 361 behavior has been shown to be possible (e.g, Datacenter TCP (DCTCP) 362 [AL10]). DCTCP is targeted at confined environments such as a 363 datacenter. It is currently unknown whether or how such behaviour 364 could be safely introduced into the Internet. 366 4. ECN Transport Mechanisms for Paths with Partial ECN support 368 Early deployment of ECN encountered a number of operational 369 difficulties when the network only partially supports the use of ECN, 370 or to respond to the challenges due to misbehaving network devices 371 and/or endpoints. These problems have been observed to diminish with 372 time, but may still be encountered on some Internet paths [TR15]. 374 This section describes transport mechanisms that allow ECN-enabled 375 endpoints to continue to work effectively over a path with partial 376 ECN support. 378 4.1. Verifying whether a Path Really Supports ECN 380 ECN transport and applications need to implement mechanisms to verify 381 ECN support on the path that they use and fall back to not using ECN 382 when it would not work. This is expected to be a normal feature of 383 IETF-defined transports supporting ECN. 385 Before a transport relies on the presence or absence of CE-marked 386 packets, it may need to verify that any ECN marks applied to packets 387 passed by the path are indeed delivered to the remote endpoint. This 388 may be achieved by the sender setting known ECN codepoints into 389 specific packets in a network flow and then verifying that these 390 reach the remote endpoint [ID.Fallback], [TR15]. 392 Endpoints also need to be robust to path changes. A change in the 393 set of network devices along a path may impact the ability to 394 effectively signal or use ECN across the path, e.g., when a path 395 changes to use a middlebox that bleaches ECN codepoints. As a 396 necessary, but short term fix, transports could implement mechanisms 397 that detect this and fall-back to disabling use of ECN [BA11]. 399 4.2. Detecting ECN Receiver Feedback Cheating 401 It is important that receiving endpoints accurately report the loss 402 they experience when using a transport that uses loss-based 403 congestion control. So also, when using ECN, a receiver must 404 correctly report the congestion marking that it receives and then 405 provide a mechanism to feed the congestion information back to the 406 sending endpoint. 408 The transport at endpoint receivers must not try to conceal reception 409 of CE-marked packets in the ECN feedback information that they 410 provide to the sending endpoint [RFC2309.bis]. Transport protocols 411 are actively encouraged to include mechanisms that can detect and 412 appropriately respond to such misbehavior (e.g., disabling use of 413 ECN, and relying on loss-based congestion detection [TR15]). 415 5. Conclusion 417 This section summarises the benefits of deploying and using AQM 418 within the Internet. It also provides a list of key requirements to 419 achieve ECN deployment. 421 Network devices should enable ECN and people configuring host stacks 422 should also enable ECN [RFC2309.bis]. Specifically network devices 423 must not change a packet with a CE mark to a zero codepoint (if the 424 CE marking is not propagated, the packet must be discarded). These 425 are prerequisites to allow applications to gain the benefits of ECN. 427 Prerequisites for network devices (including IP routers) to enable 428 use of ECN include: 430 o should not reset the ECN codepoint to zero by default (see 431 Section 2.2). 433 o should correctly update the ECN codepoint in the presence of 434 congestion [RFC2309.bis]. 436 o should correctly support alternate ECN semantics [RFC4774]. 438 Prerequisites for network endpoints to enable use of ECN include: 440 o should use transports that can set and receive ECN marks. 442 o when ECN is used, must correctly return feedback of congestion to 443 the sending endpoint. 445 o when ECN is used, must use transports that react appropriately to 446 received ECN feedback (see Section 4.2). 448 o when ECN is used, should use transports that can detect misuse of 449 ECN and detect paths that do not support ECN, providing fallback 450 to loss-based congestion detection when ECN is not supported (see 451 Section 4.1). 453 Application developers should where possible use transports that 454 enable the benefits of ECN. Applications that directly use UDP need 455 to provide support to implement the functions required for ECN 456 [RFC5405]. Once enabled, an application that uses a transport that 457 supports ECN will experience the benefits of ECN as network 458 deployment starts to enable ECN. The application does not need to be 459 rewritten to gain these benefits. Table 1 summarises some of these 460 benefits. 462 +---------+-----------------------------------------------------+ 463 | Section | Benefit | 464 +---------+-----------------------------------------------------+ 465 | 3.1 | Improved throughput | 466 | 3.2 | Reduced Head-of-Line blocking | 467 | 3.3 | Reduced probability of RTO Expiry | 468 | 3.4 | Applications that do not retransmit lost packets | 469 | 3.5 | Making incipient congestion visible | 470 | 3.6 | Opportunities for new transport mechanisms | 471 +---------+-----------------------------------------------------+ 473 Table 1: Summary of Key Benefits 475 6. Acknowledgements 477 The authors were part-funded by the European Community under its 478 Seventh Framework Programme through the Reducing Internet Transport 479 Latency (RITE) project (ICT-317700). The views expressed are solely 480 those of the authors. 482 The authors would like to thank the following people for their 483 comments on prior versions of this document: Bob Briscoe, David 484 Collier-Brown, John Leslie, Colin Perkins, Richard Scheffenegger, 485 Dave Taht, Wes Eddy, Fred Baker and other members of the TSVWG. 487 7. IANA Considerations 489 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 491 This memo includes no request to IANA. 493 8. Security Considerations 495 This document introduces no new security considerations. Each RFC 496 listed in this document discusses the security considerations of the 497 specification it contains. 499 9. Revision Information 501 XXX RFC-Ed please remove this section prior to publication. 503 Revision 00 was the first WG draft. 505 Revision 01 includes updates to complete all the sections and a 506 rewrite to improve readability. Added section 2. Author list 507 reversed, since Gorry has become the lead author. Corrections 508 following feedback from Wes Eddy upon review of an interim version of 509 this draft. 511 Note: Wes Eddy raised a question about whether discussion of the ECN 512 Pitfalls could be improved or restructured - this is expected to be 513 addressed in the next revision. 515 Revision 02 updates the title, and also the description of mechanisms 516 that help with partial ECN support. 518 We think this draft is ready for wider review. Comments are welcome 519 to the authors or via the IETF AQM or TSVWG mailing lists. 521 Revision 03 includes updates from the mailing list and WG discussions 522 at the Dallas IETF meeting. 524 The section "Avoiding Capacity Overshoot" was removed, since this 525 refers primarily to an AQM benefit, and the additional benefits of 526 ECN are already stated. Separated normative and infoirmative 527 referebc 529 XX Note: The reference to AQM Eval Requirements relises on addition 530 of material to this document to define multiple bottleneck 531 requirements 533 10. References 535 10.1. Normative References 537 [RFC2309.bis] 538 Baker, F. and G. Fairhurst, "IETF Recommendations 539 Regarding Active Queue Management", Internet-draft draft- 540 ietf-aqm-recommendation-06, October 2014. 542 [RFC2474] "Definition of the Differentiated Services Field (DS 543 Field) in the IPv4 and IPv6 Headers". 545 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 546 of Explicit Congestion Notification (ECN) to IP", RFC 547 3168, September 2001. 549 [RFC5405] . 551 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 552 Notification", RFC 6040, November 2010. 554 10.2. Informative References 556 [AL10] Alizadeh, M., Greenberg, A., Maltz, D., Padhye, J., Patel, 557 P., Prabhakar, B., Sengupta, S., and M. Sridharan, "Data 558 Center TCP (DCTCP)", SIGCOMM 2010, August 2010. 560 [BA11] Bauer, Steven., Beverly, Robert., and Arthur. Berger, 561 "Measuring the State of ECN Readiness in Servers, Clients, 562 and Routers, ACM IMC", 2011. 564 [Fla13] Flach, Tobias., Dukkipati, Nandita., Terzis, Andreas., 565 Raghavan, Barath., Cardwell, Neal., Cheng, Yuchung., Jain, 566 Ankur., Hao, Shuai., Katz-Bassett, Ethan., and Ramesh. 567 Govindan, "Reducing web latency: the virtue of gentle 568 aggression.", SIGCOMM 2013, October 2013. 570 [ID.AQM.Eval] 571 Kuhn, Nicolas., Natarajan, Preethi., Khademi, Naeem., and 572 David. Ros, "AQM Characterization Guidelines, Work-in- 573 Progress". 575 [ID.Acc.ECN] 576 Briscoe, Bob., Scheffeneger, Richard., and Mirja. 577 Kuehlewind, "More Accurate ECN Feedback in TCP, Work-in- 578 Progress". 580 [ID.ECN-Encap] 581 Briscoe, B., Kaippallimalil, J., and P. Thaler, 582 "Guidelines for Adding Congestion Notification to 583 Protocols that Encapsulate IP", Internet-draft, IETF work- 584 in-progress draft-ietf-tsvwg-ecn-encap-guidelines. 586 [ID.Fallback] 587 Kuehlewind, Mirja. and Brian. Trammell, "A Mechanism for 588 ECN Path Probing and Fallback, draft-kuehlewind-tcpm-ecn- 589 fallback, Work-in-Progress". 591 [KH13] Khademi, N., Ros, D., and M. Welzl, "The New AQM Kids on 592 the Block: Much Ado About Nothing?", University of Oslo 593 Department of Informatics technical report 434, October 594 2013. 596 [RFC0768] Postel, J., "User Datagram Protocol", 1980. 598 [RFC1349] "Type of Service in the Internet Protocol Suite". 600 [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", 601 RFC 3649, December 2003. 603 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 604 Conrad, "Stream Control Transmission Protocol (SCTP) 605 Partial Reliability Extension", RFC 3758, May 2004. 607 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 608 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 610 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 611 Explicit Congestion Notification (ECN) Field", BCP 124, 612 RFC 4774, November 2006. 614 [RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K. 615 Ramakrishnan, "Adding Explicit Congestion Notification 616 (ECN) Capability to TCP's SYN/ACK Packets", RFC 5562, June 617 2009. 619 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 620 Control", RFC 5681, September 2009. 622 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 623 and K. Carlberg, "Explicit Congestion Notification (ECN) 624 for RTP over UDP", RFC 6679, August 2012. 626 [RFC6789] Briscoe, B., Woundy, R., and A. Cooper, "Congestion 627 Exposure (ConEx) Concepts and Use Cases", RFC 6789, 628 December 2012. 630 [ST14] Stewart, R., Tuexen, M., and X. Dong, "ECN for Stream 631 Control Transmission Protocol (SCTP)", Internet-draft 632 draft-stewart-tsvwg-sctpecn-05.txt, January 2014. 634 [TR15] Tranmmel, Brian., Kuehlewind, Mirja., Boppart, Damiano, 635 Learmonth, Iain., and Gorry. Fairhurst, "Enabling 636 internet-wide deployment of Explicit Congestion 637 Notification Tramwell, B., Kuehlewind, M., Boppart, D., 638 Learmonth, I., Fairhurst, G. & Scheffnegger, Passive and 639 Active Measurement Conference (PAM)", March 2015. 641 Authors' Addresses 643 Godred Fairhurst 644 University of Aberdeen 645 School of Engineering, Fraser Noble Building 646 Aberdeen AB24 3UE 647 UK 649 Email: gorry@erg.abdn.ac.uk 651 Michael Welzl 652 University of Oslo 653 PO Box 1080 Blindern 654 Oslo N-0316 655 Norway 657 Phone: +47 22 85 24 20 658 Email: michawe@ifi.uio.no