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