draft-ietf-tcpm-ecnsyn-05.txt   draft-ietf-tcpm-ecnsyn-06.txt 
Internet Engineering Task Force A. Kuzmanovic Internet Engineering Task Force A. Kuzmanovic
INTERNET-DRAFT A. Mondal INTERNET-DRAFT A. Mondal
Intended status: Proposed Standard Northwestern University Intended status: Proposed Standard Northwestern University
Expires: 19 August 2008 S. Floyd Expires: 22 February 2009 S. Floyd
ICIR Updates: 3168 ICIR
K.K. Ramakrishnan K.K. Ramakrishnan
AT&T AT&T
19 February 2008 22 August 2008
Adding Explicit Congestion Notification (ECN) Capability Adding Explicit Congestion Notification (ECN) Capability
to TCP's SYN/ACK Packets to TCP's SYN/ACK Packets
draft-ietf-tcpm-ecnsyn-05.txt draft-ietf-tcpm-ecnsyn-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 22 skipping to change at page 2, line 22
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, when sent in response to a SYN packet with the two ECN packet itself, when sent in response to a SYN packet with the two ECN
flags set in the TCP header, indicating a willingness to use ECN. flags set in the TCP header, indicating a willingness to use ECN.
Setting TCP SYN/ACK packets as ECN-Capable can be of great benefit to Setting TCP SYN/ACK packets as ECN-Capable can be of great benefit to
the TCP connection, avoiding the severe penalty of a retransmit the TCP connection, avoiding the severe penalty of a retransmit
timeout for a connection that has not yet started placing a load on timeout for a connection that has not yet started placing a load on
the network. The sender of the SYN/ACK packet must respond to a the network. The sender of the SYN/ACK packet must respond to a
report of an ECN-marked SYN/ACK packet by reducing its initial report of an ECN-marked SYN/ACK packet 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,
thereby reducing the subsequent load from that connection on the thereby reducing the subsequent load from that connection on the
network. This document is intended to update RFC 3168. network. This document updates RFC 3168.
Table of Contents Table of Contents
1. Introduction ....................................................4 1. Introduction ....................................................5
2. Conventions and Terminology .....................................5 2. Conventions and Terminology .....................................6
3. Proposal ........................................................6 3. Specification ...................................................7
4. Discussion ......................................................9 3.1. SYN/ACK Packets Dropped in the Network .....................7
5. Related Work ...................................................12 3.2. SYN/ACK Packets ECN-Marked in the Network ..................8
6. Performance Evaluation .........................................12 3.3. Management Interface ......................................10
6.1. The Costs and Benefit of Adding ECN-Capability ............12 4. Discussion .....................................................10
4.1. Flooding Attacks ..........................................10
4.2. The TCP SYN Packet ........................................11
4.3. SYN/ACK Packets and Packet Size ...........................11
4.4. Response to ECN-marking of SYN/ACK Packets ................12
5. Related Work ...................................................13
6. Performance Evaluation .........................................14
6.1. The Costs and Benefit of Adding ECN-Capability ............14
6.2. An Evaluation of Different Responses to ECN-Marked SYN/ACK 6.2. An Evaluation of Different Responses to ECN-Marked SYN/ACK
Packets ........................................................14 Packets ........................................................15
7. Security Considerations ........................................14 7. Security Considerations ........................................16
8. Conclusions ....................................................16 7.1. 'Bad' Routers or Middleboxes ..............................16
9. Acknowledgements ...............................................16 7.2. Congestion Collapse .......................................16
A. Report on Simulations ..........................................17 8. Conclusions ....................................................17
A.1. Simulations with RED in Packet Mode .......................17 9. Acknowledgements ...............................................18
A.2. Simulations with RED in Byte Mode .........................19 A. Report on Simulations ..........................................18
B. Issues of Incremental Deployment ...............................20 A.1. Simulations with RED in Packet Mode .......................19
Normative References ..............................................23 A.2. Simulations with RED in Byte Mode .........................21
Informative References ............................................23 B. Issues of Incremental Deployment ...............................23
IANA Considerations ...............................................24 Normative References ..............................................26
Full Copyright Statement ..........................................25 Informative References ............................................26
Intellectual Property .............................................25 IANA Considerations ...............................................27
Full Copyright Statement ..........................................28
Intellectual Property .............................................28
NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION. NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION.
Changes from draft-ietf-tcpm-ecnsyn-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: Changes from draft-ietf-tcpm-ecnsyn-04:
* Updating the copyright date. * Updating the copyright date.
Changes from draft-ietf-tcpm-ecnsyn-03: Changes from draft-ietf-tcpm-ecnsyn-03:
* General editing. This includes using the terms "initiator" * General editing. This includes using the terms "initiator"
and "responder" for the two ends of the TCP connection. and "responder" for the two ends of the TCP connection.
Feedback from Alfred Hoenes. Feedback from Alfred Hoenes.
skipping to change at page 6, line 17 skipping to change at page 6, line 42
The use of ECN for SYN/ACK packets has the following potential The use of ECN for SYN/ACK packets has the following potential
benefits: benefits:
1) Avoidance of a retransmit timeout; 1) Avoidance of a retransmit timeout;
2) Improvement in the throughput of short connections. 2) Improvement in the throughput of short connections.
This draft specifies ECN+, a modification to RFC 3168 to allow TCP This draft specifies ECN+, a modification to RFC 3168 to allow TCP
SYN/ACK packets to be ECN-Capable. Section 3 contains the 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 proposed 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 [RFC 2119]. document are to be interpreted as described in [RFC 2119].
We use the following terminology from RFC 3168: We use the following terminology from RFC 3168:
The ECN field in the IP header: The ECN field in the IP header:
skipping to change at page 6, line 43 skipping to change at page 7, line 21
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. Proposal 3. Specification
This section specifies the modification to RFC 3168 to allow TCP This section specifies the modification to RFC 3168 to allow TCP
SYN/ACK packets to be ECN-Capable. SYN/ACK packets to be ECN-Capable.
RFC 3168 in Section 6.1.1. states that "A host MUST NOT set ECT on RFC 3168 in Section 6.1.1. states that "A host MUST NOT set ECT on
SYN or SYN-ACK packets." In this section, we specify that a TCP node SYN or SYN-ACK packets." In this section, we specify that a TCP node
MAY respond to an ECN-setup SYN packet by setting ECT in the MAY respond to an ECN-setup SYN packet by setting ECT in the
responding ECN-setup SYN/ACK packet, indicating to routers that the responding ECN-setup SYN/ACK packet, indicating to routers that the
SYN/ACK packet is ECN-Capable. This allows a congested router along SYN/ACK packet is ECN-Capable. This allows a congested router along
the path to mark the packet instead of dropping the packet as an the path to mark the packet instead of dropping the packet as an
indication of congestion. indication of congestion.
Assume that TCP node A transmits to TCP node B an ECN-setup SYN Assume that TCP node A transmits to TCP node B an ECN-setup SYN
packet, indicating willingness to use ECN for this connection. As packet, indicating willingness to use ECN for this connection. As
specified by RFC 3168, if TCP node B is willing to use ECN, node B specified by RFC 3168, if TCP node B is willing to use ECN, node B
responds with an ECN-setup SYN-ACK packet. responds with an ECN-setup SYN-ACK packet.
3.1. SYN/ACK Packets Dropped in the Network
Figure 1 shows an interchange with the SYN/ACK packet dropped by a Figure 1 shows an interchange with the SYN/ACK packet dropped by a
congested router. Node B waits for a retransmit timeout, and then congested router. Node B waits for a retransmit timeout, and then
retransmits the SYN/ACK packet. retransmits the SYN/ACK packet.
--------------------------------------------------------------- ---------------------------------------------------------------
TCP Node A Router TCP Node B TCP Node A Router TCP Node B
---------- ------ ---------- ---------- ------ ----------
ECN-setup SYN packet ---> ECN-setup SYN packet --->
ECN-setup SYN packet ---> ECN-setup SYN packet --->
skipping to change at page 8, line 4 skipping to change at page 8, line 38
B) responds by waiting three seconds for the retransmit timer to B) responds by waiting three seconds for the retransmit timer to
expire [RFC2988]. If a SYN/ACK packet with the ECT codepoint is expire [RFC2988]. If a SYN/ACK packet with the ECT codepoint is
dropped, the responder SHOULD resend the SYN/ACK packet without the dropped, the responder SHOULD resend the SYN/ACK packet without the
ECN-Capable codepoint. (Although we are not aware of any middleboxes ECN-Capable codepoint. (Although we are not aware of any middleboxes
that drop SYN/ACK packets that contain an ECN-Capable codepoint in that drop SYN/ACK packets that contain an ECN-Capable codepoint in
the IP header, we have learned to design our protocols defensively in the IP header, we have learned to design our protocols defensively in
this regard [RFC3360].) this regard [RFC3360].)
We note that if syn-cookies were used by the responder (node B) in We note that if syn-cookies were used by the responder (node B) in
the exchange in Figure 1, the responder wouldn't set a timer upon the exchange in Figure 1, the responder wouldn't set a timer upon
transmission of the SYN/ACK packet [SYN-COOK]. In this case, if the transmission of the SYN/ACK packet [SYN-COOK] [RFC4987]. In this
SYN/ACK packet was lost, the initiator (Node A) would have to timeout case, if the SYN/ACK packet was lost, the initiator (Node A) would
and retransmit the SYN packet in order to trigger another SYN-ACK. have to timeout and retransmit the SYN packet in order to trigger
another SYN-ACK.
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.
--------------------------------------------------------------- ---------------------------------------------------------------
TCP Node A Router TCP Node B TCP Node A Router TCP Node B
---------- ------ ---------- ---------- ------ ----------
ECN-setup SYN packet ---> ECN-setup SYN packet --->
ECN-setup SYN packet ---> ECN-setup SYN packet --->
skipping to change at page 9, line 12 skipping to change at page 10, line 5
when the congestion window is one." As specified by RFC 3168, the when the congestion window is one." As specified by RFC 3168, the
responder (node B) also sets the CWR flag in the TCP header of the responder (node B) also sets the CWR flag in the TCP header of the
next data packet sent, to acknowledge its receipt of and reaction to next data packet sent, to acknowledge its receipt of and reaction to
the ECN-Echo flag. the ECN-Echo flag.
If the data transfer in Figure 2 is entirely from Node A to Node B, If the data transfer in Figure 2 is entirely from Node A to Node B,
then data packets from Node A continue to set the ECN-Echo flag in then data packets from Node A continue to set the ECN-Echo flag in
data packets, waiting for the CWR flag from Node B acknowledging a data packets, waiting for the CWR flag from Node B acknowledging a
response to the ECN-Echo flag. response to the ECN-Echo flag.
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
Motivation: The rationale for the specification in this document is the
The rationale for the proposed change is the following. When node B following. When node B receives a TCP SYN packet with ECN-Echo bit
receives a TCP SYN packet with ECN-Echo bit set in the TCP header, set in the TCP header, this indicates that node A is ECN-capable. If
this indicates that node A is ECN-capable. If node B is also ECN- node B is also ECN-capable, there are no obstacles to immediately
capable, there are no obstacles to immediately setting one of the setting one of the ECN-Capable codepoints in the IP header in the
ECN-Capable codepoints in the IP header in the responding TCP SYN/ACK responding TCP SYN/ACK packet.
packet.
There can be a great benefit in setting an ECN-capable codepoint in There can be a great benefit in setting an ECN-capable codepoint in
SYN/ACK packets, as is discussed further in [ECN+], and reported SYN/ACK packets, as is discussed further in [ECN+], and reported
briefly in Section 5 below. Congestion is most likely to occur in briefly in Section 5 below. Congestion is most likely to occur in
the server-to-client direction. As a result, setting an ECN-capable the server-to-client direction. As a result, setting an ECN-capable
codepoint in SYN/ACK packets can reduce the occurrence of three- codepoint in SYN/ACK packets can reduce the occurrence of three-
second retransmit timeouts resulting from the drop of SYN/ACK second retransmit timeouts resulting from the drop of SYN/ACK
packets. packets.
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 novel security vulnerabilities. For packets does not raise any novel security vulnerabilities. For
example, provoking servers or hosts to send SYN/ACK packets to a example, provoking servers or hosts to send SYN/ACK packets to a
third party in order to perform a "SYN/ACK flood" attack would be third party in order to perform a "SYN/ACK flood" attack would be
highly inefficient. Third parties would immediately drop such highly inefficient. Third parties would immediately drop such
packets, since they would know that they didn't generate the TCP SYN packets, since they would know that they didn't generate the TCP SYN
packets in the first place. Moreover, such SYN/ACK attacks would packets in the first place. Moreover, such SYN/ACK attacks would
have the same signatures as the existing TCP SYN attacks. Provoking have the same signatures as the existing TCP SYN attacks. Provoking
servers or hosts to reply with SYN/ACK packets in order to congest a servers or hosts to reply with SYN/ACK packets in order to congest a
certain link would also be highly inefficient because SYN/ACK packets certain link would also be highly inefficient because SYN/ACK packets
are small in size. 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.
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.
SYN/ACK packets and packet size: 4.3. SYN/ACK Packets and Packet Size
There are a number of router buffer architectures that have smaller There are a number of router buffer architectures that have smaller
dropping rates for small (SYN) packets than for large (data) packets. dropping rates for small (SYN) packets than for large (data) packets.
For example, for a Drop Tail queue in units of packets, where each For example, for a Drop Tail queue in units of packets, where each
packet takes a single slot in the buffer regardless of packet size, packet takes a single slot in the buffer regardless of packet size,
small and large packets are equally likely to be dropped. However, small and large packets are equally likely to be dropped. However,
for a Drop Tail queue in units of bytes, small packets are less for a Drop Tail queue in units of bytes, small packets are less
likely to be dropped than are large ones. Similarly, for RED in likely to be dropped than are large ones. Similarly, for RED in
packet mode, small and large packets are equally likely to be dropped packet mode, small and large packets are equally likely to be dropped
or marked, while for RED in byte mode, a packet's chance of being or marked, while for RED in byte mode, a packet's chance of being
dropped or marked is proportional to the packet size in bytes. dropped or marked is proportional to the packet size in bytes.
skipping to change at page 11, line 5 skipping to change at page 12, line 6
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 [Tools] (Section 10). We note that all of these
alternatives listed above are available in the NS simulator (Drop alternatives listed above are available in the NS simulator (Drop
Tail queues are by default in units of packets, while the default for Tail queues are by default in units of packets, while the default for
RED queue management has been changed from packet mode to byte mode). RED queue management has been changed from packet mode to byte mode).
Response to ECN-marking of SYN/ACK packets: 4.4. Response to ECN-marking of SYN/ACK Packets
One question is why TCP SYN/ACK packets should be treated differently One question is why TCP SYN/ACK packets should be treated differently
from other packets in terms of the end node's response to an ECN- from other packets in terms of the end node's response to an ECN-
marked packet. Section 5 of RFC 3168 specifies the following: marked packet. Section 5 of RFC 3168 specifies the following:
"Upon the receipt by an ECN-Capable transport of a single CE packet, "Upon the receipt by an ECN-Capable transport of a single CE packet,
the congestion control algorithms followed at the end-systems MUST be the congestion control algorithms followed at the end-systems MUST be
essentially the same as the congestion control response to a *single* essentially the same as the congestion control response to a *single*
dropped packet. For example, for ECN-Capable TCP the source TCP is dropped packet. For example, for ECN-Capable TCP the source TCP is
required to halve its congestion window for any window of data required to halve its congestion window for any window of data
containing either a packet drop or an ECN indication." containing either a packet drop or an ECN indication."
skipping to change at page 12, line 8 skipping to change at page 13, line 13
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 simple response Adding ECN-Capability to SYN/ACK packets allows the simple response
of the responder setting the initial congestion window to one packet, of the 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,
with the responder proceeding with a cautious sending rate of one with the responder proceeding with a cautious sending rate of one
packet per round-trip time. If that data packet is ECN-marked or packet per round-trip time. If that data packet is ECN-marked or
dropped, then the responder will wait an RTO before sending another dropped, then the responder will wait an RTO before sending another
packet. This document argues that this approach is useful to users, packet. This document argues that this approach is useful to users,
with no dangers of congestion collapse or of starvation of competing with no dangers of congestion collapse or of starvation of competing
traffic. This is discussed in more detail below in Section 6.2. traffic. This is discussed in more detail below in Section 6.2. In
particular, Section 6.2 discusses simulation results that support the
responder's specified behavior of setting the initial congestion
window to one packet in response to an ECN-marked SYN/ACK packet.
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,
then there is no effective difference between the two possible then there is no effective difference between the two possible
responses to an ECN-marked SYN/ACK packet outlined above. In either responses to an ECN-marked SYN/ACK packet outlined above. In either
case, Node B sends no data packets, only sending acknowledgement case, Node B sends no data packets, only sending acknowledgement
packets in response to received data packets. packets in response to received data packets.
5. Related Work 5. Related Work
The addition of ECN-capability to TCP's SYN/ACK packets was proposed The addition of ECN-capability to TCP's SYN/ACK packets was proposed
skipping to change at page 15, line 11 skipping to change at page 16, line 16
there is no need for the TCP end-node to wait a round-trip time there is no need for the TCP end-node to wait a round-trip time
before sending a data packet after receiving an acknowledgement of an before sending a data packet after receiving an acknowledgement of an
ECN-marked SYN/ACK packet. ECN-marked SYN/ACK packet.
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.
"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 new two 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].
skipping to change at page 15, line 37 skipping to change at page 16, line 43
contain known or unknown IP options [MAF05] (Figure 1).) Thus, as contain known or unknown IP options [MAF05] (Figure 1).) Thus, as
specified in Section 3, if a SYN/ACK packet with the ECT or CE specified in Section 3, if a SYN/ACK packet with the ECT or CE
codepoint is dropped, the TCP node SHOULD resend the SYN/ACK packet codepoint is dropped, the TCP node SHOULD resend the SYN/ACK packet
without the ECN-Capable codepoint. There is also no evidence that without the ECN-Capable codepoint. There is also no evidence that
any routers or middleboxes crash when a SYN/ACK arrives with an ECN- any routers or middleboxes crash when a SYN/ACK arrives with an ECN-
Capable or CE codepoint in the IP header (over and above the routers Capable or CE codepoint in the IP header (over and above the routers
already known to crash when a data packet arrives with either ECT(0) already known to crash when a data packet arrives with either ECT(0)
or ECT(1)), but we have not conducted any measurement studies of this or ECT(1)), but we have not conducted any measurement studies of this
[F07]. [F07].
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 will only send one data packet; packet was ECN-marked, the responder will only send one data packet;
if this data packet is ECN-marked, the responder will then wait for a if this data packet is ECN-marked, the responder will then wait for a
retransmission timeout. In addition, routers are free to drop rather retransmission timeout. In addition, routers are free to drop rather
than mark arriving packets in times of high congestion, regardless of than mark arriving packets in times of high congestion, regardless of
whether the packets are ECN-capable. When congestion is very high whether 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 and a router's buffer is full, the router has no choice but to drop
skipping to change at page 16, line 46 skipping to change at page 18, line 9
connections. The sender of the SYN/ACK packet responds to an ECN connections. The sender of the SYN/ACK packet responds to an ECN
mark by reducing its initial congestion window from two, three, or mark by reducing its initial congestion window from two, three, or
four segments to one segment, reducing the subsequent load from that four segments to one segment, reducing the subsequent load from that
connection on the network. The addition of ECN-capability to SYN/ACK connection on the network. The addition of ECN-capability to SYN/ACK
packets is particularly beneficial in the server-to-client direction, packets is particularly beneficial in the server-to-client direction,
where congestion is more likely to occur. In this case, the initial where congestion is more likely to occur. In this case, the initial
information provided by the ECN marking in the SYN/ACK packet enables information provided by the ECN marking in the SYN/ACK packet enables
the server to more appropriately adjust the initial load it places on the server to more appropriately adjust the initial load it places on
the network. the network.
Future work will address the more general question of adding ECN-
Capability to relevant handshake packets in other protocols that use
retransmission-based reliability in their setup phase (e.g., SCTP,
DCCP, HIP, and the like).
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,
Alfred Hoenes, Janardhan Iyengar, and Pasi Sarolahti for feedback on Lars Eggert, Alfred Hoenes, Janardhan Iyengar, and Pasi Sarolahti for
earlier versions of this draft. feedback on earlier versions of this draft.
A. Report on Simulations 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+ with NoWaiting simulations for a comparative evaluation between ECN+ with NoWaiting
and ECN+ with Waiting. and ECN+ with Waiting.
The simulations are run with a range of file-size distributions. As The simulations are run with a range of file-size distributions,
a baseline, they use the empirical heavy-tailed distribution reported using the PackMime traffic generator in the ns-2 simulator. They all
in [SCJO01], with a mean file size of around 7 KBytes. This flow- use a heavy-tailed distribution of file sizes. The simulations
size distribution is manipulated by skewing the flow sizes towards reported in the tables below use a mean file size of 3 KBypes, to
lower and higher values to get distributions with mean file sizes of show the results with a traffic mix with a large number of small
3 KBytes, 5 KBytes, 14 KBytes and 17 KBytes. The congested link is transfers. Othe simulations were run with mean file sizes of 5
100 Mbps. RED is run in gentle mode, and arriving ECN-Capable KBytes, 7 Kbytes, 14 KBytes, and 17 Kbytes. The title of each chart
packets are only dropped instead of marked if the buffer is full (and gives the targeted average load from the traffic generator. Because
the router has no choice). the simulations use a heavy-tailed distribution of file sizes, and
run for only 85 seconds (including ten seconds of warm-up time), 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
ECN-Capable packets are only dropped instead of marked if the buffer
is full (and the router has no choice).
We explore two alternatives for a TCP node's response to a report of We explore two alternatives for a TCP node's response to a report of
an ECN-marked SYN/ACK packet. With ECN+ with NoWaiting, the TCP node an ECN-marked SYN/ACK packet. With ECN+ with NoWaiting, 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 the alternative ECN+ with Waiting, the TCP node one segment). With the alternative ECN+ with Waiting, the TCP node
waits a round-trip time before sending a data packet; the responder waits a round-trip time before sending a data packet; the responder
already has one measurement of the round-trip time when the already has one measurement of the round-trip time when the
acknowledgement for the SYN/ACK packet is received. acknowledgement for the SYN/ACK packet is received.
In the tables below, ECN+ refers to ECN+ with NoWaiting, where the In the tables below, ECN+ refers to ECN+ with NoWaiting, where the
responder starts transmitting immediately, and ECN+/wait refers to responder starts transmitting immediately, and ECN+/wait refers to
ECN+ with Waiting, where the responder waits a round-trip time before ECN+ with Waiting, where the responder waits a round-trip time before
sending a data packet into the network. sending a data packet into the network.
The simulation scripts are available on [ECN-SYN], along with graphs The simulation scripts are available on [ECN-SYN].
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 congestion, though it show that ECN+ is useful in times of moderate congestion, though it
adds little benefit in times of high congestion. The simulations adds little benefit in times of high congestion. The simulations
show a minimal increase in levels of congestion with either ECN+ with show a minimal increase in levels of congestion with either ECN+ with
Waiting or ECN+ with NoWaiting, either in terms of packet dropping or Waiting or ECN+ with NoWaiting, either in terms of packet dropping or
marking rates or in terms of the distribution of responses times. marking rates or in terms of the distribution of responses times.
Thus, the simulations show no problems with ECN+ in times of high Thus, the simulations show no problems with ECN+ in times of high
congestion, and no reason to use ECN+ with Waiting instead of ECN+ congestion, and no reason to use ECN+ with Waiting instead of ECN+
with NoWaiting. with NoWaiting.
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 three rows show the each table showing a particular traffic load, the three rows show the
number of packets dropped, the number of packets ECN-marked, and the number of packets dropped, the number of packets ECN-marked, and the
skipping to change at page 18, line 18 skipping to change at page 19, line 26
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 three rows show the each table showing a particular traffic load, the three rows show the
number of packets dropped, the number of packets ECN-marked, and the number of packets dropped, the number of packets ECN-marked, and the
aggregate packet drop rate, and the three columns show the aggregate packet drop rate, and the three columns show the
simulations with Standard ECN, ECN+ (NoWaiting) and ECN+/wait. simulations with Standard ECN, ECN+ (NoWaiting) and ECN+/wait.
The usefulness of ECN+: The first thing to observe is that for the These simulations were run with RED set to mark instead of drop
simulations with the somewhat moderate load of 95%, with packet drop packets any time that the queue is not full. For the default
rates of 5-6%, the use of ECN+ or ECN+/wait more than doubled the implementation of RED in the ns-2 simulator, the router drops instead
number of packets marked. This indicates that with ECN+ or of marks arriving packets when the average queue size exceeds a
configured threshold.
The usefulness of ECN+: The first thing to observe is that for all of
the simulations, the use of ECN+ or ECN+/wait significantly increased
the number of packets marked. This indicates that with ECN+ or
ECN+/wait, many SYN/ACK packets are marked instead of dropped. ECN+/wait, many SYN/ACK packets are marked instead of dropped.
No increase in congestion: The second thing to observe is that in all Little increase in congestion, sometimes: The second thing to observe
of the simulations, the use of ECN+ or ECN+/wait does not is that for the simulations with low or moderate levels of congestion
significantly increase the aggregate packet drop rate. (that is, with packet drop rates less than 10%), the use of ECN+ or
ECN+/wait decreases the aggregate packet drop rate, relative to the
simulations with ECN. This makes sense, since 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 add to the aggregate
congestion. However, for the simulations with packet drop rates of
15% or higher with ECN, the use of ECN+ or ECN+/wait increases the
aggregate packet drop rate, sometimes even doubling it.
Comparing ECN+ and ECN+/wait: The third thing to observe is that Comparing ECN+ and ECN+/wait: The third thing to observe is that the
there is little difference between ECN+ and ECN+/wait in terms of the aggregate packet drop rate is generally higher with ECN+/wait than
aggregate packet drop rate. Thus, there is no congestion-related with ECN+. Thus, there is no congestion-related reason to prefer
reason to prefer ECN+/wait over ECN+. ECN+/wait over ECN+.
Traffic Load = 95%: Target Load = 95%:
ECN ECN+ ECN+/wait ECN ECN+ ECN+/wait
------- ------- ------- ------- ------- -------
Dropped 74,645 64,034 64,983 Dropped 18,512 11,244 12,135
Marked 7,639 17,681 16,914 Marked 27,026 36,977 38,743
Loss rate 6.05% 5.26% 5.33% Loss rate 1.27% 0.78% 0.84%
Throughput 81% 81% 81%
Traffic Load = 110%: Target Load = 110%:
ECN ECN+ ECN+/wait ECN ECN+ ECN+/wait
------- ------- ------- ------- ------- -------
Dropped 161,644 163,620 165,196 Dropped 165,866 110,525 144,821
Marked 4,375 6,653 6,144 Marked 180,714 290,629 311,233
Loss rate 10.38% 10.45% 10.53% Loss rate 9.04% 6.36% 7.94%
Throughput 92% 92% 92%
Traffic Load = 125%: Target Load = 125%:
ECN ECN+ ECN+/wait ECN ECN+ ECN+/wait
------- ------- ------- ------- ------- -------
Dropped 257,671 268,161 264,437 Dropped 574,114 1,764,677 2,229,280
Marked 2,885 3,712 3,359 Marked 409,441 1,172,550 1,181,209
Loss rate 14.52% 15.00% 14.83% Loss rate 24.55% 52.00% 57.64%
Throughput 94% 98% 97%
Traffic Load = 150%: Table 1: Simulations with an average flow size of 3 Kbytes, a
100 Mbps link, RED in packet mode, queue in packets.
Target Load = 95%:
ECN ECN+ ECN+/wait ECN ECN+ ECN+/wait
------- ------- ------- ------- ------- -------
Loss rate 24.36% 24.61% 24.46% Dropped 8,754 6,719 7,269
Marked 10,376 17,637 16,956
Loss rate 5.68% 4.50% 4.75%
Throughput 78% 78% 78%
Traffic Load = 200%: Target Load = 110%:
ECN ECN+ ECN+/wait ECN ECN+ ECN+/wait
------- ------- ------- ------- ------- -------
Loss rate 29.99% 30.22% 30.23% Dropped 32,110 32,014 48,838
Marked 28,476 56,550 62,252
Loss rate 15.68% 16.11% 21.92%
Throughput 96% 96% 96%
Table 1: Simulations with an average flow size of 3 Kbytes, RED in Target Load = 125%:
packet mode, queue in packets. ECN ECN+ ECN+/wait
------- ------- -------
Dropped 60,710 174,920 215,001
Marked 43,497 119,620 118,172
Loss rate 25.08% 51.59% 56.27%
Throughput 98% 98% 98%
Target Load = 150%:
ECN ECN+ ECN+/wait
------- ------- -------
Dropped 133,128 250,762 327,584
Marked 63,306 146,581 147,307
Loss rate 43.34% 61.11% 67.33%
Throughput 93% 100% 100%
Table 2: Simulations with an average flow size of 3 Kbytes, a 10 Mbps
link, RED in packet mode, queue in packets.
A.2. Simulations with RED in Byte Mode A.2. Simulations with RED in Byte Mode
Table 2 below shows simulations with RED in byte mode and the queue Table 3 below shows simulations with RED in byte mode and the queue
in bytes. Like the simulations with RED in packet mode, there is no in bytes. There is no significant increase in aggregate congestion
significant increase in aggregate congestion with the use of ECN+ or with the use of ECN+ or ECN+/wait, and no congestion-related reason
ECN+/wait, and no congestion-related reason to prefer ECN+/wait over to prefer ECN+/wait over ECN+.
ECN+.
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 is
no drawback from the use of ECN+ in these scenarios, but not much 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.
Traffic Load = 95%: Target Load = 95%:
ECN ECN+ ECN+/wait ECN ECN+ ECN+/wait
------- ------- ------- ------- ------- -------
Dropped 13,044 13,323 14,855 Dropped 739 438 442
Marked 18,880 19,175 19,049 Marked 32,405 34,357 34,000
Loss rate 1.13% 1.16% 1.29% Loss rate 0.05% 0.03% 0.03%
Throughput 81% 81% 81%
Traffic Load = 110%: Target Load = 110%:
ECN ECN+ ECN+/wait ECN ECN+ ECN+/wait
------- ------- ------- ------- ------- -------
Dropped 84,809 83,013 83,564 Dropped 2,473 1,679 3,020
Marked 4,086 4,644 4,826 Marked 226,971 222,234 327,608
Loss rate 5.90% 5.78% 5.81% Loss rate 0.15% 0.10% 0.18%
Throughput 92% 92% 91%
Traffic Load = 125%: Target Load = 125%:
ECN ECN+ ECN+/wait ECN ECN+ ECN+/wait
------- ------- ------- ------- ------- -------
Dropped 157,305 157,435 158,368 Dropped 19,358 14,057 14,064
Marked 2,183 2,363 2,663 Marked 717,123 728,513 729,001
Loss rate 9.89% 9.87% 9.93% Loss rate 1.07% 0.78% 0.78%
Throughput 95% 95% 95%
Table 2: Simulations with an average flow size of 3 Kbytes, RED in Table 3: Simulations with an average flow size of 3 Kbytes, a
byte mode, queue in bytes. 100 Mbps link, RED in byte mode, queue in bytes.
Target Load = 95%:
ECN ECN+ ECN+/wait
------- ------- -------
Dropped 142 81 78
Marked 11,694 11,812 11,964
Loss rate 0.01% 0.06% 0.05%
Throughput 78% 78% 78%
Target Load = 110%:
ECN ECN+ ECN+/wait
------- ------- -------
Dropped 314 215 188
Marked 39,697 42,388 40,229
Loss rate 0.19% 0.13% 0.11%
Throughput 95% 94% 95%
Target Load = 125%:
ECN ECN+ ECN+/wait
------- ------- -------
Dropped 1,599 1,011 985
Marked 74,567 75,782 75,528
Loss rate 0.87% 0.56% 0.54%
Throughput 98% 98% 98%
Target Load = 150%:
ECN ECN+ ECN+/wait
------- ------- -------
Dropped 2,429 1,538 1,571
Marked 85,312 86,481 86,476
Loss rate 1.22% 0.78% 0.79%
Throughput 98% 98% 98%
Table 4: Simulations with an average flow size of 3 Kbytes, a 10 Mbps
link, RED in byte mode, queue in bytes.
B. Issues of Incremental Deployment 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.
skipping to change at page 21, line 33 skipping to change at page 24, line 33
Data/ACK ---> Data/ACK --->
<--- Data (up to four packets) <--- Data (up to four packets)
--------------------------------------------------------------- ---------------------------------------------------------------
Figure 3: SYN exchange with the SYN/ACK packet marked, Figure 3: 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-
Capabililty 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
skipping to change at page 23, line 19 skipping to change at page 26, line 19
[RFC3168] K.K. Ramakrishnan, S. Floyd, and D. Black, The Addition of [RFC3168] K.K. Ramakrishnan, S. Floyd, and D. Black, The Addition of
Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed
Standard, September 2001. Standard, September 2001.
Informative References Informative References
[ECN+] A. Kuzmanovic, The Power of Explicit Congestion Notification, [ECN+] A. Kuzmanovic, The Power of Explicit Congestion Notification,
SIGCOMM 2005. SIGCOMM 2005.
[ECN-SYN] ECN-SYN web page with simulation scripts, URL to be added. [ECN-SYN] ECN-SYN web page with simulation scripts, URL
"http://www.icir.org/floyd/ecn-syn".
[F07] S. Floyd, "[BEHAVE] Response of firewalls and middleboxes to [F07] S. Floyd, "[BEHAVE] Response of firewalls and middleboxes to
TCP SYN packets that are ECN-Capable?", August 2, 2007, email sent to TCP SYN packets that are ECN-Capable?", August 2, 2007, email sent to
the BEHAVE mailing list, URL "http://www1.ietf.org/mail- the BEHAVE mailing list, URL "http://www1.ietf.org/mail-
archive/web/behave/current/msg02644.html". archive/web/behave/current/msg02644.html".
[Kelson00] Dax Kelson, note sent to the Linux kernel mailing list, [Kelson00] Dax Kelson, note sent to the Linux kernel mailing list,
September 10, 2000. September 10, 2000.
[MAF05] A. Medina, M. Allman, and S. Floyd. Measuring the Evolution [MAF05] A. Medina, M. Allman, and S. Floyd. Measuring the Evolution
skipping to change at page 24, line 13 skipping to change at page 27, line 15
[RFC3042] M. Allman, H. Balakrishnan, and S. Floyd, Enhancing TCP's [RFC3042] M. Allman, H. Balakrishnan, and S. Floyd, Enhancing TCP's
Loss Recovery Using Limited Transmit, RFC 3042, Proposed Standard, Loss Recovery Using Limited Transmit, RFC 3042, Proposed Standard,
January 2001. January 2001.
[RFC3360] S. Floyd, Inappropriate TCP Resets Considered Harmful, RFC [RFC3360] S. Floyd, Inappropriate TCP Resets Considered Harmful, RFC
3360, August 2002. 3360, August 2002.
[RFC3390] M. Allman, S. Floyd, and C. Partridge, Increasing TCP's [RFC3390] M. Allman, S. Floyd, and C. Partridge, Increasing TCP's
Initial Window, RFC 3390, October 2002. Initial Window, RFC 3390, October 2002.
[SCJO01] F. Smith, F. Campos, K. Jeffay, D. Ott, What {TCP/IP} [RFC4987] W. Eddy, TCP SYN Flooding Attacks and Common Mitigations,
RFC 4987, August 2007.
[SCJO01] F. Smith, F. Campos, K. Jeffay, and D. Ott, What TCP/IP
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 [SBT07] M. Sridharan, D. Bansal, and D. Thaler, Implementation Report
on Experiences with Various TCP RFCs, Presentation in the TSVAREA, on Experiences with Various TCP RFCs, Presentation in the TSVAREA,
IETF 68, March 2007. URL IETF 68, March 2007. URL
"http://www3.ietf.org/proceedings/07mar/slides/tsvarea-3/sld6.htm". "http://www3.ietf.org/proceedings/07mar/slides/tsvarea-3/sld6.htm".
[Tools] S. Floyd and E. Kohler, Tools for the Evaluation of [Tools] S. Floyd and E. Kohler, Tools for the Evaluation of
Simulation and Testbed Scenarios, Internet-draft draft-irtf-tmrg- Simulation and Testbed Scenarios, Internet-draft draft-irtf-tmrg-
tools-04, work in progress, July 2007. tools-05, work in progress, February 2008.
IANA Considerations IANA Considerations
There are no IANA considerations regarding this document. There are no IANA considerations regarding this document.
Authors' Addresses Authors' Addresses
Aleksandar Kuzmanovic Aleksandar Kuzmanovic
Phone: +1 (847) 467-5519 Phone: +1 (847) 467-5519
Northwestern University Northwestern University
Email: akuzma at northwestern.edu Email: akuzma at northwestern.edu
 End of changes. 51 change blocks. 
115 lines changed or deleted 234 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/