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