draft-ietf-tcpm-ecnsyn-02.txt   draft-ietf-tcpm-ecnsyn-03.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: 30 December 2007 S. Floyd Expires: 18 May 2008 S. Floyd
ICIR ICIR
K.K. Ramakrishnan K.K. Ramakrishnan
AT&T AT&T
Adding Explicit Congestion Notification (ECN) Capability to TCP's 18 November 2007
SYN/ACK Packets
draft-ietf-tcpm-ecnsyn-02.txt Adding Explicit Congestion Notification (ECN) Capability
to TCP's SYN/ACK Packets
draft-ietf-tcpm-ecnsyn-03.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 30 skipping to change at page 2, line 26
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. network.
Table of Contents Table of Contents
1. Conventions .....................................................4 1. Introduction ....................................................4
2. Introduction ....................................................4 2. Conventions .....................................................5
3. Proposal ........................................................5 3. Proposal ........................................................6
4. Discussion ......................................................8 4. Discussion ......................................................9
5. Related Work ...................................................11 5. Related Work ...................................................12
6. Performance Evaluation .........................................12 6. Performance Evaluation .........................................13
6.1. The Costs and Benefit of Adding ECN-Capability ............12 6.1. The Costs and Benefit of Adding ECN-Capability ............13
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 ........................................................14
7. Security Considerations ........................................14 7. Security Considerations ........................................15
8. Conclusions ....................................................15 8. Conclusions ....................................................16
9. Acknowledgements ...............................................16 9. Acknowledgements ...............................................17
A. Report on Simulations ..........................................16 A. Report on Simulations ..........................................17
A.1. Simulations with RED in Packet Mode .......................17 A.1. Simulations with RED in Packet Mode .......................18
A.2. Simulations with RED in Byte Mode .........................18 A.2. Simulations with RED in Byte Mode .........................19
Normative References ..............................................19 Normative References ..............................................20
Informative References ............................................19 Informative References ............................................20
IANA Considerations ...............................................21 IANA Considerations ...............................................22
Full Copyright Statement ..........................................21 Full Copyright Statement ..........................................22
Intellectual Property .............................................22 Intellectual Property .............................................23
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-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 Henes.
Changes from draft-ietf-tcpm-ecnsyn-01: Changes from draft-ietf-tcpm-ecnsyn-01:
* Changes in response to feedback from Anil Agarwal. * Changes in response to feedback from Anil Agarwal.
* Added a look at the costs of adding ECN-Capability to * Added a look at the costs of adding ECN-Capability to
SYN/ACKs in a highly-congested scenario. SYN/ACKs in a highly-congested scenario.
From feedback from Mark Allman and Janardhan Iyengar. From feedback from Mark Allman and Janardhan Iyengar.
* Added a comparative evaluation of two possible responses * Added a comparative evaluation of two possible responses
to an ECN-marked SYN/ACK packet. From Mark Allman. to an ECN-marked SYN/ACK packet. From Mark Allman.
skipping to change at page 4, line 7 skipping to change at page 4, line 16
* Future work: a comparative evaluation of two * Future work: a comparative evaluation of two
possible responses to an ECN-marked SYN/ACK packet. possible responses to an ECN-marked SYN/ACK packet.
Changes from draft-kuzmanovic-ecn-syn-00.txt: Changes from draft-kuzmanovic-ecn-syn-00.txt:
* Changed name of draft to draft-ietf-twvsg-ecnsyn. * Changed name of draft to draft-ietf-twvsg-ecnsyn.
END OF NOTE TO RFC EDITOR. END OF NOTE TO RFC EDITOR.
1. Conventions 1. Introduction
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
2. 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.
skipping to change at page 5, line 38 skipping to change at page 5, line 42
initial congestion window from two, three, or four segments to one initial congestion window from two, three, or four segments to one
segment, reducing the subsequent load from that connection on the segment, reducing the subsequent load from that connection on the
network. network.
The use of ECN for SYN/ACK packets has the following potential The use of ECN for SYN/ACK packets has the following potential
benefits: benefits:
1) Avoidance of a retransmit timeout; 1) Avoidance of a retransmit timeout;
2) Improvement in the throughput of short connections. 2) Improvement in the throughput of short connections.
This draft specifies 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 2 contains the SYN/ACK packets to be ECN-Capable. Section 3 contains the
specification of the change, while Section 3 discusses some of the specification of the change, while Section 4 discusses some of the
issues, and Section 4 discusses related work. Section 5 contains an issues, and Section 5 discusses related work. Section 6 contains an
evaluation of the proposed change. evaluation of the proposed change.
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
3. Proposal 3. Proposal
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. We use the following terminology SYN/ACK packets to be ECN-Capable. We use the following terminology
from RFC 3168: from RFC 3168:
The ECN field in the IP header: The ECN field in the IP header:
o CE: the Congestion Experienced codepoint; and o CE: the Congestion Experienced codepoint; and
o ECT: either one of the two ECN-Capable Transport codepoints. o ECT: either one of the two ECN-Capable Transport codepoints.
skipping to change at page 6, line 26 skipping to change at page 6, line 36
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.
Table 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 6, line 50 skipping to change at page 7, line 25
. .
. .
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)
--------------------------------------------------------------- ---------------------------------------------------------------
Table 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 TCP host (node If the SYN/ACK packet is dropped in the network, the TCP host (node
B) responds by waiting three seconds for the retransmit timer to B) responds by waiting three seconds for the retransmit timer to
expire [RFC2988]. If a SYN/ACK packet with the ECT codepoint is expire [RFC2988]. If a SYN/ACK packet with the ECT codepoint is
dropped, the TCP node SHOULD resend the SYN/ACK packet without the dropped, the TCP node 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 Node B in the exchange in We note that if syn-cookies were used by Node B in the exchange in
Table 1, TCP Node B wouldn't set a timer upon transmission of the Figure 1, TCP Node B wouldn't set a timer upon transmission of the
SYN/ACK packet [SYN-COOK]. In this case, if the SYN/ACK packet was SYN/ACK packet [SYN-COOK]. In this case, if the SYN/ACK packet was
lost, the initiator (Node A) would have to timeout and retransmit the lost, the initiator (Node A) would have to timeout and retransmit the
SYN packet in order to trigger another SYN-ACK. SYN packet in order to trigger another SYN-ACK.
Table 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 --->
<--- ECN-setup SYN/ACK, ECT <--- ECN-setup SYN/ACK, ECT
<--- Sets CE on SYN/ACK <--- Sets CE on SYN/ACK
<--- ECN-setup SYN/ACK, CE <--- ECN-setup SYN/ACK, CE
Data/ACK, ECN-Echo ---> Data/ACK, ECN-Echo --->
Data/ACK, ECN-Echo ---> Data/ACK, ECN-Echo --->
Window reduced to one segment. Window reduced to one segment.
<--- Data, CWR (one segment only) <--- Data, CWR (one segment only)
--------------------------------------------------------------- ---------------------------------------------------------------
Table 2: SYN exchange with the SYN/ACK packet marked. Figure 2: SYN exchange with the SYN/ACK packet marked.
If the receiving node (node A) receives a SYN/ACK packet that has If the receiving node (node A) receives a SYN/ACK packet that has
been marked by the congested router, with the CE codepoint set, the been marked by the congested router, with the CE codepoint set, the
receiving node MUST respond by setting the ECN-Echo flag in the TCP receiving node MUST respond by setting the ECN-Echo flag in the TCP
header of the responding ACK packet. As specified in RFC 3168, the header of the responding ACK packet. As specified in RFC 3168, the
receiving node continues to set the ECN-Echo flag in packets until it receiving node continues to set the ECN-Echo flag in packets until it
receives a packet with the CWR flag set. receives a packet with the CWR flag set.
When the sending node (node B) receives the ECN-Echo packet reporting When the sending node (node B) receives the ECN-Echo packet reporting
the Congestion Experienced indication in the SYN/ACK packet, the node the Congestion Experienced indication in the SYN/ACK packet, the node
skipping to change at page 8, line 18 skipping to change at page 8, line 47
informing it of a Congestion Experienced indication on its SYN/ACK informing it of a Congestion Experienced indication on its SYN/ACK
packet, the sending node MAY continue to send with an initial window packet, the sending node MAY continue to send with an initial window
of one segment, without waiting for a retransmit timeout. We note of one segment, without waiting for a retransmit timeout. We note
that this updates RFC 3168, which specifies that "the sending TCP that this updates RFC 3168, which specifies that "the sending TCP
MUST reset the retransmit timer on receiving the ECN-Echo packet when MUST reset the retransmit timer on receiving the ECN-Echo packet when
the congestion window is one." As specified by RFC 3168, the sending the congestion window is one." As specified by RFC 3168, the sending
node (node B) also sets the CWR flag in the TCP header of the next node (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 the data packet sent, to acknowledge its receipt of and reaction to the
ECN-Echo flag. ECN-Echo flag.
If the data transfer in Table 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.
4. Discussion 4. Discussion
Motivation: Motivation:
The rationale for the proposed change is the following. When node B The rationale for the proposed change is the following. When node B
receives a TCP SYN packet with ECN-Echo bit set in the TCP header, receives a TCP SYN packet with ECN-Echo bit set in the TCP header,
this indicates that node A is ECN-capable. If node B is also ECN- this indicates that node A is ECN-capable. If node B is also ECN-
capable, there are no obstacles to immediately setting one of the capable, there are no obstacles to immediately setting one of the
ECN-Capable codepoints in the IP header in the responding TCP SYN/ACK ECN-Capable codepoints in the IP header in the 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 Section 4. Congestion is SYN/ACK packets, as is discussed further in [ECN+], and reported
most likely to occur in the server-to-client direction. As a result, briefly in Section 5 below. Congestion is most likely to occur in
setting an ECN-capable codepoint in SYN/ACK packets can reduce the the server-to-client direction. As a result, setting an ECN-capable
occurrence of three-second retransmit timeouts resulting from the codepoint in SYN/ACK packets can reduce the occurrence of three-
drop of SYN/ACK packets. second retransmit timeouts resulting from the drop of SYN/ACK
packets.
Flooding attacks: 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
skipping to change at page 9, line 15 skipping to change at page 9, line 45
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: 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 Table 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.
Backwards compatibility: Backwards compatibility:
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 sender ignores the CE with the ECT or CE codepoint set. If the TCP sender ignores the CE
codepoint on received SYN/ACK packets, this would mean that the TCP codepoint on received SYN/ACK packets, this would mean that the TCP
connection would not respond to this congestion indication. As connection would not respond to this congestion indication. However,
discussed in Section 2 under "Backwards compatibility", this would this seems to us an acceptable cost to pay in the incremental
not be an insurmountable problem. It would mean that the sender of deployment of ECN-Capability for TCP's SYN/ACK packets. It would
the SYN/ACK packet would not reduce the initial congestion window mean that the sender of the SYN/ACK packet would not reduce the
from two, three, or four segments down to one segment, as it should. initial congestion window from two, three, or four segments down to
However, the TCP sender would still respond correctly to any one segment, as it should. However, the TCP sender would still
subsequent CE indications on data packets later on in the connection. respond correctly to any subsequent CE indications on data packets
later on in the connection. Thus, to be explicit, when a TCP
connection includes a sender that supports ECN but *does not* support
ECN-Capability for SYN/ACK packets, in combination with a receiver
that *does* support ECN-Capabililty for SYN/ACK packets, it is quite
possible that the ECN-Capable SYN/ACK packets will be marked rather
than dropped in the network, and that the sender will not respond to
the ECN mark on the SYN/ACK packet.
It is also possible that in some older TCP implementation, the TCP It is also possible that in some older TCP implementation, the TCP
sender ignores SYN/ACK packets with the ECT or CE codepoint set. sender would ignore arriving SYN/ACK packets that had the ECT or CE
This would result in a delay in connection set-up for that TCP codepoint set. This would result in a delay in connection set-up for
connection, with the TCP sender re-sending the SYN packet after a that TCP connection, with the TCP sender re-sending the SYN packet
retransmit timeout. after a retransmit timeout. We are not aware of any TCP
implementations with this behavior.
SYN/ACK packets and packet size: 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.
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
skipping to change at page 11, line 36 skipping to change at page 12, line 24
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 setting the initial congestion window to one packet, instead of of setting the initial congestion window to one packet, instead of
its allowed default value of two, three, or four packets, with the its allowed default value of two, three, or four packets, with the
host proceeding with a cautious sending rate of one packet per round- host proceeding with a cautious sending rate of one packet per round-
trip time. If that packet is ECN-marked or dropped, then the sender trip time. If that packet is ECN-marked or dropped, then the sender
will wait an RTO before sending another packet. This document argues will wait an RTO before sending another packet. This document argues
that this approach is useful to users, with no dangers of congestion that 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 5.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,
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 13, line 11 skipping to change at page 13, line 48
can increase the download time of a short file by an order of can increase the download time of a short file by an order of
magnitude, by requiring a three-second retransmit timeout. For magnitude, by requiring a three-second retransmit timeout. For
longer-lived flows, the effect of a dropped SYN/ACK packet on file longer-lived flows, the effect of a dropped SYN/ACK packet on file
download time is less dramatic. However, even for longer-lived download time is less dramatic. However, even for longer-lived
flows, the addition of ECN-capability to SYN/ACK packets can improve flows, the addition of ECN-capability to SYN/ACK packets can improve
the fairness among long-lived flows, as newly-arriving flows would be the fairness among long-lived flows, as newly-arriving flows would be
less likely to have to wait for retransmit timeouts. less likely to have to wait for retransmit 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 of those have been ECN-marked instead of dropped if the SYN/ACK packets had
drops would have been ECN-marks instead of drops if the SYN/ACK been ECN-capable?
packets 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 3 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 ECN-
skipping to change at page 14, line 13 skipping to change at page 14, line 49
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. We call this ECN+ with NoWaiting. However, in Section 3 segments. We call this ECN+ with NoWaiting. However, in Section 4
discussed another possible response to an ECN-marked SYN/ACK packet, discussed another possible response to an ECN-marked SYN/ACK packet,
of the end-node waiting an RTT before sending a data packet. We call of the end-node waiting an RTT before sending a data packet. We call
this approach ECN+ with Waiting. this approach ECN+ with Waiting.
Simulations comparing the performance with Standard ECN (without ECN- Simulations comparing the performance with Standard ECN (without ECN-
marked SYN/ACK packets), ECN+ with NoWaiting, and ECN+ with Waiting marked SYN/ACK packets), ECN+ with NoWaiting, and ECN+ with Waiting
show little difference, in terms of aggregate congestion, between show little difference, in terms of aggregate congestion, between
ECN+ with NoWaiting and ECN+ with Waiting. The details are given in ECN+ with NoWaiting and ECN+ with Waiting. The details are given in
Appendix A below. Our conclusions are that ECN+ with NoWaiting is Appendix A below. Our conclusions are that ECN+ with NoWaiting is
perfectly safe, and there are no congestion-related reasons for perfectly safe, and there are no congestion-related reasons for
skipping to change at page 14, line 36 skipping to change at page 15, line 25
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: "Bad" routers or middleboxes:
There is a small but decreasing number of routers or middleboxes that There are a number of known deployment problems from using ECN with
drop or reset SYN and SYN/ACK packets based on the ECN-related flags TCP traffic in the Internet. The first reported problem, dating back
in the TCP header [MAF05], [RFC3360]. While there is no evidence to 2000, is of a small but decreasing number of routers or
that any middleboxes drop SYN/ACK packets that contain an ECN-Capable middleboxes that reset a TCP connection in response to TCP SYN
or CE codepoint in the *IP header*, such behavior cannot be excluded. packets using flags in the TCP header to negotiate ECN-capability
Thus, as specified in Section 2, if a SYN/ACK packet with the ECT or IETF of new two problems encountered by TCP connections using ECN;
CE codepoint is dropped, the TCP node SHOULD resend the SYN/ACK the first of the two problems concerns routers that crash when a TCP
packet without the ECN-Capable codepoint. data packet arrives with the ECN field in the IP header with the
codepoint ECT(0) or ECT(1), indicating that an ECN-Capable connection
has been established [SBT07].
While there is no evidence that any routers or middleboxes drop
SYN/ACK packets that contain an ECN-Capable or CE codepoint in the IP
header, such behavior cannot be excluded. (There seems to be a
number of routers or middleboxes that drop TCP SYN packets that
contain known or unknown IP options [MAF05] (Figure 1).) Thus, as
specified in Section 3, if a SYN/ACK packet with the ECT or CE
codepoint is dropped, the TCP node SHOULD resend the SYN/ACK packet
without the ECN-Capable codepoint. There is also no evidence that
any routers or middleboxes crash when a SYN/ACK arrives with an ECN-
Capable or CE codepoint in the IP header (over and above the routers
already known to crash when a data packet arrives with either ECT(0)
or ECT(1)), but we have not conducted any measurement studies of this
[F07].
Congestion collapse: 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 sender of that packet will only send one packet was ECN-marked, the sender of that packet will only send one
data packet; if this data packet is ECN-marked, the sender will then data packet; if this data packet is ECN-marked, the sender will then
wait for a retransmission timeout. In addition, routers are free to wait for a retransmission timeout. In addition, routers are free to
drop rather than mark arriving packets in times of high congestion, drop rather than mark arriving packets in times of high congestion,
skipping to change at page 17, line 17 skipping to change at page 18, line 20
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 3 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 The usefulness of ECN+: The first thing to observe is that for the
simulations with the somewhat moderate load of 95%, with packet drop simulations with the somewhat moderate load of 95%, with packet drop
skipping to change at page 18, line 36 skipping to change at page 19, line 36
Traffic Load = 150%: Traffic Load = 150%:
ECN ECN+ ECN+/wait ECN ECN+ ECN+/wait
------- ------- ------- ------- ------- -------
Loss rate 24.36% 24.61% 24.46% Loss rate 24.36% 24.61% 24.46%
Traffic Load = 200%: Traffic Load = 200%:
ECN ECN+ ECN+/wait ECN ECN+ ECN+/wait
------- ------- ------- ------- ------- -------
Loss rate 29.99% 30.22% 30.23% Loss rate 29.99% 30.22% 30.23%
Table 3: Simulations with an average flow size of 3 Kbytes, RED in Table 1: Simulations with an average flow size of 3 Kbytes, RED in
packet mode, queue in packets. packet mode, queue in packets.
A.2. Simulations with RED in Byte Mode A.2. Simulations with RED in Byte Mode
Table 4 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. Like the simulations with RED in packet mode, there is no
significant increase in aggregate congestion with the use of ECN+ or significant increase in aggregate congestion with the use of ECN+ or
ECN+/wait, and no congestion-related reason to prefer ECN+/wait over ECN+/wait, and no congestion-related reason 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
skipping to change at page 19, line 33 skipping to change at page 20, line 33
Marked 4,086 4,644 4,826 Marked 4,086 4,644 4,826
Loss rate 5.90% 5.78% 5.81% Loss rate 5.90% 5.78% 5.81%
Traffic Load = 125%: Traffic Load = 125%:
ECN ECN+ ECN+/wait ECN ECN+ ECN+/wait
------- ------- ------- ------- ------- -------
Dropped 157,305 157,435 158,368 Dropped 157,305 157,435 158,368
Marked 2,183 2,363 2,663 Marked 2,183 2,363 2,663
Loss rate 9.89% 9.87% 9.93% Loss rate 9.89% 9.87% 9.93%
Table 4: Simulations with an average flow size of 3 Kbytes, RED in Table 3: Simulations with an average flow size of 3 Kbytes, RED in
byte mode, queue in bytes. byte mode, queue in bytes.
Normative References Normative References
[RFC 2119] S. Bradner, Key words for use in RFCs to Indicate [RFC 2119] S. Bradner, Key words for use in RFCs to Indicate
Requirement Levels, RFC 2119, March 1997. Requirement Levels, RFC 2119, March 1997.
[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 to be added.
[F07] S. Floyd, "[BEHAVE] Response of firewalls and middleboxes to
TCP SYN packets that are ECN-Capable?", August 2, 2007, email sent to
the BEHAVE mailing list, URL "http://www1.ietf.org/mail-
archive/web/behave/current/msg02644.html".`
[Kelson00] Dax Kelson, note sent to the Linux kernel mailing list,
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
of Transport Protocols in the Internet, ACM CCR, April 2005. 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 Designing
Improved Controllers for AQM Routers Supporting TCP Flows, April Improved Controllers for AQM Routers Supporting TCP Flows, April
1998. 1998.
[RED] Floyd, S., and Jacobson, V. Random Early Detection gateways [RED] Floyd, S., and Jacobson, V. Random Early Detection gateways
for Congestion Avoidance . IEEE/ACM Transactions on Networking, V.1 for Congestion Avoidance . IEEE/ACM Transactions on Networking, V.1
N.4, August 1993. N.4, August 1993.
skipping to change at page 20, line 45 skipping to change at page 22, line 4
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} [SCJO01] F. Smith, F. Campos, K. Jeffay, 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 [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-03, work in progress, December 2006. tools-04, work in progress, July 2007.
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
URL: http://cs.northwestern.edu/~a URL: http://cs.northwestern.edu/~a
Amit Mondal Amit Mondal
Northwestern University Northwestern University
Email: a-mondal at northwestern.edu Email: a-mondal at northwestern.edu
Sally Floyd Sally Floyd
Phone: +1 (510) 666-2989 Phone: +1 (510) 666-2989
ICIR (ICSI Center for Internet Research) ICIR (ICSI Center for Internet Research)
Email: floyd at icir.org Email: floyd@icir.org
URL: http://www.icir.org/floyd/ URL: http://www.icir.org/floyd/
K. K. Ramakrishnan K. K. Ramakrishnan
Phone: +1 (973) 360-8764 Phone: +1 (973) 360-8764
AT&T Labs Research AT&T Labs Research
Email: kkrama at research.att.com Email: kkrama at research.att.com
URL: http://www.research.att.com/info/kkrama URL: http://www.research.att.com/info/kkrama
Full Copyright Statement Full Copyright Statement
 End of changes. 34 change blocks. 
79 lines changed or deleted 131 lines changed or added

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