idnits 2.17.1 draft-ietf-aqm-ecn-benefits-04.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 (May 05, 2015) is 3277 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: November 6, 2015 University of Oslo 6 May 05, 2015 8 The Benefits of using Explicit Congestion Notification (ECN) 9 draft-ietf-aqm-ecn-benefits-04 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 network paths that include equipment that supports 18 ECN-marking. It also describes methods that can help successful 19 deployment of ECN. It does not propose new algorithms to use ECN, 20 nor does it describe the details of implementation of ECN in endpoint 21 devices (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 November 6, 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 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . 6 65 2.6. Opportunities for new Transport Mechanisms . . . . . . . 7 66 2.6.1. Benefits from other forms of ECN-Marking/Reactions . 7 67 3. Network Support for ECN . . . . . . . . . . . . . . . . . . . 8 68 3.1. Enabling ECN in Network Devices . . . . . . . . . . . . . 9 69 3.2. Tunneling ECN and the use of ECN by Lower Layer Networks 9 70 3.3. Bleaching and Middlebox Requirements to deploy ECN . . . 9 71 3.4. Impact on non-ECN flows . . . . . . . . . . . . . . . . . 10 72 4. Using ECN across the Internet . . . . . . . . . . . . . . . . 10 73 4.1. Partial Deployment . . . . . . . . . . . . . . . . . . . 11 74 4.2. Verifying whether a Path Really Supports ECN . . . . . . 11 75 4.3. Detecting ECN Receiver Feedback Cheating . . . . . . . . 11 76 5. Summary: Enabling ECN in Network Devices and Hosts . . . . . 12 77 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 9. Revision Information . . . . . . . . . . . . . . . . . . . . 13 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 83 10.2. Informative References . . . . . . . . . . . . . . . . . 15 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 86 1. Introduction 88 Internet Transports (such as TCP and SCTP) are implemented in 89 endpoints (Internet hosts) and have two ways to detect network 90 congestion: the loss of an IP packet or, if Explicit Congestion 91 Notification (ECN) [RFC3168] is enabled, the reception of a packet 92 with a Congestion Experienced (CE)-marking in the IP header. Both of 93 these are treated by transports as indications of congestion. ECN 94 may also be enabled by other transports: UDP applications that 95 provide congestion control may enable ECN when they are able to 96 correctly process the ECN signals [ID.RFC5405.bis] (e.g., ECN with 97 RTP [RFC6679]). 99 Active Queue Management (AQM) [ID.RFC2309.bis] is a class of 100 techniques that can be used by network devices (a router, middlebox, 101 or other device that forwards packets through the network) to manage 102 the size of queues in network buffers. A network device that does 103 not support AQM typically uses a drop-tail policy to drop excess IP 104 packets when its queue becomes full. The discard of packets serves 105 as a signal to the end-to-end transport that there may be congestion 106 on the network path being used. This results in a congestion control 107 reaction by the transport to reduce the maximum rate permitted by the 108 sending endpoint. 110 When an application uses a transport that enables use of ECN 111 [RFC3168], the transport layer sets the ECT(0) or ECT(1) codepoint in 112 the IP header of packets that it sends. This indicates to network 113 devices that they may mark, rather than drop the ECN-capable IP 114 packets. A network device can then signal incipient congestion 115 (network queueing) at a point before a transport experiences 116 congestion loss or additional queuing delay. The marking is 117 generally performed as the result of various AQM algorithms, where 118 the exact combination of AQM/ECN algorithms does not need to be known 119 by the transport endpoints. 121 Since ECN makes it possible for the network to signal the presence of 122 incipient congestion without incurring packet loss, it lets the 123 network deliver some packets to an application that would otherwise 124 have been dropped if the application or transport did not support 125 ECN. This packet loss reduction is the most obvious benefit of ECN, 126 but it is often relatively modest. However, enabling ECN can also 127 result in a number of beneficial side-effects, some of which may be 128 much more significant than the immediate packet loss reduction from 129 ECN-marking instead of dropping packets. Several benefits reduce 130 latency (e.g., reduced Head-of-Line Blocking). The remainder of this 131 document discusses the potential for ECN to positively benefit an 132 application without making specific assumptions about configuration 133 or implementation. 135 [RFC3168] describes a method in which a network device sets the CE 136 codepoint of an ECN-Capable packet at the time that the network 137 device would otherwise have dropped the packet. While it has often 138 been assumed that network devices should CE-mark packets at the same 139 level of congestion at which they would otherwise have dropped them, 140 [ID.RFC2309.bis] recommends that network devices allow independent 141 configuration of the settings for AQM dropping and ECN marking. Such 142 separate configuration of the drop and mark policies is supported in 143 some network devices. 145 The focus of this document is on usage of ECN by transport and 146 application layer flows, not its implementation in endpoint hosts, or 147 in routers and other network devices. 149 1.1. Terminology 151 The following terms are used: 153 Network device: A router, middlebox, or other device that forwards IP 154 packets through the network. 156 Endpoint: An Internet host that terminates a transport protocol 157 connection across an Intenet path. 159 non-ECN Capable: An IP packet with a zero value codepoint. A non-ECN 160 capable packet may be forwarded, dropped or queued by a network 161 device. 163 Incipient Congestion: The detection of congestion when it is 164 starting, perhaps by noting that the arrival rate exceeds the 165 forwarding rate. 167 CE: Congestion Experienced codepoint, a value marked in the IP packet 168 header. 170 ECN-Capable: An IP packet with a header marked with a non-zero ECN 171 value (i.e., with a ECT(0), ECT(1), or CE codepoint). An ECN-capable 172 network device may forward, drop or queue a packet and may choose to 173 CE-mark an ECN-capable packet when there is incipient congestion. 175 2. Benefit of using ECN to avoid Congestion Loss 177 When a non-ECN capable packet would need to queue or discard as a 178 result of incipient congestion, an ECN-enabled router may be expected 179 to CE-mark, rather than drop an ECN-enabled IP packet 180 [ID.RFC2309.bis]. An application can benefit from this marking in 181 several ways: 183 2.1. Improved Throughput 185 ECN can improve the throughput of an application, although this 186 increase in throughput offered by ECN is often not the most 187 significant gain. 189 When an application uses a light to moderately loaded network path, 190 the number of packets that are dropped due to congestion is small. 191 Using an example from Table 1 of [RFC3649], for a standard TCP sender 192 with a Round Trip Time, RTT, of 0.1 seconds, a packet size of 1500 193 bytes and an average throughput of 1 Mbps, the average packet drop 194 ratio is 0.02 (i.e., 1 in 50 packets). This translates into an 195 approximate 2% throughput gain if ECN is enabled. In heavy 196 congestion, packet loss may be unavoidable with, or without, ECN. 198 ECN avoids the inefficiency of dropping data that has already made it 199 across at least part of the network path. 201 2.2. Reduced Head-of-Line Blocking 203 Many transports provide in-order delivery of received data segments 204 to the applications they support. When an AQM scheme drops a packet 205 as a signal of incipient congestion, this triggers loss recovery and 206 a congestion control response. For a transport providing in-order 207 delivery, this requires that the transport receiver stalls (or waits) 208 for all data that was sent ahead of a particular segment to be 209 correctly received before it can forward any later data to the 210 application. This is the usual requirement for TCP and SCTP. PR- 211 SCTP [RFC3758], UDP [RFC0768][ID.RFC5405.bis], and DCCP [RFC4340] 212 provide a transport that does not have this requirement. A 213 congestive loss therefore creates a delay of at least one RTT after a 214 loss event before data can be delivered to an application. We call 215 this Head-of-Line (HOL) blocking. 217 Using ECN, an application continues to receive data when there is 218 incipient congestion. Use of ECN avoids the additional reordering 219 delay in a reliable transport. (When a transport receives a CE- 220 marked packet, it still requests the sender to make an appropriate 221 congestion-response to reduce the maximum transmission rate for 222 future traffic [ID.RFC5405.bis].) 224 2.3. Reduced Probability of RTO Expiry 226 A reduction in the possibility of packet loss can be significant for 227 a reliable transport for a class of applications that send a burst of 228 segments and then becomes idle (either because the application has no 229 further data to send or the network prevents sending further data - 230 e.g., flow or congestion control at the transport layer). 232 Standard transport recovery methods (such as Fast Recovery ( 233 [RFC5681]) are often not able to recover from the loss of the last 234 segment (or last few segments) of a traffic burst (also known as a 235 "tail loss"). This is because the receiver is unaware that the lost 236 segments were actually sent, and therefore generates no feedback 237 [Fla13]. Retransmission of these segments therefore relies on expiry 238 of a transport retransmission timer (e.g., expiry of the TCP or SCTP 239 retransmission timeout, RTO [RFC5681]). 241 A timer expiry results in the consequent loss of state about the 242 network path being used. This typically includes resetting path 243 estimates such as the RTT, re-initialising the congestion window, and 244 possibly updates to other transport state. This can reduce the 245 performance of the transport until it again adapts to the path. 247 When incipient congestion occurs at the tail of a burst, an ECN- 248 capable network device can CE-mark the packet(s), rather than 249 triggering drop. This allows the transport to avoid the 250 retransmission timeout, which can reduce application level latency 251 and improve the throughput for applications that send intermittent 252 bursts of data and rely upon timer-based recovery of packet loss. 253 The benefit is expected to be especially significant when ECN is used 254 on TCP SYN/ACK packets [RFC5562] where the RTO interval may be large 255 because in this case TCP cannot base the timeout period on prior RTT 256 measurements from the same connection. 258 2.4. Applications that do not Retransmit Lost Packets 260 Some latency-critical applications do not retransmit lost packets, 261 yet may be able to adjust the sending rate in the presence of 262 incipient congestion. Examples of such applications include UDP- 263 based services that carry Voice over IP (VoIP), interactive video or 264 real-time data. The performance of many such applications degrades 265 rapidly with increasing packet loss, and many therefore employ 266 mechanisms (e.g., packet forward error correction, data duplication, 267 or media codec error concealment) to mitigate the effect of 268 congestion loss on the application. However, relying on such 269 mechanisms adds complexity and consumes additional network capacity, 270 reducing the available capacity for application data and contributing 271 to the path latency when congestion is experienced. 273 By decoupling congestion control from loss, ECN can allow the 274 transports supporting these applications to reduce their rate before 275 the application experiences loss from congestion. Because this 276 reduces the negative impact of using loss-hiding mechanisms, ECN can 277 have a direct positive impact on the quality experienced by the users 278 of these applications. 280 2.5. Making Incipient Congestion Visible 282 A characteristic of using ECN is that it exposes the presence of 283 congestion on a network path to the transport and network layers. 284 This information can be used for monitoring the level of congestion 285 along the path by a transport/application or a network operator. 286 Metering packet loss is harder. ECN measurements are used by 287 Congestion Exposure (ConEx) [RFC6789]. 289 A network flow that only experiences CE-marking and no loss implies 290 that the sending endpoint is experiencing only congestion and not 291 other sources of packet loss (e.g., link corruption or loss in 292 middleboxes). The converse is not true - a flow may experience a 293 mixture of ECN-marking and loss when there is only congestion, or 294 when there is a combination of packet loss and congestion 295 [ID.RFC2309.bis]. Recording the presence of CE-marked packets can 296 therefore provide information about the current congestion level 297 experienced on a network path. However, it is important to note that 298 any Internet path may also experience congestive loss (e.g., due to 299 queue overflow, AQM methods that protect other flows, middlebox 300 behaviours), so an absence of CE-marks does not indicate a path has 301 not experienced congestion. 303 2.6. Opportunities for new Transport Mechanisms 305 Loss is regarded as the standard signal from a network device 306 experiencing congestion. In contrast, CE-marked packets carry an 307 indication that network queues are filling, without incurring loss. 308 This introduces the possibility to provide richer feedback (more 309 frequent and fine-grained indications) to transports. This could 310 utilise new thresholds and algorithms for ECN-marking. ECN therefore 311 provides a mechanism that can benefit evolution of transport 312 protocols. 314 2.6.1. Benefits from other forms of ECN-Marking/Reactions 316 ECN requires a definition of both how network devices CE-mark packets 317 and how applications/transports react to reception of these CE-marked 318 packets. ECN-capable receiving endpoints therefore need to provide 319 feedback indicating that CE-marks were received.[RFC3168]provides a 320 method that signals once each round trip time that CE-marked packets 321 have been received. An endpoint may provide more detailed feedback 322 describing the set of received ECN codepoints using Accurate ECN 323 Feedback [ID.Acc.ECN]. This can provide more information to a 324 congestion control mechanism at the sending endpoint. 326 Loss and CE-marking are both used as an indication for congestion. 327 However, while the amount of feedback that is provided by loss ought 328 naturally to be minimized, this is not the case for ECN. With ECN, a 329 network device could provide richer and more frequent feedback on its 330 congestion state. This could be used by the control mechanisms in 331 the transport to make a more appropriate decision on how to react to 332 congestion, allowing it to react faster to changes in congestion 333 state. 335 Precise feedback about the number of packet marks encountered is 336 supported by the Real Time Protocol (RTP) when used over UDP 337 [RFC6679] and proposed for SCTP [ST14] and TCP [ID.Acc.ECN]. 339 Benefit has been noted when packets are CE-marked earlier using an 340 instantaneous queue, and if the receiver provides feedback about the 341 number of packet marks encountered, an improved sender behavior has 342 been shown to be possible (e.g, Datacenter TCP (DCTCP) [AL10]). 343 DCTCP is targeted at confined environments such as a datacenter. It 344 is currently unknown whether or how such behaviour could be safely 345 introduced into the Internet. 347 3. Network Support for ECN 349 For an application to use ECN requires that the endpoint first 350 enables ECN within the transport. 352 The ability to use ECN requires network devices along the path to at 353 least forward IP packets with any ECN codepoint (i.e., packets with 354 ECT(0), ECT(1), or with a CE-mark), see also Section 3.3. 356 For an application to gain benefit from using a transport that 357 enables ECN, network devices need to enable ECN. However, not all 358 network devices along the path need to enable ECN. Any network 359 device that does not CE-mark an ECN-enabled packet can be expected to 360 drop packets under congestion. Applications that experience 361 congestion in these network devices do not see any benefit from using 362 ECN, but would see benefit if the congestion were to occur within a 363 network device that did support ECN. 365 There is opportunity to design an AQM method for ECN that differs 366 from one designed to drop packets (e.g., Random Early Detection uses 367 a smoothed queue length because it was designed for loss and a 368 congestion control that halves its sending rate on congestion) 369 [ID.RFC2309.bis]. IETF-specified AQM algorithms also need to be 370 designed to work with network paths that may contain multiple 371 bottlenecks. Transports can therefore experience dropped or CE- 372 marked packets from more than one network device related to the same 373 network flow [ID.AQM.eval]. 375 ECN can be deployed both in the general Internet and in controlled 376 environments: 378 o ECN can be incrementally deployed in the general Internet. The 379 IETF has provided guidance on configuration and usage in 380 [ID.RFC2309.bis]. A recent survey reported a growing support for 381 network paths to pass ECN codepoints [TR15]. 383 o ECN may also be deployed within a controlled environment, for 384 example within a data centre or within a well-managed private 385 network. In this case, the use of ECN may be tuned to the 386 specific use-case. An example is Datacenter TCP (DCTCP) [AL10] 387 [ID.DCTCP]. 389 Some mechanisms can assist in using ECN across a path that only 390 partially supports ECN. These are noted in Section 4. Applications 391 and transports (such as TCP or SCTP) can be designed to fall-back to 392 not using ECN when they discover they are using a path that does not 393 allow use of ECN (e.g., a firewall or other network device configured 394 to drop the ECN codepoint) Section 4.2. 396 3.1. Enabling ECN in Network Devices 398 All network devices need to be configured not to drop packets solely 399 because the ECT(0) or ECT(1) codepoints are used. 401 The ECN behaviour of a network device should be configurable 402 [ID.RFC2309.bis]. An AQM algorithm that supports ECN needs to define 403 the threshold and algorithm for ECN-marking. 405 A network device must not set the CE-mark in a packet, except to 406 signal incipient congestion, since this will be interpreted as 407 incipient congestion by the transport endpoints. 409 3.2. Tunneling ECN and the use of ECN by Lower Layer Networks 411 Some networks may use ECN internally or tunnel ECN (e.g., for traffic 412 engineering or security). Guidance on the correct use of ECN in this 413 case is provided in [RFC6040]. 415 Further guidance on the encapsulation and use of ECN by non-IP 416 network devices is provided in [ID.ECN-Encap]. 418 3.3. Bleaching and Middlebox Requirements to deploy ECN 420 Cases have been noted where a sending endpoint marks a packet with a 421 non-zero ECN mark, but the packet is received with a zero ECN 422 codepoint by the remote endpoint [TR15]. This could be a result of a 423 policy that erases or "bleaches" the ECN codepoint values at a 424 network edge (resetting the codepoint to zero). 426 Bleaching may occur for various reasons (including normalising 427 packets to hide which equipment supports ECN). The current IPv4 and 428 IPv6 specifications assign usage of 2 bits in the IP header to carry 429 the ECN codepoint. This 2-bit field was reserved in [RFC2474] and 430 assigned in [RFC3168]. A previous usage assigned these bits as a 431 part of the now deprecated Type of Service (ToS) field [RFC1349]. A 432 network device that conforms to this older specification may remark 433 or erase the ECN codepoints, and such equipment needs to be updated 434 to the current specifications to support ECN. 436 This policy prevents use of ECN by applications. A network device 437 should therefore not remark an ECT(0) or ECT(1) mark to zero. This 438 can result in IP packets that were originally marked as ECN-capable 439 being dropped by ECN-capable network devices further along the path, 440 and eliminates the advantage of using of ECN. 442 A network device must not change a packet with a CE mark to a zero 443 codepoint (if the CE marking is not propagated, a CE-marked packet 444 must be discarded) [ID.RFC2309.bis]. A CE-marked packet should be 445 expected to have already received ECN treatment in the network, and 446 remarking it would then hide the congestion signal from the receiving 447 endpoint. This eliminates the benefits of ECN. It can also slow 448 down the response to congestion compared to using AQM, because the 449 transport will only react if it later discovers congestion by some 450 other mechanism. (Note that ECN-enabled network devices need to drop 451 excessive traffic [ID.RFC2309.bis], even when this is marked as ECN- 452 capable.) 454 3.4. Impact on non-ECN flows 456 A simple AQM scheme could place ECN-capable and non-ECN capable flows 457 withing the same queue. Since an ECN AQM scheme would normally CE- 458 mark packets during incipient congestion, these packets would not be 459 removed from a queue, in contrast to discarding the IP packet in a 460 drop-based AQM scheme. Design of an appropriate queue management 461 system needs to therefore consider when packets are dropped due to 462 incipient congestion, and seek to provide appropriate fairness 463 between ECN and non-ECN traffic, e.g. using more advanced AQM methods 464 or including flow isolation using scheduling [ID.RFC2309.bis]. 466 4. Using ECN across the Internet 468 This section describes partial deployment of ECN. 470 Early use of ECN by transports/applications encountered a number of 471 operational difficulties when the network path either failed to 472 transfer ECN-capable packets or the remote endpoint did not fully 473 support use of ECN. The remainder of the section describes transport 474 mechanisms that allow ECN-enabled endpoints to continue to work 475 effectively over a path with misbehaving network devices or to detect 476 and react to non-conformant paths. 478 4.1. Partial Deployment 480 ECN has been designed to allow incremental partial deployment 481 [RFC3168]. Any network device may choose to use either ECN or some 482 other loss-based policy to manage its traffic. Similarly, 483 negotiation allows senders and receivers at the transport layer to 484 choose whether ECN is to be used to manage congestion for a 485 particular network flow. 487 Usability problems were reported in early deployment of ECN and have 488 been observed to diminish with time, but may still be encountered on 489 some Internet paths [TR15]. 491 4.2. Verifying whether a Path Really Supports ECN 493 ECN transport and applications need to implement mechanisms to verify 494 ECN support on the entire path that they use (including the remote 495 endpoint) and fall back to not using ECN when it would not work. 496 This is expected to be a normal feature of IETF-defined transports 497 supporting ECN. 499 Before a transport relies on the presence or absence of CE-marked 500 packets, it may need to verify that any ECN marks applied to packets 501 passed by the path are indeed delivered to the remote endpoint. This 502 could be achieved by the sender setting known ECN codepoints into 503 specific packets in a network flow and then verifying that these 504 reach the remote endpoint [ID.Fallback], [TR15]. 506 The design of any transport/application also needs to be robust to 507 path changes. A change in the set of network devices along a path 508 could impact the ability to effectively signal or use ECN across the 509 path, e.g., when a path changes to use a middlebox that bleaches ECN 510 codepoints. As a necessary, but short term fix, transports could 511 implement mechanisms that detect this and fall-back to disabling use 512 of ECN [BA11]. 514 4.3. Detecting ECN Receiver Feedback Cheating 516 It is important that receiving endpoints accurately report the loss 517 they experience when using a transport that uses loss-based 518 congestion control. So also, when using ECN, a receiver must 519 correctly report the congestion marking that it receives by providing 520 a mechanism to feed this congestion information back to the sending 521 endpoint. 523 The transport at endpoint receivers must not try to conceal reception 524 of CE-marked packets in the ECN feedback information that they 525 provide to the sending endpoint [ID.RFC2309.bis]. Transport 526 protocols are actively encouraged to include mechanisms that can 527 detect and appropriately respond to such misbehavior (e.g., disabling 528 use of ECN, and relying on loss-based congestion detection [TR15]). 530 5. Summary: Enabling ECN in Network Devices and Hosts 532 This section provides a list of key requirements to achieve ECN 533 deployment. It also summarises the benefits of deploying and using 534 ECN within the Internet. 536 Network devices should enable ECN and people configuring host stacks 537 should also enable ECN [ID.RFC2309.bis]. 539 Prerequisites for network devices (including IP routers) to enable 540 use of ECN include: 542 o must not change a packet with a CE mark to a zero codepoint (if 543 the CE marking is not propagated, the packet must be discarded). 545 o should not reset the ECN codepoint to zero by default (see 546 Section 3.3). 548 o should correctly update the ECN codepoint in the presence of 549 congestion [ID.RFC2309.bis]. 551 o may support alternate ECN semantics [RFC4774]. 553 Prerequisites for network endpoints to enable use of ECN include: 555 o should use transports that can set and receive ECN marks. 557 o when ECN is used, must correctly return feedback indicating 558 congestion to the sending endpoint. 560 o when ECN is used, must use transports that react appropriately to 561 received ECN feedback (see Section 4.3). 563 o when ECN is used, should use transports that can detect misuse of 564 ECN and detect paths that bleach ECN, providing fallback to loss- 565 based congestion detection when ECN is not supported (see 566 Section 4.2). 568 Application developers should where possible use transports that 569 enable the benefits of ECN. Applications that directly use UDP need 570 to provide support to implement the functions required for ECN 571 [ID.RFC5405.bis]. Once enabled, an application that uses a transport 572 that supports ECN will experience the benefits of ECN as network 573 deployment starts to enable ECN. The application does not need to be 574 rewritten to gain these benefits. Table 1 summarises some of these 575 benefits. 577 +---------+-----------------------------------------------------+ 578 | Section | Benefit | 579 +---------+-----------------------------------------------------+ 580 | 2.1 | Improved throughput | 581 | 2.2 | Reduced Head-of-Line blocking | 582 | 2.3 | Reduced probability of RTO Expiry | 583 | 2.4 | Applications that do not retransmit lost packets | 584 | 2.5 | Making incipient congestion visible | 585 | 2.6 | Opportunities for new transport mechanisms | 586 +---------+-----------------------------------------------------+ 588 Table 1: Summary of Key Benefits 590 6. Acknowledgements 592 The authors were part-funded by the European Community under its 593 Seventh Framework Programme through the Reducing Internet Transport 594 Latency (RITE) project (ICT-317700). The views expressed are solely 595 those of the authors. 597 The authors would like to thank the following people for their 598 comments on prior versions of this document: Bob Briscoe, David 599 Collier-Brown, John Leslie, Colin Perkins, Richard Scheffenegger, 600 Dave Taht, Wes Eddy, Fred Baker, Mikael Abrahamsson, Mirja 601 Kuehlewind, John Leslie, and other members of the TSVWG. 603 7. IANA Considerations 605 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 607 This memo includes no request to IANA. 609 8. Security Considerations 611 This document introduces no new security considerations. Each RFC 612 listed in this document discusses the security considerations of the 613 specification it contains. 615 9. Revision Information 617 XXX RFC-Ed please remove this section prior to publication. 619 Revision 00 was the first WG draft. 621 Revision 01 includes updates to complete all the sections and a 622 rewrite to improve readability. Added section 2. Author list 623 reversed, since Gorry has become the lead author. Corrections 624 following feedback from Wes Eddy upon review of an interim version of 625 this draft. 627 Note: Wes Eddy raised a question about whether discussion of the ECN 628 Pitfalls could be improved or restructured - this is expected to be 629 addressed in the next revision. 631 Revision 02 updates the title, and also the description of mechanisms 632 that help with partial ECN support. 634 We think this draft is ready for wider review. Comments are welcome 635 to the authors or via the IETF AQM or TSVWG mailing lists. 637 Revision 03 includes updates from the mailing list and WG discussions 638 at the Dallas IETF meeting. 640 The section "Avoiding Capacity Overshoot" was removed, since this 641 refers primarily to an AQM benefit, and the additional benefits of 642 ECN are already stated. Separated normative and infoirmative 643 references 645 Revision 4 (WG Review during WGLC) 647 Updated the abstract. 649 Added a table of contents. 651 Addressed various (some conflicting) comments during WGLC with new 652 text. 654 The section on Network Support for ECN was moved, and some 655 suggestions for rewording sections were implemented. 657 Decided not to remove section headers for 2.1 and 2.2 - to ensure the 658 document clearly calls-out the benefits. 660 Updated references. Updated text to improve consistency of terms and 661 added deifinitions for key terms. 663 Note: The group suggested this document should not define 664 recommendations for end hosts or routers, but simply state the things 665 needs to enable deployment to be sucessful. 667 10. References 669 10.1. Normative References 671 [ID.RFC2309.bis] 672 Baker, F. and G. Fairhurst, "IETF Recommendations 673 Regarding Active Queue Management", Internet-draft draft- 674 ietf-aqm-recommendation-06, October 2014. 676 [ID.RFC5405.bis] 677 Eggert, Lars., Fairhurst, Gorry., and Greg. Shepherd, 678 "Unicast UDP Usage Guidelines", 2015. 680 [RFC2474] "Definition of the Differentiated Services Field (DS 681 Field) in the IPv4 and IPv6 Headers". 683 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 684 of Explicit Congestion Notification (ECN) to IP", RFC 685 3168, September 2001. 687 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 688 Notification", RFC 6040, November 2010. 690 10.2. Informative References 692 [AL10] Alizadeh, M., Greenberg, A., Maltz, D., Padhye, J., Patel, 693 P., Prabhakar, B., Sengupta, S., and M. Sridharan, "Data 694 Center TCP (DCTCP)", SIGCOMM 2010, August 2010. 696 [BA11] Bauer, Steven., Beverly, Robert., and Arthur. Berger, 697 "Measuring the State of ECN Readiness in Servers, Clients, 698 and Routers, ACM IMC", 2011. 700 [Fla13] Flach, Tobias., Dukkipati, Nandita., Terzis, Andreas., 701 Raghavan, Barath., Cardwell, Neal., Cheng, Yuchung., Jain, 702 Ankur., Hao, Shuai., Katz-Bassett, Ethan., and Ramesh. 703 Govindan, "Reducing web latency: the virtue of gentle 704 aggression.", SIGCOMM 2013, October 2013. 706 [ID.AQM.eval] 707 Kuhn, Nicolas., Natarajan, Preethi., Ros, David., and 708 Naeem. Khademi, "AQM Characterization Guidelines (Work-in- 709 progress, draft-ietf-aqm-eval-guidelines)", 2015. 711 [ID.Acc.ECN] 712 Briscoe, Bob., Scheffeneger, Richard., and Mirja. 713 Kuehlewind, "More Accurate ECN Feedback in TCP, Work-in- 714 Progress". 716 [ID.DCTCP] 717 Bensley, S., Eggert, Lars., and D. Thaler, "Microsoft's 718 Datacenter TCP (DCTCP): TCP Congestion Control for 719 Datacenters (Work-in-progress, draft-bensley-tcpm-dctcp)", 720 2015. 722 [ID.ECN-Encap] 723 Briscoe, B., Kaippallimalil, J., and P. Thaler, 724 "Guidelines for Adding Congestion Notification to 725 Protocols that Encapsulate IP", Internet-draft, IETF work- 726 in-progress draft-ietf-tsvwg-ecn-encap-guidelines. 728 [ID.Fallback] 729 Kuehlewind, Mirja. and Brian. Trammell, "A Mechanism for 730 ECN Path Probing and Fallback, draft-kuehlewind-tcpm-ecn- 731 fallback, Work-in-Progress". 733 [RFC0768] Postel, J., "User Datagram Protocol", 1980. 735 [RFC1349] "Type of Service in the Internet Protocol Suite". 737 [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", 738 RFC 3649, December 2003. 740 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 741 Conrad, "Stream Control Transmission Protocol (SCTP) 742 Partial Reliability Extension", RFC 3758, May 2004. 744 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 745 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 747 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 748 Explicit Congestion Notification (ECN) Field", BCP 124, 749 RFC 4774, November 2006. 751 [RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K. 752 Ramakrishnan, "Adding Explicit Congestion Notification 753 (ECN) Capability to TCP's SYN/ACK Packets", RFC 5562, June 754 2009. 756 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 757 Control", RFC 5681, September 2009. 759 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 760 and K. Carlberg, "Explicit Congestion Notification (ECN) 761 for RTP over UDP", RFC 6679, August 2012. 763 [RFC6789] Briscoe, B., Woundy, R., and A. Cooper, "Congestion 764 Exposure (ConEx) Concepts and Use Cases", RFC 6789, 765 December 2012. 767 [ST14] Stewart, R., Tuexen, M., and X. Dong, "ECN for Stream 768 Control Transmission Protocol (SCTP)", Internet-draft 769 draft-stewart-tsvwg-sctpecn-05.txt, January 2014. 771 [TR15] Tranmmel, Brian., Kuehlewind, Mirja., Boppart, Damiano, 772 Learmonth, Iain., and Gorry. Fairhurst, "Enabling 773 internet-wide deployment of Explicit Congestion 774 Notification Tramwell, B., Kuehlewind, M., Boppart, D., 775 Learmonth, I., Fairhurst, G. & Scheffnegger, Passive and 776 Active Measurement Conference (PAM)", March 2015. 778 Authors' Addresses 780 Godred Fairhurst 781 University of Aberdeen 782 School of Engineering, Fraser Noble Building 783 Aberdeen AB24 3UE 784 UK 786 Email: gorry@erg.abdn.ac.uk 788 Michael Welzl 789 University of Oslo 790 PO Box 1080 Blindern 791 Oslo N-0316 792 Norway 794 Phone: +47 22 85 24 20 795 Email: michawe@ifi.uio.no