idnits 2.17.1 draft-ietf-aqm-ecn-benefits-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 309: '... MUST not change a packet with a CE ...' RFC 2119 keyword, line 310: '...ated, the packet MUST be discarded), a...' RFC 2119 keyword, line 311: '... SHOULD NOT remark an ECT(0) or ECT(...' RFC 2119 keyword, line 315: '...dpoint receivers MUST NOT try to conce...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The recommendation of this document is that a router or middlebox MUST not change a packet with a CE mark to a zero codepoint (if the CE marking is not propagated, the packet MUST be discarded), and SHOULD NOT remark an ECT(0) or ECT(1) mark to zero. -- The document date (October 24, 2014) is 3471 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-tcpm-accecn-reqs-04 == Outdated reference: A later version (-07) exists of draft-stewart-tsvwg-sctpecn-05 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Welzl 3 Internet-Draft University of Oslo 4 Intended status: Informational G. Fairhurst 5 Expires: April 27, 2015 University of Aberdeen 6 October 24, 2014 8 The Benefits and Pitfalls of using Explicit Congestion Notification 9 (ECN) 10 draft-ietf-aqm-ecn-benefits-00 12 Abstract 14 This document describes the potential benefits and pitfalls when 15 applications enable Explicit Congestion Notification (ECN). It 16 outlines the principal gains in terms of increased throughput, 17 reduced delay and other benefits when ECN is used over network paths 18 that include equipment that supports ECN-marking. It also lists 19 potential problems that might occur when ECN is used. The document 20 does not propose new algorithms that may be able to use ECN or 21 describe the details of implementation of ECN in endpoint devices, 22 routers and other network 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 April 27, 2015. 41 Copyright Notice 43 Copyright (c) 2014 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 1. Introduction 58 Internet Transports (such as TCP and SCTP) have two ways to detect 59 congestion: the loss of a packet and, if Explicit Congestion 60 Notification (ECN) [RFC3168] is enabled, by reception of a packet 61 with a Congestion Experienced (CE)-marking in the IP header. Both of 62 these are treated by transports as indications of (potential) 63 congestion. ECN may also be enabled by other transports. UDP 64 applications may enable ECN when they are able to correctly process 65 the ECN signals (e.g. ECN with RTP [RFC6679]). 67 When an application enables the use of ECN, the transport layer sets 68 the ECT(0) or ECT(1) codepoint in the IP header of packets that it 69 sends to indicate to routers that they may mark, rather than drop, 70 packets in periods of congestion. This marking is generally 71 performed by Active Queue Management (AQM) [RFC2309.bis] and may be 72 the result of various AQM algorithms, where the exact combination of 73 AQM/ECN algorithms is generally not known by the transport endpoints. 75 ECN makes it possible for the network to signal congestion without 76 packet loss. This lets the network deliver some packets to an 77 application that would otherwise have been dropped. This packet loss 78 reduction is the most obvious benefit of ECN, but it is often 79 relatively modest. However, enabling ECN can also result in a number 80 of beneficial side-effects, some of which may be much more 81 significant than the immediate packet loss reduction from ECN-marking 82 instead of dropping packets. Several of these benefits have to do 83 with reducing latency in some way (e.g. reduced Head-of-Line Blocking 84 and potentially smaller queuing delay, depending on the marking rules 85 in routers). There are also some potential pitfalls when enabling 86 ECN. 88 The focus of this document is on usage of ECN, not its implementation 89 in endpoint devices, routers and other network devices. [RFC3168] 90 describes a method in which a router sets the CE codepoint of an ECN- 91 Capable packet at the time that the router would otherwise have 92 dropped the packet. 94 While it has often been assumed that routers mark packets at the same 95 level of congestion at which they would otherwise drop them, separate 96 configuration of the drop and mark thresholds is known to be 97 supported in some network devices and this is recommended in 98 [RFC2309.bis]. Some benefits of ECN that are discussed rely upon 99 routers marking packets at a lower level of congestion before they 100 would otherwise drop packets from queue overflow [KH13]. 102 Some of benefits are also only realised when the transport endpoint 103 behaviour is also updated, this is discussed further in Section 5. 105 The remainder of this document discusses the potential for ECN to 106 positively benefit an application without making specific assumptions 107 about configuration or implementation. 109 2. ECN Deployment Scenarios / Use Cases 111 XXX to be continued -- this section is intended to describe some 112 specific example cases of where ECN has provided benefit XXX 114 2.1. ECN within data centers 116 ECN with a low marking threshold has been proposed for use within a 117 data centre environment. This proposed usage exploits ECN in 118 combination with an updated transport behaviour, Datacenter TCP 119 (DCTCP) [AL10]. 121 3. Benefit of using ECN to avoid congestion loss 123 An application that uses a transport that supports ECN can benefit in 124 several ways: 126 3.1. Improved Throughput 128 ECN can improve the throughput performance of applications, although 129 this increase in throughput offered by ECN is often not the most 130 significant gain. 132 When an application uses a light to moderately loaded network path, 133 the number of packets that are dropped due to congestion is small. 134 Using an example from Table 1 of [RFC3649], for a standard TCP sender 135 with a Round Trip Time, RTT, of 0.1 seconds, a packet size of 1500 136 bytes and an average throughput of 1 Mbps, the average packet drop 137 ratio is 0.02. This translates into an approximate 2% throughput 138 gain if ECN is enabled. In heavy congestion, packet loss may be 139 unavoidable with, or without, ECN. 141 3.2. Reduced Head-of-Line Blocking 143 Many transports provide in-order delivery of received data to the 144 applications they support. This requires that the transport stalls 145 (or waits) for all data that was sent ahead of a particular segment 146 to be correctly received before it can forward any later data. This 147 is the usual requirement for TCP and SCTP. PR-SCTP [RFC3758], UDP, 148 and DCCP [RFC4340] provide a transport that does not have this 149 requirement. 151 Delaying data to provide in-order transmission to an application 152 results in latency when segments are dropped as indications of 153 congestion. The congestive loss creates a delay of at least one RTT 154 for a loss event before data can be delivered to an application. We 155 call this Head-of-Line (HOL) blocking. 157 In contrast, using ECN can remove the resulting delay for a loss that 158 is a result of congestion: 160 o First, the application receives the data normally - this also 161 avoids dropping data that has already made it across at least part 162 of the network path. This avoids the additional delay of waiting 163 for recovery of the lost segment. 165 o Second, the transport receiver notes the ECN-marked packets, and 166 then requests the sender to make an appropriate congestion- 167 response for future traffic. 169 3.3. Reduced Probability of RTO Expiry 171 ECN can help reduce the chance of the TCP or SCTP retransmission 172 timer expiring (RTO expiry). When an application sends a burst of 173 segments and then becomes idle (either because the application has no 174 further data to send or the network prevents sending further data - 175 e.g. flow or congestion control at the transport layer), the last 176 segment of the burst may be lost. It is often not possible to 177 recover the last segment (or last few segments) using standard 178 methods such as Fast Recovery, since the receiver is unaware that the 179 lost segments were actually sent. 181 ECN provides a mitigation when the loss is a result of (mild) 182 congestion, since a router may mark, rather than drop, these segments 183 - which benefits the application in a way similar to above, but with 184 the significant additional benefit that this eliminates a 185 retransmission event. The application benefits because: 187 o Data is received without HOL blocking. 189 o The transport does not suffer RTO expiry with consequent loss of 190 state about the network path it is using. This would cause it to 191 reset path estimates such as the RTT, the congestion window, and 192 possibly other transport state that can reduce the performance of 193 the transport until it adapts to the path again. This can improve 194 the throughput of the application. 196 The benefit of avoiding reliance on an RTO-based retransmission event 197 can be especially significant when ECN is used on TCP SYN/ACK packets 198 as specified in [RFC5562] because in this case TCP cannot base its 199 RTO for these packets on prior RTT measurements from the same 200 connection. 202 3.4. Applications that do not retransmit lost packets 204 Certain latency-critical applications do not retransmit lost packets, 205 yet they may be able to adjust the sending rate in the presence of 206 congestion. Examples of such applications include UDP-based services 207 that carry Voice over IP (VoIP), interactive video or real-time data. 208 By decoupling congestion control from loss, ECN can allow such 209 applications to reduce their rate before experiencing significant 210 loss. It also enables them to decide how to discard data in a 211 controlled manner, rather than forcing them to recover from loss. 212 This reduces the negative impact of having to rely on loss-hiding 213 mechanisms (e.g. Packet forward error correction, or data 214 duplication), yielding a direct positive impact on the quality 215 experienced by the users of these applications. 217 4. Benefit from Early Congestion Detection 219 If ECN is configured such that routers mark packets at a lower level 220 of congestion before they would otherwise drop packets from queue 221 overflow, an application can benefit from using ECN in the following 222 ways: 224 4.1. Avoiding Capacity Overshoot 226 ECN can help capacity probing algorithms (such as Slow Start) from 227 significantly exceeding the bottleneck capacity of a network path. 228 Since a transport that enables ECN can receive congestion signals 229 before there is serious congestion, an early-marking method can help 230 a transport respond before it induces significant congestion. For 231 example, a TCP or SCTP sender can avoid incurring significant 232 congestion during Slow Start, or a bulk application that tries to 233 increase its rate as fast as possible, may detect the presence of 234 congestion, causing it to reduce its rate. 236 Use of ECN is more effective than schemes such as Limited Slow-Start 237 [RFC3742] because it provides direct information about the state of 238 the network path. An ECN-enabled application probing for bandwidth 239 can reduce its rate as soon as ECN-marked packets are detected, and 240 before the applications increases its rate to the point where it 241 builds a router queue that induces congestion loss. This benefits 242 the application seeking to increase its rate - but perhaps more 243 significantly, it eliminates the often unwanted loss and queueing 244 delay that otherwise may be inflicted on flows that share a common 245 bottleneck. 247 4.2. Making Congestion Visible 249 A characteristic of using ECN is that it exposes the presence of 250 congestion on a network path to the transport and network layers. 251 This information could be used for monitoring performance of the 252 path, and could be used to directly meter the amount of congestion 253 that has been encountered upstream on a path; metering packet loss is 254 harder. This is used by Congestion Exposure (CoNex) [RFC6789]. 256 Note: traffic that observes only congestion marks and no loss implies 257 that a sender is experiencing only congestion and not other sources 258 of packet loss (e.g. link corruption or loss in middleboxes). The 259 converse is not true - a mixture of ECN-marks and loss may occur 260 during only congestion or from a combination of packet loss and 261 congestion. 263 5. Other forms of ECN-Marking/Reactions 265 The ECN mechanism defines both how packets are marked and transports 266 need to react to markings. This section describes the benefits when 267 updated methods are used. 269 Benefit has been noted when packets are marked earlier than they 270 would otherwise be dropped, using an instantaneous queue, and if the 271 receiver provides precise feedback about the number of packet marks 272 encountered, a better sender behavior is possible. This has been 273 shown by Datacenter TCP (DCTCP) [AL10]. 275 Precise feedback about the number of packet marks encountered is 276 supported by RTP over UDP [RFC6679] and proposed for SCTP [ST14] and 277 TCP [KU13]. An underlying assumption of DCTCP is that it is deployed 278 in confined environments such as a datacenter. It is currently 279 unknown whether or how such behaviour could be safely introduced into 280 the Internet. 282 6. Pitfalls when using ECN 284 This section describes issues with ECN. 286 6.1. Bleaching and middlebox requirements to deploy 288 Cases have been noted where a sending endpoint marks a packet with a 289 non-zero ECN mark, but the packet is received with a zero ECN value 290 by the remote endpoint. 292 The current IPv4 and IPv6 specifications assign usage of 2 bits in 293 the IP header to carry the ECN codepoint. A previous usage assigned 294 these bits as a part of the now deprecated Type of Service (ToS) 295 field. Equipment conformant with this older specification may remark 296 or erase the ECN codepoints, such equipment needs to be updated to 297 the current specifications to support ECN. 299 Another policy may erase or "bleach" the ECN marks at a network edge 300 (resetting these to zero) for various reasons (including normalising 301 packets to hide which equipment support ECN). This policy prevents 302 use of ECN. 304 Some networks may use ECN internally or tunnel ECN fro traffic 305 engineering or security. Guidance on the correct use of ECN in this 306 case is provided in [RFC6040]. 308 The recommendation of this document is that a router or middlebox 309 MUST not change a packet with a CE mark to a zero codepoint (if the 310 CE marking is not propagated, the packet MUST be discarded), and 311 SHOULD NOT remark an ECT(0) or ECT(1) mark to zero. 313 6.2. Cheating 315 Endpoint receivers MUST NOT try to conceal reception of CE marks in 316 the ECN feedback information they provide to the sending endpoint. 317 Transport protocols are actively encouraged to include mechanisms 318 that can detect and appropriately respond to such misbehavior. 320 6.3. The possible need to verify if a path really supports ECN 322 Endpoints need to be robust to path changes that may impact the 323 ability to effectively signal or use ECN across a path, e.g. when a 324 path changes to use a middlebox that bleaches ECN codepoints. As a 325 necessary but short term fix, such mechanisms could fall-back to 326 disabling use of ECN. 328 7. Conclusion 330 People configuring host stacks and network devices should ensure that 331 their equipment correctly reacts to packets carrying ECN codepoints. 332 This includes: 334 o routers not resetting the ECN codepoint to zero by default 336 o routers correctly updating the codepoint in the presence of 337 congestion 339 o routers correctly supporting alternate ECN semantics ([RFC4774]) 341 o hosts receiving ECN marks correctly reflecting them 343 Application developers should where possible use transports that 344 enable the benefits of ECN. Once enabled, the benefits of ECN are 345 provided by the transport layer and the application does not need to 346 be rewritten to gain these benefits. Table 1 summarises some of 347 these benefits. 348 +---------+-----------------------------------------------------+ 349 | Section | Benefit | 350 +---------+-----------------------------------------------------+ 351 | 2.1 | Improved Throughput | 352 | 2.2 | Reduced Head-of-Line | 353 | 2.3 | Reduced Probability of RTO Expiry | 354 | 2.4 | Applications that do not retransmit lost packets | 355 | 3.1 | Avoiding Capacity Overshoot | 356 | 3.2 | Making Congestion Visible | 357 +---------+-----------------------------------------------------+ 359 Table 1: Summary of Key Benefits 361 8. Acknowledgements 363 The authors were part-funded by the European Community under its 364 Seventh Framework Programme through the Reducing Internet Transport 365 Latency (RITE) project (ICT-317700). The views expressed are solely 366 those of the authors. 368 The authors would like to thank the following people for their 369 comments on prior versions of this document: Bob Briscoe, David 370 Collier-Brown, John Leslie, Colin Perkins, Richard Scheffenegger, 371 Dave Taht 373 9. IANA Considerations 375 XXRFC ED - PLEASE REMOVE THIS SECTION XXX 377 This memo includes no request to IANA. 379 10. Security Considerations 381 This document introduces no new security considerations. Each RFC 382 listed in this document discusses the security considerations of the 383 specification it contains. 385 11. References 387 11.1. Normative References 389 [RFC2309.bis] 390 Baker, F. and G. Fairhurst, "IETF Recommendations 391 Regarding Active Queue Management", 392 draft-ietf-aqm-recommendation-06 (work in progress), 393 October 2014. 395 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 396 of Explicit Congestion Notification (ECN) to IP", 397 RFC 3168, September 2001. 399 11.2. Informative References 401 [AL10] Alizadeh, M., Greenberg, A., Maltz, D., Padhye, J., Patel, 402 P., Prabhakar, B., Sengupta, S., and M. Sridharan, "Data 403 Center TCP (DCTCP)", SIGCOMM 2010, August 2010. 405 [KH13] Khademi, N., Ros, D., and M. Welzl, "The New AQM Kids on 406 the Block: Much Ado About Nothing?", University of Oslo 407 Department of Informatics technical report 434, 408 October 2013. 410 [KU13] Kuehlewind, M. and R. Scheffenegger, "Problem Statement 411 and Requirements for a More Accurate ECN Feedback", 412 draft-ietf-tcpm-accecn-reqs-04.txt (work in progress), 413 October 2013. 415 [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", 416 RFC 3649, December 2003. 418 [RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large 419 Congestion Windows", RFC 3742, March 2004. 421 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 422 Conrad, "Stream Control Transmission Protocol (SCTP) 423 Partial Reliability Extension", RFC 3758, May 2004. 425 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 426 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 428 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 429 Explicit Congestion Notification (ECN) Field", BCP 124, 430 RFC 4774, November 2006. 432 [RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K. 433 Ramakrishnan, "Adding Explicit Congestion Notification 434 (ECN) Capability to TCP's SYN/ACK Packets", RFC 5562, 435 June 2009. 437 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 438 Notification", RFC 6040, November 2010. 440 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 441 and K. Carlberg, "Explicit Congestion Notification (ECN) 442 for RTP over UDP", RFC 6679, August 2012. 444 [RFC6789] Briscoe, B., Woundy, R., and A. Cooper, "Congestion 445 Exposure (ConEx) Concepts and Use Cases", RFC 6789, 446 December 2012. 448 [ST14] Stewart, R., Tuexen, M., and X. Dong, "ECN for Stream 449 Control Transmission Protocol (SCTP)", 450 draft-stewart-tsvwg-sctpecn-05.txt (work in progress), 451 January 2014. 453 Authors' Addresses 455 Michael Welzl 456 University of Oslo 457 PO Box 1080 Blindern 458 Oslo, N-0316 459 Norway 461 Phone: +47 22 85 24 20 462 Email: michawe@ifi.uio.no 463 Godred Fairhurst 464 University of Aberdeen 465 School of Engineering, Fraser Noble Building 466 Aberdeen, AB24 3UE 467 UK 469 Phone: 470 Email: gorry@erg.abdn.ac.uk