idnits 2.17.1 draft-welzl-ecn-benefits-02.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 (March 09, 2015) is 3328 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2884' is defined on line 424, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-tcpm-accecn-reqs-04 -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) == Outdated reference: A later version (-06) exists of draft-stewart-tsvwg-sctpecn-05 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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: September 10, 2015 University of Aberdeen 6 March 09, 2015 8 The Benefits to Applications of using Explicit Congestion Notification 9 (ECN) 10 draft-welzl-ecn-benefits-02 12 Abstract 14 This document describes the potential benefits to applications when 15 they enable Explicit Congestion Notification (ECN). It outlines the 16 principal gains in terms of increased throughput, reduced delay and 17 other benefits when ECN is used over network paths that include 18 equipment that supports ECN-marking. The focus of this document is 19 on usage of ECN, not its implementation in hosts, routers and other 20 network devices. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 10, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 1. Introduction 56 Internet Transports (such as TCP and SCTP) have two ways to detect 57 congestion: the loss of a packet and, if Explicit Congestion 58 Notification (ECN) [RFC3168] is enabled, by reception of a packet 59 with a Congestion Experienced (CE)-marking in the IP header. Both of 60 these are treated by transports as indications of (potential) 61 congestion. ECN may also be enabled by other transports: UDP 62 applications may enable ECN when they are able to correctly process 63 the ECN signals [RFC5405] (e.g. ECN with RTP [RFC6679]). 65 A network device (router, middlebox, or other device that forward 66 packets through the network) that does not support AQM, typically 67 uses a drop-tail policy to discard excess IP packets when its queue 68 becomes full. The discard of this packet serves as a signal to the 69 end-to-end transport that there may be congestion on the network path 70 being used. This triggers a congestion control reaction to reduce 71 the maximum rate permitted by the sending endpoint. 73 When an application uses a transport that enables the use of ECN, the 74 transport layer sets the ECT(0) or ECT(1) codepoint in the IP header 75 of packets that it sends. This indicate to network devices that they 76 may mark, rather than drop, packets in periods of congestion. This 77 marking is generally performed by Active Queue Management (AQM) 78 [RFC2309.bis] and may be the result of various AQM algorithms, where 79 the exact combination of AQM/ECN algorithms is generally not known by 80 the transport endpoints. The focus of this document is on usage of 81 ECN, not its implementation in hosts, routers and other network 82 devices. 84 ECN makes it possible for the network to signal congestion without 85 packet loss. This lets the network deliver some packets to an 86 application that would otherwise have been dropped. This reduction 87 in packet loss is the most obvious benefit of ECN, but it is often 88 relatively modest. However, enabling ECN can also result in a number 89 of beneficial side-effects, some of which may be much more 90 significant than the immediate reduction in packet loss from ECN- 91 marking instead of dropping packets. 93 The remainder of this document discusses the potential for ECN to 94 positively benefit an application without making specific assumptions 95 about configuration or implementation. 97 [RFC3168] describes a method in which a router, sets the CE codepoint 98 of an ECN-Capable packet at the time that the network device would 99 otherwise have dropped the packet. While it has often been assumed 100 that network devices mark packets at the same level of congestion at 101 which they would otherwise have dropped them (e.g., when a queue 102 reaches an AQM threshold), separate configuration of the drop and 103 mark thresholds is known to be supported in some network devices and 104 this is recommended in [RFC2309.bis]. Some benefits of ECN that are 105 discussed rely upon routers marking packets at a lower level of 106 congestion before they would otherwise drop packets [KH13]. 108 Some benefits are also only realised when the transport endpoint 109 behaviour is also updated, this is discussed further in Section 5. 111 2. ECN Deployment 113 For an application to use ECN requires that the endpoint first 114 enables ECN within the transport. This requires network devices 115 along the path to at least pass IP packets that set ECN codepoints, 116 and do not drop packets because these codepoints are used. This is 117 the recommended behaviour for network devices [RFC2309.bis]. 118 Applications and transports (such as TCP or SCTP) can be designed to 119 fall-back to not using ECN when they discover they are using a path 120 that does not allow use of ECN (e.g., a firewall or other network 121 device configured to drop the ECN codepoint). 123 XXX NOTE: A future revision could include some words and reference a 124 paper on the current state of network support for transparently 125 passing the ECN codepoints. 127 For an application at an endpoint to gain benefit from ECN, network 128 devices need to enable ECN marking. Not all network devices along 129 the path need to enable ECN, for the application to benefit. Any 130 network devices that does not set a CE-codepoint can be expected to 131 drop packets under congestion. Applications that experience 132 congestion in such endpoints do not see any benefit from using ECN, 133 but would see benefit if the congestion were to occur within a 134 network device that did support ECN. 136 ECN can be incrementally deployed in the general Internet. The IETF 137 has provided guidance on configuration and usage in [RFC2309.bis]. 139 ECN may also be deployed within a controlled environment, for example 140 within a data centre or within a well-managed private network. In 141 this case, the use of ECN may be tuned to the specific use-case. An 142 example is Datacenter TCP (DCTCP) [AL10]. 144 Deployment needs also to consider the requirements for processing ECN 145 at tunnel endpoints of network tunnels, and guidance on the treatment 146 of ECN is provided in [RFC6040]. Further guidance on the 147 encapsulation and use of ECN by non-IP network devices is provided in 148 [ID.ECN-Encap]. 150 3. Benefit of using ECN to avoid congestion loss 152 When packet loss is a result of (mild) congestion, an ECN-enabled 153 router may CE-mark, rather than drop an ECN-enabled packet. An 154 application can benefit from this marking in several ways: 156 3.1. Improved Throughput 158 ECN can improve the throughput performance of an application, 159 although this increase in throughput offered by ECN is often not the 160 most significant gain. 162 When an application uses a light to moderately loaded network path, 163 the number of packets that are dropped due to congestion is small. 164 Using an example from Table 1 of [RFC3649], for a standard TCP sender 165 with a Round Trip Time, RTT, of 0.1 seconds, a packet size of 1500 166 bytes and an average throughput of 1 Mbps, the average packet drop 167 ratio is 0.02. This translates into an approximate 2% throughput 168 gain if ECN is enabled. In heavy congestion, packet loss may be 169 unavoidable with, or without, ECN [RFC2309.bis]. 171 3.2. Reduced Head-of-Line Blocking 173 Many transports provide in-order delivery of received data segments 174 to the applications they support. This requires that the transport 175 stalls (or waits) for all data that was sent ahead of a particular 176 segment to be correctly received before it can forward any later 177 data. This is the usual requirement for TCP and SCTP. PR-SCTP 178 [RFC3758], UDP, and DCCP [RFC4340] provide a transport that does not 179 have this requirement. 181 Delaying data to provide in-order transmission to an application 182 results in latency when segments are dropped as indications of 183 congestion. The congestive loss creates a delay of at least one RTT 184 for a loss event before data can be delivered to an application. We 185 call this Head-of-Line (HOL) blocking. 187 In contrast, using ECN can remove the resulting delay following a 188 loss that is a result of congestion: 190 o First, the application receives the data normally - this also 191 avoids dropping data that has already made it across the network 192 path. It avoids the additional delay of waiting for recovery of 193 the lost segment when using a reliable transport. 195 o Second, the transport receiver notes that it has received CE- 196 marked packets, and then requests the sender to make an 197 appropriate congestion-response to reduce the maximum transmission 198 rate for future traffic. 200 3.3. Reduced Probability of RTO Expiry 202 In some situations, ECN can help reduce the chance of a 203 retransmission timer expiring (e.g., expiry of the TCP or SCTP 204 retransmission timeout, RTO [RFC5681]). When an application sends a 205 burst of segments and then becomes idle (either because the 206 application has no further data to send or the network prevents 207 sending further data - e.g., flow or congestion control at the 208 transport layer), the last segment of the burst may be lost. It is 209 often not possible to recover this last segment (or last few 210 segments) using standard methods such as Fast Recovery [RFC5681], 211 since the receiver generates no feedback because it is unaware that 212 the lost segments were actually sent. 214 In addition to avoiding HOL blocking, this allows the transport to 215 avoid the consequent loss of state about the network path it is 216 using, which would have arisen had there been a retransmission 217 timeout. Typical impacts of a transport timeout are to reset path 218 estimates such as the RTT, the congestion window, and possibly other 219 transport state that can reduce the performance of the transport 220 until it again adapts to the path. 222 Avoiding timeouts can hence improve the throughput of the 223 application. This benefits applications that send intermittent 224 bursts of data, and rely upon timer-based recovery of packet loss. 225 It can be especially significant when ECN is used on TCP SYN/ACK 226 packets as specified in [RFC5562] where the RTO interval may be large 227 because in this case TCP cannot base the timeout period on prior RTT 228 measurements from the same connection. 230 3.4. Applications that do not retransmit lost packets 232 Some latency-critical applications use transports that do not 233 retransmit lost packets, yet these applications may be able to adjust 234 the sending rate in the presence of congestion. Examples of such 235 applications include UDP-based services that carry Voice over IP 236 (VoIP), interactive video, or real-time data. The performance of 237 many such applications degrades rapidly with increasing packet loss, 238 and many therefore employ loss-hiding mechanisms (e.g., packet 239 forward error correction, or data duplication) to mitigate the effect 240 of congestion loss on the application. However, such mechanisms add 241 complexity and can themselves consume additional network capacity 242 reducing the capacity for application data and contributing to the 243 path latency when congestion is experienced. 245 By decoupling congestion control from loss, ECN can allow the 246 transports supporting these applications to reduce their rate before 247 the application experiences loss from congestion, especially when the 248 congestion is mild and the application/transport can react promptly 249 to reception of a CE-marked packet. Because this reduces the 250 negative impact of using loss-hiding mechanisms, ECN can have a 251 direct positive impact on the quality experienced by the users of 252 these applications. 254 4. Benefit from Early Congestion Detection 256 An application can further benefit from using ECN, when the network 257 devices are configured such that they mark packets at a lower level 258 of congestion before they would otherwise have dropped packets from 259 queue overflow: 261 4.1. Avoiding Capacity Overshoot 263 Internet transports do not know apriori how much capacity exists 264 along a network path. Transports therefore try to measure the 265 capacity available to an application by probing the network path with 266 increasing traffic to the point where they detect the onset of 267 congestion (such as TCP or SCTP Slow Start). 269 ECN can help capacity probing algorithms from significantly exceeding 270 the bottleneck capacity of a network path. Since a transport that 271 enables ECN can receive congestion signals before there is 272 significant congestion, an early-marking method in network devices 273 can help a transport respond before it induces significant congestion 274 with resultant loss to itself or other applications sharing a common 275 bottleneck. For example, an application/transport can avoid 276 incurring significant congestion during Slow Start, or a bulk 277 application that tries to increase its rate as fast as possible, may 278 quickly detect the presence of congestion, causing it to promptly 279 reduce its rate. 281 Use of ECN is more effective than transport mechanisms such as 282 Limited Slow-Start [RFC3742] because it provides direct information 283 about the state of the network path. An ECN-enabled application/ 284 transport that probes for capacity can reduce its rate as soon as it 285 discovers CE-marked packets are received, and before the applications 286 increases its rate to the point where it builds a queue in a network 287 device that induces congestion loss. This benefits an application 288 seeking to increase its rate - but perhaps more significantly, it 289 eliminates the often unwanted loss and queueing delay that otherwise 290 may be inflicted on flows that share a common bottleneck. 292 4.2. Making Congestion Visible 294 A characteristic of using ECN is that it exposes the presence of 295 congestion on a network path to the transport and network layers. 296 This information could be used for monitoring the performance of the 297 path, and could be used to directly meter the amount of congestion 298 that has been encountered upstream on a path; metering packet loss is 299 harder. This is used by Congestion Exposure (CoNex) [RFC6789]. 301 A network flow that only experiences CE-marks and no loss implies 302 that the sending endpoint is experiencing only congestion and not 303 other sources of packet loss (e.g., link corruption or loss in 304 middleboxes). The converse is not true - a flow may experience a 305 mixture of ECN-marks and loss when there is only congestion or when 306 there is a combination of packet loss and congestion [RFC2309.bis]. 307 Recording the presence of CE-marked packets can therefore provide 308 information about the performance of the network path. 310 5. Other forms of ECN-Marking/Reactions 312 The ECN mechanism defines both how packets are CE-marked and how 313 transports need to react to reception of marked packets. This 314 section describes the benefits when updated methods are used. 316 Benefit has been noted when packets are CE-marked earlier than they 317 would otherwise be dropped, using an instantaneous queue, and if the 318 receiver provides precise feedback about the number of packet marks 319 encountered, a better sender behavior is possible. This has been 320 shown by Datacenter TCP (DCTCP) [AL10]. 322 Precise feedback about the number of packet marks encountered is 323 supported by RTP over UDP [RFC6679] and proposed for SCTP [ST14] and 324 TCP [KU13]. An underlying assumption of DCTCP is that it is deployed 325 in confined environments such as a datacenter. It is currently 326 unknown whether or how such behaviour could be introduced into the 327 Internet. 329 6. Conclusion 331 Network devices should enable ECN and people configuring host stacks 332 should also enable ECN. These are pre-requisites to allow 333 applications to gain the benefits of ECN. 335 Application developers should where possible use transports that 336 enable the benefits of ECN. Applications that directly use UDP need 337 to provide support to implement the functions required for ECN. Once 338 enabled, an application that uses a transport that supports ECN will 339 experience the benefits of ECN as network deployment starts to enable 340 ECN. The application does not need to be rewritten to gain these 341 benefits. 343 Table 1 summarizes some of these benefits. 345 +---------+-----------------------------------------------------+ 346 | Section | Benefit | 347 +---------+-----------------------------------------------------+ 348 | 2.1 | Improved Throughput | 349 | 2.2 | Reduced Head-of-Line | 350 | 2.3 | Reduced Probability of RTO Expiry | 351 | 2.4 | Applications that do not retransmit lost packets | 352 | 3.1 | Avoiding Capacity Overshoot | 353 | 3.2 | Making Congestion Visible | 354 +---------+-----------------------------------------------------+ 356 Table 1: Summary of Key Benefits from using ECN 358 7. Acknowledgements 360 The authors were part-funded by the European Community under its 361 Seventh Framework Programme through the Reducing Internet Transport 362 Latency (RITE) project (ICT-317700). The views expressed are solely 363 those of the authors. 365 8. IANA Considerations 367 XXRFC ED - PLEASE REMOVE THIS SECTION XXX 369 This memo includes no request to IANA. 371 9. Security Considerations 373 This document introduces no new security considerations. Each RFC 374 listed in this document discusses the security considerations of the 375 specification it contains. 377 10. Revision Information 379 RFC-Ed please remove this section prior to publication. 381 Revision 00 was the first WG draft. 383 Revision 01 includes updates to complete sections and improve 384 readability. Added section 2. 386 Comments are welcome to the authors or via the IETF AQM or TSVWG 387 mailing lists. 389 11. References 391 11.1. Normative References 393 [RFC2309.bis] 394 Baker, F. and G. Fairhurst, "IETF Recommendations 395 Regarding Active Queue Management", Internet-draft draft- 396 ietf-aqm-recommendation-06, October 2014. 398 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 399 of Explicit Congestion Notification (ECN) to IP", RFC 400 3168, September 2001. 402 11.2. Informative References 404 [AL10] Alizadeh, M., Greenberg, A., Maltz, D., Padhye, J., Patel, 405 P., Prabhakar, B., Sengupta, S., and M. Sridharan, "Data 406 Center TCP (DCTCP)", SIGCOMM 2010, August 2010. 408 [ID.ECN-Encap] 409 Briscoe, B., Kaippallimalil, J., and P. Thaler, 410 "Guidelines for Adding Congestion Notification to 411 Protocols that Encapsulate IP , IETF work-in-progress: 412 draft-ietf-tsvwg-ecn-encap-guidelines", . 414 [KH13] Khademi, N., Ros, D., and M. Welzl, "The New AQM Kids on 415 the Block: Much Ado About Nothing?", University of Oslo 416 Department of Informatics technical report 434, October 417 2013. 419 [KU13] Kuehlewind, M. and R. Scheffenegger, "Problem Statement 420 and Requirements for a More Accurate ECN Feedback", 421 Internet-draft draft-ietf-tcpm-accecn-reqs-04.txt, October 422 2013. 424 [RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of 425 Explicit Congestion Notification (ECN) in IP Networks", 426 RFC 2884, July 2000. 428 [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", 429 RFC 3649, December 2003. 431 [RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large 432 Congestion Windows", RFC 3742, March 2004. 434 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 435 Conrad, "Stream Control Transmission Protocol (SCTP) 436 Partial Reliability Extension", RFC 3758, May 2004. 438 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 439 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 441 [RFC5405] Eggert, Lars. and Gorry. Fairhurst, "Unicast UDP Usage 442 Guidelines for Application Designers", November 2008. 444 [RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K. 445 Ramakrishnan, "Adding Explicit Congestion Notification 446 (ECN) Capability to TCP's SYN/ACK Packets", RFC 5562, June 447 2009. 449 [RFC5681] "TCP Congestion Control", . 451 [RFC6040] "Tunnelling of Explicit Congestion Notification", . 453 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 454 and K. Carlberg, "Explicit Congestion Notification (ECN) 455 for RTP over UDP", RFC 6679, August 2012. 457 [RFC6789] Briscoe, B., Woundy, R., and A. Cooper, "Congestion 458 Exposure (ConEx) Concepts and Use Cases", RFC 6789, 459 December 2012. 461 [ST14] Stewart, R., Tuexen, M., and X. Dong, "ECN for Stream 462 Control Transmission Protocol (SCTP)", Internet-draft 463 draft-stewart-tsvwg-sctpecn-05.txt, January 2014. 465 Authors' Addresses 467 Michael Welzl 468 University of Oslo 469 PO Box 1080 Blindern 470 Oslo N-0316 471 Norway 473 Phone: +47 22 85 24 20 474 Email: michawe@ifi.uio.no 475 Godred Fairhurst 476 University of Aberdeen 477 School of Engineering, Fraser Noble Building 478 Aberdeen AB24 3UE 479 UK 481 Email: gorry@erg.abdn.ac.uk