idnits 2.17.1 draft-ietf-aqm-ecn-benefits-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 (July 27, 2015) is 3194 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- 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: 0 errors (**), 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: January 28, 2016 University of Oslo 6 July 27, 2015 8 The Benefits of using Explicit Congestion Notification (ECN) 9 draft-ietf-aqm-ecn-benefits-06 11 Abstract 13 The goal of this document is to describe the potential benefits when 14 applications use a transport that enables Explicit Congestion 15 Notification (ECN). The document outlines the principal gains in 16 terms of increased throughput, reduced delay and other benefits when 17 ECN is used over a network path that includes equipment that supports 18 ECN-marking. It also discusses challenges for successful deployment 19 of ECN. It does not propose new algorithms to use ECN, nor does it 20 describe the details of implementation of ECN in endpoint devices 21 (Internet hosts), routers or 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 January 28, 2016. 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 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Benefit of using ECN to avoid Congestion Loss . . . . . . . . 4 60 2.1. Improved Throughput . . . . . . . . . . . . . . . . . . . 4 61 2.2. Reduced Head-of-Line Blocking . . . . . . . . . . . . . . 5 62 2.3. Reduced Probability of RTO Expiry . . . . . . . . . . . . 5 63 2.4. Applications that do not Retransmit Lost Packets . . . . 6 64 2.5. Making Incipient Congestion Visible . . . . . . . . . . . 7 65 2.6. Opportunities for new Transport Mechanisms . . . . . . . 7 66 3. Network Support for ECN . . . . . . . . . . . . . . . . . . . 8 67 3.1. The ECN Field . . . . . . . . . . . . . . . . . . . . . . 9 68 3.2. Forwarding ECN-Capable IP Packets . . . . . . . . . . . . 9 69 3.3. Enabling ECN in Network Devices . . . . . . . . . . . . . 9 70 3.4. Co-existance of ECN and non-ECN flows . . . . . . . . . . 10 71 3.5. Bleaching and Middlebox Requirements to deploy ECN . . . 10 72 3.6. Tunneling ECN and the use of ECN by Lower Layer Networks 11 73 4. Using ECN across the Internet . . . . . . . . . . . . . . . . 11 74 4.1. Partial Deployment . . . . . . . . . . . . . . . . . . . 11 75 4.2. Detecting whether a Path Really Supports ECN . . . . . . 12 76 4.3. Detecting ECN Receiver Feedback Cheating . . . . . . . . 12 77 5. Summary: Enabling ECN in Network Devices and Hosts . . . . . 12 78 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 81 9. Revision Information . . . . . . . . . . . . . . . . . . . . 15 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 84 10.2. Informative References . . . . . . . . . . . . . . . . . 17 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 87 1. Introduction 89 Internet Transports (such as TCP and SCTP) are implemented in 90 endpoints (Internet hosts) and are designed to detect and react to 91 network congestion. Congestion may be detected by loss of an IP 92 packet or, if Explicit Congestion Notification (ECN) [RFC3168] is 93 enabled, by the reception of a packet with a Congestion Experienced 94 (CE)-marking in the IP header. Both of these are treated by 95 transports as indications of congestion. ECN may also be enabled by 96 other transports: UDP applications that provide congestion control 97 may enable ECN when they are able to correctly process the ECN 98 signals [ID.RFC5405.bis] (e.g., ECN with RTP [RFC6679]). 100 Active Queue Management (AQM) [ID.RFC2309.bis] is a class of 101 techniques that can be used by network devices (a router, middlebox, 102 or other device that forwards packets through the network) to manage 103 the size of queues in network buffers. A network device that does 104 not support AQM typically uses a drop-tail policy to drop excess IP 105 packets when its queue becomes full. The discard of packets serves 106 as a signal to the end-to-end transport that there may be congestion 107 on the network path being used. This results in a congestion control 108 reaction by the transport to reduce the maximum rate permitted by the 109 sending endpoint. 111 When an application uses a transport that enables use of ECN 112 [RFC3168], the transport layer sets the ECT(0) or ECT(1) codepoint in 113 the IP header of packets that it sends. This indicates to network 114 devices that they may mark, rather than drop the ECN-capable IP 115 packets. An ECN-capable network device can then signal incipient 116 congestion (network queueing) at a point before a transport 117 experiences congestion loss or high queuing delay. The marking is 118 generally performed as the result of various AQM algorithms, where 119 the exact combination of AQM/ECN algorithms does not need to be known 120 by the transport endpoints. 122 Since ECN makes it possible for the network to signal the presence of 123 incipient congestion without incurring packet loss, it lets the 124 network deliver some packets to an application that would otherwise 125 have been dropped if the application or transport did not support 126 ECN. This packet loss reduction is the most obvious benefit of ECN, 127 but it is often relatively modest. However, enabling ECN can also 128 result in a number of beneficial side-effects, some of which may be 129 much more significant than the immediate packet loss reduction from 130 ECN-marking instead of dropping packets. Several benefits reduce 131 latency (e.g., reduced Head-of-Line Blocking). 133 The focus of the document is on usage of ECN by transport and 134 application layer flows, not its implementation in endpoint hosts, or 135 in routers and other network devices. 137 1.1. Terminology 139 The following terms are used: 141 AQM: Active Queue Management. 143 CE: Congestion Experienced, a codepoint value marked in the IP packet 144 header. 146 ECN-capable: An IP packet with a non-zero ECN value (i.e., with a 147 ECT(0), ECT(1), or the CE codepoint). An ECN-capable network device 148 may forward, drop or queue an ECN-capable packet and may choose to 149 CE-mark this packet when there is incipient congestion. 151 ECN field: A 2-bit field specified for use explicit congestion 152 signalling in the IPv4 and IPv6 packet headers. 154 Endpoint: An Internet host that terminates a transport protocol 155 connection across an Internet path. 157 Incipient Congestion: The detection of congestion when it is 158 starting, perhaps by a network device noting that the arrival rate 159 exceeds the forwarding rate. 161 Network device: A router, middlebox, or other device that forwards IP 162 packets through the network. 164 non-ECN-capable: An IP packet with a zero value ECN codepoint. A 165 non-ECN-capable packet may be forwarded, dropped or queued by a 166 network device. 168 2. Benefit of using ECN to avoid Congestion Loss 170 An ECN-capable network device is expected to CE-mark an ECN-capable 171 IP packet when an AQM method detects incipient congestion, rather 172 than to drop the packet [ID.RFC2309.bis]. An application can benefit 173 from this marking in several ways: 175 2.1. Improved Throughput 177 ECN seeks to avoid the inefficiency of dropping data that has already 178 made it across at least part of the network path. 180 ECN can improve the throughput of an application, although this 181 increase in throughput is often not the most significant gain. When 182 an application uses a light to moderately loaded network path, the 183 number of packets that are dropped due to congestion is small. Using 184 an example from Table 1 of [RFC3649], for a standard TCP sender with 185 a Round Trip Time, RTT, of 0.1 seconds, a packet size of 1500 bytes 186 and an average throughput of 1 Mbps, the average packet drop ratio 187 would be 0.02 (i.e., 1 in 50 packets). This translates into an 188 approximate 2% throughput gain if ECN is enabled. (Note that in 189 heavy congestion, packet loss may be unavoidable with, or without, 190 ECN.) 192 2.2. Reduced Head-of-Line Blocking 194 Many Internet transports provide in-order delivery of received data 195 segments to the applications they support. For these applications, 196 use of ECN can reduce the delay that can result when these 197 applications experience packet loss. 199 Packet loss may occur for various reasons. One cause arises when an 200 AQM scheme drops a packet as a signal of incipient congestion. 201 Whatever the cause of loss, a missing packet needs to trigger a 202 congestion control response. A reliable transport also triggers 203 retransmission to recover the lost data. For a transport providing 204 in-order delivery, this requires that the transport receiver stalls 205 (or waits) for all data that was sent ahead of a lost segment to be 206 correctly received before it can forward any later data to the 207 application. A loss therefore creates a delay of at least one RTT 208 after a loss event before data can be delivered to an application. 209 We call this Head-of-Line (HOL) blocking. This is the usual 210 requirement for TCP and SCTP. (PR-SCTP [RFC3758], UDP 211 [RFC0768][ID.RFC5405.bis], and DCCP [RFC4340] provide a transport 212 that does not provide re-ordering). 214 By enabling ECN, a transport continues to receive in-order data when 215 there is incipient congestion, and can pass this data to the 216 receiving application. Use of ECN avoids the additional reordering 217 delay in a reliable transport. The sender still needs to make an 218 appropriate congestion-response to reduce the maximum transmission 219 rate for future traffic, which usually will require a reduction in 220 the sending rate [ID.RFC5405.bis].) 222 2.3. Reduced Probability of RTO Expiry 224 Some patterns of packet loss can result in a Retransmission Time Out 225 (RTO), which causes a sudden and significant change in the allowed 226 rate at which a transport/application can forward packets. Because 227 ECN provides an alternative to drop for network devices to signal 228 incipient congestion, this can reduce the probability of loss and 229 hence reduce the likelihood of RTO expiry. 231 Internet transports/applications generally use a RTO timer as a last 232 resort to detect and recover loss [ID.RFC5405.bis] [RFC5681]). 233 Specifically, a RTO timer detects loss of a packet that is not 234 followed by other packets, such as at the end of a burst of data 235 segments or when an application becomes idle (either because the 236 application has no further data to send or the network prevents 237 sending further data, e.g., flow or congestion control at the 238 transport layer). This loss of the last segment (or last few 239 segments) of a traffic burst is also known as a "tail loss". 241 Standard transport recovery methods, such as Fast Recovery ( 242 [RFC5681], are often unable to recover from a tail loss. This is 243 because the endpoint receiver is unaware that the lost segments were 244 actually sent, and therefore generates no feedback [Fla13]. 245 Retransmission of these segments therefore relies on expiry of a 246 transport retransmission timer. This timer is also used to detect a 247 lack of forwarding along a path. Expiry of the RTO therefore results 248 in the consequent loss of state about the network path being used. 249 This typically includes resetting path estimates such as the RTT, re- 250 initialising the congestion window, and possibly updates to other 251 transport state. This can reduce the performance of the transport 252 until it again adapts to the path. 254 An ECN-capable network device cannot eliminate the possibility of 255 tail loss, because a drop may occur due to a traffic burst exceeding 256 the instantaneous available capacity of a network buffer or as a 257 result of the AQM algorithm (overload protection mechanisms, etc 258 [ID.RFC2309.bis]). However, an ECN-capable network device that 259 observes incipient congestion may be expected to buffer the IP 260 packets of an ECN-capable flow and set a CE-mark in one or more 261 packet(s), rather than triggering packet drop. Setting a CE-mark 262 signals incipient congestion without forcing the transport/ 263 application to enter retransmission timeout. This reduces 264 application-level latency and can improve the throughput for 265 applications that send intermittent bursts of data. 267 The benefit of avoiding retransmission loss is expected to be 268 significant when ECN is used on TCP SYN/ACK packets [RFC5562] where 269 the RTO interval may be large because TCP cannot base the timeout 270 period on prior RTT measurements from the same connection. 272 2.4. Applications that do not Retransmit Lost Packets 274 A transport that enables ECN can receive timely congestion signals 275 without the need to retransmit packets each time it receives a 276 congestion signal. 278 Some latency-critical applications do not retransmit lost packets, 279 yet may be able to adjust their sending rate following detection of 280 incipient congestion. Examples of such applications include UDP- 281 based services that carry Voice over IP (VoIP), interactive video, or 282 real-time data. The performance of many such applications degrades 283 rapidly with increasing packet loss and the transport/application may 284 therefore employ mechanisms (e.g., packet forward error correction, 285 data duplication, or media codec error concealment) to mitigate the 286 immediate effect of congestion loss on the application. Some 287 mechanisms consume additional network capacity, some require 288 additional processing and some contribute additional path latency 289 when congestion is experienced. By decoupling congestion control 290 from loss, ECN can allow transports that support these applications 291 to reduce their rate before the application experiences loss from 292 congestion. This can reduce the negative impact of triggering loss- 293 hiding mechanisms with a direct positive impact on the quality 294 experienced by the users of these applications. 296 2.5. Making Incipient Congestion Visible 298 A characteristic of using ECN is that it exposes the presence of 299 congestion on a network path to the transport and network layers 300 allowing information to be collected about the presence of incipient 301 congestion. 303 Recording the presence of CE-marked packets can provide information 304 about the current congestion level experienced on a network path. A 305 network flow that only experiences CE-marking and no loss implies 306 that the sending endpoint is experiencing only congestion. A network 307 flow may also experience loss (e.g., due to queue overflow, AQM 308 methods that protect other flows, link corruption or loss in 309 middleboxes). When a mixture of ECN-marking and packet loss is 310 experienced, transports and measurements need to assume there is 311 congestion [ID.RFC2309.bis]. An absence of CE-marks therefore does 312 not indicate a path has not experienced congestion. 314 The reception of CE-marked packets can be used to monitor the level 315 of congestion by a transport/application or a network operator. For 316 example, ECN measurements are used by Congestion Exposure (ConEx) 317 [RFC6789]. In contrast, metering packet loss is harder. 319 2.6. Opportunities for new Transport Mechanisms 321 ECN can enable design and deployment of new algorithms in network 322 devices and Internet transports. Internet transports need to regard 323 both loss and CE-marking as an indication of congestion. However, 324 while the amount of feedback provided by drop ought naturally to be 325 minimized, this is not the case for ECN. In contrast, an ECN-Capable 326 network device could provide richer (more frequent and fine-grained) 327 indication of its congestion state to the transport. 329 All ECN-capable receiving endpoints need to provide feedback to the 330 transport sender to indicate that CE-marks have been 331 received.[RFC3168] provides one method that signals once each round 332 trip time that CE-marked packets have been received. 334 A receiving endpoint may provide more detailed feedback to the 335 congestion controller at the sender (e.g., describing the set of 336 received ECN codepoints, or indicating each received CE-marked 337 packet). Precise feedback about the number of CE-marks encountered 338 is supported by the Real Time Protocol (RTP) when used over UDP 339 [RFC6679] and has been proposed for SCTP [ST14] and TCP [ID.Acc.ECN]. 341 More detailed feedback is expected to enable evolution of transport 342 protocols allowing the congestion control mechanism to make a more 343 appropriate decision on how to react to congestion. Designers of 344 transport protocols need to consider not only how network devices CE- 345 mark packets, but also how the control loop in the application/ 346 transport reacts to reception of these CE-marked packets. 348 Benefit has been noted when packets are CE-marked early using an 349 instantaneous queue, and if the receiving endpoint provides feedback 350 about the number of packet marks encountered, an improved sender 351 behavior has been shown to be possible, e.g, Datacenter TCP (DCTCP) 352 [AL10]. DCTCP is targeted at controlled environments such as a 353 datacenter. This is work-in-progress and it is currently unknown 354 whether or how such behaviour could be safely introduced into the 355 Internet. Any update to an Internet transport protocol requires 356 careful consideration of the robustness of the behaviour when working 357 with endpoints or network devices that were not designed for the new 358 congestion reaction. 360 3. Network Support for ECN 362 For an application to use ECN requires that the endpoints first 363 enable ECN within the transport being used, but also for all network 364 devices along the path to at least forward IP packets that set a non- 365 zero ECN codepoint. 367 ECN can be deployed both in the general Internet and in controlled 368 environments: 370 o ECN can be incrementally deployed in the general Internet. The 371 IETF has provided guidance on configuration and usage in 372 [ID.RFC2309.bis]. 374 o ECN may be deployed within a controlled environment, for example 375 within a data centre or within a well-managed private network. 376 This use of ECN may be tuned to the specific use-case. An example 377 is DCTCP [AL10] [ID.DCTCP]. 379 Early experience of using ECN across the general Internet encountered 380 a number of operational difficulties when the network path either 381 failed to transfer ECN-capable packets or inappropriately changed the 382 ECN codepoints [BA11]. A recent survey reported a growing support 383 for network paths to pass ECN codepoints [TR15]. 385 The remainder of this section identifies what is needed for network 386 devices to effectively support ECN. 388 3.1. The ECN Field 390 The current IPv4 and IPv6 specifications assign usage of 2 bits in 391 the IP header to carry the ECN codepoint. This 2-bit field was 392 reserved in [RFC2474] and assigned in [RFC3168]. 394 [RFC4774] discusses some of the issues in defining alternate 395 semantics for the ECN field, and specifies requirements for a safe 396 coexistence in an Internet that could include routers that do not 397 understand the defined alternate semantics. 399 3.2. Forwarding ECN-Capable IP Packets 401 Not all network devices along a path need to be ECN-capable (i.e., 402 perform CE-marking). However, all network devices need to be 403 configured not to drop packets solely because the ECT(0) or ECT(1) 404 codepoints are used. 406 Any network device that does not perform CE-marking of an ECN-capable 407 packet can be expected to drop these packets under congestion. 408 Applications that experience congestion at these network devices do 409 not see any benefit from enabling ECN. However, they may see benefit 410 if the congestion were to occur within a network device that did 411 support ECN. 413 3.3. Enabling ECN in Network Devices 415 Network devices should use an AQM algorithm that CE-marks ECN-capable 416 traffic when making decisions about the response to congestion 417 [ID.RFC2309.bis]. An ECN method should set a CE-mark on ECN-capable 418 packets in the presence of incipient congestion. A CE-marked packet 419 will be interpreted as an indication of incipient congestion by the 420 transport endpoints. 422 There is opportunity to design an AQM method for an ECN-capable 423 network device that differs from an AQM method designed to drop 424 packets. [ID.RFC2309.bis] states that the network device should 425 allow this behaviour to be configurable. 427 [RFC3168] describes a method in which a network device sets the CE- 428 mark at the time that the network device would otherwise have dropped 429 the packet. While it has often been assumed that network devices 430 should CE-mark packets at the same level of congestion at which they 431 would otherwise have dropped them, [ID.RFC2309.bis] recommends that 432 network devices allow independent configuration of the settings for 433 AQM dropping and ECN marking. Such separate configuration of the 434 drop and mark policies is supported in some network devices. 436 3.4. Co-existance of ECN and non-ECN flows 438 Network devices need to be able to forward all IP flows and provide 439 appropriate treatment for both ECN and non-ECN traffic. 441 The design considerations for an AQM scheme supporting ECN needs to 442 consider the impact of queueing during incipient congestion. For 443 example, a simple AQM scheme could choose to queue ECN-capable and 444 non-ECN capable flows in the same queue with an ECN scheme that CE- 445 mark packets during incipient congestion. The CE-marked packets that 446 remain in the queue during congestion can continue to contribute to 447 queueing delay. In contrast, non-ECN-capable packets would normally 448 be dropped by an AQM scheme under incipient congestion. This 449 difference in queueing is one motivation for consideration of more 450 advanced AQM schemes, and may provide an incentive for enabling flow 451 isolation using scheduling [ID.RFC2309.bis]. The IETF is defining 452 methods to evaluate the suitability of AQM schemes for deployment in 453 the general Internet [ID.AQM.eval]. 455 3.5. Bleaching and Middlebox Requirements to deploy ECN 457 Network devices should not be configured to change the ECN codepoint 458 in the packets that they forward, except to set the CE-codepoint to 459 signal incipient congestion. 461 Cases have been noted where an endpoint sends a packet with a non- 462 zero ECN mark, but the packet is received by the remote endpoint with 463 a zero ECN codepoint [TR15]. This could be a result of a policy that 464 erases or "bleaches" the ECN codepoint values at a network edge 465 (resetting the codepoint to zero). Bleaching may occur for various 466 reasons (including normalising packets to hide which equipment 467 supports ECN). This policy prevents use of ECN by applications. 469 When ECN-capable IP packets, marked as ECT(0) or ECT(1), are remarked 470 to non-ECN-capable (i.e., the ECN field is set to zero codepoint), 471 this could result in the packets being dropped by ECN-capable network 472 devices further along the path. This eliminates the advantage of 473 using of ECN. 475 A network device must not change a packet with a CE mark to a zero 476 codepoint, if the network device decides not to forward the packet 477 with the CE-mark, it has to instead drop the packet and not bleach 478 the marking. This is because a CE-marked packet has already received 479 ECN treatment in the network, and remarking it would then hide the 480 congestion signal from the receiving endpoint. This eliminates the 481 benefits of ECN. It can also slow down the response to congestion 482 compared to using AQM, because the transport will only react if it 483 later discovers congestion by some other mechanism. 485 Prior to RFC2474, a previous usage assigned the bits now forming the 486 ECN field as a part of the now deprecated Type of Service (ToS) field 487 [RFC1349]. A network device that conforms to this older 488 specification was allowed to remark or erase the ECN codepoints, and 489 such equipment needs to be updated to the current specifications to 490 support ECN. 492 3.6. Tunneling ECN and the use of ECN by Lower Layer Networks 494 Some networks may use ECN internally or tunnel ECN (e.g., for traffic 495 engineering or security). These methods need to ensure that the ECN- 496 field of the tunnel packets is handled correctly at the ingress and 497 egress of the tunnel. Guidance on the correct use of ECN is provided 498 in [RFC6040]. 500 Further guidance on the encapsulation and use of ECN by non-IP 501 network devices is provided in [ID.ECN-Encap]. 503 4. Using ECN across the Internet 505 A receiving endpoint needs to report the loss it experiences when it 506 uses loss-based congestion control. So also, when ECN is enabled, a 507 receiving endpoint must correctly report the presence of CE-marks by 508 providing a mechanism to feed this congestion information back to the 509 sending endpoint , [RFC3168], [ID.RFC5405.bis], enabling the sender 510 to react to experienced congestion. This mechanism needs to be 511 designed to operate robustly across a wide range of Internet path 512 characteristics. This section describes partial deployment, how ECN- 513 enabled endpoints can continue to work effectively over a path that 514 experiences misbehaving network devices or when an endpoint does not 515 correctly provide feedback of ECN congestion information. 517 4.1. Partial Deployment 519 Use of ECN is negotiated between the endpoints prior to using the 520 mechanism. 522 ECN has been designed to allow incremental partial deployment 523 [RFC3168]. Any network device can choose to use either ECN or some 524 other loss-based policy to manage its traffic. Similarly, transport/ 525 application negotiation allows senders and receiving endpoints to 526 choose whether ECN will be used to manage congestion for a particular 527 network flow. 529 4.2. Detecting whether a Path Really Supports ECN 531 Internet transport and applications need to be robust to the variety 532 and sometimes varying path characteristics that are encountered in 533 the general Internet. They need to monitor correct forwarding of ECN 534 over the entire path and duration of a session. 536 To be robust, applications and transports need to be designed with 537 the expectation of heterogeneous forwarding (e.g., where some IP 538 packets are CE-marked by one network device, and some by another, 539 possibly using a different AQM algorithm, or when a combination of 540 CE-marking and loss-based congestion indications are used. 541 ([ID.AQM.eval] describes methodologies for evaluating AQM schemes.) 543 A transport/application also needs to be robust to path changes. A 544 change in the set of network devices along a path could impact the 545 ability to effectively signal or use ECN across the path, e.g., when 546 a path changes to use a middlebox that bleaches ECN codepoints (see 547 Section 3.5). 549 A sending endpoint can check that any CE-marks applied to packets 550 received over the path are indeed delivered to the remote receiving 551 endpoint and that appropriate feedback is provided. (This could be 552 done by a sender setting known a CE codepoint for specific packets in 553 a network flow and then checking whether the remote endpoint 554 correctly reports these marks [ID.Fallback], [TR15].) If a sender 555 detects misuse of ECN, it needs to either conservatively react to 556 congestion or even fall back to using loss-based recovery instead of 557 ECN. 559 4.3. Detecting ECN Receiver Feedback Cheating 561 Appropriate feedback requires that the endpoint receiver does not try 562 to conceal reception of CE-marked packets in the ECN feedback 563 information provided to the sending endpoint [ID.RFC2309.bis]. 564 Designers of applications/transports are therefore encouraged to 565 include mechanisms that can detect this misbehavior. If a sending 566 endpoint detects that a receiver is not correctly providing this 567 feedback, it can either conservatively react to congestion or fall 568 back to using loss-based recovery instead of ECN. 570 5. Summary: Enabling ECN in Network Devices and Hosts 572 This section summarises the benefits of deploying and using ECN 573 within the Internet. It also provides a list of prerequisites to 574 achieve ECN deployment. 576 Application developers should where possible use transports that 577 enable ECN. Applications that directly use UDP need to provide 578 support to implement the functions required for ECN [ID.RFC5405.bis]. 579 Once enabled, an application that uses a transport that supports ECN 580 will experience the benefits of ECN as network deployment starts to 581 enable ECN. The application does not need to be rewritten to gain 582 these benefits. Table 1 summarises the key benefits. 584 +---------+-----------------------------------------------------+ 585 | Section | Benefit | 586 +---------+-----------------------------------------------------+ 587 | 2.1 | Improved throughput | 588 | 2.2 | Reduced Head-of-Line blocking | 589 | 2.3 | Reduced probability of RTO Expiry | 590 | 2.4 | Applications that do not retransmit lost packets | 591 | 2.5 | Making incipient congestion visible | 592 | 2.6 | Opportunities for new transport mechanisms | 593 +---------+-----------------------------------------------------+ 595 Table 1: Summary of Key Benefits 597 Network operators and people configuring network devices should 598 enable ECN [ID.RFC2309.bis]. 600 Prerequisites for network devices (including IP routers) to enable 601 use of ECN include: 603 o A network device that updates the ECN field in IP packets must use 604 IETF-specified methods (see Section 3.1). 606 o A network device may support alternate ECN semantics (see 607 Section 3.1). 609 o Network devices need to be configured not to drop packets solely 610 because the ECT(0) or ECT(1) codepoints are used (see 611 Section 3.2). 613 o A network device must not change a packet with a CE mark to a zero 614 codepoint, if the network device decides not to forward the packet 615 with the CE-mark, it has to instead drop the packet and not bleach 616 the marking (see Section 3.5). 618 o An ECN-capable network device should correctly update the ECN 619 codepoint of ECN-capable packets in the presence of incipient 620 congestion (see Section 3.3). 622 o Network devices need to be able to forward both ECN-capable and 623 non-ECN-capable flows (see Section 3.4). 625 Prerequisites for network endpoints to enable use of ECN include: 627 o An application should use an Internet transport that can set and 628 receive ECN marks (see Section 4). 630 o An ECN-capable transport/application must return feedback 631 indicating congestion to the sending endpoint and perform an 632 appropriate congestion response (see Section 4). 634 o An ECN-capable transport/application should detect paths where 635 there is misuse of ECN and either conservatively react to 636 congestion or even fall back to not sending ECT(0) or ECT(1) (see 637 Section 4.2). 639 o Designers of applications/transports are encouraged to include 640 mechanisms that can detect and react appropriately to misbehaving 641 receivers that fail to report CE-marked packets (see Section 4.3). 643 6. Acknowledgements 645 The authors were part-funded by the European Community under its 646 Seventh Framework Programme through the Reducing Internet Transport 647 Latency (RITE) project (ICT-317700). The views expressed are solely 648 those of the authors. 650 The authors would like to thank the following people for their 651 comments on prior versions of this document: Bob Briscoe, David 652 Collier-Brown, Colin Perkins, Richard Scheffenegger, Dave Taht, Wes 653 Eddy, Fred Baker, Mikael Abrahamsson, Mirja Kuehlewind, John Leslie, 654 and other members of the AQM and TSV Working Groups. 656 7. IANA Considerations 658 XX RFC Ed - PLEASE REMOVE THIS SECTION XXX 660 This memo includes no request to IANA. 662 8. Security Considerations 664 This document introduces no new security considerations. Each RFC 665 listed in this document discusses the security considerations of the 666 specification it contains. 668 9. Revision Information 670 XXX RFC-Ed please remove this section prior to publication. 672 Revision 00 was the first WG draft. 674 Revision 01 includes updates to complete all the sections and a 675 rewrite to improve readability. Added section 2. Author list 676 reversed, since Gorry has become the lead author. Corrections 677 following feedback from Wes Eddy upon review of an interim version of 678 this draft. 680 Note: Wes Eddy raised a question about whether discussion of the ECN 681 Pitfalls could be improved or restructured - this is expected to be 682 addressed in the next revision. 684 Revision 02 updates the title, and also the description of mechanisms 685 that help with partial ECN support. 687 We think this draft is ready for wider review. Comments are welcome 688 to the authors or via the IETF AQM or TSVWG mailing lists. 690 Revision 03 includes updates from the mailing list and WG discussions 691 at the Dallas IETF meeting. 693 The section "Avoiding Capacity Overshoot" was removed, since this 694 refers primarily to an AQM benefit, and the additional benefits of 695 ECN are already stated. Separated normative and informative 696 references 698 Revision 04 (WG Review during WGLC) 700 Updated the abstract. 702 Added a table of contents. 704 Addressed various (some conflicting) comments during WGLC with new 705 text. 707 The section on Network Support for ECN was moved, and some 708 suggestions for rewording sections were implemented. 710 Decided not to remove section headers for 2.1 and 2.2 - to ensure the 711 document clearly calls-out the benefits. 713 Updated references. Updated text to improve consistency of terms and 714 added definitions for key terms. 716 Note: The group suggested this document should not define 717 recommendations for end hosts or routers, but simply state the things 718 needs to enable deployment to be successful. 720 Revision 05 (after WGLC comments) 722 Updated abstract to avoid suggesting that this describes new methods 723 for deployment. 725 Added ECN-field definition, and sorted terms in order. 727 Added an opening para to each "benefit" to say what this is. Sought 728 to remove redundancy between sections. 730 Added new section on Codepoints to avoid saying the same thing twice. 732 Reworked sections 3 and 4 to clarify discussion and to remove 733 unnecessary text. 735 Reformatted Summary to refer to sections describing things, rather 736 than appear as a list of new recommendations. Reordered to match the 737 new document order. 739 Note: This version expects an update to RFC5405.bis that will 740 indicate UDP ECN requirements (normative). 742 Revision 06 744 Corrections from Miria. 746 10. References 748 10.1. Normative References 750 [ID.RFC2309.bis] 751 Baker, F. and G. Fairhurst, "IETF Recommendations 752 Regarding Active Queue Management", Internet-draft draft- 753 ietf-aqm-recommendation-06, October 2014. 755 [ID.RFC5405.bis] 756 Eggert, Lars., Fairhurst, Gorry., and Greg. Shepherd, 757 "Unicast UDP Usage Guidelines", 2015. 759 [RFC2474] "Definition of the Differentiated Services Field (DS 760 Field) in the IPv4 and IPv6 Headers". 762 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 763 of Explicit Congestion Notification (ECN) to IP", 764 RFC 3168, DOI 10.17487/RFC3168, September 2001, 765 . 767 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 768 Notification", RFC 6040, DOI 10.17487/RFC6040, November 769 2010, . 771 10.2. Informative References 773 [AL10] Alizadeh, M., Greenberg, A., Maltz, D., Padhye, J., Patel, 774 P., Prabhakar, B., Sengupta, S., and M. Sridharan, "Data 775 Center TCP (DCTCP)", SIGCOMM 2010, August 2010. 777 [BA11] Bauer, Steven., Beverly, Robert., and Arthur. Berger, 778 "Measuring the State of ECN Readiness in Servers, Clients, 779 and Routers, ACM IMC", 2011. 781 [Fla13] Flach, Tobias., Dukkipati, Nandita., Terzis, Andreas., 782 Raghavan, Barath., Cardwell, Neal., Cheng, Yuchung., Jain, 783 Ankur., Hao, Shuai., Katz-Bassett, Ethan., and Ramesh. 784 Govindan, "Reducing web latency: the virtue of gentle 785 aggression.", SIGCOMM 2013, October 2013. 787 [ID.Acc.ECN] 788 Briscoe, Bob., Scheffeneger, Richard., and Mirja. 789 Kuehlewind, "More Accurate ECN Feedback in TCP, Work-in- 790 Progress". 792 [ID.AQM.eval] 793 Kuhn, Nicolas., Natarajan, Preethi., Ros, David., and 794 Naeem. Khademi, "AQM Characterization Guidelines (Work-in- 795 progress, draft-ietf-aqm-eval-guidelines)", 2015. 797 [ID.DCTCP] 798 Bensley, S., Eggert, Lars., and D. Thaler, "Microsoft's 799 Datacenter TCP (DCTCP): TCP Congestion Control for 800 Datacenters (Work-in-progress, draft-bensley-tcpm-dctcp)", 801 2015. 803 [ID.ECN-Encap] 804 Briscoe, B., Kaippallimalil, J., and P. Thaler, 805 "Guidelines for Adding Congestion Notification to 806 Protocols that Encapsulate IP", Internet-draft, IETF work- 807 in-progress draft-ietf-tsvwg-ecn-encap-guidelines. 809 [ID.Fallback] 810 Kuehlewind, Mirja. and Brian. Trammell, "A Mechanism for 811 ECN Path Probing and Fallback, draft-kuehlewind-tcpm-ecn- 812 fallback, Work-in-Progress". 814 [RFC0768] Postel, J., "User Datagram Protocol", 1980. 816 [RFC1349] "Type of Service in the Internet Protocol Suite". 818 [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", 819 RFC 3649, DOI 10.17487/RFC3649, December 2003, 820 . 822 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 823 Conrad, "Stream Control Transmission Protocol (SCTP) 824 Partial Reliability Extension", RFC 3758, 825 DOI 10.17487/RFC3758, May 2004, 826 . 828 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 829 Congestion Control Protocol (DCCP)", RFC 4340, 830 DOI 10.17487/RFC4340, March 2006, 831 . 833 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 834 Explicit Congestion Notification (ECN) Field", BCP 124, 835 RFC 4774, DOI 10.17487/RFC4774, November 2006, 836 . 838 [RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K. 839 Ramakrishnan, "Adding Explicit Congestion Notification 840 (ECN) Capability to TCP's SYN/ACK Packets", RFC 5562, 841 DOI 10.17487/RFC5562, June 2009, 842 . 844 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 845 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 846 . 848 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 849 and K. Carlberg, "Explicit Congestion Notification (ECN) 850 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 851 2012, . 853 [RFC6789] Briscoe, B., Ed., Woundy, R., Ed., and A. Cooper, Ed., 854 "Congestion Exposure (ConEx) Concepts and Use Cases", 855 RFC 6789, DOI 10.17487/RFC6789, December 2012, 856 . 858 [ST14] Stewart, R., Tuexen, M., and X. Dong, "ECN for Stream 859 Control Transmission Protocol (SCTP)", Internet-draft 860 draft-stewart-tsvwg-sctpecn-05.txt, January 2014. 862 [TR15] Tranmmel, Brian., Kuehlewind, Mirja., Boppart, Damiano, 863 Learmonth, Iain., and Gorry. Fairhurst, "Enabling 864 internet-wide deployment of Explicit Congestion 865 Notification Tramwell, B., Kuehlewind, M., Boppart, D., 866 Learmonth, I., Fairhurst, G. & Scheffnegger, Passive and 867 Active Measurement Conference (PAM)", March 2015. 869 Authors' Addresses 871 Godred Fairhurst 872 University of Aberdeen 873 School of Engineering, Fraser Noble Building 874 Aberdeen AB24 3UE 875 UK 877 Email: gorry@erg.abdn.ac.uk 879 Michael Welzl 880 University of Oslo 881 PO Box 1080 Blindern 882 Oslo N-0316 883 Norway 885 Phone: +47 22 85 24 20 886 Email: michawe@ifi.uio.no