draft-ietf-tcpm-ecnsyn-08.txt   draft-ietf-tcpm-ecnsyn-09.txt 
Internet Engineering Task Force A. Kuzmanovic Internet Engineering Task Force A. Kuzmanovic
INTERNET-DRAFT A. Mondal INTERNET-DRAFT A. Mondal
Intended status: Experimental Northwestern University Intended status: Experimental Northwestern University
Expires: 2 October 2009 S. Floyd Expires: 13 November 2009 S. Floyd
ICSI ICSI
K.K. Ramakrishnan K.K. Ramakrishnan
AT&T AT&T
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-08.txt draft-ietf-tcpm-ecnsyn-09.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
skipping to change at page 2, line 8 skipping to change at page 2, line 8
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 2 October 2009. This Internet-Draft will expire on 13 November 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Abstract Abstract
The proposal in this document is experimental. While it may be The proposal in this document is experimental. While it may be
deployed in the current Internet, it does not represent a consensus 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 that this is the best possible mechanism for the use of ECN in TCP
SYN/ACK packets. SYN/ACK packets.
This draft describes an optional, experimental modification to RFC This draft describes an optional, experimental modification to RFC
3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, 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, 3168 specifies setting an ECN-Capable codepoint on data packets, but
and not on SYN and SYN/ACK packets. However, because of the high not on SYN and SYN/ACK packets. However, because of the high cost to
cost to the TCP transfer of having a SYN/ACK packet dropped, with the the TCP transfer of having a SYN/ACK packet dropped, with the
resulting retransmit timeout, this document describes the use of ECN resulting retransmission timeout, this document describes the use of
for the SYN/ACK packet itself, when sent in response to a SYN packet ECN for the SYN/ACK packet itself, when sent in response to a SYN
with the two ECN flags set in the TCP header, indicating a 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 willingness to use ECN. Setting the initial TCP SYN/ACK packet as
ECN-Capable can be of great benefit to the TCP connection, avoiding ECN-Capable can be of great benefit to the TCP connection, avoiding
the severe penalty of a retransmit timeout for a connection that has the severe penalty of a retransmission timeout for a connection that
not yet started placing a load on the network. The TCP responder 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- (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- 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 Capable. If the resent SYN/ACK packet is acknowledged, then the TCP
responder reduces its initial congestion window from two, three, or responder reduces its initial congestion window from two, three, or
four segments to one segment, thereby reducing the subsequent load four segments to one segment, thereby reducing the subsequent load
from that connection on the network. If instead the SYN/ACK packet from that connection on the network. If instead the SYN/ACK packet
is dropped, or for some other reason the TCP responder does not is dropped, or for some other reason the TCP responder does not
receive an acknowledgement in the specified time, the TCP responder receive an acknowledgement in the specified time, the TCP responder
follows TCP standards for a dropped SYN/ACK packet (setting the follows TCP standards for a dropped SYN/ACK packet (setting the
retransmit timer). retransmission timer).
Table of Contents Table of Contents
1. Introduction ....................................................6 1. Introduction ....................................................6
2. Conventions and Terminology .....................................7 2. Conventions and Terminology .....................................8
3. Specification ...................................................8 3. Specification ...................................................8
3.1. SYN/ACK Packets Dropped in the Network .....................8 3.1. SYN/ACK Packets Dropped in the Network .....................9
3.2. SYN/ACK Packets ECN-Marked in the Network ..................9 3.2. SYN/ACK Packets ECN-Marked in the Network .................10
3.3. Management Interface ......................................12 3.3. Management Interface ......................................12
4. Discussion .....................................................13 4. Discussion .....................................................13
4.1. Flooding Attacks ..........................................13 4.1. Flooding Attacks ..........................................13
4.2. The TCP SYN Packet ........................................13 4.2. The TCP SYN Packet ........................................13
4.3. SYN/ACK Packets and Packet Size ...........................14 4.3. SYN/ACK Packets and Packet Size ...........................14
4.4. Response to ECN-marking of SYN/ACK Packets ................14 4.4. Response to ECN-marking of SYN/ACK Packets ................14
5. Related Work ...................................................16 5. Related Work ...................................................16
6. Performance Evaluation .........................................17 6. Performance Evaluation .........................................17
6.1. The Costs and Benefit of Adding ECN-Capability ............17 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
skipping to change at page 3, line 37 skipping to change at page 3, line 37
9. Acknowledgements ...............................................21 9. Acknowledgements ...............................................21
A. Report on Simulations ..........................................21 A. Report on Simulations ..........................................21
A.1. Simulations with RED in Packet Mode .......................22 A.1. Simulations with RED in Packet Mode .......................22
A.2. Simulations with RED in Byte Mode .........................26 A.2. Simulations with RED in Byte Mode .........................26
B. Issues of Incremental Deployment ...............................28 B. Issues of Incremental Deployment ...............................28
Informative References ............................................31 Informative References ............................................31
IANA Considerations ...............................................32 IANA Considerations ...............................................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-08:
* Minor editing and bug-fixes. Feedback from Anil Agarwal and
Alfred Hoenes.
* Changed the specification so that after the first SYN/ACK packet
is ECN-marked, and the responder receives an ECN-Echo, the
responder does not set the CWR flag in the second SYN/ACK packet.
We also specified that on receiving the non-ECN-marked SYN/ACK
packet, the TCP initiator clears the ECN-Echo flag on replying
packets. Feedback from Anil Agarwal.
* Changed it so that the initiator moves from the "SYN-Sent" state
to the "Established" state when it receives a SYN/ACK packet
that is not ECN-marked.
Changes from draft-ietf-tcpm-ecnsyn-07: Changes from draft-ietf-tcpm-ecnsyn-07:
* Updated boilerplates. * Updated boilerplates.
* Changed proposed status from "Proposed Standard" to "Experimental", * Changed proposed status from "Proposed Standard" to "Experimental",
and modified text in the Introduction to match. The added text and modified text in the Introduction to match. The added text
in the introduction is based on similar text in the Introduction of in the introduction is based on similar text in the Introduction of
RFC 3649. RFC 3649.
* Specified that with ECN+/TryOnce, the originator resets the * Specified that with ECN+/TryOnce, the originator restarts the
retransmit timer when it receives an ECN-marked SYN/ACK. retransmission timer when it receives an ECN-marked SYN/ACK.
Also reran simulations for ECN+/TryOnce, and updated Also reran simulations for ECN+/TryOnce, and updated
Tables 1-6. Tables 1-6.
* Specified that the originator follows the traditional rules in * Specified that the originator follows the traditional rules in
setting the cumulative ack field for the ACK acking the SYN/ACK. setting the cumulative ack field for the ACK acking the SYN/ACK.
* Minor editing. * Minor editing.
Changes from draft-ietf-tcpm-ecnsyn-06: Changes from draft-ietf-tcpm-ecnsyn-06:
skipping to change at page 6, line 48 skipping to change at page 7, line 14
the router detects congestion before buffer overflow, the router can the router detects congestion before buffer overflow, the router can
provide a congestion indication either by dropping a packet, or by provide a congestion indication either by dropping a packet, or by
setting the Congestion Experienced (CE) codepoint in the Explicit setting the Congestion Experienced (CE) codepoint in the Explicit
Congestion Notification (ECN) field in the IP header [RFC3168]. The Congestion Notification (ECN) field in the IP header [RFC3168]. The
IETF has standardized the use of the Congestion Experienced (CE) IETF has standardized the use of the Congestion Experienced (CE)
codepoint in the IP header for routers to indicate congestion. For codepoint in the IP header for routers to indicate congestion. For
incremental deployment and backwards compatibility, the RFC on ECN incremental deployment and backwards compatibility, the RFC on ECN
[RFC3168] specifies that routers may mark ECN-capable packets that [RFC3168] specifies that routers may mark ECN-capable packets that
would otherwise have been dropped, using the Congestion Experienced would otherwise have been dropped, using the Congestion Experienced
codepoint in the ECN field. The use of ECN allows TCP to react to codepoint in the ECN field. The use of ECN allows TCP to react to
congestion while avoiding unnecessary retransmit timeouts. Thus, congestion while avoiding unnecessary retransmission timeouts. Thus,
using ECN has several benefits: using ECN has several benefits:
1) For short transfers, a TCP connection's congestion window may be 1) For short transfers, a TCP connection's congestion window may be
small. For example, if the current window contains only one packet, small. For example, if the current window contains only one packet,
and that packet is dropped, TCP will have to wait for a retransmit and that packet is dropped, TCP will have to wait for a
timeout to recover, reducing its overall throughput. Similarly, if retransmission timeout to recover, reducing its overall throughput.
the current window contains only a few packets and one of those Similarly, if the current window contains only a few packets and one
packets is dropped, there might not be enough duplicate of those packets is dropped, there might not be enough duplicate
acknowledgements for a fast retransmission, and the sender of the acknowledgements for a fast retransmission, and the sender of the
data packet might have to wait for a delay of several round-trip data packet might have to wait for a delay of several round-trip
times using Limited Transmit [RFC3042]. With the use of ECN, short times using Limited Transmit [RFC3042]. With the use of ECN, short
flows are less likely to have packets dropped, sometimes avoiding flows are less likely to have packets dropped, sometimes avoiding
unnecessary delays or costly retransmit timeouts. unnecessary delays or costly retransmission timeouts.
2) While longer flows may not see substantially improved throughput 2) While longer flows may not see substantially improved throughput
with the use of ECN, they may experience lower loss. This may benefit with the use of ECN, they may experience lower loss. This may benefit
TCP applications that are latency- and loss-sensitive, because of the TCP applications that are latency- and loss-sensitive, because of the
avoidance of retransmissions. avoidance of retransmissions.
RFC 3168 only specifies marking the Congestion Experienced codepoint RFC 3168 [RFC3168] specifies setting the ECN-Capable codepoint on TCP
on TCP's data packets, and not on SYN and SYN/ACK packets. RFC 3168 data packets, but not on TCP SYN and SYN/ACK packets. RFC 3168
specifies the negotiation of the use of ECN between the two TCP end- [RFC3168] specifies the negotiation of the use of ECN between the two
points in the TCP SYN and SYN-ACK exchange, using flags in the TCP TCP end-points in the TCP SYN and SYN-ACK exchange, using flags in
header. Erring on the side of being conservative, RFC 3168 does not the TCP header. Erring on the side of being conservative, RFC 3168
specify the use of ECN for the first SYN/ACK packet itself. However, [RFC3168] does not specify the use of ECN for the first SYN/ACK
because of the high cost to the TCP transfer of having a SYN/ACK packet itself. However, because of the high cost to the TCP transfer
packet dropped, with the resulting retransmit timeout, this document of having a SYN/ACK packet dropped, with the resulting retransmission
specifies the use of ECN for the SYN/ACK packet itself. This can be timeout, this document specifies the use of ECN for the SYN/ACK
of great benefit to the TCP connection, avoiding the severe penalty packet itself. This can be of great benefit to the TCP connection,
of a retransmit timeout for a connection that has not yet started avoiding the severe penalty of a retransmission timeout for a
placing a load on the network. The sender of the SYN/ACK packet must connection that has not yet started placing a load on the network.
respond to a report of an ECN-marked SYN/ACK packet (a router with The sender of the SYN/ACK packet must respond to a report of an ECN-
the CE codepoint set in the ECN field in the IP header) by sending a marked SYN/ACK packet (a SYN/ACK packet with the CE codepoint set in
non-ECN-Capable SYN/ACK packet, and by reducing its initial the ECN field in the IP header) by sending a non-ECN-Capable SYN/ACK
congestion window from two, three, or four segments to one segment, packet, and by reducing its initial congestion window from two,
reducing the subsequent load from that connection on the network. 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 retransmission 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 [RFC3168] to allow
packets to be ECN-Capable. Section 3 contains the specification of TCP SYN/ACK packets to be ECN-Capable. Section 3 contains the
the change, while Section 4 discusses some of the issues, and Section specification of the change, while Section 4 discusses some of the
5 discusses related work. Section 6 contains an evaluation of the issues, and Section 5 discusses related work. Section 6 contains an
specified change. evaluation of the specified change.
2. Conventions and Terminology 2. Conventions and Terminology
We use the following terminology from RFC 3168: We use the following terminology from RFC 3168 [RFC3168]:
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.
ECN-setup packets: ECN-setup packets:
o ECN-setup SYN packet: a SYN packet with the ECE and CWR flags; o ECN-setup SYN packet: a SYN packet with the ECE and CWR flags;
o ECN-setup SYN-ACK packet: a SYN-ACK packet with ECE but not CWR. o ECN-setup SYN-ACK packet: a SYN-ACK packet with ECE but not CWR.
In this document we use the terms "initiator" and "responder" to In this document we use the terms "initiator" and "responder" to
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 [RFC3168] to
SYN/ACK packets to be ECN-Capable. 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 Section 6.1.1 of RFC 3168 [RFC3168] states that "A host MUST NOT set
SYN or SYN-ACK packets." In this section, we specify that a TCP node ECT on SYN or SYN-ACK packets." In this section, we specify that a
may respond to an initial ECN-setup SYN packet by setting ECT in the TCP node may respond to an initial ECN-setup SYN packet by setting
responding ECN-setup SYN/ACK packet, indicating to routers that the ECT in the responding ECN-setup SYN/ACK packet, indicating to routers
SYN/ACK packet is ECN-Capable. This allows a congested router along that the SYN/ACK packet is ECN-Capable. This allows a congested
the path to mark the packet instead of dropping the packet as an router along the path to mark the packet instead of dropping the
indication of congestion. packet as an 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 [RFC3168], if TCP node B is willing to use ECN,
responds with an ECN-setup SYN-ACK packet. node B responds with an ECN-setup SYN-ACK packet.
3.1. SYN/ACK Packets Dropped in the Network 3.1. SYN/ACK Packets Dropped in the Network
Figure 1 shows an interchange with the SYN/ACK packet dropped by a Figure 1 shows an interchange with the SYN/ACK packet dropped by a
congested router. Node B waits for a retransmit timeout, and then congested router. Node B waits for a retransmission timeout, and
retransmits the SYN/ACK packet. then retransmits the 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, possibly ECT <--- ECN-setup SYN/ACK, possibly ECT
skipping to change at page 9, line 29 skipping to change at page 9, line 35
<--- ECN-setup SYN/ACK, not ECT <--- ECN-setup SYN/ACK, not ECT
<--- ECN-setup SYN/ACK <--- ECN-setup SYN/ACK
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 retransmission 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
skipping to change at page 10, line 22 skipping to change at page 10, line 30
---------- ------ ---------- ---------- ------ ----------
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
3-second timer set 3-second timer set
<--- Sets CE on SYN/ACK <--- Sets CE on SYN/ACK
<--- ECN-setup SYN/ACK, CE <--- ECN-setup SYN/ACK, CE
Data/ACK, ECN-Echo ---> ACK, ECN-Echo --->
Data/ACK, ECN-Echo ---> ACK, ECN-Echo --->
Window reduced to one segment. Window reduced to one segment.
<--- ECN-setup SYN/ACK, CWR, not ECT <--- ECN-setup SYN/ACK, not ECT
<--- ECN-setup SYN/ACK, CWR <--- ECN-setup SYN/ACK
Data/ACK ---> Data/ACK, ECT --->
Data/ACK ---> Data/ACK, ECT --->
<--- Data (one segment only) <--- Data, ECT (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
ECN-marked by the congested router, with the CE codepoint set, the ECN-marked by the congested router, with the CE codepoint set, the
initiator resets the retransmit timer. The initiator responds to the initiator restarts the retransmission timer. The initiator responds
ECN-marked SYN/ACK packet by setting the ECN-Echo flag in the TCP to the ECN-marked SYN/ACK packet by setting the ECN-Echo flag in the
header of the responding ACK packet. The initiator uses the standard TCP header of the responding ACK packet. The initiator uses the
rules in setting the cumulative acknowledgement field in the standard rules in setting the cumulative acknowledgement field in the
responding ACK packet. responding ACK packet.
However, with ECN+/TryOnce the initiator does not advance from the The initiator does not advance from the "SYN-Sent" to the
"SYN-Sent" to the "SYN-Received" state until it receives a SYN/ACK "Established" state until it receives a SYN/ACK packet that is not
packet that is not ECN-marked. As specified in RFC 3168, the ECN-marked.
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 sets the initial congestion window to one segment, instead responder sets the initial congestion window to one segment, instead
of two segments as allowed by [RFC2581], or three or four segments of two segments as allowed by [RFC2581], or three or four segments
allowed by [RFC3390]. With ECN+/TryOnce, illustrated in Figure 2, if allowed by [RFC3390]. As illustrated in Figure 2, if the responder
the responder (node B) receives an ECN-Echo packet informing it of a (node B) receives an ECN-Echo packet informing it of a Congestion
Congestion Experienced indication on its SYN/ACK packet, the Experienced indication on its SYN/ACK packet, the responder sends a
responder sends a SYN/ACK packet that is not ECN-Capable, in addition SYN/ACK packet that is not ECN-Capable, in addition to setting the
to setting the initial window to one segment. initial window to one segment. The responder does not advance the
send sequence number. The responder also sets the retransmission
timer. The responder follows RFC 2988 [RFC2988] in setting the RTO
(retransmission timeout).
We note that the mechanism in this document differs from RFC 3168, The TCP hosts follow the standard specification for the response to
which specifies that "the sending TCP MUST reset the retransmit timer duplicate SYN/ACK packets (e.g., Section 3.4 of RFC 793 [RFC793]).
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 We note that the mechanism in this document differs from RFC 3168
responder also sets the CWR flag in the TCP header of the next data [RFC3168], which specifies that "the sending TCP MUST restart the
packet sent, to acknowledge its receipt of and reaction to the ECN- retransmission timer on receiving the ECN-Echo packet when the
Echo flag. In contrast, this document describes that in response to congestion window is one." RFC 3168 [RFC3168] does not allow SYN/ACK
an ECN-Echo packet acknowledging the receipt of an ECN-Capable packets to be ECN-Capable. RFC 3168 [RFC3168] specifies that in
SYN/ACK packet, the responder sets the CWR flag in the TCP header of response to an ECN-Echo packet, the TCP responder also sets the CWR
the non-ECN-Capable SYN/ACK packet. flag in the TCP header of the next data packet sent, to acknowledge
its receipt of and reaction to the ECN-Echo flag. In contrast, in
response to an ECN-Echo packet acknowledging the receipt of an ECN-
Capable SYN/ACK packet, the TCP responder doesn't set the CWR flag,
but simply sends a SYN/ACK packet that is not ECN-Capable. On
receiving the non-ECN-Capable SYN/ACK packet, the TCP initiator
clears the ECN-Echo flag on replying packets.
--------------------------------------------------------------- ---------------------------------------------------------------
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
<--- Sets CE on SYN/ACK <--- Sets CE on SYN/ACK
<--- ECN-setup SYN/ACK, CE <--- ECN-setup SYN/ACK, CE
Data/ACK, ECN-Echo ---> ACK, ECN-Echo --->
Data/ACK, ECN-Echo ---> ACK, ECN-Echo --->
Window reduced to one segment. Window reduced to one segment.
<--- ECN-setup SYN/ACK, CWR, not ECT <--- ECN-setup SYN/ACK, not ECT
3-second timer set 3-second timer set
SYN/ACK dropped . SYN/ACK dropped .
. .
. .
3-second timer expires 3-second timer expires
<--- ECN-setup SYN/ACK, CWR, not ECT <--- ECN-setup SYN/ACK, not ECT
<--- ECN-setup SYN/ACK, CWR, not ECT <--- ECN-setup SYN/ACK, not ECT
Data/ACK ---> Data/ACK, ECT --->
Data/ACK ---> Data/ACK, ECT --->
<--- Data (one segment only) <--- Data, ECT (one segment only)
--------------------------------------------------------------- ---------------------------------------------------------------
Figure 3: SYN exchange with the first SYN/ACK packet marked, Figure 3: SYN exchange with the first SYN/ACK packet marked,
and the second SYN/ACK packet dropped. ECN+/TryOnce. and the second SYN/ACK packet dropped. ECN+/TryOnce.
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
skipping to change at page 13, line 19 skipping to change at page 13, line 19
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
setting one of the ECN-Capable codepoints in the IP header in the setting one of the ECN-Capable codepoints in the IP header in the
responding TCP SYN/ACK packet. responding TCP SYN/ACK packet.
There can be a great benefit in setting an ECN-capable codepoint in There can be a great benefit in setting an ECN-capable codepoint in
SYN/ACK packets, as is discussed further in [ECN+], and reported SYN/ACK packets, as is discussed further in [ECN+], and reported
briefly in Section 5 below. Congestion is most likely to occur in briefly in Section 5 below. Congestion is most likely to occur in
the server-to-client direction. As a result, setting an ECN-capable the server-to-client direction. As a result, setting an ECN-capable
codepoint in SYN/ACK packets can reduce the occurrence of three- codepoint in SYN/ACK packets can reduce the occurrence of three-
second retransmit timeouts resulting from the drop of SYN/ACK second retransmission timeouts resulting from the drop of SYN/ACK
packets. packets.
4.1. Flooding Attacks 4.1. Flooding Attacks
Setting an ECN-Capable codepoint in the responding TCP SYN/ACK Setting an ECN-Capable codepoint in the responding TCP SYN/ACK
packets does not raise any new or additional security packets does not raise any new or additional security
vulnerabilities. For example, provoking servers or hosts to send vulnerabilities. For example, provoking servers or hosts to send
SYN/ACK packets to a third party in order to perform a "SYN/ACK SYN/ACK packets to a third party in order to perform a "SYN/ACK
flood" attack would be highly inefficient. Third parties would flood" attack would be highly inefficient. Third parties would
immediately drop such packets, since they would know that they didn't immediately drop such packets, since they would know that they didn't
skipping to change at page 14, line 49 skipping to change at page 14, line 49
in terms of the drop or mark behavior at routers as a function of in terms of the drop or mark behavior at routers as a function of
packet size [Tools] (Section 10). We note that all of these packet size [Tools] (Section 10). We note that all of these
alternatives listed above are available in the NS simulator (Drop alternatives listed above are available in the NS simulator (Drop
Tail queues are by default in units of packets, while the default for Tail queues are by default in units of packets, while the default for
RED queue management has been changed from packet mode to byte mode). RED queue management has been changed from packet mode to byte mode).
4.4. Response to ECN-marking of SYN/ACK Packets 4.4. Response to ECN-marking of SYN/ACK Packets
One question is why TCP SYN/ACK packets should be treated differently One question is why TCP SYN/ACK packets should be treated differently
from other packets in terms of the end node's response to an ECN- from other packets in terms of the end node's response to an ECN-
marked packet. Section 5 of RFC 3168 specifies the following: marked packet. Section 5 of RFC 3168 [RFC3168] specifies the
following:
"Upon the receipt by an ECN-Capable transport of a single CE packet, "Upon the receipt by an ECN-Capable transport of a single CE packet,
the congestion control algorithms followed at the end-systems MUST be the congestion control algorithms followed at the end-systems MUST be
essentially the same as the congestion control response to a *single* essentially the same as the congestion control response to a *single*
dropped packet. For example, for ECN-Capable TCP the source TCP is dropped packet. For example, for ECN-Capable TCP the source TCP is
required to halve its congestion window for any window of data required to halve its congestion window for any window of data
containing either a packet drop or an ECN indication." containing either a packet drop or an ECN indication."
In particular, Section 6.1.2 of RFC 3168 specifies that when the TCP In particular, Section 6.1.2 of RFC 3168 [RFC3168] specifies that
congestion window consists of a single packet and that packet is ECN- when the TCP congestion window consists of a single packet and that
marked in the network, then the data sender must reduce the sending packet is ECN-marked in the network, then the data sender must reduce
rate below one packet per round-trip time, by waiting for one RTO the sending rate below one packet per round-trip time, by waiting for
before sending another packet. If the RTO was set to the average one RTO before sending another packet. If the RTO was set to the
round-trip time, this would result in halving the sending rate; average round-trip time, this would result in halving the sending
because the RTO is in fact larger than the average round-trip time, rate; because the RTO is in fact larger than the average round-trip
the sending rate is reduced to less than half of its previous value. time, the sending rate is reduced to less than half of its previous
value.
TCP's congestion control response to the *dropping* of a SYN/ACK TCP's congestion control response to the *dropping* of a SYN/ACK
packet is to wait a default time before sending another packet. This packet is to wait a default time before sending another packet. This
document argues that ECN gives end-systems a wider range of possible document argues that ECN gives end-systems a wider range of possible
responses to the *marking* of a SYN/ACK packet, and that waiting a responses to the *marking* of a SYN/ACK packet, and that waiting a
default time before sending another packet is not the desired default time before sending another packet is not the desired
response. response.
On the conservative end, one could assume an effective congestion On the conservative end, one could assume an effective congestion
window of one packet for the SYN/ACK packet, and respond to an ECN- window of one packet for the SYN/ACK packet, and respond to an ECN-
skipping to change at page 16, line 30 skipping to change at page 16, line 31
performance measures were the end-to-end response times for each performance measures were the end-to-end response times for each
request/response pair, and the aggregate throughput on the bottleneck request/response pair, and the aggregate throughput on the bottleneck
link. The end-to-end response time was computed as the time from the link. The end-to-end response time was computed as the time from the
moment when the request for the file is sent to the server, until moment when the request for the file is sent to the server, until
that file is successfully downloaded by the client. that file is successfully downloaded by the client.
The measurements from [ECN+] show that setting an ECN-Capable The measurements from [ECN+] show that setting an ECN-Capable
codepoint in the IP packet header in TCP SYN/ACK packets codepoint in the IP packet header in TCP SYN/ACK packets
systematically improves performance with all evaluated AQM schemes. systematically improves performance with all evaluated AQM schemes.
When SYN/ACK packets at a congested router are ECN-marked instead of When SYN/ACK packets at a congested router are ECN-marked instead of
dropped, this can avoid a long initial retransmit timeout, improving dropped, this can avoid a long initial retransmission timeout,
the response time for the affected flow dramatically. improving the response time for the affected flow dramatically.
[ECN+] shows that the impact on aggregate throughput can also be [ECN+] shows that the impact on aggregate throughput can also be
quite significant, because marking SYN ACK packets can prevent larger quite significant, because marking SYN ACK packets can prevent larger
flows from suffering long timeouts before being "admitted" into the flows from suffering long timeouts before being "admitted" into the
network. In addition, the testbed measurements from [ECN+] show that network. In addition, the testbed measurements from [ECN+] show that
web servers setting the ECN-Capable codepoint in TCP SYN/ACK packets web servers setting the ECN-Capable codepoint in TCP SYN/ACK packets
could serve more requests. could serve more requests.
As a final step, [ECN+] explores the co-existence of flows that do As a final step, [ECN+] explores the co-existence of flows that do
and don't set the ECN-capable codepoint in TCP SYN/ACK packets. The and don't set the ECN-capable codepoint in TCP SYN/ACK packets. The
skipping to change at page 17, line 23 skipping to change at page 17, line 23
dropped in the network, and for which the ECN-Capability would allow dropped in the network, and for which the ECN-Capability would allow
the SYN/ACK to be marked rather than dropped. the SYN/ACK to be marked rather than dropped.
The percent of SYN/ACK packets on a link can be quite high. In The percent of SYN/ACK packets on a link can be quite high. In
particular, measurements on links dominated by web traffic indicate particular, measurements on links dominated by web traffic indicate
that 15-20% of the packets can be SYN/ACK packets [SCJO01]. that 15-20% of the packets can be SYN/ACK packets [SCJO01].
The benefit of adding ECN-capability to SYN/ACK packets depends in The benefit of adding ECN-capability to SYN/ACK packets depends in
part on the size of the data transfer. The drop of a SYN/ACK packet part on the size of the data transfer. The drop of a SYN/ACK packet
can increase the download time of a short file by an order of can increase the download time of a short file by an order of
magnitude, by requiring a three-second retransmit timeout. For magnitude, by requiring a three-second retransmission timeout. For
longer-lived flows, the effect of a dropped SYN/ACK packet on file longer-lived flows, the effect of a dropped SYN/ACK packet on file
download time is less dramatic. However, even for longer-lived download time is less dramatic. However, even for longer-lived
flows, the addition of ECN-capability to SYN/ACK packets can improve flows, the addition of ECN-capability to SYN/ACK packets can improve
the fairness among long-lived flows, as newly-arriving flows would be the fairness among long-lived flows, as newly-arriving flows would be
less likely to have to wait for retransmit timeouts. less likely to have to wait for retransmission timeouts.
One question that arises is what fraction of connections would see One question that arises is what fraction of connections would see
the benefit from making SYN/ACK packets ECN-capable, in a particular the benefit from making SYN/ACK packets ECN-capable, in a particular
scenario. Specifically: scenario. Specifically:
(1) What fraction of arriving SYN/ACK packets are dropped at the (1) What fraction of arriving SYN/ACK packets are dropped at the
congested router when the SYN/ACK packets are not ECN-capable? congested router when the SYN/ACK packets are not ECN-capable?
(2) Of those SYN/ACK packets that are dropped, what fraction would (2) Of those SYN/ACK packets that are dropped, what fraction would
have been ECN-marked instead of dropped if the SYN/ACK packets had have been ECN-marked instead of dropped if the SYN/ACK packets had
skipping to change at page 18, line 47 skipping to change at page 18, line 47
However, Section 4 discussed two other possible responses to an ECN- However, Section 4 discussed two other possible responses to an ECN-
marked SYN/ACK packet. In ECN+, the original proposal from [ECN+], marked SYN/ACK packet. In ECN+, the original proposal from [ECN+],
the end node responds to the report of an ECN-marked SYN/ACK packet the end node responds to the report of an ECN-marked SYN/ACK packet
by setting the initial congestion window to one segment and by setting the initial congestion window to one segment and
immediately sending a data packet, if it has one to send. In immediately sending a data packet, if it has one to send. In
ECN+/Wait, the end node responds to the report of an ECN-marked ECN+/Wait, the end node responds to the report of an ECN-marked
SYN/ACK packet by setting the initial congestion window to one SYN/ACK packet by setting the initial congestion window to one
segment and waiting an RTT before sending a data packet. segment and waiting an RTT before sending a data packet.
Simulations comparing the performance with Standard ECN (without ECN- Simulations comparing the performance with Standard ECN (without ECN-
marked SYN/ACK packets), ECN+, and ECN+/Wait, and ECN/TryOnce show marked SYN/ACK packets), ECN+, ECN+/Wait, and ECN/TryOnce show little
little difference, in terms of aggregate congestion, between ECN+ and difference, in terms of aggregate congestion, between ECN+ and
ECN+/Wait. However, for some scenarios with queues that are packet- ECN+/Wait. However, for some scenarios with queues that are packet-
based rather than byte-based, and with packet drop rates above 25% based rather than byte-based, and with packet drop rates above 25%
without ECN+, the use of ECN+ or of ECN+/Wait can more than double without ECN+, the use of ECN+ or of ECN+/Wait can more than double
the packet drop rates, to greater than 50%. The details are given in the packet drop rates, to greater than 50%. The details are given in
Tables 1 and 3 of Appendix A below. ECN+/TryOnce does not increase Tables 1 and 3 of Appendix A below. ECN+/TryOnce does not increase
the packet drop rate in scenarios of high congestion. Therefore, the packet drop rate in scenarios of high congestion. Therefore,
ECN+/TryOnce is superior to ECN+ or to ECN+/Wait, which both ECN+/TryOnce is superior to ECN+ or to ECN+/Wait, which both
significantly increase the packet drop rate in scenarios of high significantly increase the packet drop rate in scenarios of high
congestion. At the same time, ECN+/TryOnce gives a performance congestion. At the same time, ECN+/TryOnce gives a performance
improvement similar to that of ECN+ or ECN+/Wait (Tables 2 and 4 of improvement similar to that of ECN+ or ECN+/Wait (Tables 2 and 4 of
skipping to change at page 20, line 36 skipping to change at page 20, line 36
The simulations reported in Appendix A show that even with demanding The simulations reported in Appendix A show that even with demanding
traffic mixes dominated by short flows and high levels of congestion, traffic mixes dominated by short flows and high levels of congestion,
the aggregate packet dropping rates are not significantly different the aggregate packet dropping rates are not significantly different
with Standard ECN or with ECN+/TryOnce. However, in our simulations, with Standard ECN or with ECN+/TryOnce. However, in our simulations,
we have one scenario where ECN+ or ECN+/Wait results in a we have one scenario where ECN+ or ECN+/Wait results in a
significantly higher packet drop rate than ECN or ECN+/TryOnce significantly higher packet drop rate than ECN or ECN+/TryOnce
(Tables 1 and 3 in Appendix A below). (Tables 1 and 3 in Appendix A below).
8. Conclusions 8. Conclusions
This draft specifies a modification to RFC 3168 to allow TCP nodes to This draft specifies a modification to RFC 3168 [RFC3168] to allow
send SYN/ACK packets as being ECN-Capable. Making the SYN/ACK packet TCP nodes to send SYN/ACK packets as being ECN-Capable. Making the
ECN-Capable avoids the high cost to a TCP transfer when a SYN/ACK SYN/ACK packet ECN-Capable avoids the high cost to a TCP transfer
packet is dropped by a congested router, by avoiding the resulting when a SYN/ACK packet is dropped by a congested router, by avoiding
retransmit timeout. This improves the throughput of short the resulting retransmission timeout. This improves the throughput
connections. This document specifies the ECN+/TryOnce mechanism for of short connections. This document specifies the ECN+/TryOnce
ECN-Capability for SYN/ACK packets, where the sender of the SYN/ACK mechanism for ECN-Capability for SYN/ACK packets, where the sender of
packet responds to an ECN mark by reducing its initial congestion the SYN/ACK packet responds to an ECN mark by reducing its initial
window from two, three, or four segments to one segment, and sending congestion window from two, three, or four segments to one segment,
a SYN/ACK packet that is not ECN-Capable. The addition of ECN- and sending a SYN/ACK packet that is not ECN-Capable. The addition
capability to SYN/ACK packets is particularly beneficial in the of ECN-capability to SYN/ACK packets is particularly beneficial in
server-to-client direction, where congestion is more likely to occur. the server-to-client direction, where congestion is more likely to
In this case, the initial information provided by the ECN marking in occur. In this case, the initial information provided by the ECN
the SYN/ACK packet enables the server to appropriately adjust the marking in the SYN/ACK packet enables the server to appropriately
initial load it places on the network, while avoiding the delay of a adjust the initial load it places on the network, while avoiding the
retransmit timeout. delay of a retransmission timeout.
9. Acknowledgements 9. Acknowledgements
We thank Anil Agarwal, Mark Allman, Remi Denis-Courmont, Wesley Eddy, We thank Anil Agarwal, Mark Allman, Remi Denis-Courmont, Wesley Eddy,
Lars Eggert, Alfred Hoenes, Janardhan Iyengar, and Pasi Sarolahti for Lars Eggert, Alfred Hoenes, Janardhan Iyengar, and Pasi Sarolahti for
feedback on earlier versions of this draft. We thank Adam Langley feedback on earlier versions of this draft. We thank Adam Langley
[L08] for contributing a patch for ECN+/TryOnce for the Linux [L08] for contributing a patch for ECN+/TryOnce for the Linux
development tree. development tree.
A. Report on Simulations A. Report on Simulations
skipping to change at page 22, line 31 skipping to change at page 22, line 31
each table showing a particular traffic load, the four rows show the each table showing a particular traffic load, the four rows show the
number of packets dropped, the number of packets ECN-marked, the number of packets dropped, the number of packets ECN-marked, the
aggregate packet drop rate, and the aggregate throughput, and the aggregate packet drop rate, and the aggregate throughput, and the
four columns show the simulations with Standard ECN, ECN+, ECN+/Wait, four columns show the simulations with Standard ECN, ECN+, ECN+/Wait,
and ECN+/TryOnce. and ECN+/TryOnce.
These simulations were run with RED set to mark instead of drop These simulations were run with RED set to mark instead of drop
packets any time that the queue is not full. This is a worst-case packets any time that the queue is not full. This is a worst-case
scenario for ECN+ and its variants. For the default implementation scenario for ECN+ and its variants. For the default implementation
of RED in the ns-2 simulator, when the average queue size exceeds a of RED in the ns-2 simulator, when the average queue size exceeds a
configured threshold. the router drops all arriving packets. For configured threshold, the router drops all arriving packets. For
scenarios with this RED mechanisms, it is less likely that ECN+ or scenarios with this RED mechanisms, it is less likely that ECN+ or
one of its variants would increase the average queue size above the one of its variants would increase the average queue size above the
configured threshold. configured threshold.
The usefulness of ECN+: The first thing to observe is that for all of The usefulness of ECN+: The first thing to observe is that for all of
the simulations, the use of ECN+ or ECN+/Wait significantly increases the simulations, the use of ECN+ or ECN+/Wait significantly increases
the number of packets marked. In contrast, the use of ECN+/TryOnce the number of packets marked. In contrast, the use of ECN+/TryOnce
significantly increases the number of packets marked in the significantly increases the number of packets marked in the
simulations with moderate congestion, and gives a more moderate simulations with moderate congestion, and gives a more moderate
increase in the number of packets marked for the simulations with increase in the number of packets marked for the simulations with
skipping to change at page 23, line 41 skipping to change at page 23, line 41
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 625,552 Dropped 600,628 1,746,768 2,176,530 625,552
Marked 418,433 1,166,450 1,164,932 439,847 Marked 418,433 1,166,450 1,164,932 439,847
Loss rate 25.45% 51.73% 56.87% 18.31% 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 = 150%
ECN ECN+ ECN+/Wait ECN+/TryOnce ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ---------- ------- ------- ------- ----------
Dropped 1,449,945 1,565,0517 1,563,0801 1,351,637 Dropped 1,449,945 1,565,0517 1,563,0801 1,351,637
Marked 669,840 583,378 591,315 684,715 Marked 669,840 583,378 591,315 684,715
Loss rate 46.7% 59.0% 59.0% 32.7% Loss rate 46.7% 59.0% 59.0% 32.7%
Throughput 88% 94% 94% 92% 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.
skipping to change at page 24, line 7 skipping to change at page 24, line 7
------- ------- ------- ---------- ------- ------- ------- ----------
Dropped 1,449,945 1,565,0517 1,563,0801 1,351,637 Dropped 1,449,945 1,565,0517 1,563,0801 1,351,637
Marked 669,840 583,378 591,315 684,715 Marked 669,840 583,378 591,315 684,715
Loss rate 46.7% 59.0% 59.0% 32.7% Loss rate 46.7% 59.0% 59.0% 32.7%
Throughput 88% 94% 94% 92% 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.42 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
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.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.27 0.46 0.59 0.72 0.75 0.75 0.88 0.88 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 = 95%
ECN ECN+ ECN+/Wait ECN+/TryOnce ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ---------- ------- ------- ------- ----------
Dropped 8,448 6,362 7,740 14,107 Dropped 8,448 6,362 7,740 14,107
Marked 9,891 16,787 17,456 16,132 Marked 9,891 16,787 17,456 16,132
Loss rate 5.5% 4.3% 5.0% 5.0% Loss rate 5.5% 4.3% 5.0% 5.0%
Throughput 78% 78% 78% 81% Throughput 78% 78% 78% 81%
Target Load = 1.10% Target Load = 110%
ECN ECN+ ECN+/Wait ECN+/TryOnce ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ---------- ------- ------- ------- ----------
Dropped 31,284 29,773 49,297 45,277 Dropped 31,284 29,773 49,297 45,277
Marked 28,429 54,729 60,383 34,622 Marked 28,429 54,729 60,383 34,622
Loss rate 15.3% 15.2% 21.9% 13.6% Loss rate 15.3% 15.2% 21.9% 13.6%
Throughput 97% 96% 96% 94% Throughput 97% 96% 96% 94%
Target Load = 1.25% Target Load = 125%
ECN ECN+ ECN+/Wait ECN+/TryOnce ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ---------- ------- ------- ------- ----------
Dropped 61,433 176,682 214,096 75,612 Dropped 61,433 176,682 214,096 75,612
Marked 44,408 119,728 117,301 49,442 Marked 44,408 119,728 117,301 49,442
Loss rate 25.4% 51.9% 56.0% 22.3% Loss rate 25.4% 51.9% 56.0% 22.3%
Throughput 97% 98% 98% 96% Throughput 97% 98% 98% 96%
Target Load = 1.50% Target Load = 150%
ECN ECN+ ECN+/Wait ECN+/TryOnce ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ---------- ------- ------- ------- ----------
Dropped 130,007 251,856 326,845 133,603 Dropped 130,007 251,856 326,845 133,603
Marked 63,066 146,757 147,239 66,444 Marked 63,066 146,757 147,239 66,444
Loss rate 42.5% 61.3% 67.3% 31.7% 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.
skipping to change at page 28, line 5 skipping to change at page 28, line 5
ECN ECN+ ECN+/Wait ECN+/TryOnce ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ---------- ------- ------- ------- ----------
Dropped 484,251 483,847 507,727 600,737 Dropped 484,251 483,847 507,727 600,737
Marked 865,905 872,254 873,317 818,451 Marked 865,905 872,254 873,317 818,451
Loss rate 19.09% 19.13% 19.71% 12.66% 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 = 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 = 110%
ECN ECN+ ECN+/Wait ECN+/TryOnce ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ---------- ------- ------- ------- ----------
Dropped 338 210 247 274 Dropped 338 210 247 274
Marked 41,676 40,412 44,173 36,265 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% 96% Throughput 94% 94% 94% 96%
Target Load = 1.25% Target Load = 125%
ECN ECN+ ECN+/Wait ECN+/TryOnce ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ---------- ------- ------- ------- ----------
Dropped 1,559 951 978 1,723 Dropped 1,559 951 978 1,723
Marked 74,933 75,499 75,481 59,670 Marked 74,933 75,499 75,481 59,670
Loss rate 0.8% 0.5% 0.5% 0.6% 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 = 150%
ECN ECN+ ECN+/Wait ECN+/TryOnce ECN ECN+ ECN+/Wait ECN+/TryOnce
------- ------- ------- ---------- ------- ------- ------- ----------
Dropped 2,374 1,528 1,515 4,848 Dropped 2,374 1,528 1,515 4,848
Marked 85,739 86,428 86,144 81,350 Marked 85,739 86,428 86,144 81,350
Loss rate 1.2% 0.8% 0.8% 1.4% 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.
skipping to change at page 30, line 6 skipping to change at page 30, line 6
packets immediately after the SYN/ACK exchange. Of course, with packets immediately after the SYN/ACK exchange. Of course, with
*severe* congestion, the SYN/ACK packets would likely be dropped *severe* congestion, the SYN/ACK packets would likely be dropped
rather than ECN-marked at the congested router, preventing the TCP rather than ECN-marked at the congested router, preventing the TCP
responder from adding to the congestion by sending its initial window responder from adding to the congestion by sending its initial window
of four data packets. of four data packets.
It is also possible that in some older TCP implementation, the It is also possible that in some older TCP implementation, the
initiator would ignore arriving SYN/ACK packets that had the ECT or initiator would ignore arriving SYN/ACK packets that had the ECT or
CE codepoint set. This would result in a delay in connection set-up CE codepoint set. This would result in a delay in connection set-up
for that TCP connection, with the initiator re-sending the SYN packet for that TCP connection, with the initiator re-sending the SYN packet
after a retransmit timeout. We are not aware of any TCP after a retransmission timeout. We are not aware of any TCP
implementations with this behavior. implementations with this behavior.
One possibility for coping with problems of backwards compatibility One possibility for coping with problems of backwards compatibility
would be for TCP initiators to use a TCP flag that means "I would be for TCP initiators to use a TCP flag that means "I
understand ECN-Capable SYN/ACK packets". If this document were to understand ECN-Capable SYN/ACK packets". If this document were to
standardize the use of such an "ECN-SYN" flag, then the TCP responder standardize the use of such an "ECN-SYN" flag, then the TCP responder
would only send a SYN/ACK packet as ECN-capable if the incoming SYN would only send a SYN/ACK packet as ECN-capable if the incoming SYN
packet had the "ECN-SYN" flag set. An ECN-SYN flag would prevent the packet had the "ECN-SYN" flag set. An ECN-SYN flag would prevent the
backwards compatibility problems described in the paragraphs above. backwards compatibility problems described in the paragraphs above.
skipping to change at page 30, line 40 skipping to change at page 30, line 40
implementations. This limits the scope of any backwards implementations. This limits the scope of any backwards
compatibility problems. compatibility problems.
(2) Limits to the scope of the problem: The backwards compatibility (2) Limits to the scope of the problem: The backwards compatibility
problem would not be serious enough to cause congestion collapse; problem would not be serious enough to cause congestion collapse;
with severe congestion, the buffer at the congested router will with severe congestion, the buffer at the congested router will
overflow, and the congested router will drop rather than ECN-mark overflow, and the congested router will drop rather than ECN-mark
arriving SYN packets. Some active queue management mechanisms might arriving SYN packets. Some active queue management mechanisms might
switch from packet-marking to packet-dropping in times of high switch from packet-marking to packet-dropping in times of high
congestion before buffer overflow, as recommended in Section 19.1 of congestion before buffer overflow, as recommended in Section 19.1 of
RFC 3168. This helps to prevent congestion collapse problems with RFC 3168 [RFC3168]. This helps to prevent congestion collapse
the use of ECN. problems with the use of ECN.
(3) Detection of and response to backwards-compatibility problems: A (3) Detection of and response to backwards-compatibility problems: A
TCP responder such as a web server can't differentiate between a TCP responder such as a web server can't differentiate between a
SYN/ACK packet that is not ECN-marked in the network, and a SYN/ACK SYN/ACK packet that is not ECN-marked in the network, and a SYN/ACK
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
skipping to change at page 31, line 41 skipping to change at page 31, line 41
Improved Controllers for AQM Routers Supporting TCP Flows, April Improved Controllers for AQM Routers Supporting TCP Flows, April
1998. 1998.
[RED] Floyd, S., and Jacobson, V. Random Early Detection gateways [RED] Floyd, S., and Jacobson, V. Random Early Detection gateways
for Congestion Avoidance . IEEE/ACM Transactions on Networking, V.1 for Congestion Avoidance . IEEE/ACM Transactions on Networking, V.1
N.4, August 1993. N.4, August 1993.
[REM] S. Athuraliya, V. H. Li, S. H. Low and Q. Yin, REM: Active [REM] S. Athuraliya, V. H. Li, S. H. Low and Q. Yin, REM: Active
Queue Management, IEEE Network, May 2001. Queue Management, IEEE Network, May 2001.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[RFC2309] B. Braden et al., Recommendations on Queue Management and [RFC2309] B. Braden et al., Recommendations on Queue Management and
Congestion Avoidance in the Internet, RFC 2309, April 1998. Congestion Avoidance in the Internet, RFC 2309, April 1998.
[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
 End of changes. 58 change blocks. 
151 lines changed or deleted 174 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/