--- 1/draft-ietf-tcpm-ecnsyn-07.txt 2009-04-02 20:12:10.000000000 +0200 +++ 2/draft-ietf-tcpm-ecnsyn-08.txt 2009-04-02 20:12:10.000000000 +0200 @@ -1,112 +1,148 @@ Internet Engineering Task Force A. Kuzmanovic INTERNET-DRAFT A. Mondal -Intended status: Proposed Standard Northwestern University -Expires: 3 May 2009 S. Floyd -Updates: 3168 ICIR +Intended status: Experimental Northwestern University +Expires: 2 October 2009 S. Floyd + ICSI K.K. Ramakrishnan AT&T - 3 November 2008 - Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets - draft-ietf-tcpm-ecnsyn-07.txt + draft-ietf-tcpm-ecnsyn-08.txt Status of this Memo - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and BCP 79. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on May 2009. + This Internet-Draft will expire on 2 October 2009. Copyright Notice - Copyright (C) The IETF Trust (2008). + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. Abstract - This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK - packets to be ECN-Capable. For TCP, RFC 3168 only specifies setting - an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK - packets. However, because of the high cost to the TCP transfer of - having a SYN/ACK packet dropped, with the resulting retransmit - timeout, this document specifies the use of ECN for the SYN/ACK - packet itself, when sent in response to a SYN packet with the two ECN - flags set in the TCP header, indicating a willingness to use ECN. - Setting the initial TCP SYN/ACK packet as ECN-Capable can be of great - benefit to the TCP connection, avoiding the severe penalty of a - retransmit timeout for a connection that has not yet started placing - a load on the network. The TCP responder (the sender of the SYN/ACK - packet) must reply to a report of an ECN-marked SYN/ACK packet by - resending a SYN/ACK packet that is not ECN-Capable. If the resent - SYN/ACK packet is acknowledged, then the TCP responder reduces its - initial congestion window from two, three, or four segments to one - segment, thereby reducing the subsequent load from that connection on - the network. If instead the SYN/ACK packet is dropped, or for some - other reason the TCP responder does not receive an acknowledgement in - the specified time, the TCP responder follows TCP standards for a - dropped SYN/ACK packet (setting the retransmit timer). This document - updates RFC 3168. + The proposal in this document is experimental. While it may be + deployed in the current Internet, it does not represent a consensus + that this is the best possible mechanism for the use of ECN in TCP + SYN/ACK packets. + + This draft describes an optional, experimental modification to RFC + 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC + 3168 only specifies setting an ECN-Capable codepoint on data packets, + and not on SYN and SYN/ACK packets. However, because of the high + cost to the TCP transfer of having a SYN/ACK packet dropped, with the + resulting retransmit timeout, this document describes the use of ECN + for the SYN/ACK packet itself, when sent in response to a SYN packet + with the two ECN flags set in the TCP header, indicating a + willingness to use ECN. Setting the initial TCP SYN/ACK packet as + ECN-Capable can be of great benefit to the TCP connection, avoiding + the severe penalty of a retransmit timeout for a connection that has + not yet started placing a load on the network. The TCP responder + (the sender of the SYN/ACK packet) must reply to a report of an ECN- + marked SYN/ACK packet by resending a SYN/ACK packet that is not ECN- + Capable. If the resent SYN/ACK packet is acknowledged, then the TCP + responder reduces its initial congestion window from two, three, or + four segments to one segment, thereby reducing the subsequent load + from that connection on the network. If instead the SYN/ACK packet + is dropped, or for some other reason the TCP responder does not + receive an acknowledgement in the specified time, the TCP responder + follows TCP standards for a dropped SYN/ACK packet (setting the + retransmit timer). Table of Contents - 1. Introduction ....................................................5 + 1. Introduction ....................................................6 2. Conventions and Terminology .....................................7 - 3. Specification ...................................................7 + 3. Specification ...................................................8 3.1. SYN/ACK Packets Dropped in the Network .....................8 3.2. SYN/ACK Packets ECN-Marked in the Network ..................9 - 3.3. Management Interface ......................................11 - 4. Discussion .....................................................12 - 4.1. Flooding Attacks ..........................................12 - 4.2. The TCP SYN Packet ........................................12 - 4.3. SYN/ACK Packets and Packet Size ...........................13 - 4.4. Response to ECN-marking of SYN/ACK Packets ................13 - 5. Related Work ...................................................15 - 6. Performance Evaluation .........................................16 - 6.1. The Costs and Benefit of Adding ECN-Capability ............16 + 3.3. Management Interface ......................................12 + 4. Discussion .....................................................13 + 4.1. Flooding Attacks ..........................................13 + 4.2. The TCP SYN Packet ........................................13 + 4.3. SYN/ACK Packets and Packet Size ...........................14 + 4.4. Response to ECN-marking of SYN/ACK Packets ................14 + 5. Related Work ...................................................16 + 6. Performance Evaluation .........................................17 + 6.1. The Costs and Benefit of Adding ECN-Capability ............17 6.2. An Evaluation of Different Responses to ECN-Marked SYN/ACK - Packets ........................................................17 - 7. Security Considerations ........................................18 - 7.1. 'Bad' Routers or Middleboxes ..............................18 - 7.2. Congestion Collapse .......................................19 - 8. Conclusions ....................................................19 - 9. Acknowledgements ...............................................20 - A. Report on Simulations ..........................................20 - A.1. Simulations with RED in Packet Mode .......................21 - A.2. Simulations with RED in Byte Mode .........................25 - B. Issues of Incremental Deployment ...............................27 - Normative References ..............................................30 - Informative References ............................................30 - IANA Considerations ...............................................31 - Full Copyright Statement ..........................................32 - Intellectual Property .............................................32 + Packets ........................................................18 + 7. Security Considerations ........................................19 + 7.1. 'Bad' Routers or Middleboxes ..............................19 + 7.2. Congestion Collapse .......................................20 + 8. Conclusions ....................................................20 + 9. Acknowledgements ...............................................21 + A. Report on Simulations ..........................................21 + A.1. Simulations with RED in Packet Mode .......................22 + A.2. Simulations with RED in Byte Mode .........................26 + B. Issues of Incremental Deployment ...............................28 + Informative References ............................................31 + IANA Considerations ...............................................32 NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION. + Changes from draft-ietf-tcpm-ecnsyn-07: + + * Updated boilerplates. + + * Changed proposed status from "Proposed Standard" to "Experimental", + and modified text in the Introduction to match. The added text + in the introduction is based on similar text in the Introduction of + RFC 3649. + + * Specified that with ECN+/TryOnce, the originator resets the + retransmit timer when it receives an ECN-marked SYN/ACK. + Also reran simulations for ECN+/TryOnce, and updated + Tables 1-6. + + * Specified that the originator follows the traditional rules in + setting the cumulative ack field for the ACK acking the SYN/ACK. + + * Minor editing. + Changes from draft-ietf-tcpm-ecnsyn-06: * Updated text and simulation results to specify ECN+/TryOnce instead of ECN+. Added tables on CDFs. * Acknowledged Adam's Linux implementation of ECN+/TryOnce. Changes from draft-ietf-tcpm-ecnsyn-05: * Added "Updates: 3168" to the header. Added a reference @@ -260,42 +296,39 @@ specifies the negotiation of the use of ECN between the two TCP end- points in the TCP SYN and SYN-ACK exchange, using flags in the TCP header. Erring on the side of being conservative, RFC 3168 does not specify the use of ECN for the first SYN/ACK packet itself. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmit timeout, this document specifies the use of ECN for the SYN/ACK packet itself. This can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmit timeout for a connection that has not yet started placing a load on the network. The sender of the SYN/ACK packet must - respond to a report of an ECN-marked SYN/ACK packet by sending a non- - ECN-Capable SYN/ACK packet, and by reducing its initial congestion - window from two, three, or four segments to one segment, reducing the - subsequent load from that connection on the network. + respond to a report of an ECN-marked SYN/ACK packet (a router with + the CE codepoint set in the ECN field in the IP header) by sending a + non-ECN-Capable SYN/ACK packet, and by reducing its initial + congestion window from two, three, or four segments to one segment, + reducing the subsequent load from that connection on the network. The use of ECN for SYN/ACK packets has the following potential benefits: 1) Avoidance of a retransmit timeout; 2) Improvement in the throughput of short connections. This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. Section 3 contains the specification of the change, while Section 4 discusses some of the issues, and Section 5 discusses related work. Section 6 contains an evaluation of the specified change. 2. Conventions and Terminology - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC 2119]. - We use the following terminology from RFC 3168: The ECN field in the IP header: o CE: the Congestion Experienced codepoint; and o ECT: either one of the two ECN-Capable Transport codepoints. The ECN flags in the TCP header: o CWR: the Congestion Window Reduced flag; and o ECE: the ECN-Echo flag. @@ -307,21 +340,21 @@ refer to the sender of the SYN packet and of the SYN-ACK packet, respectively. 3. Specification This section specifies the modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. RFC 3168 in Section 6.1.1. states that "A host MUST NOT set ECT on SYN or SYN-ACK packets." In this section, we specify that a TCP node - MAY respond to an initial ECN-setup SYN packet by setting ECT in the + may respond to an initial ECN-setup SYN packet by setting ECT in the responding ECN-setup SYN/ACK packet, indicating to routers that the SYN/ACK packet is ECN-Capable. This allows a congested router along the path to mark the packet instead of dropping the packet as an indication of congestion. Assume that TCP node A transmits to TCP node B an ECN-setup SYN packet, indicating willingness to use ECN for this connection. As specified by RFC 3168, if TCP node B is willing to use ECN, node B responds with an ECN-setup SYN-ACK packet. @@ -350,21 +383,21 @@ Data/ACK ---> Data/ACK ---> <--- Data (one to four segments) --------------------------------------------------------------- Figure 1: SYN exchange with the SYN/ACK packet dropped. If the SYN/ACK packet is dropped in the network, the responder (node B) responds by waiting three seconds for the retransmit timer to expire [RFC2988]. If a SYN/ACK packet with the ECT codepoint is - dropped, the responder SHOULD resend the SYN/ACK packet without the + dropped, the responder should resend the SYN/ACK packet without the ECN-Capable codepoint. (Although we are not aware of any middleboxes that drop SYN/ACK packets that contain an ECN-Capable codepoint in the IP header, we have learned to design our protocols defensively in this regard [RFC3360].) We note that if syn-cookies were used by the responder (node B) in the exchange in Figure 1, the responder wouldn't set a timer upon transmission of the SYN/ACK packet [SYN-COOK] [RFC4987]. In this case, if the SYN/ACK packet was lost, the initiator (Node A) would have to timeout and retransmit the SYN packet in order to trigger @@ -372,22 +405,22 @@ 3.2. SYN/ACK Packets ECN-Marked in the Network Figure 2 shows an interchange with the SYN/ACK packet sent as ECN- Capable, and ECN-marked instead of dropped at the congested router. This document specifies ECN+/TryOnce, which differs from the original proposal for ECN+ in [ECN+]; with ECN+/TryOnce, if the TCP responder is informed that the SYN/ACK was ECN-marked, the TCP responder immediately sends a SYN/ACK packet that is not ECN-Capable. The TCP responder is only allowed to send data packets after the TCP - initiator reports the receipt of a SYN/ACK packet that is neither - marked nor dropped. + initiator reports the receipt of a SYN/ACK packet that is not ECN- + marked. --------------------------------------------------------------- TCP Node A Router TCP Node B (initiator) (responder) ---------- ------ ---------- ECN-setup SYN packet ---> ECN-setup SYN packet ---> <--- ECN-setup SYN/ACK, ECT @@ -403,57 +436,57 @@ Data/ACK ---> Data/ACK ---> <--- Data (one segment only) --------------------------------------------------------------- Figure 2: SYN exchange with the SYN/ACK packet marked. ECN+/TryOnce. If the initiator (node A) receives a SYN/ACK packet that has been - marked by the congested router, with the CE codepoint set, the - initiator MUST respond by setting the ECN-Echo flag in the TCP header - of the responding ACK packet. However, with ECN+/TryOnce the - initiator does not advance from the "SYN-Sent" to the "SYN-Received" - state until it receives a SYN/ACK packet that is not ECN-marked. As - specified in RFC 3168, the initiator continues to set the ECN-Echo - flag in packets until it receives a packet with the CWR flag set. + ECN-marked by the congested router, with the CE codepoint set, the + initiator resets the retransmit timer. The initiator responds to the + ECN-marked SYN/ACK packet by setting the ECN-Echo flag in the TCP + header of the responding ACK packet. The initiator uses the standard + rules in setting the cumulative acknowledgement field in the + responding ACK packet. + + However, with ECN+/TryOnce the initiator does not advance from the + "SYN-Sent" to the "SYN-Received" state until it receives a SYN/ACK + packet that is not ECN-marked. As specified in RFC 3168, the + initiator continues to set the ECN-Echo flag in packets until it + receives a packet with the CWR flag set. When the responder (node B) receives the ECN-Echo packet reporting the Congestion Experienced indication in the SYN/ACK packet, the - responder MUST set the initial congestion window to one segment, - instead of two segments as allowed by [RFC2581], or three or four - segments allowed by [RFC3390]. In the original proposal for ECN+, if - the responder (node B) received an ECN-Echo packet informing it of a + responder sets the initial congestion window to one segment, instead + of two segments as allowed by [RFC2581], or three or four segments + allowed by [RFC3390]. With ECN+/TryOnce, illustrated in Figure 2, if + the responder (node B) receives an ECN-Echo packet informing it of a Congestion Experienced indication on its SYN/ACK packet, the - responder would been able to send data packets using an initial - window of one segment, without waiting for a retransmit timeout. In - contrast, this document specifies ECN+/TryOnce, illustrated in Figure - 2; if the responder (node B) receives an ECN-Echo packet informing it - of a Congestion Experienced indication on its SYN/ACK packet, the responder sends a SYN/ACK packet that is not ECN-Capable, in addition to setting the initial window to one segment. - We note that this document updates RFC 3168, which specified that - "the sending TCP MUST reset the retransmit timer on receiving the - ECN-Echo packet when the congestion window is one." As an update, - this document specifies the response of a TCP host to receiving an - ECN-Echo packet acknowledging the receipt of an ECN-Capable SYN/ACK - packet. + We note that the mechanism in this document differs from RFC 3168, + which specifies that "the sending TCP MUST reset the retransmit timer + on receiving the ECN-Echo packet when the congestion window is one." + In contrast, this document describes the response of a TCP host to + receiving an ECN-Echo packet acknowledging the receipt of an ECN- + Capable SYN/ACK packet. RFC 3168 specifies that in response to an ECN-Echo packet, the TCP responder also sets the CWR flag in the TCP header of the next data packet sent, to acknowledge its receipt of and reaction to the ECN- - Echo flag. This document updates RFC 3168 by specifying that in - response to an ECN-Echo packet acknowledging the receipt of an ECN- - Capable SYN/ACK packet, the responder sets the CWR flag in the TCP - header of the non-ECN-Capable SYN/ACK packet. + Echo flag. In contrast, this document describes that in response to + an ECN-Echo packet acknowledging the receipt of an ECN-Capable + SYN/ACK packet, the responder sets the CWR flag in the TCP header of + the non-ECN-Capable SYN/ACK packet. --------------------------------------------------------------- TCP Node A Router TCP Node B (initiator) (responder) ---------- ------ ---------- ECN-setup SYN packet ---> ECN-setup SYN packet ---> <--- ECN-setup SYN/ACK, ECT @@ -483,21 +516,21 @@ In contrast to Figure 2, Figure 3 shows an interchange where the first SYN/ACK packet is ECN-marked and the second SYN/ACK packet is dropped in the network. As in Figure 2, the TCP responder sets a timer when the second SYN/ACK packet is sent. Figure 3 shows that if the timer expires before the TCP responder receives an acknowledgement for the other end, the TCP responder resends the SYN/ACK packet, following the TCP standards. 3.3. Management Interface - The TCP implementation using ECN-Capable SYN/ACK packets SHOULD + The TCP implementation using ECN-Capable SYN/ACK packets should include a management interface to allow the use of ECN to be turned off for SYN/ACK packets. This is to deal with possible backwards compatibility problems such as those discussed in Appendix B. 4. Discussion The rationale for the specification in this document is the following. When node B receives a TCP SYN packet with ECN-Echo bit set in the TCP header, this indicates that node A is ECN-capable. If node B is also ECN-capable, there are no obstacles to immediately @@ -526,35 +559,35 @@ in order to congest a certain link would also be highly inefficient because SYN/ACK packets are small in size. However, the addition of ECN-Capability to SYN/ACK packets could allow SYN/ACK packets to persist for more hops along a network path before being dropped, thus adding somewhat to the ability of a SYN/ACK attack to flood a network link. 4.2. The TCP SYN Packet - There are several reasons why an ECN-Capable codepoint MUST NOT be + There are several reasons why an ECN-Capable codepoint must not be set in the IP header of the initiating TCP SYN packet. First, when the TCP SYN packet is sent, there are no guarantees that the other TCP endpoint (node B in Figure 2) is ECN-capable, or that it would be able to understand and react if the ECN CE codepoint was set by a congested router. Second, the ECN-Capable codepoint in TCP SYN packets could be misused by malicious clients to `improve' the well-known TCP SYN attack. By setting an ECN-Capable codepoint in TCP SYN packets, a malicious host might be able to inject a large number of TCP SYN packets through a potentially congested ECN-enabled router, congesting it even further. For both these reasons, we continue the restriction that the TCP SYN - packet MUST NOT have the ECN-Capable codepoint in the IP header set. + packet must not have the ECN-Capable codepoint in the IP header set. 4.3. SYN/ACK Packets and Packet Size There are a number of router buffer architectures that have smaller dropping rates for small (SYN) packets than for large (data) packets. For example, for a Drop Tail queue in units of packets, where each packet takes a single slot in the buffer regardless of packet size, small and large packets are equally likely to be dropped. However, for a Drop Tail queue in units of bytes, small packets are less likely to be dropped than are large ones. Similarly, for RED in @@ -811,21 +844,21 @@ data packet arrives with the ECN field in the IP header with the codepoint ECT(0) or ECT(1), indicating that an ECN-Capable connection has been established [SBT07]. While there is no evidence that any routers or middleboxes drop SYN/ACK packets that contain an ECN-Capable or CE codepoint in the IP header, such behavior cannot be excluded. (There seems to be a number of routers or middleboxes that drop TCP SYN packets that contain known or unknown IP options [MAF05] (Figure 1).) Thus, as specified in Section 3, if a SYN/ACK packet with the ECT or CE - codepoint is dropped, the TCP node SHOULD resend the SYN/ACK packet + codepoint is dropped, the TCP node should resend the SYN/ACK packet without the ECN-Capable codepoint. There is also no evidence that any routers or middleboxes crash when a SYN/ACK arrives with an ECN- Capable or CE codepoint in the IP header (over and above the routers already known to crash when a data packet arrives with either ECT(0) or ECT(1)), but we have not conducted any measurement studies of this [F07]. 7.2. Congestion Collapse Because TCP SYN/ACK packets carrying an ECT codepoint could be ECN- @@ -970,160 +1003,160 @@ Comparing ECN+, ECN+/Wait, and ECN+/TryOnce: The aggregate packet drop rate is generally higher with ECN+/Wait than with ECN+. Thus, there is no congestion-related reason to prefer ECN+/Wait over ECN+. In contrast, the aggregate packet drop rate with ECN+/TryOnce is often significantly lower than the aggregate packet drop rate with either ECN, ECN+, ECN+/Wait. Target Load = 95%: ECN ECN+ ECN+/Wait ECN+/TryOnce ------- ------- ------- ---------- - Dropped 20,516 11,226 11,735 16,446` - Marked 30,586 37,741 37,425 40,530 - Loss rate 1.41% 0.78% 0.81% 1.01% + Dropped 20,516 11,226 11,735 16,755` + Marked 30,586 37,741 37,425 40,764 + Loss rate 1.41% 0.78% 0.81% 1.02% Throughput 81% 81% 81% 81% Target Load = 110%: ECN ECN+ ECN+/Wait ECN+/TryOnce ------- ------- ------- ---------- - Dropped 165,566 106,083 147,180 218,594 - Marked 179,735 281,306 308,473 242,969 - Loss rate 9.01% 6.12% 8.02% 7.14% + Dropped 165,566 106,083 147,180 208,422 + Marked 179,735 281,306 308,473 235,483 + Loss rate 9.01% 6.12% 8.02% 6.89% Throughput 92% 92% 92% 94% Target Load = 125%: ECN ECN+ ECN+/Wait ECN+/TryOnce ------- ------- ------- ---------- - Dropped 600,628 1,746,768 2,176,530 650,781 - Marked 418,433 1,166,450 1,164,932 440,432 - Loss rate 25.45% 51.73% 56.87% 18.22% + Dropped 600,628 1,746,768 2,176,530 625,552 + Marked 418,433 1,166,450 1,164,932 439,847 + Loss rate 25.45% 51.73% 56.87% 18.31% Throughput 94% 98% 97% 95% Target Load = 1.50% ECN ECN+ ECN+/Wait ECN+/TryOnce ------- ------- ------- ---------- - Dropped 1,449,945 1,565,0517 1,563,0801 1,372,067 - Marked 669,840 583,378 591,315 675,290 - Loss rate 46.7% 59.0% 59.0% 32.3% - Throughput 88% 94% 94% 93% + Dropped 1,449,945 1,565,0517 1,563,0801 1,351,637 + Marked 669,840 583,378 591,315 684,715 + Loss rate 46.7% 59.0% 59.0% 32.7% + Throughput 88% 94% 94% 92% Table 1: Simulations with an average flow size of 3 Kbytes, a 100 Mbps link, RED in packet mode, queue in packets. Target Load = 95%: TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000 ------------------------------------------------------ ECN: 0.00 0.07 0.26 0.51 0.82 0.96 0.97 0.97 0.97 1.00 1.00 ECN+: 0.00 0.07 0.27 0.53 0.85 0.99 1.00 1.00 1.00 1.00 1.00 Wait: 0.00 0.07 0.26 0.51 0.83 0.97 1.00 1.00 1.00 1.00 1.00 Once: 0.00 0.07 0.24 0.49 0.83 0.97 1.00 1.00 1.00 1.00 1.00 Target Load = 110%: TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000 ------------------------------------------------------ ECN: 0.00 0.05 0.19 0.41 0.67 0.79 0.80 0.80 0.80 0.96 0.96 ECN+: 0.00 0.07 0.22 0.48 0.81 0.96 1.00 1.00 1.00 1.00 1.00 Wait: 0.00 0.05 0.18 0.38 0.64 0.77 0.95 1.00 1.00 1.00 1.00 - Once: 0.00 0.06 0.19 0.41 0.70 0.86 0.95 0.96 0.96 0.99 0.99 + Once: 0.00 0.06 0.19 0.42 0.70 0.86 0.95 0.96 0.96 0.99 0.99 Target Load = 125%: TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000 ------------------------------------------------------ ECN: 0.00 0.04 0.13 0.27 0.46 0.56 0.58 0.59 0.59 0.82 0.82 ECN+: 0.00 0.06 0.18 0.33 0.58 0.76 0.97 0.99 0.99 1.00 1.00 Wait: 0.00 0.01 0.06 0.13 0.21 0.27 0.68 0.98 0.99 1.00 1.00 Once: 0.00 0.05 0.16 0.34 0.58 0.73 0.85 0.87 0.87 0.95 0.96 TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000 ------------------------------------------------------ ECN: 0.00 0.03 0.08 0.18 0.31 0.39 0.42 0.42 0.43 0.68 0.68 ECN+: 0.00 0.06 0.18 0.39 0.67 0.81 0.83 0.84 0.84 0.93 0.93 Wait: 0.00 0.06 0.18 0.39 0.67 0.81 0.83 0.84 0.84 0.93 0.94 - Once: 0.00 0.04 0.13 0.28 0.47 0.60 0.72 0.75 0.76 0.88 0.89 + Once: 0.00 0.04 0.13 0.27 0.46 0.59 0.72 0.75 0.75 0.88 0.88 Table 2: The cumulative distribution function (CDF) for transfer times, for simulations with an average flow size of 3 Kbytes, a 100 Mbps link, RED in packet mode, queue in packets. (The graphs are available from "http://www.icir.org/floyd/ecn-syn/".) Target Load = 0.95% ECN ECN+ ECN+/Wait ECN+/TryOnce ------- ------- ------- ---------- - Dropped 8,448 6,362 7,740 16,323 - Marked 9,891 16,787 17,456 17,186 - Loss rate 5.5% 4.3% 5.0% 5.4% - Throughput 78% 78% 78% 82% + Dropped 8,448 6,362 7,740 14,107 + Marked 9,891 16,787 17,456 16,132 + Loss rate 5.5% 4.3% 5.0% 5.0% + Throughput 78% 78% 78% 81% Target Load = 1.10% ECN ECN+ ECN+/Wait ECN+/TryOnce ------- ------- ------- ---------- - Dropped 31,284 29,773 49,297 42,201 - Marked 28,429 54,729 60,383 33,672 - Loss rate 15.3% 15.2% 21.9% 13.5% - Throughput 97% 96% 96% 95% + Dropped 31,284 29,773 49,297 45,277 + Marked 28,429 54,729 60,383 34,622 + Loss rate 15.3% 15.2% 21.9% 13.6% + Throughput 97% 96% 96% 94% Target Load = 1.25% ECN ECN+ ECN+/Wait ECN+/TryOnce ------- ------- ------- ---------- - Dropped 61,433 176,682 214,096 79,463 - Marked 44,408 119,728 117,301 48,991 - Loss rate 25.4% 51.9% 56.0% 22.5% - Throughput 97% 98% 98% 95% + Dropped 61,433 176,682 214,096 75,612 + Marked 44,408 119,728 117,301 49,442 + Loss rate 25.4% 51.9% 56.0% 22.3% + Throughput 97% 98% 98% 96% Target Load = 1.50% ECN ECN+ ECN+/Wait ECN+/TryOnce ------- ------- ------- ---------- - Dropped 130,007 251,856 326,845 141,418 - Marked 63,066 146,757 147,239 67,772 - Loss rate 42.5% 61.3% 67.3% 33.3% + Dropped 130,007 251,856 326,845 133,603 + Marked 63,066 146,757 147,239 66,444 + Loss rate 42.5% 61.3% 67.3% 31.7% Throughput 93% 99% 99% 94% Table 3: Simulations with an average flow size of 3 Kbytes, a 10 Mbps link, RED in packet mode, queue in packets. Target Load = 95%: TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000 ------------------------------------------------------ ECN: 0.00 0.05 0.18 0.42 0.70 0.86 0.88 0.88 0.88 0.98 0.98 ECN+: 0.00 0.06 0.20 0.45 0.78 0.96 1.00 1.00 1.00 1.00 1.00 Wait: 0.00 0.05 0.18 0.40 0.68 0.84 0.96 1.00 1.00 1.00 1.00 - Once: 0.00 0.05 0.18 0.39 0.69 0.87 0.96 0.96 0.96 0.99 0.99 + Once: 0.00 0.05 0.18 0.40 0.71 0.88 0.96 0.97 0.97 0.99 0.99 Target Load = 110%: TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000 ------------------------------------------------------ ECN: 0.00 0.03 0.13 0.29 0.52 0.66 0.69 0.69 0.69 0.91 0.91 ECN+: 0.00 0.05 0.17 0.36 0.66 0.88 0.98 0.99 1.00 1.00 1.00 Wait: 0.00 0.02 0.08 0.20 0.35 0.47 0.76 0.98 1.00 1.00 1.00 - Once: 0.00 0.04 0.15 0.33 0.59 0.76 0.89 0.91 0.91 0.98 0.98 + Once: 0.00 0.05 0.15 0.32 0.58 0.75 0.88 0.90 0.90 0.97 0.97 Target Load = 125%: TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000 ------------------------------------------------------ ECN: 0.00 0.03 0.10 0.22 0.40 0.52 0.56 0.56 0.57 0.82 0.82 ECN+: 0.00 0.03 0.14 0.27 0.49 0.70 0.96 0.99 0.99 0.99 1.00 Wait: 0.00 0.00 0.03 0.07 0.12 0.18 0.50 0.94 0.99 0.99 1.00 - Once: 0.00 0.04 0.13 0.29 0.51 0.66 0.81 0.84 0.84 0.94 0.94 + Once: 0.00 0.04 0.13 0.28 0.51 0.66 0.81 0.84 0.84 0.94 0.94 Target Load = 150%: TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000 ------------------------------------------------------ ECN: 0.00 0.02 0.07 0.15 0.28 0.38 0.42 0.42 0.43 0.67 0.68 ECN+: 0.00 0.00 0.00 0.00 0.01 0.05 0.68 0.83 0.95 0.97 0.98 Wait: 0.00 0.00 0.00 0.00 0.00 0.00 0.10 0.62 0.83 0.93 0.97 - Once: 0.00 0.03 0.11 0.23 0.42 0.56 0.71 0.74 0.74 0.87 0.88 + Once: 0.00 0.03 0.11 0.24 0.42 0.56 0.71 0.75 0.75 0.88 0.88 Table 4: The cumulative distribution function (CDF) for transfer times, for simulations with an average flow size of 3 Kbytes, a 10 Mbps link, RED in packet mode, queue in packets. (The graphs are available from "http://www.icir.org/floyd/ecn-syn/".) A.2. Simulations with RED in Byte Mode Table 5 below shows simulations with RED in byte mode and the queue in bytes. There is no significant increase in aggregate congestion @@ -1143,74 +1176,74 @@ ECN ECN+ ECN+/Wait ECN+/TryOnce ------- ------- ------- ---------- Dropped 766 446 427 408 Marked 32,683 34,289 33,412 31,892 Loss rate 0.05% 0.03% 0.03% 0.03% Throughput 81% 81% 81% 81% Target Load = 110% ECN ECN+ ECN+/Wait ECN+/TryOnce ------- ------- ------- ---------- - Dropped 2,496 2,110 1,733 2,024 - Marked 220,573 258,696 230,955 224,338 + Dropped 2,496 2,110 1,733 2,020 + Marked 220,573 258,696 230,955 214,604 Loss rate 0.15% 0.13% 0.11% 0.11% Throughput 92% 91% 92% 92% Target Load = 125% ECN ECN+ ECN+/Wait ECN+/TryOnce ------- ------- ------- ---------- - Dropped 20,032 13,555 13,979 19,544 - Marked 725,165 726,992 726,823 627,088 - Loss rate 1.11% 0.76% 0.78% 0.72% - Throughput 95% 95% 95% 95% + Dropped 20,032 13,555 13,979 16,918 + Marked 725,165 726,992 726,823 615,235 + Loss rate 1.11% 0.76% 0.78% 0.66% + Throughput 95% 95% 95% 96% Target Load = 150% ECN ECN+ ECN+/Wait ECN+/TryOnce ------- ------- ------- ---------- - Dropped 484,251 483,847 507,727 572,373 - Marked 865,905 872,254 873,317 816,841 - Loss rate 19.09% 19.13% 19.71% 12.28% + Dropped 484,251 483,847 507,727 600,737 + Marked 865,905 872,254 873,317 818,451 + Loss rate 19.09% 19.13% 19.71% 12.66% Throughput 99% 98% 99% 99% Table 5: Simulations with an average flow size of 3 Kbytes, a 100 Mbps link, RED in byte mode, queue in bytes. Target Load = 0.95% ECN ECN+ ECN+/Wait ECN+/TryOnce ------- ------- ------- ---------- Dropped 142 77 103 99 Marked 11,694 11,387 11,604 12,129 Loss rate 0.1% 0.1% 0.1% 0.1% Throughput 78% 78% 78% 78% Target Load = 1.10% ECN ECN+ ECN+/Wait ECN+/TryOnce ------- ------- ------- ---------- - Dropped 338 210 247 292 - Marked 41,676 40,412 44,173 37,527 + Dropped 338 210 247 274 + Marked 41,676 40,412 44,173 36,265 Loss rate 0.2% 0.1% 0.1% 0.1% - Throughput 94% 94% 94% 95% + Throughput 94% 94% 94% 96% Target Load = 1.25% ECN ECN+ ECN+/Wait ECN+/TryOnce ------- ------- ------- ---------- - Dropped 1,559 951 978 1,490 - Marked 74,933 75,499 75,481 57,721 - Loss rate 0.8% 0.5% 0.5% 0.5% + Dropped 1,559 951 978 1,723 + Marked 74,933 75,499 75,481 59,670 + Loss rate 0.8% 0.5% 0.5% 0.6% Throughput 99% 99% 99% 96% Target Load = 1.50% ECN ECN+ ECN+/Wait ECN+/TryOnce ------- ------- ------- ---------- - Dropped 2,374 1,528 1,515 4,517 - Marked 85,739 86,428 86,144 81,695 - Loss rate 1.2% 0.8% 0.8% 1.3% + Dropped 2,374 1,528 1,515 4,848 + Marked 85,739 86,428 86,144 81,350 + Loss rate 1.2% 0.8% 0.8% 1.4% Throughput 99% 98% 98% 98% Table 6: Simulations with an average flow size of 3 Kbytes, a 10 Mbps link, RED in byte mode, queue in bytes. B. Issues of Incremental Deployment In order for TCP node B to send a SYN/ACK packet as ECN-Capable, node B must have received an ECN-setup SYN packet from node A. However, it is possible that node A supports ECN, but either ignores the CE @@ -1314,29 +1347,20 @@ packet that is ECN-marked, but where the ECN mark is ignored by the TCP initiator. However, a TCP responder *can* detect if a SYN/ACK packet is sent as ECN-capable and not reported as ECN-marked, but data packets are dropped or marked from the initial window of data. We will call this scenario "initial-window-congestion". If a web server frequently experienced initial-window congestion (without SYN/ACK congestion), then the web server *might* be experiencing backwards compatibility problems with ECN-Capable SYN/ACK packets, and could respond by not sending SYN/ACK packets as ECN-Capable. -Normative References - - [RFC 2119] S. Bradner, Key words for use in RFCs to Indicate - Requirement Levels, RFC 2119, March 1997. - - [RFC3168] K.K. Ramakrishnan, S. Floyd, and D. Black, The Addition of - Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed - Standard, September 2001. - Informative References [ECN+] A. Kuzmanovic, The Power of Explicit Congestion Notification, SIGCOMM 2005. [ECN-SYN] ECN-SYN web page with simulation scripts, URL "http://www.icir.org/floyd/ecn-syn". [F07] S. Floyd, "[BEHAVE] Response of firewalls and middleboxes to TCP SYN packets that are ECN-Capable?", August 2, 2007, email sent to @@ -1369,20 +1393,24 @@ [RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion Control, RFC 2581, April 1999. [RFC2988] V. Paxson and M. Allman, Computing TCP's Retransmission Timer, RFC 2988, November 2000. [RFC3042] M. Allman, H. Balakrishnan, and S. Floyd, Enhancing TCP's Loss Recovery Using Limited Transmit, RFC 3042, Proposed Standard, January 2001. + [RFC3168] K.K. Ramakrishnan, S. Floyd, and D. Black, The Addition of + Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed + Standard, September 2001. + [RFC3360] S. Floyd, Inappropriate TCP Resets Considered Harmful, RFC 3360, August 2002. [RFC3390] M. Allman, S. Floyd, and C. Partridge, Increasing TCP's Initial Window, RFC 3390, October 2002. [RFC4987] W. Eddy, TCP SYN Flooding Attacks and Common Mitigations, RFC 4987, August 2007. [SCJO01] F. Smith, F. Campos, K. Jeffay, and D. Ott, What TCP/IP @@ -1419,50 +1447,10 @@ Phone: +1 (510) 666-2989 ICIR (ICSI Center for Internet Research) Email: floyd@icir.org URL: http://www.icir.org/floyd/ K. K. Ramakrishnan Phone: +1 (973) 360-8764 AT&T Labs Research Email: kkrama at research.att.com URL: http://www.research.att.com/info/kkrama - -Full Copyright Statement - - Copyright (C) The IETF Trust (2008). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org.