idnits 2.17.1 draft-ietf-aqm-ecn-benefits-01.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 22, 2015) is 3317 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 1349 (Obsoleted by RFC 2474) == Outdated reference: A later version (-06) exists of draft-stewart-tsvwg-sctpecn-05 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Fairhurst 3 Internet-Draft University of Aberdeen 4 Intended status: Informational M. Welzl 5 Expires: September 23, 2015 University of Oslo 6 March 22, 2015 8 The Benefits and Pitfalls of using Explicit Congestion Notification 9 (ECN) 10 draft-ietf-aqm-ecn-benefits-01 12 Abstract 14 XXX Author Note: The WG are being asked to consider changing this 15 title - see list XXX 17 This document describes the potential benefits and pitfalls when 18 applications enable Explicit Congestion Notification (ECN). It 19 outlines the principal gains in terms of increased throughput, 20 reduced delay and other benefits when ECN is used over network paths 21 that include equipment that supports ECN-marking. It also lists 22 potential problems that might occur when ECN is used. The document 23 does not propose new algorithms that may be able to use ECN or 24 describe the details of implementation of ECN in endpoint devices, 25 routers and other network devices. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 23, 2015. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 1. Introduction 61 Internet Transports (such as TCP and SCTP) have two ways to detect 62 congestion: the loss of a packet and, if Explicit Congestion 63 Notification (ECN) [RFC3168] is enabled, by reception of a packet 64 with a Congestion Experienced (CE)-marking in the IP header. Both of 65 these are treated by transports as indications of (potential) 66 congestion. ECN may also be enabled by other transports: UDP 67 applications may enable ECN when they are able to correctly process 68 the ECN signals (e.g. ECN with RTP [RFC6679]). 70 A network device (router, middlebox, or other device that forwards 71 packets through the network) that does not support AQM, typically 72 uses a drop-tail policy to discard excess IP packets when its queue 73 becomes full. The discard of packets serves as a signal to the end- 74 to-end transport that there may be congestion on the network path 75 being used. This triggers a congestion control reaction to reduce 76 the maximum rate permitted by the sending endpoint. 78 When an application uses a transport that enables the use of ECN, the 79 transport layer sets the ECT(0) or ECT(1) codepoint in the IP header 80 of packets that it sends. This indicates to network devices that 81 they may mark, rather than drop, packets in periods of congestion. 82 This marking is generally performed by Active Queue Management (AQM) 83 [RFC2309.bis] and may be the result of various AQM algorithms, where 84 the exact combination of AQM/ECN algorithms does not need to be known 85 by the transport endpoints. The focus of this document is on usage 86 of ECN by transport and application layer flows, not its 87 implementation in hosts, routers and other network devices. 89 ECN makes it possible for the network to signal the presence of 90 congestion without incurring packet loss. This lets the network 91 deliver some packets to an application that would otherwise have been 92 dropped if the application or transport did not support ECN. This 93 packet loss reduction is the most obvious benefit of ECN, but it is 94 often relatively modest. However, enabling ECN can also result in a 95 number of beneficial side-effects, some of which may be much more 96 significant than the immediate packet loss reduction from ECN-marking 97 instead of dropping packets. Several of these benefits have to do 98 with reducing latency in some way (e.g., reduced Head-of-Line 99 Blocking and potentially smaller queuing delay, depending on the 100 marking rules in routers). There are also some potential pitfalls 101 when enabling ECN. 103 The remainder of this document discusses the potential for ECN to 104 positively benefit an application without making specific assumptions 105 about configuration or implementation. 107 [RFC3168] describes a method in which a network device sets the CE 108 codepoint of an ECN-Capable packet at the time that the router would 109 otherwise have dropped the packet. While it has often been assumed 110 that network devices should CE-mark packets at the same level of 111 congestion at which they would otherwise have dropped them, separate 112 configuration of the drop and mark thresholds is known to be 113 supported in some network devices and this is recommended 114 [RFC2309.bis]. Some benefits of ECN that are discussed rely upon 115 network devices marking packets at a lower level of congestion, 116 before they would otherwise drop packets from queue overflow [KH13]. 118 The ability to use ECN relies upon using a transport that can support 119 ECN. Some benefits are also only realised when the transport 120 endpoint behaviour is also updated, this is discussed further in 121 Section 5. 123 2. ECN Deployment 125 For an application to use ECN requires that the endpoint first 126 enables ECN within the transport. 128 The ability to use ECN requires network devices along the path to at 129 least pass IP packets that set ECN codepoints, and do not drop 130 packets because these codepoints are used Section 6.1. This is the 131 recommended behaviour for network devices [RFC2309.bis] [RFC3168]. 132 Applications and transports (such as TCP or SCTP) can be designed to 133 fall-back to not using ECN when they discover they are using a path 134 that does not allow use of ECN (e.g., a firewall or other network 135 device configured to drop the ECN codepoint) Section 6.2. 137 For an application at an endpoint to gain benefit from ECN, network 138 devices need to enable ECN marking. However, not all network devices 139 along the path need to enable ECN, for the application to benefit. 140 Any network device that does not mark an ECN-enabled packet with a 141 CE-codepoint can be expected to drop packets under congestion. 142 Applications that experience congestion in these network devices do 143 not see any benefit from using ECN, but would see benefit if the 144 congestion were to occur within a network device that did support 145 ECN. 147 ECN can be deployed in the general Internet and in controlled 148 environments: 150 o ECN can be incrementally deployed in the general Internet. The 151 IETF has provided guidance on configuration and usage in 152 [RFC2309.bis]. A recent survey reported growing support for ECN 153 on common network paths [TR15]. 155 o ECN may also be deployed within a controlled environment, for 156 example within a data centre or within a well-managed private 157 network. In this case, the use of ECN may be tuned to the 158 specific use-case. An example is Datacenter TCP (DCTCP) [AL10]. 160 Network deployment needs also to consider the requirements for 161 processing ECN at tunnel endpoints of network tunnels, and guidance 162 on the treatment of ECN is provided in [RFC6040]. Further guidance 163 on the encapsulation and use of ECN by non-IP network devices is 164 provided in [ID.ECN-Encap]. 166 Some pitfalls in deploying ECN are noted in Section 6. 168 3. Benefit of using ECN to avoid congestion loss 170 When packet loss is a result of (mild) congestion, an ECN-enabled 171 router may be expected to CE-mark, rather than drop an ECN-enabled 172 packet [RFC2309.bis]. An application can benefit from this marking 173 in several ways: 175 3.1. Improved Throughput 177 ECN can improve the throughput performance of applications, although 178 this increase in throughput offered by ECN is often not the most 179 significant gain. 181 When an application uses a light to moderately loaded network path, 182 the number of packets that are dropped due to congestion is small. 183 Using an example from Table 1 of [RFC3649], for a standard TCP sender 184 with a Round Trip Time, RTT, of 0.1 seconds, a packet size of 1500 185 bytes and an average throughput of 1 Mbps, the average packet drop 186 ratio is 0.02. This translates into an approximate 2% throughput 187 gain if ECN is enabled. In heavy congestion, packet loss may be 188 unavoidable with, or without, ECN. 190 3.2. Reduced Head-of-Line Blocking 192 Many transports provide in-order delivery of received data segments 193 to the applications they support. This requires that the transport 194 stalls (or waits) for all data that was sent ahead of a particular 195 segment to be correctly received before it can forward any later 196 data. This is the usual requirement for TCP and SCTP. PR-SCTP 197 [RFC3758], UDP, and DCCP [RFC4340] provide a transport that does not 198 have this requirement. 200 Delaying data to provide in-order transmission to an application 201 results in additional latency when segments are dropped as 202 indications of congestion. The congestive loss creates a delay of at 203 least one RTT for a loss event before data can be delivered to an 204 application. We call this Head-of-Line (HOL) blocking. 206 In contrast, using ECN can remove the resulting delay following a 207 loss that is a result of congestion: 209 o First, the application receives the data normally. This also 210 avoids the inefficiency of dropping data that has already made it 211 across at least part of the network path. It also avoids the 212 additional delay of waiting for recovery of the lost segment. 214 o Second, the transport receiver notes that it has received CE- 215 marked packets, and then requests the sender to make an 216 appropriate congestion-response to reduce the maximum transmission 217 rate for future traffic. 219 3.3. Reduced Probability of RTO Expiry 221 In some situations, ECN can help reduce the chance of a 222 retransmission timer expiring (e.g., expiry of the TCP or SCTP 223 retransmission timeout, RTO [RFC5681]. When an application sends a 224 burst of segments and then becomes idle (either because the 225 application has no further data to send or the network prevents 226 sending further data - e.g., flow or congestion control at the 227 transport layer), the last segment of the burst may be lost. It is 228 often not possible to recover this last segment (or last few 229 segments) using standard methods such as Fast Recovery [RFC5681], 230 since the receiver generates no feedback because it is unaware that 231 the lost segments were actually sent. 233 In addition to avoiding HOL blocking, this allows the transport to 234 avoid the consequent loss of state about the network path it is 235 using, which would have arisen had there been a retransmission 236 timeout. Typical impacts of a transport timeout are to reset path 237 estimates such as the RTT, the congestion window, and possibly other 238 transport state that can reduce the performance of the transport 239 until it again adapts to the path. 241 Avoiding timeouts can hence improve the throughput of the 242 application. This benefits applications that send intermittent 243 bursts of data, and rely upon timer-based recovery of packet loss. 244 It can be especially significant when ECN is used on TCP SYN/ACK 245 packets [RFC5562] where the RTO interval may be large because in this 246 case TCP cannot base the timeout period on prior RTT measurements 247 from the same connection. 249 3.4. Applications that do not retransmit lost packets 251 Some latency-critical applications do not retransmit lost packets, 252 yet they may be able to adjust the sending rate in the presence of 253 congestion. Examples of such applications include UDP-based services 254 that carry Voice over IP (VoIP), interactive video or real-time data. 255 The performance of many such applications degrades rapidly with 256 increasing packet loss, and many therefore employ loss-hiding 257 mechanisms (e.g., packet forward error correction, or data 258 duplication) to mitigate the effect of congestion loss on the 259 application. However, such mechanisms add complexity and can 260 themselves consume additional network capacity reducing the capacity 261 for application data and contributing to the path latency when 262 congestion is experienced. 264 By decoupling congestion control from loss, ECN can allow the 265 transports supporting these applications to reduce their rate before 266 the application experiences loss from congestion, especially when the 267 congestion is mild and the application/transport can react promptly 268 to reception of a CE-marked packet. Because this reduces the 269 negative impact of using loss-hiding mechanisms, ECN can have a 270 direct positive impact on the quality experienced by the users of 271 these applications. 273 4. Benefit from Early Congestion Detection 275 An application can further benefit from using ECN, when the network 276 devices are configured such that they mark packets at a lower level 277 of congestion before they would otherwise have dropped packets from 278 queue overflow: 280 4.1. Avoiding Capacity Overshoot 282 Internet transports do not know apriori how much capacity exists 283 along a network path. Transports therefore try to measure the 284 capacity available to an application by probing the network path with 285 increasing traffic to the point where they detect the onset of 286 congestion (such as TCP or SCTP Slow Start). 288 ECN can help capacity probing algorithms (such as Slow Start) from 289 significantly exceeding the bottleneck capacity of a network path. 290 Since a transport that enables ECN can receive congestion signals 291 before there is significant congestion, an early-marking method in 292 network devices can help a transport respond before it induces 293 significant congestion with resultant loss to itself or other 294 applications sharing a common bottleneck. For example, an 295 application/transport can avoid incurring significant congestion 296 during Slow Start, or a bulk application that tries to increase its 297 rate as fast as possible, may quickly detect the presence of 298 congestion, causing it to promptly reduce its rate. 300 Use of ECN is more effective than schemes such as Limited Slow-Start 301 [RFC3742] because it provides direct information about the state of 302 the network path. An ECN-enabled application/transport that probes 303 for capacity can reduce its rate as soon as it discovers CE-marked 304 packets are received, and before the applications increases its rate 305 to the point where it builds a queue in a network device that induces 306 congestion loss. This benefits an application seeking to increase 307 its rate - but perhaps more significantly, it eliminates the often 308 unwanted loss and queueing delay that otherwise may be inflicted on 309 flows that share a common bottleneck. 311 4.2. Making Congestion Visible 313 A characteristic of using ECN is that it exposes the presence of 314 congestion on a network path to the transport and network layers. 315 This information can be used for monitoring performance of the path, 316 and could be used to directly meter the amount of congestion that has 317 been encountered upstream on a path; metering packet loss is harder. 318 ECN measurements are used by Congestion Exposure (CoNex) [RFC6789]. 320 A network flow that only experiences CE-marks and no loss implies 321 that the sending endpoint is experiencing only congestion and not 322 other sources of packet loss (e.g., link corruption or loss in 323 middleboxes). The converse is not true - a flow may experience a 324 mixture of ECN-marks and loss when there is only congestion or when 325 there is a combination of packet loss and congestion [RFC2309.bis]. 326 Recording the presence of CE-marked packets can therefore provide 327 information about the performance of the network path. 329 5. Other forms of ECN-Marking/Reactions 331 ECN requires a definition of both how packets are CE-marked and how 332 applications/transports need to react to reception of CE-marked 333 packets. This section describes the benefits when updated methods 334 are used. 336 Benefit has been noted when packets are CE-marked earlier than they 337 would otherwise be dropped, using an instantaneous queue, and if the 338 receiver provides precise feedback about the number of packet marks 339 encountered, a better sender behavior is possible. This has been 340 shown by Datacenter TCP (DCTCP) [AL10]. 342 Precise feedback about the number of packet marks encountered is 343 supported by the Real Time Protocol (RTP) when used over UDP 344 [RFC6679] and proposed for SCTP [ST14] and TCP [ID.Acc-ECN]. An 345 underlying assumption of DCTCP is that it is deployed in confined 346 environments such as a datacenter. It is currently unknown whether 347 or how such behaviour could be safely introduced into the Internet. 349 6. Pitfalls when using ECN 351 Early deployment of ECN encountered a number of operationl 352 difficulties when the network deonly partially supports the use of 353 ECN, or to respond to the challenges due to misbehaving network 354 devices and/or endpoints. These problems have been observed to 355 diminish with time, but may still be encountered on some Internet 356 paths [TR15]. 358 This section describes transport mechanisms that allow ECN-enabled 359 endpoints to continue to work effectively over a path with partial 360 ECN support. 362 6.1. Bleaching and middlebox requirements to deploy ECN 364 Cases have been noted where a sending endpoint marks a packet with a 365 non-zero ECN mark, but the packet is received with a zero ECN value 366 by the remote endpoint. 368 The current IPv4 and IPv6 specifications assign usage of 2 bits in 369 the IP header to carry the ECN codepoint[RFC2474] [RFC3168]. A 370 previous usage assigned these bits as a part of the now deprecated 371 Type of Service (ToS) field [RFC1349]. Network devices that conform 372 to this older specification may still remark or erase the ECN 373 codepoints, such equipment needs to be updated to the current 374 specifications to support ECN . 376 Some network devices have been observed to implement a policy that 377 erases or "bleaches" the ECN marks at a network edge (resetting these 378 to zero). This may be implemented for various reasons (including 379 normalising packets to hide which equipment supports ECN). This 380 policy prevents use of ECN by applications. A network device should 381 therefore not remark an ECT(0) or ECT(1) mark to zero. 383 A network device must not change a packet with a CE mark to a zero 384 codepoint (if the CE marking is not propagated, the packet must be 385 discarded). Such a packet has already received ECN treatment in the 386 network, and remarking it would then hide the congestion signal from 387 the endpoints. 389 Some networks may use ECN internally or tunnel ECN for traffic 390 engineering or security. Guidance on the correct use of ECN in this 391 case is provided in [RFC6040]. 393 6.2. Verifying whether a path really supports ECN 395 ECN transport and applications need to implement a mechanisms to 396 verify ECN support on the path that they use. This is expected to be 397 a normal feature of IETF-defined transports supporting ECN. 399 Before a transport relies on the presence or absence of CE-marked 400 packets, it may need to verify that any ECN marks applied to packets 401 passed by the path are indeed delivered to the remote endpoint. This 402 may be achieved by the sender setting known ECN codepoints into 403 specific packets in a network flow and then verifying that these 404 reach the remote endpoint. Such methods typically rely on Accurate 405 ECN Feedback [ID.Acc-ECN], [TR15]. 407 Endpoints also need to be robust to path changes. A change in the 408 set of network devices along a path may impact the ability to 409 effectively signal or use ECN across the path, e.g., when a path 410 changes to use a middlebox that bleaches ECN codepoints. As a 411 necessary, but short term fix, transports could implement mechanisms 412 that detect this and fall-back to disabling use of ECN [BA11]. 414 6.3. Detecting ECN receiver feedback cheating 416 It is important that receiving endpoints accurately report the loss 417 they experience when using a transport that uses loss-based 418 congestion control. So also, when using ECN. a receiver must 419 correctly report the congestion marking that it receives and then 420 provide a mechanism to feed the congestion information back to the 421 sending endpoint. 423 The transport at endpoint receivers must not try to conceal reception 424 of CE-marked packets in the ECN feedback information that they 425 provide to the sending endpoint [RFC2309.bis]. Transport protocols 426 are actively encouraged to include mechanisms that can detect and 427 appropriately respond to such misbehavior (e.g., disabling use of 428 ECN, and relying on loss-based congestion detection [TR15]). 430 7. Conclusion 432 Network devices should enable ECN and people configuring host stacks 433 should also enable ECN. These are prerequisites to allow 434 applications to gain the benefits of ECN. 436 Prerequisites for network devices (including IP routers) to enable 437 use of ECN include: 439 o should not reset the ECN codepoint to zero by default Section 6.1. 441 o should correctly update the ECN codepoint in the presence of 442 congestion. 444 o should correctly support alternate ECN semantics ([RFC4774]). 446 Prerequisites for network endpoints to enable use of ECN include: 448 o should use transports that can set and receive ECN marks. 450 o should correctly return feedback of congestion to the sending 451 endpoint. 453 o must use transports that react appropriately to received ECN 454 feedback Section 6.3. 456 o should use transports that can detect misuse of ECN and detect 457 paths that do not support ECN, providing fallback to loss-based 458 congestion detection when ECN is not supported Section 6.2. 460 Application developers should where possible use transports that 461 enable the benefits of ECN. Applications that directly use UDP need 462 to provide support to implement the functions required for ECN. Once 463 enabled, an application that uses a transport that supports ECN will 464 experience the benefits of ECN as network deployment starts to enable 465 ECN. The application does not need to be rewritten to gain these 466 benefits. Table 1 summarises some of these benefits. 468 +---------+-----------------------------------------------------+ 469 | Section | Benefit | 470 +---------+-----------------------------------------------------+ 471 | 2.1 | Improved Throughput | 472 | 2.2 | Reduced Head-of-Line | 473 | 2.3 | Reduced Probability of RTO Expiry | 474 | 2.4 | Applications that do not retransmit lost packets | 475 | 3.1 | Avoiding Capacity Overshoot | 476 | 3.2 | Making Congestion Visible | 477 +---------+-----------------------------------------------------+ 479 Table 1: Summary of Key Benefits 481 8. Acknowledgements 483 The authors were part-funded by the European Community under its 484 Seventh Framework Programme through the Reducing Internet Transport 485 Latency (RITE) project (ICT-317700). The views expressed are solely 486 those of the authors. 488 The authors would like to thank the following people for their 489 comments on prior versions of this document: Bob Briscoe, David 490 Collier-Brown, John Leslie, Colin Perkins, Richard Scheffenegger, 491 Dave Taht 493 9. IANA Considerations 495 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 497 This memo includes no request to IANA. 499 10. Security Considerations 501 This document introduces no new security considerations. Each RFC 502 listed in this document discusses the security considerations of the 503 specification it contains. 505 11. Revision Information 507 XXX RFC-Ed please remove this section prior to publication. 509 Revision 00 was the first WG draft. 511 Revision 01 includes updates to complete all the sections and a 512 rewrite to improve readability. Added section 2. Author list 513 reversed, since Gorry has become the lead author. Corrections 514 following feedback from Wes Eddy upon review of an interim version of 515 this draft. 517 Note: Wes Eddy raised a question about whether discussion of the ECN 518 Pitfalls could be improved or restrcutured - this is expected to be 519 addressed in the next revision. 521 We think this draft is ready for wider review. Comments are welcome 522 to the authors or via the IETF AQM or TSVWG mailing lists. 524 12. References 526 12.1. Normative References 528 [RFC2309.bis] 529 Baker, F. and G. Fairhurst, "IETF Recommendations 530 Regarding Active Queue Management", Internet-draft draft- 531 ietf-aqm-recommendation-06, October 2014. 533 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 534 of Explicit Congestion Notification (ECN) to IP", RFC 535 3168, September 2001. 537 12.2. Informative References 539 [AL10] Alizadeh, M., Greenberg, A., Maltz, D., Padhye, J., Patel, 540 P., Prabhakar, B., Sengupta, S., and M. Sridharan, "Data 541 Center TCP (DCTCP)", SIGCOMM 2010, August 2010. 543 [BA11] Bauer, Steven., Beverly, Robert., and Arthur. Berger, 544 "Measuring the State of ECN Readiness in Servers, Clients, 545 and Routers, ACM IMC", 2011. 547 [ID.Acc-ECN] 548 Kuehlewind, Mirja., Scheffenegger, Richard., and Bob. 549 Briscoe, "Problem Statement and Requirements for a More 550 Accurate ECN Feedback", Internet-draft, IETF work-in- 551 progress draft-ietf-tcpm-accecn-reqs, 2015. 553 [ID.ECN-Encap] 554 Briscoe, B., Kaippallimalil, J., and P. Thaler, 555 "Guidelines for Adding Congestion Notification to 556 Protocols that Encapsulate IP", Internet-draft, IETF work- 557 in-progress draft-ietf-tsvwg-ecn-encap-guidelines, . 559 [KH13] Khademi, N., Ros, D., and M. Welzl, "The New AQM Kids on 560 the Block: Much Ado About Nothing?", University of Oslo 561 Department of Informatics technical report 434, October 562 2013. 564 [RFC1349] "Type of Service in the Internet Protocol Suite", . 566 [RFC2474] "Definition of the Differentiated Services Field (DS 567 Field) in the IPv4 and IPv6 Headers", . 569 [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", 570 RFC 3649, December 2003. 572 [RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large 573 Congestion Windows", RFC 3742, March 2004. 575 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 576 Conrad, "Stream Control Transmission Protocol (SCTP) 577 Partial Reliability Extension", RFC 3758, May 2004. 579 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 580 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 582 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 583 Explicit Congestion Notification (ECN) Field", BCP 124, 584 RFC 4774, November 2006. 586 [RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K. 587 Ramakrishnan, "Adding Explicit Congestion Notification 588 (ECN) Capability to TCP's SYN/ACK Packets", RFC 5562, June 589 2009. 591 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 592 Control", RFC 5681, September 2009. 594 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 595 Notification", RFC 6040, November 2010. 597 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 598 and K. Carlberg, "Explicit Congestion Notification (ECN) 599 for RTP over UDP", RFC 6679, August 2012. 601 [RFC6789] Briscoe, B., Woundy, R., and A. Cooper, "Congestion 602 Exposure (ConEx) Concepts and Use Cases", RFC 6789, 603 December 2012. 605 [ST14] Stewart, R., Tuexen, M., and X. Dong, "ECN for Stream 606 Control Transmission Protocol (SCTP)", Internet-draft 607 draft-stewart-tsvwg-sctpecn-05.txt, January 2014. 609 [TR15] Tranmmel, Brian., Kuehlewind, Mirja., Boppart, Damiano, 610 Learmonth, Iain., and Gorry. Fairhurst, "Enabling 611 internet-wide deployment of Explicit Congestion 612 Notification Tramwell, B., Kuehlewind, M., Boppart, D., 613 Learmonth, I., Fairhurst, G. & Scheffnegger, Passive and 614 Active Measurement Conference (PAM)", March 2015. 616 Authors' Addresses 618 Godred Fairhurst 619 University of Aberdeen 620 School of Engineering, Fraser Noble Building 621 Aberdeen AB24 3UE 622 UK 624 Email: gorry@erg.abdn.ac.uk 626 Michael Welzl 627 University of Oslo 628 PO Box 1080 Blindern 629 Oslo N-0316 630 Norway 632 Phone: +47 22 85 24 20 633 Email: michawe@ifi.uio.no