draft-ietf-tcpm-ecnsyn-10.txt   rfc5562.txt 
Internet Engineering Task Force A. Kuzmanovic
INTERNET-DRAFT A. Mondal Network Working Group A. Kuzmanovic
Intended status: Experimental Northwestern University Request for Comments: 5562 A. Mondal
Expires: 25 November 2009 S. Floyd Category: Experimental Northwestern University
S. Floyd
ICSI ICSI
K.K. Ramakrishnan K. Ramakrishnan
AT&T AT&T Labs Research
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-10.txt
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This memo defines an Experimental Protocol for the Internet
provisions of BCP 78 and BCP 79. community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
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.
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
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on 25 November 2009.
Copyright Notice
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
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 Explicit
SYN/ACK packets. Congestion Notification (ECN) in TCP SYN/ACK packets.
This draft describes an optional, experimental modification to RFC This document 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 specifies setting an ECN-Capable codepoint on data packets, but 3168 specifies setting an ECN-Capable codepoint on data packets, but
not on SYN and SYN/ACK packets. However, because of the high cost to not on SYN and SYN/ACK packets. However, because of the high cost to
the TCP transfer of having a SYN/ACK packet dropped, with the the TCP transfer of having a SYN/ACK packet dropped, with the
resulting retransmission timeout, this document describes the use of resulting retransmission timeout, this document describes the use of
ECN for the SYN/ACK packet itself, when sent in response to a SYN ECN for the SYN/ACK packet itself, when sent in response to a SYN
packet with the two ECN flags set in the TCP header, indicating a 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 retransmission timeout for a connection that the severe penalty of a retransmission timeout for a connection that
skipping to change at page 3, line 7 skipping to change at page 3, line 7
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
retransmission timer). retransmission timer).
Table of Contents Table of Contents
1. Introduction ....................................................6 1. Introduction ....................................................3
2. Conventions and Terminology .....................................8 2. Conventions and Terminology .....................................5
3. Specification ...................................................9 3. Specification ...................................................6
3.1. SYN/ACK Packets Dropped in the Network .....................9 3.1. SYN/ACK Packets Dropped in the Network ....................7
3.2. SYN/ACK Packets ECN-Marked in the Network .................10 3.2. SYN/ACK Packets ECN-Marked in the Network .................8
3.3. Management Interface ......................................13 3.3. Management Interface .....................................10
4. Discussion .....................................................14 4. Discussion .....................................................11
4.1. Flooding Attacks ..........................................14 4.1. Flooding Attacks .........................................11
4.2. The TCP SYN Packet ........................................14 4.2. The TCP SYN Packet .......................................11
4.3. SYN/ACK Packets and Packet Size ...........................15 4.3. SYN/ACK Packets and Packet Size ..........................12
4.4. Response to ECN-marking of SYN/ACK Packets ................15 4.4. Response to ECN-Marking of SYN/ACK Packets ...............12
5. Related Work ...................................................17 5. Related Work ...................................................14
6. Performance Evaluation .........................................17 6. Performance Evaluation .........................................15
6.1. The Costs and Benefit of Adding ECN-Capability ............17 6.1. The Costs and Benefits of Adding ECN-Capability ..........15
6.2. An Evaluation of Different Responses to ECN-Marked SYN/ACK 6.2. An Evaluation of Different Responses to ECN-Marked
Packets ........................................................19 SYN/ACK Packets ..........................................16
6.3. Experiments ...............................................20 6.3. Experiments ..............................................17
7. Security Considerations ........................................20 7. Security Considerations ........................................18
7.1. 'Bad' Routers or Middleboxes ..............................20 7.1. "Bad" Routers or Middleboxes .............................18
7.2. Congestion Collapse .......................................21 7.2. Congestion Collapse ......................................18
8. Conclusions ....................................................21 8. Conclusions ....................................................19
9. Acknowledgements ...............................................22 9. Acknowledgements ...............................................19
A. Report on Simulations ..........................................22 Appendix A. Report on Simulations .................................20
A.1. Simulations with RED in Packet Mode .......................23 A.1. Simulations with RED in Packet Mode .......................20
A.2. Simulations with RED in Byte Mode .........................28 A.2. Simulations with RED in Byte Mode .........................25
B. Issues of Incremental Deployment ...............................30 Appendix B. Issues of Incremental Deployment ......................28
Normative References ..............................................33 Normative References ..............................................30
Informative References ............................................33 Informative References ............................................30
IANA Considerations ...............................................34
NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION.
Changes from draft-ietf-tcpm-ecnsyn-09:
* Added back Normative References and RFC 2119.
(These were deleted accidentally.)
IESG feedback from Pasi Eronen.
* Added Section 6.3 on a discussion of possible experiments.
IESG Feedback from Tim Polk.
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:
* 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 restarts the
retransmission timer when it receives an ECN-marked SYN/ACK.
Also reran simulations for ECN+/TryOnce, and updated
Tables 1-6.
* Specified that the originator follows the traditional rules in
setting the cumulative ack field for the ACK acking the SYN/ACK.
* Minor editing.
Changes from draft-ietf-tcpm-ecnsyn-06:
* Updated text and simulation results to specify ECN+/TryOnce
instead of ECN+. Added tables on CDFs.
* Acknowledged Adam's Linux implementation of ECN+/TryOnce.
Changes from draft-ietf-tcpm-ecnsyn-05:
* Added "Updates: 3168" to the header. Added a reference
to RFC 4987. Mild editing.
Feedback from Lars's Area Director review.
* Updated simulation results with new simulation scripts that
don't require any modifications to the ns simulator, and that
all use the same seed for generating traffic. The results are
somewhat different for the very-high-congestion scenarios
(with loss rates of 25% in the absence of ECN-capability
for SYN/ACK packets). This is reflected in the simulations with
a target load of 125% in Tables 1 and 2.
* Added the URL for the web page that has the simulation scripts.
Changes from draft-ietf-tcpm-ecnsyn-04:
* Updating the copyright date.
Changes from draft-ietf-tcpm-ecnsyn-03:
* General editing. This includes using the terms "initiator"
and "responder" for the two ends of the TCP connection.
Feedback from Alfred Hoenes.
* Added some text to the backwards compatibility discussion,
now in Appendix B, about the pros and cons of using a TCP
flag for the TCP initiator to signal that it understands
ECN-Capable SYN/ACK packets. The consensus at this time is
not to use such a flag. Also added a recommendation that
TCP implementations include a management interface to turn
off the use of ECN for SYN/ACK packets. From email from
Bob Briscoe.
Changes from draft-ietf-tcpm-ecnsyn-02:
* Added to the discussion in the Security section of whether
ECN-Capable TCP SYN packets have problems with firewalls,
over and above the known problems of TCP data packets
(e.g., as in the Microsoft report). From a question raised
at the TCPM meeting at the July 2007 IETF.
* Added a sentence to the discussion of routers or middleboxes that
*might* drop TCP SYN packets on the basis of IP header fields.
Feedback from Remi Denis-Courmont.
* General editing. Feedback from Alfred Hoenes.
Changes from draft-ietf-tcpm-ecnsyn-01:
* Changes in response to feedback from Anil Agarwal.
* Added a look at the costs of adding ECN-Capability to
SYN/ACKs in a highly-congested scenario.
From feedback from Mark Allman and Janardhan Iyengar.
* Added a comparative evaluation of two possible responses
to an ECN-marked SYN/ACK packet. From Mark Allman.
Changes from draft-ietf-tcpm-ecnsyn-00:
* Only updating the revision number.
Changes from draft-ietf-twvsg-ecnsyn-00:
* Changed name of draft to draft-ietf-tcpm-ecnsyn.
* Added a discussion in Section 3 of "Response to
ECN-marking of SYN/ACK packets". Based on
suggestions from Mark Allman.
* Added a discussion to the Conclusions about adding
ECN-capability to relevant set-up packets in other
protocols. From a suggestion from Wesley Eddy.
* Added a description of SYN exchanges with SYN cookies.
From a suggestion from Wesley Eddy.
* Added a discussion of one-way data transfers, where the
host sending the SYN/ACK packet sends no data packets.
* Minor editing, from feedback from Mark Allman and Janardhan
Iyengar.
* Future work: a look at the costs of adding
ECN-Capability in a worst-case scenario.
From feedback from Mark Allman and Janardhan Iyengar.
* Future work: a comparative evaluation of two
possible responses to an ECN-marked SYN/ACK packet.
Changes from draft-kuzmanovic-ecn-syn-00.txt:
* Changed name of draft to draft-ietf-twvsg-ecnsyn.
END OF NOTE TO RFC EDITOR.
1. Introduction 1. Introduction
TCP's congestion control mechanism has primarily used packet loss as TCP's congestion control mechanism has primarily used packet loss as
the congestion indication, with packets dropped when buffers the congestion indication, with packets dropped when buffers
overflow. With such tail-drop mechanisms, the packet delay can be overflow. With such tail-drop mechanisms, the packet delay can be
high, as the queue at bottleneck routers can be fairly large. high, as the queue at bottleneck routers can be fairly large.
Dropping packets only when the queue overflows, and having TCP react Dropping packets only when the queue overflows, and having TCP react
only to such losses, results in: only to such losses, results in:
1) significantly higher packet delay; 1) significantly higher packet delay;
2) unnecessarily many packet losses; and 2) unnecessarily many packet losses; and
3) unfairness due to synchronization effects. 3) unfairness due to synchronization effects.
The adoption of Active Queue Management (AQM) mechanisms allows The adoption of Active Queue Management (AQM) mechanisms allows
better control of bottleneck queues [RFC2309]. This use of AQM has better control of bottleneck queues [RFC2309]. This use of AQM has
the following potential benefits: the following potential benefits:
1) better control of the queue, with reduced queueing delay;
1) better control of the queue, with reduced queuing delay;
2) fewer packet drops; and 2) fewer packet drops; and
3) better fairness because of fewer synchronization effects. 3) better fairness because of fewer synchronization effects.
With the adoption of ECN, performance may be further improved. When With the adoption of ECN, performance may be further improved. When
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 retransmission 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
and that packet is dropped, TCP will have to wait for a packet, and that packet is dropped, TCP will have to wait for a
retransmission timeout to recover, reducing its overall throughput. retransmission timeout to recover, reducing its overall
Similarly, if the current window contains only a few packets and one throughput. Similarly, if the current window contains only a few
of those packets is dropped, there might not be enough duplicate packets and one of those packets is dropped, there might not be
acknowledgements for a fast retransmission, and the sender of the enough duplicate acknowledgements for a fast retransmission, and
data packet might have to wait for a delay of several round-trip the sender of the data packet might have to wait for a delay of
times using Limited Transmit [RFC3042]. With the use of ECN, short several round-trip times (RTT) using Limited Transmit [RFC3042].
flows are less likely to have packets dropped, sometimes avoiding With the use of ECN, short flows are less likely to have packets
unnecessary delays or costly retransmission timeouts. dropped, sometimes avoiding 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
TCP applications that are latency- and loss-sensitive, because of the benefit TCP applications that are latency- and loss-sensitive,
avoidance of retransmissions. because of the avoidance of retransmissions.
RFC 3168 [RFC3168] specifies setting the ECN-Capable codepoint on TCP RFC 3168 [RFC3168] specifies setting the ECN-Capable codepoint on TCP
data packets, but not on TCP SYN and SYN/ACK packets. RFC 3168 data packets, but not on TCP SYN and SYN/ACK packets. RFC 3168
[RFC3168] specifies the negotiation of the use of ECN between the two [RFC3168] 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 TCP endpoints in the TCP SYN and SYN-ACK exchange, using flags in the
the TCP header. Erring on the side of being conservative, RFC 3168 TCP header. Erring on the side of being conservative, RFC 3168
[RFC3168] does not specify the use of ECN for the first SYN/ACK [RFC3168] does not specify the use of ECN for the first SYN/ACK
packet itself. However, because of the high cost to the TCP transfer packet itself. However, because of the high cost to the TCP transfer
of having a SYN/ACK packet dropped, with the resulting retransmission of having a SYN/ACK packet dropped, with the resulting retransmission
timeout, this document specifies the use of ECN for the SYN/ACK timeout, this document specifies the use of ECN for the SYN/ACK
packet itself. This can be of great benefit to the TCP connection, packet itself. This can be of great benefit to the TCP connection,
avoiding the severe penalty of a retransmission timeout for a avoiding the severe penalty of a retransmission timeout for a
connection that has not yet started placing a load on the network. connection that has not yet started placing a load on the network.
The sender of the SYN/ACK packet must respond to a report of an ECN- The sender of the SYN/ACK packet must respond to a report of an ECN-
marked SYN/ACK packet (a SYN/ACK packet with the CE codepoint set in marked SYN/ACK packet (a SYN/ACK packet with the CE codepoint set in
the ECN field in the IP header) by sending a non-ECN-Capable SYN/ACK the ECN field in the IP header) by sending a non-ECN-Capable SYN/ACK
skipping to change at page 8, line 17 skipping to change at page 5, line 19
connection that has not yet started placing a load on the network. connection that has not yet started placing a load on the network.
The sender of the SYN/ACK packet must respond to a report of an ECN- The sender of the SYN/ACK packet must respond to a report of an ECN-
marked SYN/ACK packet (a SYN/ACK packet with the CE codepoint set in marked SYN/ACK packet (a SYN/ACK packet with the CE codepoint set in
the ECN field in the IP header) by sending a non-ECN-Capable SYN/ACK the ECN field in the IP header) by sending a non-ECN-Capable SYN/ACK
packet, and by reducing its initial congestion window from two, packet, and by reducing its initial congestion window from two,
three, or four segments to one segment, reducing the subsequent load three, or four segments to one segment, reducing the subsequent load
from that connection on the network. 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 retransmission 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 [RFC3168] to allow This document specifies a modification to RFC 3168 [RFC3168] to allow
TCP SYN/ACK packets to be ECN-Capable. Section 3 contains the TCP SYN/ACK packets to be ECN-Capable. Section 3 contains the
specification of the change, while Section 4 discusses some of the specification of the change, while Section 4 discusses some of the
issues, and Section 5 discusses related work. Section 6 contains an issues, and Section 5 discusses related work. Section 6 contains an
evaluation of the specified change. evaluation of the specified change.
2. Conventions and Terminology 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 8, line 35 skipping to change at page 5, line 39
2. Conventions and Terminology 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
We use the following terminology from RFC 3168 [RFC3168]: 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 [RFC3168] to This section specifies the modification to RFC 3168 [RFC3168] to
allow TCP SYN/ACK packets to be ECN-Capable. allow TCP SYN/ACK packets to be ECN-Capable.
Section 6.1.1 of RFC 3168 [RFC3168] states that "A host MUST NOT set Section 6.1.1 of RFC 3168 [RFC3168] states that "A host MUST NOT set
ECT on SYN or SYN-ACK packets." In this section, we specify that a ECT on SYN or SYN-ACK packets". In this section, we specify that a
TCP node may respond to an initial ECN-setup SYN packet by setting TCP node may respond to an initial ECN-setup SYN packet by setting
ECT in the responding ECN-setup SYN/ACK packet, indicating to routers ECT in the responding ECN-setup SYN/ACK packet, indicating to routers
that the SYN/ACK packet is ECN-Capable. This allows a congested that the SYN/ACK packet is ECN-Capable. This allows a congested
router along the path to mark the packet instead of dropping the router along the path to mark the packet instead of dropping the
packet as an 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 [RFC3168], if TCP node B is willing to use ECN, specified by RFC 3168 [RFC3168], if TCP node B is willing to use ECN,
node B responds with an ECN-setup SYN-ACK packet. node B responds with an ECN-setup SYN-ACK packet.
skipping to change at page 9, line 50 skipping to change at page 7, line 32
. .
. .
3-second timer expires 3-second timer expires
<--- 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 retransmission 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
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
another SYN-ACK. another SYN-ACK.
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
skipping to change at page 11, line 29 skipping to change at page 8, line 41
ACK, ECN-Echo ---> ACK, ECN-Echo --->
Window reduced to one segment. Window reduced to one segment.
<--- ECN-setup SYN/ACK, not ECT <--- ECN-setup SYN/ACK, not ECT
<--- ECN-setup SYN/ACK <--- ECN-setup SYN/ACK
Data/ACK, ECT ---> Data/ACK, ECT --->
Data/ACK, ECT ---> Data/ACK, ECT --->
<--- Data, ECT (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 restarts the retransmission timer. The initiator responds initiator restarts the retransmission timer. The initiator responds
to the ECN-marked SYN/ACK packet by setting the ECN-Echo flag in the to the ECN-marked SYN/ACK packet by setting the ECN-Echo flag in the
TCP header of the responding ACK packet. The initiator uses the TCP header of the responding ACK packet. The initiator uses the
standard 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.
The initiator does not advance from the "SYN-Sent" to the The initiator does not advance from the "SYN-Sent" to the
skipping to change at page 12, line 15 skipping to change at page 9, line 28
send sequence number. The responder also sets the retransmission send sequence number. The responder also sets the retransmission
timer. The responder follows RFC 2988 [RFC2988] in setting the RTO timer. The responder follows RFC 2988 [RFC2988] in setting the RTO
(retransmission timeout). (retransmission timeout).
The TCP hosts follow the standard specification for the response to The TCP hosts follow the standard specification for the response to
duplicate SYN/ACK packets (e.g., Section 3.4 of RFC 793 [RFC793]). duplicate SYN/ACK packets (e.g., Section 3.4 of RFC 793 [RFC793]).
We note that the mechanism in this document differs from RFC 3168 We note that the mechanism in this document differs from RFC 3168
[RFC3168], which specifies that "the sending TCP MUST restart the [RFC3168], which specifies that "the sending TCP MUST restart the
retransmission timer on receiving the ECN-Echo packet when the retransmission timer on receiving the ECN-Echo packet when the
congestion window is one." RFC 3168 [RFC3168] does not allow SYN/ACK congestion window is one". RFC 3168 [RFC3168] does not allow SYN/ACK
packets to be ECN-Capable. RFC 3168 [RFC3168] specifies that in packets to be ECN-Capable. RFC 3168 [RFC3168] specifies that in
response to an ECN-Echo packet, the TCP responder also sets the CWR response to an ECN-Echo packet, the TCP responder also sets the CWR
flag in the TCP header of the next data packet sent, to acknowledge 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 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- 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, 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 but simply sends a SYN/ACK packet that is not ECN-Capable. On
receiving the non-ECN-Capable SYN/ACK packet, the TCP initiator receiving the non-ECN-Capable SYN/ACK packet, the TCP initiator
clears the ECN-Echo flag on replying packets. clears the ECN-Echo flag on replying packets.
skipping to change at page 13, line 34 skipping to change at page 10, line 34
. .
. .
3-second timer expires 3-second timer expires
<--- ECN-setup SYN/ACK, not ECT <--- ECN-setup SYN/ACK, not ECT
<--- ECN-setup SYN/ACK, not ECT <--- ECN-setup SYN/ACK, not ECT
Data/ACK, ECT ---> Data/ACK, ECT --->
Data/ACK, ECT ---> Data/ACK, ECT --->
<--- Data, ECT (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
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
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 retransmission 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
generate the TCP SYN packets in the first place. Moreover, such generate the TCP SYN packets in the first place. Moreover, such
SYN/ACK attacks would have the same signatures as the existing TCP SYN/ACK attacks would have the same signatures as the existing TCP
SYN attacks. Provoking servers or hosts to reply with SYN/ACK packets SYN attacks. Provoking servers or hosts to reply with SYN/ACK
in order to congest a certain link would also be highly inefficient packets in order to congest a certain link would also be highly
because SYN/ACK packets are small in size. inefficient 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 Random
packet mode, small and large packets are equally likely to be dropped Early Detection (RED) in packet mode, small and large packets are
or marked, while for RED in byte mode, a packet's chance of being equally likely to be dropped or marked, while for RED in byte mode, a
dropped or marked is proportional to the packet size in bytes. packet's chance of being dropped or marked is proportional to the
packet size in bytes.
For a congested router with an AQM mechanism in byte mode, where a For a congested router with an AQM mechanism in byte mode, where a
packet's chance of being dropped or marked is proportional to the packet's chance of being dropped or marked is proportional to the
packet size in bytes, the drop or marking rate for TCP SYN/ACK packet size in bytes, the drop or marking rate for TCP SYN/ACK
packets should generally be low. In this case, the benefit of making packets should generally be low. In this case, the benefit of making
SYN/ACK packets ECN-Capable should be similarly moderate. However, SYN/ACK packets ECN-Capable should be similarly moderate. However,
for a congested router with a Drop Tail queue in units of packets or for a congested router with a Drop-Tail queue in units of packets or
with an AQM mechanism in packet mode, and with no priority queueing with an AQM mechanism in packet mode, and with no priority queuing
for smaller packets, small and large packets should have the same for smaller packets, small and large packets should have the same
probability of being dropped or marked. In such a case, making probability of being dropped or marked. In such a case, making
SYN/ACK packets ECN-Capable should be of significant benefit. SYN/ACK packets ECN-Capable should be of significant benefit.
We believe that there are a wide range of behaviors in the real world We believe that there are a wide range of behaviors in the real world
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 (see Section 10 of [Tools]). 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 [RFC3168] specifies the marked packet. Section 5 of RFC 3168 [RFC3168] specifies the
following: 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
the congestion control algorithms followed at the end-systems MUST be packet, the congestion control algorithms followed at the end-
essentially the same as the congestion control response to a *single* systems MUST be essentially the same as the congestion control
dropped packet. For example, for ECN-Capable TCP the source TCP is response to a *single* dropped packet. For example, for ECN-
required to halve its congestion window for any window of data Capable TCP the source TCP is required to halve its congestion
containing either a packet drop or an ECN indication." window for any window of data containing either a packet drop or
an ECN indication.
In particular, Section 6.1.2 of RFC 3168 [RFC3168] specifies that In particular, Section 6.1.2 of RFC 3168 [RFC3168] specifies that
when the TCP congestion window consists of a single packet and that when the TCP congestion window consists of a single packet and that
packet is ECN-marked in the network, then the data sender must reduce packet is ECN-marked in the network, then the data sender must reduce
the sending rate below one packet per round-trip time, by waiting for the sending rate below one packet per round-trip time, by waiting for
one RTO before sending another packet. If the RTO was set to the one RTO before sending another packet. If the RTO was set to the
average round-trip time, this would result in halving the sending average round-trip time, this would result in halving the sending
rate; because the RTO is in fact larger than the average round-trip rate; because the RTO is in fact larger than the average round-trip
time, the sending rate is reduced to less than half of its previous time, the sending rate is reduced to less than half of its previous
value. value.
skipping to change at page 16, line 27 skipping to change at page 13, line 33
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-
marked SYN/ACK packet by reducing the sending rate to one packet marked SYN/ACK packet by reducing the sending rate to one packet
every two round-trip times. As an approximation, the TCP end-node every two round-trip times. As an approximation, the TCP end node
could measure the round-trip time T between the sending of the could measure the round-trip time T between the sending of the
SYN/ACK packet and the receipt of the acknowledgement, and reply to SYN/ACK packet and the receipt of the acknowledgement, and reply to
the acknowledgement of the ECN-marked SYN/ACK packet by waiting T the acknowledgement of the ECN-marked SYN/ACK packet by waiting T
seconds before sending a data packet. seconds before sending a data packet.
However, we note that for an ECN-marked SYN/ACK packet, halving the However, we note that for an ECN-marked SYN/ACK packet, halving the
*congestion window* is not the same as halving the *sending rate*; *congestion window* is not the same as halving the *sending rate*;
there is no `sending rate' associated with an ECN-Capable SYN/ACK there is no "sending rate" associated with an ECN-Capable SYN/ACK
packet, as such packets are only sent as the first packet in a packet, as such packets are only sent as the first packet in a
connection from that host. Further, a router's marking of a SYN/ACK connection from that host. Further, a router's marking of a SYN/ACK
packet is not affected by any past history of that connection. packet is not affected by any past history of that connection.
Adding ECN-Capability to SYN/ACK packets allows the response of the Adding ECN-Capability to SYN/ACK packets allows the response of the
responder setting the initial congestion window to one packet, responder setting the initial congestion window to one packet,
instead of its allowed default value of two, three, or four packets. instead of its allowed default value of two, three, or four packets.
The responder sends a non-ECN-Capable SYN/ACK packet, and proceeds The responder sends a non-ECN-Capable SYN/ACK packet, and proceeds
with a cautious sending rate of one data packet per round-trip time with a cautious sending rate of one data packet per round-trip time
after that SYN/ACK packet is acknowledged. This document argues that after that SYN/ACK packet is acknowledged. This document argues that
this approach is useful to users, with no dangers of congestion this approach is useful to users, with no dangers of congestion
collapse or of starvation of competing traffic. This is discussed in collapse or of starvation of competing traffic. This is discussed in
more detail below in Section 6.2. more detail below in Section 6.2.
We note that if the data transfer is entirely from Node A to Node B, We note that if the data transfer is entirely from node A to node B,
there is still a difference in performance between the original there is still a difference in performance between the original
mechanism ECN+ and the mechanism ECN+/TryOnce specified in this mechanism ECN+ and the mechanism ECN+/TryOnce specified in this
document. In particular, with ECN+/TryOnce the TCP originator does document. In particular, with ECN+/TryOnce, the TCP originator does
not send data packets until it has received a non-ECN-marked SYN/ACK not send data packets until it has received a non-ECN-marked SYN/ACK
packet from the other end. packet from the other end.
5. Related Work 5. Related Work
The addition of ECN-capability to TCP's SYN/ACK packets was initially The addition of ECN-Capability to TCP's SYN/ACK packets was initially
proposed in [ECN+]. The paper includes an extensive set of proposed in [ECN+]. The paper includes an extensive set of
simulation and testbed experiments to evaluate the effects of the simulation and testbed experiments to evaluate the effects of the
proposal, using several Active Queue Management (AQM) mechanisms, proposal, using several Active Queue Management (AQM) mechanisms,
including Random Early Detection (RED) [RED], Random Exponential including Random Early Detection (RED) [RED], Random Exponential
Marking (REM) [REM], and Proportional Integrator (PI) [PI]. The Marking (REM) [REM], and Proportional Integrator (PI) [PI]. The
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.
skipping to change at page 17, line 37 skipping to change at page 14, line 45
dropped, this can avoid a long initial retransmission timeout, dropped, this can avoid a long initial retransmission timeout,
improving 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 coexistence of flows that do and
and don't set the ECN-capable codepoint in TCP SYN/ACK packets. The don't set the ECN-Capable codepoint in TCP SYN/ACK packets. The
results in [ECN+] show that both types of flows can coexist, with results in [ECN+] show that both types of flows can coexist, with
some performance degradation for flows that don't use ECN+. Flows some performance degradation for flows that don't use ECN+. Flows
that do use ECN+ improve their end-to-end performance. At the same that do use ECN+ improve their end-to-end performance. At the same
time, the performance degradation for flows that don't use ECN+, as a time, the performance degradation for flows that don't use ECN+, as a
result of the flows that do use ECN+, increases as a greater fraction result of the flows that do use ECN+, increases as a greater fraction
of flows use ECN+. of flows use ECN+.
6. Performance Evaluation 6. Performance Evaluation
6.1. The Costs and Benefit of Adding ECN-Capability 6.1. The Costs and Benefits of Adding ECN-Capability
[ECN+] explores the costs and benefits of adding ECN-Capability to [ECN+] explores the costs and benefits of adding ECN-Capability to
SYN/ACK packets with both simulations and experiments. The addition SYN/ACK packets with both simulations and experiments. The addition
of ECN-capability to SYN/ACK packets could be of significant benefit of ECN-Capability to SYN/ACK packets could be of significant benefit
for those ECN connections that would have had the SYN/ACK packet for those ECN connections that would have had the SYN/ACK packet
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 retransmission 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 retransmission 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
been ECN-capable? had been ECN-Capable?
To answer (1), it is necessary to consider not only the level of To answer (1), it is necessary to consider not only the level of
congestion but also the queue architecture at the congested link. As congestion but also the queue architecture at the congested link. As
described in Section 4 above, for some queue architectures small described in Section 4 above, for some queue architectures, small
packets are less likely to be dropped than large ones. In such an packets are less likely to be dropped than large ones. In such an
environment, SYN/ACK packets would have lower packet drop rates; environment, SYN/ACK packets would have lower packet drop rates;
question (1) could not necessarily be inferred from the overall question (1) could not necessarily be inferred from the overall
packet drop rate, but could be answered by measuring the drop rate packet drop rate, but could be answered by measuring the drop rate
for SYN/ACK packets directly. In such an environment, adding ECN- for SYN/ACK packets directly. In such an environment, adding ECN-
capability to SYN/ACK packets would be of less dramatic benefit than Capability to SYN/ACK packets would be of less dramatic benefit than
in environments where all packets are equally likely to be dropped in environments where all packets are equally likely to be dropped
regardless of packet size. regardless of packet size.
As question (2) implies, even if all of the SYN/ACK packets were ECN- As question (2) implies, even if all of the SYN/ACK packets were
capable, there could still be some SYN/ACK packets dropped instead of ECN-Capable, there could still be some SYN/ACK packets dropped
marked at the congested link; the full answer to question (2) depends instead of marked at the congested link; the full answer to question
on the details of the queue management mechanism at the router. If (2) depends on the details of the queue management mechanism at the
congestion is sufficiently bad, and the queue management mechanism router. If congestion is sufficiently bad, and the queue management
cannot prevent the buffer from overflowing, then SYN/ACK packets will mechanism cannot prevent the buffer from overflowing, then SYN/ACK
be dropped rather than marked upon buffer overflow whether or not packets will be dropped rather than marked upon buffer overflow
they are ECN-capable. whether or not they are ECN-Capable.
For some AQM mechanisms, ECN-capable packets are marked instead of For some AQM mechanisms, ECN-Capable packets are marked instead of
dropped any time this is possible, that is, any time the buffer is dropped any time this is possible, that is, any time the buffer is
not yet full. For other AQM mechanisms however, such as the RED not yet full. For other AQM mechanisms however, such as the RED
mechanism as recommended in [RED], packets are dropped rather than mechanism as recommended in [RED], packets are dropped rather than
marked when the packet drop/mark rate exceeds a certain threshold, marked when the packet drop/mark rate exceeds a certain threshold,
e.g., 10%, even if the packets are ECN-capable. For a router with e.g., 10%, even if the packets are ECN-Capable. For a router with
such an AQM mechanism, when congestion is sufficiently severe to such an AQM mechanism, when congestion is sufficiently severe to
cause a high drop/mark rate, some SYN/ACK packets would be dropped cause a high drop/mark rate, some SYN/ACK packets would be dropped
instead of marked whether or not they were ECN-capable. instead of marked whether or not they were ECN-Capable.
Thus, the degree of benefit of adding ECN-Capability to SYN/ACK Thus, the degree of benefit of adding ECN-Capability to SYN/ACK
packets depends not only on the overall packet drop rate in the packets depends not only on the overall packet drop rate in the
network, but also on the queue management architecture at the network, but also on the queue management architecture at the
congested link. congested link.
6.2. An Evaluation of Different Responses to ECN-Marked SYN/ACK Packets 6.2. An Evaluation of Different Responses to ECN-Marked SYN/ACK Packets
This document specifies that the end-node responds to the report of This document specifies that the end node responds to the report of
an ECN-marked SYN/ACK packet by setting the initial congestion window an ECN-marked SYN/ACK packet by setting the initial congestion window
to one segment, instead of its possible default value of two to four to one segment, instead of its possible default value of two to four
segments, and resending a SYN/ACK packet that is not ECN-Capable. We segments, and resending a SYN/ACK packet that is not ECN-Capable. We
call this ECN+/TryOnce. call this ECN+/TryOnce.
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
marked SYN/ACK packets), ECN+, ECN+/Wait, and ECN/TryOnce show little ECN-marked SYN/ACK packets), ECN+, ECN+/Wait, and ECN/TryOnce show
difference, in terms of aggregate congestion, between ECN+ and little 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
Appendix A). Appendix A).
Our conclusions are that ECN+/TryOnce is safe, and has significant Our conclusions are that ECN+/TryOnce is safe, and has significant
benefits to the user, and avoids the problems of ECN+ or ECN+/Wait benefits to the user, and avoids the problems of ECN+ or ECN+/Wait
under extreme levels of congestion. As a consequence, this document under extreme levels of congestion. As a consequence, this document
specifies the use of ECN+/TryOnce. specifies the use of ECN+/TryOnce.
[Note: We only discovered the occasional congestion-related problems Note: We only discovered the occasional congestion-related problems
of ECN+ and of ECN+/Wait when re-running the simulations with an of ECN+ and of ECN+/Wait when re-running the simulations with an
updated version of the ns-2 simulator, after the internet-draft had updated version of the ns-2 simulator, after the document had almost
almost completed the standardization process.] completed the standardization process.
6.3. Experiments 6.3. Experiments
This section discusses experiments that would be useful before a This section discusses experiments that would be useful before a
widespread deployment of ECN-Capability for TCP SYN/ACK packets. widespread deployment of ECN-Capability for TCP SYN/ACK packets.
Section 7.1 below discusses some of the know deployment problems of Section 7.1 below discusses some of the known deployment problems of
ECN, in terms of routers or middleboxes that react inappropriately to ECN, in terms of routers or middleboxes that react inappropriately to
packets that use ECN codepoints in the IP or TCP packet headers. One packets that use ECN codepoints in the IP or TCP packet headers. One
goal of a measurement study of ECN-Capablility for TCP SYN/ACK goal of a measurement study of ECN-Capability for TCP SYN/ACK packets
packets would be to determine if there were any routers or would be to determine if there were any routers or middleboxes that
middleboxes that react inappropriately to TCP SYN/ACK packets react inappropriately to TCP SYN/ACK packets containing an ECN-
containing an ECN-Capable or CE codepoint in the IP header. A second Capable or CE codepoint in the IP header. A second goal of a
goal of a measurement study would be to check the deployment status measurement study would be to check the deployment status of older
of older TCP implementations that are ECN-Capable, but that don't TCP implementations that are ECN-Capable, but that don't respond to
respond to ECN-Capability for SYN/ACK packets. (This is discussed in ECN-Capability for SYN/ACK packets. (This is discussed in more
more detail in Appendix B below.) detail in Appendix B below.)
Following the discussion in Section 6.2, an experimental study could Following the discussion in Section 6.2, an experimental study could
explore the use of ECN-Capability for TCP SYN/ACK packets in highly- explore the use of ECN-Capability for TCP SYN/ACK packets in highly
congested environments with ECN-capable routers. congested environments with ECN-Capable routers.
7. Security Considerations 7. Security Considerations
TCP packets carrying the ECT codepoint in IP headers can be marked TCP packets carrying the ECT codepoint in IP headers can be marked
rather than dropped by ECN-capable routers. This raises several rather than dropped by ECN-Capable routers. This raises several
security concerns that we discuss below. security concerns that we discuss below.
7.1. 'Bad' Routers or Middleboxes 7.1. "Bad" Routers or Middleboxes
There are a number of known deployment problems from using ECN with There are a number of known deployment problems from using ECN with
TCP traffic in the Internet. The first reported problem, dating back TCP traffic in the Internet. The first reported problem, dating back
to 2000, is of a small but decreasing number of routers or to 2000, is of a small but decreasing number of routers or
middleboxes that reset a TCP connection in response to TCP SYN middleboxes that reset a TCP connection in response to TCP SYN
packets using flags in the TCP header to negotiate ECN-capability packets using flags in the TCP header to negotiate ECN-Capability
IETF of new two problems encountered by TCP connections using ECN; IETF of two new problems encountered by TCP connections using ECN;
the first of the two problems concerns routers that crash when a TCP the first of the two problems concerns routers that crash when a TCP
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 (see figure 1 of [MAF05].) Thus,
specified in Section 3, if a SYN/ACK packet with the ECT or CE as specified in Section 3, if a SYN/ACK packet with the ECT or CE
codepoint is dropped, the TCP node should resend the SYN/ACK packet codepoint is dropped, the TCP node should resend the SYN/ACK packet
without the ECN-Capable codepoint. There is also no evidence that 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-
marked instead of dropped at an ECN-capable router, the concern is marked instead of dropped at an ECN-Capable router, the concern is
whether this can either invoke congestion, or worsen performance in whether this can either invoke congestion or worsen performance in
highly congested scenarios. However, after learning that a SYN/ACK highly congested scenarios. However, after learning that a SYN/ACK
packet was ECN-marked, the responder sends a SYN/ACK packet that is packet was ECN-marked, the responder sends a SYN/ACK packet that is
not ECN-Capable; if this SYN/ACK packet is dropped, the responder not ECN-Capable; if this SYN/ACK packet is dropped, the responder
then waits for a retransmission timeout, as specified in the TCP then waits for a retransmission timeout, as specified in the TCP
standards. In addition, routers are free to drop rather than mark standards. In addition, routers are free to drop rather than mark
arriving packets in times of high congestion, regardless of whether arriving packets in times of high congestion, regardless of whether
the packets are ECN-capable. When congestion is very high and a the packets are ECN-Capable. When congestion is very high and a
router's buffer is full, the router has no choice but to drop rather router's buffer is full, the router has no choice but to drop rather
than to mark an arriving packet. than to mark an arriving packet.
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 [RFC3168] to allow This document specifies a modification to RFC 3168 [RFC3168] to allow
TCP nodes to send SYN/ACK packets as being ECN-Capable. Making the TCP nodes to send SYN/ACK packets as being ECN-Capable. Making the
SYN/ACK packet ECN-Capable avoids the high cost to a TCP transfer SYN/ACK packet ECN-Capable avoids the high cost to a TCP transfer
when a SYN/ACK packet is dropped by a congested router, by avoiding when a SYN/ACK packet is dropped by a congested router, by avoiding
the resulting retransmission timeout. This improves the throughput the resulting retransmission timeout. This improves the throughput
of short connections. This document specifies the ECN+/TryOnce of short connections. This document specifies the ECN+/TryOnce
mechanism for ECN-Capability for SYN/ACK packets, where the sender of mechanism for ECN-Capability for SYN/ACK packets, where the sender of
the SYN/ACK packet responds to an ECN mark by reducing its initial the SYN/ACK packet responds to an ECN mark by reducing its initial
congestion window from two, three, or four segments to one segment, congestion window from two, three, or four segments to one segment,
and sending a SYN/ACK packet that is not ECN-Capable. The addition and sending a SYN/ACK packet that is not ECN-Capable. The addition
of ECN-capability to SYN/ACK packets is particularly beneficial in of ECN-Capability to SYN/ACK packets is particularly beneficial in
the server-to-client direction, where congestion is more likely to the server-to-client direction, where congestion is more likely to
occur. In this case, the initial information provided by the ECN occur. In this case, the initial information provided by the ECN
marking in the SYN/ACK packet enables the server to appropriately marking in the SYN/ACK packet enables the server to appropriately
adjust the initial load it places on the network, while avoiding the adjust the initial load it places on the network, while avoiding the
delay of a retransmission 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 working drafts of this document. We thank Adam
[L08] for contributing a patch for ECN+/TryOnce for the Linux Langley [L08] for contributing a patch for ECN+/TryOnce for the Linux
development tree. development tree.
A. Report on Simulations Appendix A. Report on Simulations
This section reports on simulations showing the costs of adding ECN+ This section reports on simulations showing the costs of adding ECN+
in highly-congested scenarios. This section also reports on in highly congested scenarios. This section also reports on
simulations for a comparative evaluation between ECN, ECN+, simulations for a comparative evaluation between ECN, ECN+,
ECN+/Wait, and ECN+/TryOnce. ECN+/Wait, and ECN+/TryOnce.
The simulations are run with a range of file-size distributions, The simulations are run with a range of file-size distributions,
using the PackMime traffic generator in the ns-2 simulator. They all using the PackMime traffic generator in the ns-2 simulator. They all
use a heavy-tailed distribution of file sizes. The simulations use a heavy-tailed distribution of file sizes. The simulations
reported in the tables below use a mean file size of 3 KBypes, to reported in the tables below use a mean file size of 3 Kbytes, to
show the results with a traffic mix with a large number of small show the results with a traffic mix with a large number of small
transfers. Other simulations were run with mean file sizes of 5 transfers. Other simulations were run with mean file sizes of 5
KBytes, 7 Kbytes, 14 KBytes, and 17 Kbytes. The title of each chart Kbytes, 7 Kbytes, 14 Kbytes, and 17 Kbytes. The title of each chart
gives the targeted average load from the traffic generator. Because gives the targeted average load from the traffic generator. Because
the simulations use a heavy-tailed distribution of file sizes, and the simulations use a heavy-tailed distribution of file sizes, and
run for only 85 seconds (including ten seconds of warm-up time), the run for only 85 seconds (including ten seconds of warm-up time), the
actual load is often much smaller than the targeted load. The actual load is often much smaller than the targeted load. The
congested link is 100 Mbps. RED is run in gentle mode, and arriving congested link is 100 Mbps. RED is run in gentle mode, and arriving
ECN-Capable packets are only dropped instead of marked if the buffer ECN-Capable packets are only dropped instead of marked if the buffer
is full (and the router has no choice). is full (and the router has no choice).
We explore three possible mechanisms for a TCP node's response to a We explore three possible mechanisms for a TCP node's response to a
report of an ECN-marked SYN/ACK packet. With ECN+, the TCP node report of an ECN-marked SYN/ACK packet. With ECN+, the TCP node
sends a data packet immediately (with an initial congestion window of sends a data packet immediately (with an initial congestion window of
one segment). With ECN+/Wait, the TCP node waits a round-trip time one segment). With ECN+/Wait, the TCP node waits a round-trip time
before sending a data packet; the responder already has one before sending a data packet; the responder already has one
measurement of the round-trip time when the acknowledgement for the measurement of the round-trip time when the acknowledgement for the
SYN/ACK packet is received. With ECN+/TryOnce, the mechanism SYN/ACK packet is received. With ECN+/TryOnce, the mechanism
standardized in this document, the TCP responder replies to a report standardized in this document, the TCP responder replies to a report
of an ECN-marked SYN/ACK packet by sending a SYN/ACK packet that is of an ECN-marked SYN/ACK packet by sending a SYN/ACK packet that is
not ECN-Capable, and reducing the initial congestion window to one not ECN-Capable, and reducing the initial congestion window to one
segment. segment.
The simulation scripts are available on [ECN-SYN]. along with graphs The simulation scripts are available on [ECN-SYN], along with graphs
showing the distribution of response times for the TCP connections. showing the distribution of response times for the TCP connections.
A.1. Simulations with RED in Packet Mode A.1. Simulations with RED in Packet Mode
The simulations with RED in packet mode and with the queue in packets The simulations with RED in packet mode and with the queue in packets
show that ECN+ is useful in times of moderate or of high congestion. show that ECN+ is useful in times of moderate or high congestion.
However, for the simulations with a target load of 125%, with a However, for the simulations with a target load of 125%, with a
packet loss rate of over 25% for ECN, ECN+ and ECN+/Wait both result packet loss rate of over 25% for ECN, ECN+ and ECN+/Wait both result
in a packet loss rate of over 50%. (In contrast, the packet loss in a packet loss rate of over 50%. (In contrast, the packet loss
rate with ECN+/TryOnce is less than that of ECN alone.) For the rate with ECN+/TryOnce is less than that of ECN alone.) For the
distribution of response times, the simulations show that ECN+, distribution of response times, the simulations show that ECN+,
ECN+/Wait, and ECN+/TryOnce all significantly improve the response ECN+/Wait, and ECN+/TryOnce all significantly improve the response
times, compared to the response times with plain ECN. times, when compared to the response times with Standard ECN.
Table 1 shows the congestion levels for simulations with RED in Table 1 shows the congestion levels for simulations with RED in
packet mode, with a queue in packets. To explore a worst-case packet mode, with a queue in packets. To explore a worst-case
scenario, these simulations use a traffic mix with an unrealistically scenario, these simulations use a traffic mix with an unrealistically
small flow size distribution, with a mean flow size of 3 Kbytes. For small flow size distribution, with a mean flow size of 3 Kbytes. For
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. The four
four columns show the simulations with Standard ECN, ECN+, ECN+/Wait, columns show the simulations with Standard ECN, ECN+, ECN+/Wait, and
and ECN+/TryOnce. 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 mechanism, it is less likely that ECN+ or one
one of its variants would increase the average queue size above the 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
higher levels of congestion. However, the cumulative distribution higher levels of congestion. However, the cumulative distribution
function (CDF) in Table 2 shows that ECN+, ECN+/Wait, and function (CDF) in Table 2 shows that ECN+, ECN+/Wait, and
ECN+/TryOnce all improve response times for all of the simulations, ECN+/TryOnce all improve response times for all of the simulations,
with moderate or with larger levels of congestion. with moderate or with larger levels of congestion.
Little increase in congestion, sometimes: The second thing to observe Little increase in congestion, sometimes: The second thing to observe
is that for the simulations with low or moderate levels of congestion is that for the simulations with low or moderate levels of congestion
(that is, with packet drop rates less than 10%), the use of ECN+, (that is, with packet drop rates less than 10%), the use of ECN+,
ECN+/Wait, and ECN+/TryOnce all decrease the aggregate packet drop ECN+/Wait, and ECN+/TryOnce all decrease the aggregate packet drop
rate, relative to the simulations with ECN. This makes sense, since rate relative to the simulations with ECN. This makes sense, since
with low or moderate levels of congestion, ECN+ allows SYN/ACK with low or moderate levels of congestion, ECN+ allows SYN/ACK
packets to be marked instead of dropped, and the use of ECN+ doesn't packets to be marked instead of dropped, and the use of ECN+ doesn't
add to the aggregate congestion. However, for the simulations with add to the aggregate congestion. However, for the simulations with
packet drop rates of 15% or higher with ECN, the use of ECN+ or packet drop rates of 15% or higher with ECN, the use of ECN+ or
ECN+/Wait increases the aggregate packet drop rate, sometimes even ECN+/Wait increases the aggregate packet drop rate, sometimes even
doubling it. doubling it.
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+, or 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,755` Dropped 20,516 11,226 11,735 16,755`
Marked 30,586 37,741 37,425 40,764 Marked 30,586 37,741 37,425 40,764
Loss rate 1.41% 0.78% 0.81% 1.02% 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%:
skipping to change at page 25, line 37 skipping to change at page 22, line 37
Throughput 94% 98% 97% 95% Throughput 94% 98% 97% 95%
Target Load = 150% 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
100 Mbps link, RED in packet mode, queue in packets. 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
skipping to change at page 26, line 38 skipping to change at page 23, line 37
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.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
100 Mbps link, RED in packet mode, queue in packets. (The graphs are Kbytes, a 100 Mbps link, RED in packet mode, queue in
available from "http://www.icir.org/floyd/ecn-syn/".) packets (the graphs are available from
"http://www.icir.org/floyd/ecn-syn/")
Target Load = 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 = 110% Target Load = 110%
ECN ECN+ ECN+/Wait ECN+/TryOnce ECN ECN+ ECN+/Wait ECN+/TryOnce
skipping to change at page 27, line 36 skipping to change at page 24, line 36
Throughput 97% 98% 98% 96% Throughput 97% 98% 98% 96%
Target Load = 150% 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
link, RED in packet mode, queue in packets. 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.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.40 0.71 0.88 0.96 0.97 0.97 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
skipping to change at page 28, line 38 skipping to change at page 25, line 37
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.24 0.42 0.56 0.71 0.75 0.75 0.88 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
10 Mbps link, RED in packet mode, queue in packets. (The graphs are Kbytes, a 10 Mbps link, RED in packet mode, queue in
available from "http://www.icir.org/floyd/ecn-syn/".) packets (the graphs are 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
with the use of ECN+, ECN+/Wait, or ECN+/TryOnce. with the use of ECN+, ECN+/Wait, or ECN+/TryOnce.
However, unlike the simulations with RED in packet mode, the However, unlike the simulations with RED in packet mode, the
simulations with RED in byte mode show little benefit from the use of simulations with RED in byte mode show little benefit from the use of
ECN+ or ECN+/Wait, in that the packet marking rate with ECN+ or ECN+ or ECN+/Wait, in that the packet marking rate with ECN+ or
ECN+/Wait is not much different than the packet marking rate with ECN+/Wait is not much different than the packet marking rate with
Standard ECN. This is because with RED in byte mode, small packets Standard ECN. This is because with RED in byte mode, small packets
like SYN/ACK packets are rarely dropped or marked - that is, there is like SYN/ACK packets are rarely dropped or marked -- that is, there
no drawback from the use of ECN+ in these scenarios, but not much is no drawback from the use of ECN+ in these scenarios, but not much
need for ECN+ either, in a scenario where small packets are unlikely need for ECN+ either, in a scenario where small packets are unlikely
to be dropped or marked. to be dropped or marked.
Target Load = 95% Target Load = 95%
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%
skipping to change at page 29, line 43 skipping to change at page 26, line 43
Throughput 95% 95% 95% 96% 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 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
100 Mbps link, RED in byte mode, queue in bytes. Mbps link, RED in byte mode, queue in bytes
Target Load = 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 = 110% Target Load = 110%
ECN ECN+ ECN+/Wait ECN+/TryOnce ECN ECN+ ECN+/Wait ECN+/TryOnce
skipping to change at page 30, line 37 skipping to change at page 27, line 36
Throughput 99% 99% 99% 96% Throughput 99% 99% 99% 96%
Target Load = 150% 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
link, RED in byte mode, queue in bytes. Mbps link, RED in byte mode, queue in bytes
B. Issues of Incremental Deployment Appendix 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
codepoint on received SYN/ACK packets, or ignores SYN/ACK packets codepoint on received SYN/ACK packets, or ignores SYN/ACK packets
with the ECT or CE codepoint set. If the TCP initiator ignores the with the ECT or CE codepoint set. If the TCP initiator ignores the
CE codepoint on received SYN/ACK packets, this would mean that the CE codepoint on received SYN/ACK packets, this would mean that the
TCP responder would not respond to this congestion indication. TCP responder would not respond to this congestion indication.
However, this seems to us an acceptable cost to pay in the However, this seems to us an acceptable cost to pay in the
incremental deployment of ECN-Capability for TCP's SYN/ACK packets. incremental deployment of ECN-Capability for TCP's SYN/ACK packets.
It would mean that the responder would not reduce the initial It would mean that the responder would not reduce the initial
congestion window from two, three, or four segments down to one congestion window from two, three, or four segments down to one
segment, as it should. and would not sent a non-ECN-Capable SYN/ACK segment, as it should, and would not sent a non-ECN-Capable SYN/ACK
packet to complete the SYN exchange. However, the TCP end nodes packet to complete the SYN exchange. However, the TCP end nodes
would still respond correctly to any subsequent CE indications on would still respond correctly to any subsequent CE indications on
data packets later on in the connection. data packets later on in the connection.
Figure 4 shows an interchange with the SYN/ACK packet ECN-marked, but Figure 4 shows an interchange with the SYN/ACK packet ECN-marked, but
with the ECN mark ignored by the TCP originator. with the ECN mark ignored by the TCP originator.
--------------------------------------------------------------- ---------------------------------------------------------------
TCP Node A Router TCP Node B TCP Node A Router TCP Node B
(initiator) (responder) (initiator) (responder)
skipping to change at page 31, line 31 skipping to change at page 28, line 44
<--- 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, No ECN-Echo ---> Data/ACK, No ECN-Echo --->
Data/ACK ---> Data/ACK --->
<--- Data (up to four packets) <--- Data (up to four packets)
--------------------------------------------------------------- ---------------------------------------------------------------
Figure 4: SYN exchange with the SYN/ACK packet marked, Figure 4: SYN exchange with the SYN/ACK packet marked,
but with the ECN mark ignored by the TCP initiator. but with the ECN mark ignored by the TCP initiator
Thus, to be explicit, when a TCP connection includes an initiator Thus, to be explicit, when a TCP connection includes an initiator
that supports ECN but *does not* support ECN-Capability for SYN/ACK that supports ECN but *does not* support ECN-Capability for SYN/ACK
packets, in combination with a responder that *does* support ECN- packets, in combination with a responder that *does* support ECN-
Capability for SYN/ACK packets, it is possible that the ECN-Capable Capability for SYN/ACK packets, it is possible that the ECN-Capable
SYN/ACK packets will be marked rather than dropped in the network, SYN/ACK packets will be marked rather than dropped in the network,
and that the responder will not learn about the ECN mark on the and that the responder will not learn about the ECN mark on the
SYN/ACK packet. This would not be a problem if most packets from the SYN/ACK packet. This would not be a problem if most packets from the
responder supporting ECN for SYN/ACK packets were in long-lived TCP responder supporting ECN for SYN/ACK packets were in long-lived TCP
connections, but it would be more problematic if most of the packets connections, but it would be more problematic if most of the packets
were from TCP connections consisting of four data packets, and the were from TCP connections consisting of four data packets, and the
TCP responder for these connections was ready to send its data TCP responder for these connections was ready to send its data
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 setup
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 retransmission 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.
One drawback to the use of an ECN-SYN flag is that it would use one One drawback to the use of an ECN-SYN flag is that it would use one
of the four remaining reserved bits in the TCP header, for a of the four remaining reserved bits in the TCP header for a transient
transient backwards compatibility problem. This drawback is limited backwards compatibility problem. This drawback is limited by the
by the fact that the "ECN-SYN" flag would be defined only for use fact that the "ECN-SYN" flag would be defined only for use with ECN-
with ECN-setup SYN packets; that bit in the TCP header could be setup SYN packets; that bit in the TCP header could be defined to
defined to have other uses for other kinds of TCP packets. have other uses for other kinds of TCP packets.
Factors in deciding not to use an ECN-SYN flag include the following: Factors in deciding not to use an ECN-SYN flag include the following:
(1) The limited installed base: At the time that this document was (1) The limited installed base: At the time that this document was
written, the TCP implementations in Microsoft Vista and Mac OS X written, the TCP implementations in Microsoft Vista and Mac OS X
included ECN, but ECN was not enabled by default [SBT07]. Thus, included ECN, but ECN was not enabled by default [SBT07]. Thus,
there was not a large deployed base of ECN-Capable TCP there was not a large deployed base of ECN-Capable TCP
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
switch from packet-marking to packet-dropping in times of high might switch from packet-marking to packet-dropping in times of
congestion before buffer overflow, as recommended in Section 19.1 of high congestion before buffer overflow, as recommended in Section
RFC 3168 [RFC3168]. This helps to prevent congestion collapse 19.1 of RFC 3168 [RFC3168]. This helps to prevent congestion
problems with the use of ECN. collapse 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
packet that is ECN-marked, but where the ECN mark is ignored by the SYN/ACK packet that is ECN-marked, but where the ECN mark is
TCP initiator. However, a TCP responder *can* detect if a SYN/ACK ignored by the TCP initiator. However, a TCP responder *can*
packet is sent as ECN-capable and not reported as ECN-marked, but detect if a SYN/ACK packet is sent as ECN-capable and not
data packets are dropped or marked from the initial window of data. reported as ECN-marked, but data packets are dropped or marked
We will call this scenario "initial-window-congestion". If a web from the initial window of data. We will call this scenario
server frequently experienced initial-window congestion (without "initial-window-congestion". If a web server frequently
SYN/ACK congestion), then the web server *might* be experiencing experienced initial-window-congestion (without SYN/ACK
backwards compatibility problems with ECN-Capable SYN/ACK packets, congestion), then the web server *might* be experiencing
and could respond by not sending SYN/ACK packets as ECN-Capable. backwards compatibility problems with ECN-Capable SYN/ACK
packets, and could respond by not sending SYN/ACK packets as
ECN-Capable.
Normative References Normative References
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
September 1981. 793, September 1981.
[RFC2119] S. Bradner, Key Words For Use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels, RFC 2119. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2988] V. Paxson and M. Allman, Computing TCP's Retransmission [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer, RFC 2988, November 2000. Timer", RFC 2988, November 2000.
[RFC3168] K.K. Ramakrishnan, S. Floyd, and D. Black, The Addition of [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed of Explicit Congestion Notification (ECN) to IP", RFC
Standard, September 2001. 3168, September 2001.
Informative References Informative References
[ECN+] A. Kuzmanovic, The Power of Explicit Congestion Notification, [ECN+] A. Kuzmanovic, The Power of Explicit Congestion
SIGCOMM 2005. Notification, SIGCOMM 2005.
[ECN-SYN] ECN-SYN web page with simulation scripts, URL [ECN-SYN] ECN-SYN web page with simulation scripts,
"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
TCP SYN packets that are ECN-Capable?", August 2, 2007, email sent to to TCP SYN packets that are ECN-Capable?", August 2, 2007,
the BEHAVE mailing list, URL "http://www1.ietf.org/mail- email to the BEHAVE mailing list, http://www1.ietf.org/
archive/web/behave/current/msg02644.html". mail-archive/web/behave/current/msg02644.html.
[Kelson00] Dax Kelson, note sent to the Linux kernel mailing list, [Kelson00] Dax Kelson, "8% of the Internet unreachable!", September
September 10, 2000. 10, 2000, email to the Linux kernel mailing list,
http://lkml.indiana.edu/hypermail/linux/kernel/
0009.1/0329.html.
[L08] A. Landley, "Re: [tcpm] I-D Action:draft-ietf-tcpm- [L08] A. Landley, "Re: [tcpm] I-D Action:draft-ietf-tcpm-
ecnsyn-06.txt", Email to the tcpm mailing list, August 24, 2008. ecnsyn-06.txt", August 24, 2008, email to the tcpm mailing
list, http://www.ietf.org/
mail-archive/web/tcpm/current/msg03988.html.
[MAF05] A. Medina, M. Allman, and S. Floyd. Measuring the Evolution [MAF05] A. Medina, M. Allman, and S. Floyd, "Measuring the
of Transport Protocols in the Internet, ACM CCR, April 2005. Evolution of Transport Protocols in the Internet", ACM
CCR, April 2005.
[PI] C. Hollot, V. Misra, W. Gong, and D. Towsley, On Designing [PI] C. Hollot, V. Misra, W. Gong, and D. Towsley, "On
Improved Controllers for AQM Routers Supporting TCP Flows, April Designing Improved Controllers for AQM Routers Supporting
1998. TCP Flows", April 1998.
[RED] Floyd, S., and Jacobson, V. Random Early Detection gateways [RED] Floyd, S., and Jacobson, V., "Random Early Detection
for Congestion Avoidance . IEEE/ACM Transactions on Networking, V.1 gateways for Congestion Avoidance", IEEE/ACM Transactions
N.4, August 1993. on Networking, V.1 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:
Queue Management, IEEE Network, May 2001. Active Queue Management", IEEE Network, May 2001.
[RFC2309] B. Braden et al., Recommendations on Queue Management and [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
Congestion Avoidance in the Internet, RFC 2309, April 1998. S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
S., Wroclawski, J., and L. Zhang, "Recommendations on
Queue Management and Congestion Avoidance in the
Internet", RFC 2309, April 1998.
[RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control, RFC 2581, April 1999. Control", RFC 2581, April 1999.
[RFC3042] M. Allman, H. Balakrishnan, and S. Floyd, Enhancing TCP's [RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing
Loss Recovery Using Limited Transmit, RFC 3042, Proposed Standard, TCP's Loss Recovery Using Limited Transmit", RFC 3042,
January 2001. January 2001.
[RFC3360] S. Floyd, Inappropriate TCP Resets Considered Harmful, RFC [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful",
3360, August 2002. BCP 60, RFC 3360, August 2002.
[RFC3390] M. Allman, S. Floyd, and C. Partridge, Increasing TCP's [RFC3390] Allman, M., Floyd, S., 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] Eddy, W., "TCP SYN Flooding Attacks and Common
RFC 4987, August 2007. Mitigations", 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
Protocol Headers Can Tell us about the Web, SIGMETRICS, June 2001. Protocol Headers Can Tell us about the Web", SIGMETRICS,
June 2001.
[SYN-COOK] Dan J. Bernstein, SYN cookies, 1997, see also [SYN-COOK] Dan J. Bernstein, SYN cookies, 1997, see also
<http://cr.yp.to/syncookies.html> <http://cr.yp.to/syncookies.html>.
[SBT07] M. Sridharan, D. Bansal, and D. Thaler, Implementation Report
on Experiences with Various TCP RFCs, Presentation in the TSVAREA,
IETF 68, March 2007. URL
"http://www3.ietf.org/proceedings/07mar/slides/tsvarea-3/sld6.htm".
[Tools] S. Floyd and E. Kohler, Tools for the Evaluation of
Simulation and Testbed Scenarios, Internet-draft draft-irtf-tmrg-
tools-05, work in progress, February 2008.
IANA Considerations [SBT07] M. Sridharan, D. Bansal, and D. Thaler, "Implementation
Report on Experiences with Various TCP RFCs", Presentation
in the TSVAREA, IETF 68, March 2007.
http://www3.ietf.org/proceedings/07mar/slides/tsvarea-
3/sld6.htm.
There are no IANA considerations regarding this document. [Tools] S. Floyd, Ed., and E. Kohler, Ed., "Tools for the
Evaluation of Simulation and Testbed Scenarios", Work in
Progress, February 2008.
Authors' Addresses Authors' Addresses
Aleksandar Kuzmanovic Aleksandar Kuzmanovic
Phone: +1 (847) 467-5519
Northwestern University Northwestern University
Email: akuzma at northwestern.edu
URL: http://cs.northwestern.edu/~a Phone: +1 (847) 467-5519
EMail: akuzma@northwestern.edu
URL: http://cs.northwestern.edu/~akuzma
Amit Mondal Amit Mondal
Northwestern University Northwestern University
Email: a-mondal at northwestern.edu
Phone: +1 (847) 467-6455
EMail: a-mondal@northwestern.edu
URL: http://www.cs.northwestern.edu/~akm175/
Sally Floyd Sally Floyd
Phone: +1 (510) 666-2989
ICIR (ICSI Center for Internet Research) ICIR (ICSI Center for Internet Research)
Email: floyd@icir.org
Phone: +1 (510) 666-2989
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
AT&T Labs Research AT&T Labs Research
Email: kkrama at research.att.com Rm. A161
180 Park Ave.
Florham Park, NJ 07932
Phone: +1 (973) 360-8764
EMail: kkrama@research.att.com
URL: http://www.research.att.com/info/kkrama URL: http://www.research.att.com/info/kkrama
 End of changes. 141 change blocks. 
460 lines changed or deleted 327 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/