draft-ietf-tcpm-ecnsyn-07.txt   draft-ietf-tcpm-ecnsyn-08.txt 
Internet Engineering Task Force A. Kuzmanovic Internet Engineering Task Force A. Kuzmanovic
INTERNET-DRAFT A. Mondal INTERNET-DRAFT A. Mondal
Intended status: Proposed Standard Northwestern University Intended status: Experimental Northwestern University
Expires: 3 May 2009 S. Floyd Expires: 2 October 2009 S. Floyd
Updates: 3168 ICIR ICSI
K.K. Ramakrishnan K.K. Ramakrishnan
AT&T AT&T
3 November 2008
Adding Explicit Congestion Notification (ECN) Capability Adding Explicit Congestion Notification (ECN) Capability
to TCP's SYN/ACK Packets to TCP's SYN/ACK Packets
draft-ietf-tcpm-ecnsyn-07.txt draft-ietf-tcpm-ecnsyn-08.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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 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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 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 Abstract
This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK The proposal in this document is experimental. While it may be
packets to be ECN-Capable. For TCP, RFC 3168 only specifies setting deployed in the current Internet, it does not represent a consensus
an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK that this is the best possible mechanism for the use of ECN in TCP
packets. However, because of the high cost to the TCP transfer of SYN/ACK packets.
having a SYN/ACK packet dropped, with the resulting retransmit
timeout, this document specifies the use of ECN for the SYN/ACK This draft describes an optional, experimental modification to RFC
packet itself, when sent in response to a SYN packet with the two ECN 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC
flags set in the TCP header, indicating a willingness to use ECN. 3168 only specifies setting an ECN-Capable codepoint on data packets,
Setting the initial TCP SYN/ACK packet as ECN-Capable can be of great and not on SYN and SYN/ACK packets. However, because of the high
benefit to the TCP connection, avoiding the severe penalty of a cost to the TCP transfer of having a SYN/ACK packet dropped, with the
retransmit timeout for a connection that has not yet started placing resulting retransmit timeout, this document describes the use of ECN
a load on the network. The TCP responder (the sender of the SYN/ACK for the SYN/ACK packet itself, when sent in response to a SYN packet
packet) must reply to a report of an ECN-marked SYN/ACK packet by with the two ECN flags set in the TCP header, indicating a
resending a SYN/ACK packet that is not ECN-Capable. If the resent willingness to use ECN. Setting the initial TCP SYN/ACK packet as
SYN/ACK packet is acknowledged, then the TCP responder reduces its ECN-Capable can be of great benefit to the TCP connection, avoiding
initial congestion window from two, three, or four segments to one the severe penalty of a retransmit timeout for a connection that has
segment, thereby reducing the subsequent load from that connection on not yet started placing a load on the network. The TCP responder
the network. If instead the SYN/ACK packet is dropped, or for some (the sender of the SYN/ACK packet) must reply to a report of an ECN-
other reason the TCP responder does not receive an acknowledgement in marked SYN/ACK packet by resending a SYN/ACK packet that is not ECN-
the specified time, the TCP responder follows TCP standards for a Capable. If the resent SYN/ACK packet is acknowledged, then the TCP
dropped SYN/ACK packet (setting the retransmit timer). This document responder reduces its initial congestion window from two, three, or
updates RFC 3168. 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 Table of Contents
1. Introduction ....................................................5 1. Introduction ....................................................6
2. Conventions and Terminology .....................................7 2. Conventions and Terminology .....................................7
3. Specification ...................................................7 3. Specification ...................................................8
3.1. SYN/ACK Packets Dropped in the Network .....................8 3.1. SYN/ACK Packets Dropped in the Network .....................8
3.2. SYN/ACK Packets ECN-Marked in the Network ..................9 3.2. SYN/ACK Packets ECN-Marked in the Network ..................9
3.3. Management Interface ......................................11 3.3. Management Interface ......................................12
4. Discussion .....................................................12 4. Discussion .....................................................13
4.1. Flooding Attacks ..........................................12 4.1. Flooding Attacks ..........................................13
4.2. The TCP SYN Packet ........................................12 4.2. The TCP SYN Packet ........................................13
4.3. SYN/ACK Packets and Packet Size ...........................13 4.3. SYN/ACK Packets and Packet Size ...........................14
4.4. Response to ECN-marking of SYN/ACK Packets ................13 4.4. Response to ECN-marking of SYN/ACK Packets ................14
5. Related Work ...................................................15 5. Related Work ...................................................16
6. Performance Evaluation .........................................16 6. Performance Evaluation .........................................17
6.1. The Costs and Benefit of Adding ECN-Capability ............16 6.1. The Costs and Benefit of Adding ECN-Capability ............17
6.2. An Evaluation of Different Responses to ECN-Marked SYN/ACK 6.2. An Evaluation of Different Responses to ECN-Marked SYN/ACK
Packets ........................................................17 Packets ........................................................18
7. Security Considerations ........................................18 7. Security Considerations ........................................19
7.1. 'Bad' Routers or Middleboxes ..............................18 7.1. 'Bad' Routers or Middleboxes ..............................19
7.2. Congestion Collapse .......................................19 7.2. Congestion Collapse .......................................20
8. Conclusions ....................................................19 8. Conclusions ....................................................20
9. Acknowledgements ...............................................20 9. Acknowledgements ...............................................21
A. Report on Simulations ..........................................20 A. Report on Simulations ..........................................21
A.1. Simulations with RED in Packet Mode .......................21 A.1. Simulations with RED in Packet Mode .......................22
A.2. Simulations with RED in Byte Mode .........................25 A.2. Simulations with RED in Byte Mode .........................26
B. Issues of Incremental Deployment ...............................27 B. Issues of Incremental Deployment ...............................28
Normative References ..............................................30 Informative References ............................................31
Informative References ............................................30 IANA Considerations ...............................................32
IANA Considerations ...............................................31
Full Copyright Statement ..........................................32
Intellectual Property .............................................32
NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION. 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: Changes from draft-ietf-tcpm-ecnsyn-06:
* Updated text and simulation results to specify ECN+/TryOnce * Updated text and simulation results to specify ECN+/TryOnce
instead of ECN+. Added tables on CDFs. instead of ECN+. Added tables on CDFs.
* Acknowledged Adam's Linux implementation of ECN+/TryOnce. * Acknowledged Adam's Linux implementation of ECN+/TryOnce.
Changes from draft-ietf-tcpm-ecnsyn-05: Changes from draft-ietf-tcpm-ecnsyn-05:
* Added "Updates: 3168" to the header. Added a reference * Added "Updates: 3168" to the header. Added a reference
skipping to change at page 6, line 40 skipping to change at page 7, line 31
specifies the negotiation of the use of ECN between the two TCP end- 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 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 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, 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 because of the high cost to the TCP transfer of having a SYN/ACK
packet dropped, with the resulting retransmit timeout, this document packet dropped, with the resulting retransmit timeout, this document
specifies the use of ECN for the SYN/ACK packet itself. This can be 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 great benefit to the TCP connection, avoiding the severe penalty
of a retransmit timeout for a connection that has not yet started 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 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- respond to a report of an ECN-marked SYN/ACK packet (a router with
ECN-Capable SYN/ACK packet, and by reducing its initial congestion the CE codepoint set in the ECN field in the IP header) by sending a
window from two, three, or four segments to one segment, reducing the non-ECN-Capable SYN/ACK packet, and by reducing its initial
subsequent load from that connection on the network. 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 The use of ECN for SYN/ACK packets has the following potential
benefits: benefits:
1) Avoidance of a retransmit timeout; 1) Avoidance of a retransmit timeout;
2) Improvement in the throughput of short connections. 2) Improvement in the throughput of short connections.
This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK
packets to be ECN-Capable. Section 3 contains the specification of packets to be ECN-Capable. Section 3 contains the specification of
the change, while Section 4 discusses some of the issues, and Section the change, while Section 4 discusses some of the issues, and Section
5 discusses related work. Section 6 contains an evaluation of the 5 discusses related work. Section 6 contains an evaluation of the
specified change. specified change.
2. Conventions and Terminology 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: We use the following terminology from RFC 3168:
The ECN field in the IP header: The ECN field in the IP header:
o CE: the Congestion Experienced codepoint; and o CE: the Congestion Experienced codepoint; and
o ECT: either one of the two ECN-Capable Transport codepoints. o ECT: either one of the two ECN-Capable Transport codepoints.
The ECN flags in the TCP header: The ECN flags in the TCP header:
o CWR: the Congestion Window Reduced flag; and o CWR: the Congestion Window Reduced flag; and
o ECE: the ECN-Echo flag. o ECE: the ECN-Echo flag.
skipping to change at page 7, line 39 skipping to change at page 8, line 28
refer to the sender of the SYN packet and of the SYN-ACK packet, refer to the sender of the SYN packet and of the SYN-ACK packet,
respectively. respectively.
3. Specification 3. Specification
This section specifies the modification to RFC 3168 to allow TCP This section specifies the modification to RFC 3168 to allow TCP
SYN/ACK packets to be ECN-Capable. SYN/ACK packets to be ECN-Capable.
RFC 3168 in Section 6.1.1. states that "A host MUST NOT set ECT on 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 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 responding ECN-setup SYN/ACK packet, indicating to routers that the
SYN/ACK packet is ECN-Capable. This allows a congested router along 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 the path to mark the packet instead of dropping the packet as an
indication of congestion. indication of congestion.
Assume that TCP node A transmits to TCP node B an ECN-setup SYN Assume that TCP node A transmits to TCP node B an ECN-setup SYN
packet, indicating willingness to use ECN for this connection. As 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 specified by RFC 3168, if TCP node B is willing to use ECN, node B
responds with an ECN-setup SYN-ACK packet. responds with an ECN-setup SYN-ACK packet.
skipping to change at page 8, line 37 skipping to change at page 9, line 31
Data/ACK ---> Data/ACK --->
Data/ACK ---> Data/ACK --->
<--- Data (one to four segments) <--- Data (one to four segments)
--------------------------------------------------------------- ---------------------------------------------------------------
Figure 1: SYN exchange with the SYN/ACK packet dropped. Figure 1: SYN exchange with the SYN/ACK packet dropped.
If the SYN/ACK packet is dropped in the network, the responder (node If the SYN/ACK packet is dropped in the network, the responder (node
B) responds by waiting three seconds for the retransmit timer to B) responds by waiting three seconds for the retransmit timer to
expire [RFC2988]. If a SYN/ACK packet with the ECT codepoint is 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 ECN-Capable codepoint. (Although we are not aware of any middleboxes
that drop SYN/ACK packets that contain an ECN-Capable codepoint in that drop SYN/ACK packets that contain an ECN-Capable codepoint in
the IP header, we have learned to design our protocols defensively in the IP header, we have learned to design our protocols defensively in
this regard [RFC3360].) this regard [RFC3360].)
We note that if syn-cookies were used by the responder (node B) in 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 the exchange in Figure 1, the responder wouldn't set a timer upon
transmission of the SYN/ACK packet [SYN-COOK] [RFC4987]. In this transmission of the SYN/ACK packet [SYN-COOK] [RFC4987]. In this
case, if the SYN/ACK packet was lost, the initiator (Node A) would 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 have to timeout and retransmit the SYN packet in order to trigger
skipping to change at page 9, line 14 skipping to change at page 10, line 6
3.2. SYN/ACK Packets ECN-Marked in the Network 3.2. SYN/ACK Packets ECN-Marked in the Network
Figure 2 shows an interchange with the SYN/ACK packet sent as ECN- Figure 2 shows an interchange with the SYN/ACK packet sent as ECN-
Capable, and ECN-marked instead of dropped at the congested router. Capable, and ECN-marked instead of dropped at the congested router.
This document specifies ECN+/TryOnce, which differs from the original This document specifies ECN+/TryOnce, which differs from the original
proposal for ECN+ in [ECN+]; with ECN+/TryOnce, if the TCP responder proposal for ECN+ in [ECN+]; with ECN+/TryOnce, if the TCP responder
is informed that the SYN/ACK was ECN-marked, 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 immediately sends a SYN/ACK packet that is not ECN-Capable. The TCP
responder is only allowed to send data packets after 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 initiator reports the receipt of a SYN/ACK packet that is not ECN-
marked nor dropped. marked.
--------------------------------------------------------------- ---------------------------------------------------------------
TCP Node A Router TCP Node B TCP Node A Router TCP Node B
(initiator) (responder) (initiator) (responder)
---------- ------ ---------- ---------- ------ ----------
ECN-setup SYN packet ---> ECN-setup SYN packet --->
ECN-setup SYN packet ---> ECN-setup SYN packet --->
<--- ECN-setup SYN/ACK, ECT <--- ECN-setup SYN/ACK, ECT
skipping to change at page 9, line 45 skipping to change at page 10, line 37
Data/ACK ---> Data/ACK --->
Data/ACK ---> Data/ACK --->
<--- Data (one segment only) <--- Data (one segment only)
--------------------------------------------------------------- ---------------------------------------------------------------
Figure 2: SYN exchange with the SYN/ACK packet marked. Figure 2: SYN exchange with the SYN/ACK packet marked.
ECN+/TryOnce. ECN+/TryOnce.
If the initiator (node A) receives a SYN/ACK packet that has been If the initiator (node A) receives a SYN/ACK packet that has been
marked by the congested router, with the CE codepoint set, the ECN-marked by the congested router, with the CE codepoint set, the
initiator MUST respond by setting the ECN-Echo flag in the TCP header initiator resets the retransmit timer. The initiator responds to the
of the responding ACK packet. However, with ECN+/TryOnce the ECN-marked SYN/ACK packet by setting the ECN-Echo flag in the TCP
initiator does not advance from the "SYN-Sent" to the "SYN-Received" header of the responding ACK packet. The initiator uses the standard
state until it receives a SYN/ACK packet that is not ECN-marked. As rules in setting the cumulative acknowledgement field in the
specified in RFC 3168, the initiator continues to set the ECN-Echo responding ACK packet.
flag in packets until it receives a packet with the CWR flag set.
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 When the responder (node B) receives the ECN-Echo packet reporting
the Congestion Experienced indication in the SYN/ACK packet, the the Congestion Experienced indication in the SYN/ACK packet, the
responder MUST set the initial congestion window to one segment, responder sets the initial congestion window to one segment, instead
instead of two segments as allowed by [RFC2581], or three or four of two segments as allowed by [RFC2581], or three or four segments
segments allowed by [RFC3390]. In the original proposal for ECN+, if allowed by [RFC3390]. With ECN+/TryOnce, illustrated in Figure 2, if
the responder (node B) received an ECN-Echo packet informing it of a the responder (node B) receives an ECN-Echo packet informing it of a
Congestion Experienced indication on its SYN/ACK packet, the 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 responder sends a SYN/ACK packet that is not ECN-Capable, in addition
to setting the initial window to one segment. to setting the initial window to one segment.
We note that this document updates RFC 3168, which specified that We note that the mechanism in this document differs from RFC 3168,
"the sending TCP MUST reset the retransmit timer on receiving the which specifies that "the sending TCP MUST reset the retransmit timer
ECN-Echo packet when the congestion window is one." As an update, on receiving the ECN-Echo packet when the congestion window is one."
this document specifies the response of a TCP host to receiving an In contrast, this document describes the response of a TCP host to
ECN-Echo packet acknowledging the receipt of an ECN-Capable SYN/ACK receiving an ECN-Echo packet acknowledging the receipt of an ECN-
packet. Capable SYN/ACK packet.
RFC 3168 specifies that in response to an ECN-Echo packet, the TCP 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 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- packet sent, to acknowledge its receipt of and reaction to the ECN-
Echo flag. This document updates RFC 3168 by specifying that in Echo flag. In contrast, this document describes that in response to
response to an ECN-Echo packet acknowledging the receipt of an ECN- an ECN-Echo packet acknowledging the receipt of an ECN-Capable
Capable SYN/ACK packet, the responder sets the CWR flag in the TCP SYN/ACK packet, the responder sets the CWR flag in the TCP header of
header of the non-ECN-Capable SYN/ACK packet. the non-ECN-Capable SYN/ACK packet.
--------------------------------------------------------------- ---------------------------------------------------------------
TCP Node A Router TCP Node B TCP Node A Router TCP Node B
(initiator) (responder) (initiator) (responder)
---------- ------ ---------- ---------- ------ ----------
ECN-setup SYN packet ---> ECN-setup SYN packet --->
ECN-setup SYN packet ---> ECN-setup SYN packet --->
<--- ECN-setup SYN/ACK, ECT <--- ECN-setup SYN/ACK, ECT
skipping to change at page 11, line 47 skipping to change at page 12, line 47
In contrast to Figure 2, Figure 3 shows an interchange where the 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 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 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 timer when the second SYN/ACK packet is sent. Figure 3 shows that if
the timer expires before the TCP responder receives an the timer expires before the TCP responder receives an
acknowledgement for the other end, the TCP responder resends the acknowledgement for the other end, the TCP responder resends the
SYN/ACK packet, following the TCP standards. SYN/ACK packet, following the TCP standards.
3.3. Management Interface 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 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 off for SYN/ACK packets. This is to deal with possible backwards
compatibility problems such as those discussed in Appendix B. compatibility problems such as those discussed in Appendix B.
4. Discussion 4. Discussion
The rationale for the specification in this document is the The rationale for the specification in this document is the
following. When node B receives a TCP SYN packet with ECN-Echo bit 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 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 node B is also ECN-capable, there are no obstacles to immediately
skipping to change at page 12, line 43 skipping to change at page 13, line 43
in order to congest a certain link would also be highly inefficient in order to congest a certain link would also be highly inefficient
because SYN/ACK packets are small in size. because SYN/ACK packets are small in size.
However, the addition of ECN-Capability to SYN/ACK packets could However, the addition of ECN-Capability to SYN/ACK packets could
allow SYN/ACK packets to persist for more hops along a network path allow SYN/ACK packets to persist for more hops along a network path
before being dropped, thus adding somewhat to the ability of a before being dropped, thus adding somewhat to the ability of a
SYN/ACK attack to flood a network link. SYN/ACK attack to flood a network link.
4.2. The TCP SYN Packet 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 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 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 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 able to understand and react if the ECN CE codepoint was set by a
congested router. congested router.
Second, the ECN-Capable codepoint in TCP SYN packets could be misused Second, the ECN-Capable codepoint in TCP SYN packets could be misused
by malicious clients to `improve' the well-known TCP SYN attack. By by malicious clients to `improve' the well-known TCP SYN attack. By
setting an ECN-Capable codepoint in TCP SYN packets, a malicious host 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 might be able to inject a large number of TCP SYN packets through a
potentially congested ECN-enabled router, congesting it even further. potentially congested ECN-enabled router, congesting it even further.
For both these reasons, we continue the restriction that the TCP SYN 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 4.3. SYN/ACK Packets and Packet Size
There are a number of router buffer architectures that have smaller There are a number of router buffer architectures that have smaller
dropping rates for small (SYN) packets than for large (data) packets. dropping rates for small (SYN) packets than for large (data) packets.
For example, for a Drop Tail queue in units of packets, where each 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, packet takes a single slot in the buffer regardless of packet size,
small and large packets are equally likely to be dropped. However, small and large packets are equally likely to be dropped. However,
for a Drop Tail queue in units of bytes, small packets are less 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 likely to be dropped than are large ones. Similarly, for RED in
skipping to change at page 18, line 48 skipping to change at page 19, line 48
data packet arrives with the ECN field in the IP header with the 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 codepoint ECT(0) or ECT(1), indicating that an ECN-Capable connection
has been established [SBT07]. has been established [SBT07].
While there is no evidence that any routers or middleboxes drop 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 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 header, such behavior cannot be excluded. (There seems to be a
number of routers or middleboxes that drop TCP SYN packets that number of routers or middleboxes that drop TCP SYN packets that
contain known or unknown IP options [MAF05] (Figure 1).) Thus, as 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 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 without the ECN-Capable codepoint. There is also no evidence that
any routers or middleboxes crash when a SYN/ACK arrives with an ECN- 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 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) 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 or ECT(1)), but we have not conducted any measurement studies of this
[F07]. [F07].
7.2. Congestion Collapse 7.2. Congestion Collapse
Because TCP SYN/ACK packets carrying an ECT codepoint could be ECN- Because TCP SYN/ACK packets carrying an ECT codepoint could be ECN-
skipping to change at page 22, line 20 skipping to change at page 23, line 20
Comparing ECN+, ECN+/Wait, and ECN+/TryOnce: The aggregate packet Comparing ECN+, ECN+/Wait, and ECN+/TryOnce: The aggregate packet
drop rate is generally higher with ECN+/Wait than with ECN+. Thus, drop rate is generally higher with ECN+/Wait than with ECN+. Thus,
there is no congestion-related reason to prefer ECN+/Wait over ECN+. there is no congestion-related reason to prefer ECN+/Wait over ECN+.
In contrast, the aggregate packet drop rate with ECN+/TryOnce is In contrast, the aggregate packet drop rate with ECN+/TryOnce is
often significantly lower than the aggregate packet drop rate with often significantly lower than the aggregate packet drop rate with
either ECN, ECN+, ECN+/Wait. either ECN, ECN+, ECN+/Wait.
Target Load = 95%: Target Load = 95%:
ECN ECN+ ECN+/Wait ECN+/TryOnce ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ---------- ------- ------- ------- ----------
Dropped 20,516 11,226 11,735 16,446` Dropped 20,516 11,226 11,735 16,755`
Marked 30,586 37,741 37,425 40,530 Marked 30,586 37,741 37,425 40,764
Loss rate 1.41% 0.78% 0.81% 1.01% Loss rate 1.41% 0.78% 0.81% 1.02%
Throughput 81% 81% 81% 81% Throughput 81% 81% 81% 81%
Target Load = 110%: Target Load = 110%:
ECN ECN+ ECN+/Wait ECN+/TryOnce ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ---------- ------- ------- ------- ----------
Dropped 165,566 106,083 147,180 218,594 Dropped 165,566 106,083 147,180 208,422
Marked 179,735 281,306 308,473 242,969 Marked 179,735 281,306 308,473 235,483
Loss rate 9.01% 6.12% 8.02% 7.14% Loss rate 9.01% 6.12% 8.02% 6.89%
Throughput 92% 92% 92% 94% Throughput 92% 92% 92% 94%
Target Load = 125%: Target Load = 125%:
ECN ECN+ ECN+/Wait ECN+/TryOnce ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ---------- ------- ------- ------- ----------
Dropped 600,628 1,746,768 2,176,530 650,781 Dropped 600,628 1,746,768 2,176,530 625,552
Marked 418,433 1,166,450 1,164,932 440,432 Marked 418,433 1,166,450 1,164,932 439,847
Loss rate 25.45% 51.73% 56.87% 18.22% Loss rate 25.45% 51.73% 56.87% 18.31%
Throughput 94% 98% 97% 95% Throughput 94% 98% 97% 95%
Target Load = 1.50% Target Load = 1.50%
ECN ECN+ ECN+/Wait ECN+/TryOnce ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ---------- ------- ------- ------- ----------
Dropped 1,449,945 1,565,0517 1,563,0801 1,372,067 Dropped 1,449,945 1,565,0517 1,563,0801 1,351,637
Marked 669,840 583,378 591,315 675,290 Marked 669,840 583,378 591,315 684,715
Loss rate 46.7% 59.0% 59.0% 32.3% Loss rate 46.7% 59.0% 59.0% 32.7%
Throughput 88% 94% 94% 93% Throughput 88% 94% 94% 92%
Table 1: Simulations with an average flow size of 3 Kbytes, a Table 1: Simulations with an average flow size of 3 Kbytes, a
100 Mbps link, RED in packet mode, queue in packets. 100 Mbps link, RED in packet mode, queue in packets.
Target Load = 95%: Target Load = 95%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000 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.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 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 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 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%: Target Load = 110%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000 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.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 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 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%: Target Load = 125%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000 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.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 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 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 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 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.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 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 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 Table 2: The cumulative distribution function (CDF) for transfer
times, for simulations with an average flow size of 3 Kbytes, a 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 100 Mbps link, RED in packet mode, queue in packets. (The graphs are
available from "http://www.icir.org/floyd/ecn-syn/".) available from "http://www.icir.org/floyd/ecn-syn/".)
Target Load = 0.95% Target Load = 0.95%
ECN ECN+ ECN+/Wait ECN+/TryOnce ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ---------- ------- ------- ------- ----------
Dropped 8,448 6,362 7,740 16,323 Dropped 8,448 6,362 7,740 14,107
Marked 9,891 16,787 17,456 17,186 Marked 9,891 16,787 17,456 16,132
Loss rate 5.5% 4.3% 5.0% 5.4% Loss rate 5.5% 4.3% 5.0% 5.0%
Throughput 78% 78% 78% 82% Throughput 78% 78% 78% 81%
Target Load = 1.10% Target Load = 1.10%
ECN ECN+ ECN+/Wait ECN+/TryOnce ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ---------- ------- ------- ------- ----------
Dropped 31,284 29,773 49,297 42,201 Dropped 31,284 29,773 49,297 45,277
Marked 28,429 54,729 60,383 33,672 Marked 28,429 54,729 60,383 34,622
Loss rate 15.3% 15.2% 21.9% 13.5% Loss rate 15.3% 15.2% 21.9% 13.6%
Throughput 97% 96% 96% 95% Throughput 97% 96% 96% 94%
Target Load = 1.25% Target Load = 1.25%
ECN ECN+ ECN+/Wait ECN+/TryOnce ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ---------- ------- ------- ------- ----------
Dropped 61,433 176,682 214,096 79,463 Dropped 61,433 176,682 214,096 75,612
Marked 44,408 119,728 117,301 48,991 Marked 44,408 119,728 117,301 49,442
Loss rate 25.4% 51.9% 56.0% 22.5% Loss rate 25.4% 51.9% 56.0% 22.3%
Throughput 97% 98% 98% 95% Throughput 97% 98% 98% 96%
Target Load = 1.50% Target Load = 1.50%
ECN ECN+ ECN+/Wait ECN+/TryOnce ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ---------- ------- ------- ------- ----------
Dropped 130,007 251,856 326,845 141,418 Dropped 130,007 251,856 326,845 133,603
Marked 63,066 146,757 147,239 67,772 Marked 63,066 146,757 147,239 66,444
Loss rate 42.5% 61.3% 67.3% 33.3% Loss rate 42.5% 61.3% 67.3% 31.7%
Throughput 93% 99% 99% 94% Throughput 93% 99% 99% 94%
Table 3: Simulations with an average flow size of 3 Kbytes, a 10 Mbps Table 3: Simulations with an average flow size of 3 Kbytes, a 10 Mbps
link, RED in packet mode, queue in packets. link, RED in packet mode, queue in packets.
Target Load = 95%: Target Load = 95%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000 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.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 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 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%: Target Load = 110%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000 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.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 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 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%: Target Load = 125%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000 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.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 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 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%: Target Load = 150%:
TIME: 10 100 200 300 400 500 1000 2000 3000 4000 5000 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.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 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 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 Table 4: The cumulative distribution function (CDF) for transfer
times, for simulations with an average flow size of 3 Kbytes, a 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 10 Mbps link, RED in packet mode, queue in packets. (The graphs are
available from "http://www.icir.org/floyd/ecn-syn/".) available from "http://www.icir.org/floyd/ecn-syn/".)
A.2. Simulations with RED in Byte Mode A.2. Simulations with RED in Byte Mode
Table 5 below shows simulations with RED in byte mode and the queue Table 5 below shows simulations with RED in byte mode and the queue
in bytes. There is no significant increase in aggregate congestion in bytes. There is no significant increase in aggregate congestion
skipping to change at page 26, line 26 skipping to change at page 27, line 27
ECN ECN+ ECN+/Wait ECN+/TryOnce ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ---------- ------- ------- ------- ----------
Dropped 766 446 427 408 Dropped 766 446 427 408
Marked 32,683 34,289 33,412 31,892 Marked 32,683 34,289 33,412 31,892
Loss rate 0.05% 0.03% 0.03% 0.03% Loss rate 0.05% 0.03% 0.03% 0.03%
Throughput 81% 81% 81% 81% Throughput 81% 81% 81% 81%
Target Load = 110% Target Load = 110%
ECN ECN+ ECN+/Wait ECN+/TryOnce ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ---------- ------- ------- ------- ----------
Dropped 2,496 2,110 1,733 2,024 Dropped 2,496 2,110 1,733 2,020
Marked 220,573 258,696 230,955 224,338 Marked 220,573 258,696 230,955 214,604
Loss rate 0.15% 0.13% 0.11% 0.11% Loss rate 0.15% 0.13% 0.11% 0.11%
Throughput 92% 91% 92% 92% Throughput 92% 91% 92% 92%
Target Load = 125% Target Load = 125%
ECN ECN+ ECN+/Wait ECN+/TryOnce ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ---------- ------- ------- ------- ----------
Dropped 20,032 13,555 13,979 19,544 Dropped 20,032 13,555 13,979 16,918
Marked 725,165 726,992 726,823 627,088 Marked 725,165 726,992 726,823 615,235
Loss rate 1.11% 0.76% 0.78% 0.72% Loss rate 1.11% 0.76% 0.78% 0.66%
Throughput 95% 95% 95% 95% Throughput 95% 95% 95% 96%
Target Load = 150% Target Load = 150%
ECN ECN+ ECN+/Wait ECN+/TryOnce ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ---------- ------- ------- ------- ----------
Dropped 484,251 483,847 507,727 572,373 Dropped 484,251 483,847 507,727 600,737
Marked 865,905 872,254 873,317 816,841 Marked 865,905 872,254 873,317 818,451
Loss rate 19.09% 19.13% 19.71% 12.28% Loss rate 19.09% 19.13% 19.71% 12.66%
Throughput 99% 98% 99% 99% Throughput 99% 98% 99% 99%
Table 5: Simulations with an average flow size of 3 Kbytes, a Table 5: Simulations with an average flow size of 3 Kbytes, a
100 Mbps link, RED in byte mode, queue in bytes. 100 Mbps link, RED in byte mode, queue in bytes.
Target Load = 0.95% Target Load = 0.95%
ECN ECN+ ECN+/Wait ECN+/TryOnce ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ---------- ------- ------- ------- ----------
Dropped 142 77 103 99 Dropped 142 77 103 99
Marked 11,694 11,387 11,604 12,129 Marked 11,694 11,387 11,604 12,129
Loss rate 0.1% 0.1% 0.1% 0.1% Loss rate 0.1% 0.1% 0.1% 0.1%
Throughput 78% 78% 78% 78% Throughput 78% 78% 78% 78%
Target Load = 1.10% Target Load = 1.10%
ECN ECN+ ECN+/Wait ECN+/TryOnce ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ---------- ------- ------- ------- ----------
Dropped 338 210 247 292 Dropped 338 210 247 274
Marked 41,676 40,412 44,173 37,527 Marked 41,676 40,412 44,173 36,265
Loss rate 0.2% 0.1% 0.1% 0.1% Loss rate 0.2% 0.1% 0.1% 0.1%
Throughput 94% 94% 94% 95% Throughput 94% 94% 94% 96%
Target Load = 1.25% Target Load = 1.25%
ECN ECN+ ECN+/Wait ECN+/TryOnce ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ---------- ------- ------- ------- ----------
Dropped 1,559 951 978 1,490 Dropped 1,559 951 978 1,723
Marked 74,933 75,499 75,481 57,721 Marked 74,933 75,499 75,481 59,670
Loss rate 0.8% 0.5% 0.5% 0.5% Loss rate 0.8% 0.5% 0.5% 0.6%
Throughput 99% 99% 99% 96% Throughput 99% 99% 99% 96%
Target Load = 1.50% Target Load = 1.50%
ECN ECN+ ECN+/Wait ECN+/TryOnce ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ---------- ------- ------- ------- ----------
Dropped 2,374 1,528 1,515 4,517 Dropped 2,374 1,528 1,515 4,848
Marked 85,739 86,428 86,144 81,695 Marked 85,739 86,428 86,144 81,350
Loss rate 1.2% 0.8% 0.8% 1.3% Loss rate 1.2% 0.8% 0.8% 1.4%
Throughput 99% 98% 98% 98% Throughput 99% 98% 98% 98%
Table 6: Simulations with an average flow size of 3 Kbytes, a 10 Mbps Table 6: Simulations with an average flow size of 3 Kbytes, a 10 Mbps
link, RED in byte mode, queue in bytes. link, RED in byte mode, queue in bytes.
B. Issues of Incremental Deployment B. Issues of Incremental Deployment
In order for TCP node B to send a SYN/ACK packet as ECN-Capable, node 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, 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 it is possible that node A supports ECN, but either ignores the CE
skipping to change at page 30, line 8 skipping to change at page 31, line 8
packet that is ECN-marked, but where the ECN mark is ignored by the 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 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 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. data packets are dropped or marked from the initial window of data.
We will call this scenario "initial-window-congestion". If a web We will call this scenario "initial-window-congestion". If a web
server frequently experienced initial-window congestion (without server frequently experienced initial-window congestion (without
SYN/ACK congestion), then the web server *might* be experiencing SYN/ACK congestion), then the web server *might* be experiencing
backwards compatibility problems with ECN-Capable SYN/ACK packets, backwards compatibility problems with ECN-Capable SYN/ACK packets,
and could respond by not sending SYN/ACK packets as ECN-Capable. 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 Informative References
[ECN+] A. Kuzmanovic, The Power of Explicit Congestion Notification, [ECN+] A. Kuzmanovic, The Power of Explicit Congestion Notification,
SIGCOMM 2005. SIGCOMM 2005.
[ECN-SYN] ECN-SYN web page with simulation scripts, URL [ECN-SYN] ECN-SYN web page with simulation scripts, URL
"http://www.icir.org/floyd/ecn-syn". "http://www.icir.org/floyd/ecn-syn".
[F07] S. Floyd, "[BEHAVE] Response of firewalls and middleboxes to [F07] S. Floyd, "[BEHAVE] Response of firewalls and middleboxes to
TCP SYN packets that are ECN-Capable?", August 2, 2007, email sent to TCP SYN packets that are ECN-Capable?", August 2, 2007, email sent to
skipping to change at page 31, line 16 skipping to change at page 32, line 6
[RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion [RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion
Control, RFC 2581, April 1999. Control, RFC 2581, April 1999.
[RFC2988] V. Paxson and M. Allman, Computing TCP's Retransmission [RFC2988] V. Paxson and M. Allman, Computing TCP's Retransmission
Timer, RFC 2988, November 2000. Timer, RFC 2988, November 2000.
[RFC3042] M. Allman, H. Balakrishnan, and S. Floyd, Enhancing TCP's [RFC3042] M. Allman, H. Balakrishnan, and S. Floyd, Enhancing TCP's
Loss Recovery Using Limited Transmit, RFC 3042, Proposed Standard, Loss Recovery Using Limited Transmit, RFC 3042, Proposed Standard,
January 2001. 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 [RFC3360] S. Floyd, Inappropriate TCP Resets Considered Harmful, RFC
3360, August 2002. 3360, August 2002.
[RFC3390] M. Allman, S. Floyd, and C. Partridge, Increasing TCP's [RFC3390] M. Allman, S. Floyd, and C. Partridge, Increasing TCP's
Initial Window, RFC 3390, October 2002. Initial Window, RFC 3390, October 2002.
[RFC4987] W. Eddy, TCP SYN Flooding Attacks and Common Mitigations, [RFC4987] W. Eddy, TCP SYN Flooding Attacks and Common Mitigations,
RFC 4987, August 2007. RFC 4987, August 2007.
[SCJO01] F. Smith, F. Campos, K. Jeffay, and D. Ott, What TCP/IP [SCJO01] F. Smith, F. Campos, K. Jeffay, and D. Ott, What TCP/IP
skipping to change at page 32, line 25 skipping to change at line 1457
Phone: +1 (510) 666-2989 Phone: +1 (510) 666-2989
ICIR (ICSI Center for Internet Research) ICIR (ICSI Center for Internet Research)
Email: floyd@icir.org Email: floyd@icir.org
URL: http://www.icir.org/floyd/ URL: http://www.icir.org/floyd/
K. K. Ramakrishnan K. K. Ramakrishnan
Phone: +1 (973) 360-8764 Phone: +1 (973) 360-8764
AT&T Labs Research AT&T Labs Research
Email: kkrama at research.att.com Email: kkrama at research.att.com
URL: http://www.research.att.com/info/kkrama 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.
 End of changes. 50 change blocks. 
163 lines changed or deleted 191 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/