draft-ietf-tcpm-ecnsyn-01.txt   draft-ietf-tcpm-ecnsyn-02.txt 
Internet Engineering Task Force A. Kuzmanovic Internet Engineering Task Force A. Kuzmanovic
INTERNET DRAFT Northwestern University INTERNET-DRAFT A. Mondal
draft-ietf-tcpm-ecnsyn-01.txt S. Floyd Intended status: Proposed Standard Northwestern University
Expires: 30 December 2007 S. Floyd
ICIR ICIR
K.K. Ramakrishnan K.K. Ramakrishnan
AT&T AT&T
October, 2006
Adding Explicit Congestion Notification (ECN) Capability to TCP's Adding Explicit Congestion Notification (ECN) Capability to TCP's
SYN/ACK Packets SYN/ACK Packets
draft-ietf-tcpm-ecnsyn-02.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 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 2006. This Internet-Draft will expire on December 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract Abstract
This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK
packets to be ECN-Capable. For TCP, RFC 3168 only specified setting packets to be ECN-Capable. For TCP, RFC 3168 only specifies setting
an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK
packets. However, because of the high cost to the TCP transfer of packets. However, because of the high cost to the TCP transfer of
having a SYN/ACK packet dropped, with the resulting retransmit having a SYN/ACK packet dropped, with the resulting retransmit
timeout, this document is specifying 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 an ECN the network. The sender of the SYN/ACK packet must respond to a
mark by reducing its initial congestion window from two, three, or report of an ECN-marked SYN/ACK packet by reducing its initial
four segments to one segment, reducing the subsequent load from that congestion window from two, three, or four segments to one segment,
connection on the network. thereby reducing the subsequent load from that connection on the
network.
Table of Contents
1. Conventions .....................................................4
2. Introduction ....................................................4
3. Proposal ........................................................5
4. Discussion ......................................................8
5. Related Work ...................................................11
6. Performance Evaluation .........................................12
6.1. The Costs and Benefit of Adding ECN-Capability ............12
6.2. An Evaluation of Different Responses to ECN-Marked SYN/ACK
Packets ........................................................14
7. Security Considerations ........................................14
8. Conclusions ....................................................15
9. Acknowledgements ...............................................16
A. Report on Simulations ..........................................16
A.1. Simulations with RED in Packet Mode .......................17
A.2. Simulations with RED in Byte Mode .........................18
Normative References ..............................................19
Informative References ............................................19
IANA Considerations ...............................................21
Full Copyright Statement ..........................................21
Intellectual Property .............................................22
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-01:
* Changes in response to feedback from Anil Agarwal.
* Added a look at the costs of adding ECN-Capability to
SYN/ACKs in a highly-congested scenario.
From feedback from Mark Allman and Janardhan Iyengar.
* Added a comparative evaluation of two possible responses
to an ECN-marked SYN/ACK packet. From Mark Allman.
Changes from draft-ietf-tcpm-ecnsyn-00: Changes from draft-ietf-tcpm-ecnsyn-00:
* Only updating the revision number. * Only updating the revision number.
Changes from draft-ietf-twvsg-ecnsyn-00: Changes from draft-ietf-twvsg-ecnsyn-00:
* Changed name of draft to draft-ietf-tcpm-ecnsyn. * Changed name of draft to draft-ietf-tcpm-ecnsyn.
* Added a discussion in Section 3 of "Response to * Added a discussion in Section 3 of "Response to
ECN-marking of SYN/ACK packets". Based on ECN-marking of SYN/ACK packets". Based on
skipping to change at page 3, line 13 skipping to change at page 4, line 13
* 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. Conventions
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].
1. Introduction 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 4, line 8 skipping to change at page 5, line 8
1) For short transfers, a TCP connection's congestion window may be 1) For short transfers, a TCP connection's congestion window may be
small. For example, if the current window contains only one packet, small. For example, if the current window contains only one packet,
and that packet is dropped, TCP will have to wait for a retransmit and that packet is dropped, TCP will have to wait for a retransmit
timeout to recover, reducing its overall throughput. Similarly, if timeout to recover, reducing its overall throughput. Similarly, if
the current window contains only a few packets and one of those the current window contains only a few packets and one of those
packets is dropped, there might not be enough duplicate packets is dropped, there might not be enough duplicate
acknowledgements for a fast retransmission, and the sender might have acknowledgements for a fast retransmission, and the sender might have
to wait for a delay of several round-trip times using Limited to wait for a delay of several round-trip times using Limited
Transmit [RFC3042]. With the use of ECN, short flows are less likely Transmit [RFC3042]. With the use of ECN, short flows are less likely
to have packets dropped, sometimes avoiding unnecessary delays or to have packets dropped, sometimes avoiding unnecessary delays or
costly retransmit timeouts. costly retransit timeouts.
2) While longer flows may not see substantially improved throughput 2) While longer flows may not see substantially improved throughput
with the use of ECN, they experience lower loss. This may benefit TCP with the use of ECN, they experience lower loss. This may benefit TCP
applications that are latency- and loss-sensitive, because of the applications that are latency- and loss-sensitive, because of the
avoidance of retransmissions. avoidance of retransmissions.
RFC 3168 only specified marking the Congestion Experienced codepoint RFC 3168 only specifies marking the Congestion Experienced codepoint
on TCP's data packets, and not on SYN and SYN/ACK packets. RFC 3168 on TCP's data packets, and not on SYN and SYN/ACK packets. RFC 3168
specified the negotiation of the use of ECN between the two TCP end- specifies the negotiation of the use of ECN between the two TCP end-
points in the TCP SYN and SYN-ACK exchange, using flags in the TCP points in the TCP SYN and SYN-ACK exchange, using flags in the TCP
header. Erring on the side of being conservative, RFC 3168 did not header. Erring on the side of being conservative, RFC 3168 does not
specify the use of ECN for the SYN/ACK packet itself. However, specify the use of ECN for the SYN/ACK packet itself. However,
because of the high cost to the TCP transfer of having a SYN/ACK because of the high cost to the TCP transfer of having a SYN/ACK
packet dropped, with the resulting retransmit timeout, this document packet dropped, with the resulting retransmit timeout, this document
is specifying the use of ECN for the SYN/ACK packet itself. This can specifies the use of ECN for the SYN/ACK packet itself. This can be
be of great benefit to the TCP connection, avoiding the severe of great benefit to the TCP connection, avoiding the severe penalty
penalty of a retransmit timeout for a connection that has not yet of a retransmit timeout for a connection that has not yet started
started placing a load on the network. The sender of the SYN/ACK placing a load on the network. The sender of the SYN/ACK packet must
packet must respond to an ECN mark by reducing its initial congestion respond to a report of an ECN-marked SYN/ACK packet by reducing its
window from two, three, or four segments to one segment, reducing the initial congestion window from two, three, or four segments to one
subsequent load from that connection on the network. segment, reducing the subsequent load from that connection on the
network.
The use of ECN for SYN/ACK packets has the following potential The use of ECN for SYN/ACK packets has the following potential
benefits: benefits:
1) Avoidance of a retransmit timeout; 1) Avoidance of a retransmit timeout;
2) Improvement in the throughput of short connections. 2) Improvement in the throughput of short connections.
This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK This draft specifies ECN+, a modification to RFC 3168 to allow TCP
packets to be ECN-Capable. Section 2 contains the specification of SYN/ACK packets to be ECN-Capable. Section 2 contains the
the change, while Section 3 discusses some of the issues, and Section specification of the change, while Section 3 discusses some of the
4 discusses related work. Section 5 contains an evaluation of the issues, and Section 4 discusses related work. Section 5 contains an
proposed change. evaluation of the proposed change.
2. 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.
The ECN flags in the TCP header: The ECN flags in the TCP header:
skipping to change at page 7, line 23 skipping to change at page 8, line 23
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 Table 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. 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 Section 4. Congestion is
most likely to occur in the server-to-client direction. As a result, most likely to occur in the server-to-client direction. As a result,
setting an ECN-capable codepoint in SYN/ACK packets can reduce the setting an ECN-capable codepoint in SYN/ACK packets can reduce the
occurence of three-second retransmit timeouts resulting from the drop occurrence of three-second retransmit timeouts resulting from the
of SYN/ACK packets. 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
greatly 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: 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
skipping to change at page 8, line 28 skipping to change at page 9, line 29
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:
If there are some older TCP implementations that don't respond to the In order for TCP node B to send a SYN/ACK packet as ECN-Capable, node
Congestion Experienced codepoint in a SYN/ACK packet, that would not B must have received an ECN-setup SYN packet from node A. However,
be an insurmountable problem. It would mean that the sender of the it is possible that node A supports ECN, but either ignores the CE
SYN/ACK packet would not reduce the initial congestion window from codepoint on received SYN/ACK packets, or ignores SYN/ACK packets
two, three, or four segments down to one segment, as it should. 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
connection would not respond to this congestion indication. As
discussed in Section 2 under "Backwards compatibility", this would
not be an insurmountable problem. It would mean that the sender of
the SYN/ACK packet would not reduce the initial congestion window
from two, three, or four segments down to one segment, as it should.
However, the TCP sender would still respond correctly to any However, the TCP sender would still respond correctly to any
subsequent CE indications on data packets later on in the connection. subsequent CE indications on data packets later on in the connection.
It is also possible that in some older TCP implementation, the TCP
sender ignores SYN/ACK packets with the ECT or CE codepoint set.
This would result in a delay in connection set-up for that TCP
connection, with the TCP sender re-sending the SYN packet after a
retransmit timeout.
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 10, line 4 skipping to change at page 11, line 19
default time before sending a data packet is not the desired default time before sending a data packet is not the desired
response. response.
On the conservative end, one could assume an effective congestion On the conservative end, one could assume an effective congestion
window of one packet for the SYN/ACK packet, and respond to an ECN- window of one packet for the SYN/ACK packet, and respond to an ECN-
marked SYN/ACK packet by reducing the sending rate to one packet marked SYN/ACK packet by reducing the sending rate to one packet
every two round-trip times. As an approximation, the TCP end-node every two round-trip times. As an approximation, the TCP end-node
could measure the round-trip time T between the sending of the could measure the round-trip time T between the sending of the
SYN/ACK packet and the receipt of the acknowledgement, and reply to SYN/ACK packet and the receipt of the acknowledgement, and reply to
the acknowledgement of the ECN-marked SYN/ACK packet by waiting T the acknowledgement of the ECN-marked SYN/ACK packet by waiting T
seconds before sending a data packet. However, we note that for an seconds before sending a data packet.
ECN-marked SYN/ACK packet, halving the *congestion window* is not the
same as halving the *sending rate*; there is no `sending rate' However, we note that for an ECN-marked SYN/ACK packet, halving the
associated with an ECN-Capable SYN/ACK packet, as such packets are *congestion window* is not the same as halving the *sending rate*;
only sent as the first packet in a connection from that host. there is no `sending rate' associated with an ECN-Capable SYN/ACK
Further, a router's marking of a SYN/ACK packet is not affected by packet, as such packets are only sent as the first packet in a
any past history of that connection. connection from that host. Further, a router's marking of a SYN/ACK
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 such an approach is useful to users, with no dangers of that this approach is useful to users, with no dangers of congestion
congestion collapse or of starvation of competing traffic. collapse or of starvation of competing traffic. This is discussed in
more detail below in Section 5.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.
4. 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
in [ECN+]. The paper includes an extensive set of simulation and in [ECN+]. The paper includes an extensive set of simulation and
testbed experiments to evaluate the effects of the proposal, using testbed experiments to evaluate the effects of the proposal, using
several Active Queue Management (AQM) mechanisms, including Random several Active Queue Management (AQM) mechanisms, including Random
Early Detection (RED) [RED], Random Exponential Marking (REM) [REM], Early Detection (RED) [RED], Random Exponential Marking (REM) [REM],
and Proportional Integrator (PI) [PI]. The performance measures were and Proportional Integrator (PI) [PI]. The performance measures were
the end-to-end response times for each request/response pair, and the the end-to-end response times for each request/response pair, and the
aggregate throughput on the bottleneck link. The end-to-end response aggregate throughput on the bottleneck link. The end-to-end response
time was computed as the time from the moment when the request for time was computed as the time from the moment when the request for
the file is sent to the server, until that file is successfully the file is sent to the server, until that file is successfully
downloaded by the client. downloaded by the client.
The measurements from [ECN+] showed that setting an ECN-Capable The measurements from [ECN+] show that setting an ECN-Capable
codepoint in the IP packet header in TCP SYN/ACK packets codepoint in the IP packet header in TCP SYN/ACK packets
systematically improves performance with all evaluated AQM schemes. systematically improves performance with all evaluated AQM schemes.
When SYN/ACK packets at a congested router are ECN-marked instead of When SYN/ACK packets at a congested router are ECN-marked instead of
dropped, this can avoid a long initial retransmit timeout, improving dropped, this can avoid a long initial retransmit timeout, improving
the response time for the affected flow dramatically. the response time for the affected flow dramatically.
[ECN+] showed that the impact on aggregate throughput can also be [ECN+] shows that the impact on aggregate throughput can also be
quite significant, because marking SYN ACK packets can prevent larger quite significant, because marking SYN ACK packets can prevent larger
flows from suffering long timeouts before being "admitted" into the flows from suffering long timeouts before being "admitted" into the
network. In addition, the testbed measurements from [ECN+] showed network. In addition, the testbed measurements from [ECN+] show that
that Web servers setting the ECN-Capable codepoint in TCP SYN/ACK web servers setting the ECN-Capable codepoint in TCP SYN/ACK packets
packets could serve more requests. could serve more requests.
As a final step, [ECN+] explored the co-existence of flows that do As a final step, [ECN+] explores the co-existence of flows that do
and don't set the ECN-capable codepoint in TCP SYN/ACK packets. The and don't set the ECN-capable codepoint in TCP SYN/ACK packets. The
results in [ECN+] show that both types of flows can coexist, with results in [ECN+] show that both types of flows can coexist, with
some performance degradation for flows that don't apply the change. some performance degradation for flows that don't use ECN+. Flows
Flows that apply the change improve their end-to-end performance. At that do use ECN+ improve their end-to-end performance. At the same
the same time, the performance degradation for flows that don't apply time, the performance degradation for flows that don't use ECN+, as a
the change, as a result of the flows that do apply the change, result of the flows that do use ECN+, increases as a greater fraction
increases as a greater fraction of flows apply the change. of flows use ECN+.
5. Performance Evaluation 6. Performance Evaluation
5.1. The Costs and Benefit of Adding ECN-Capability 6.1. The Costs and Benefit of Adding ECN-Capability
[ECN+] explored the costs and benefits of adding ECN-Capability to [ECN+] explores the costs and benefits of adding ECN-Capability to
SYN/ACK packets with both simulations and experiments. The addition SYN/ACK packets with both simulations and experiments. The addition
of ECN-capability to SYN/ACK packets could be of significant benefit of ECN-capability to SYN/ACK packets could be of significant benefit
for those ECN connections that would have had the SYN/ACK packet for those ECN connections that would have had the SYN/ACK packet
dropped in the network, and for which the ECN-Capability would allow dropped in the network, and for which the ECN-Capability would allow
the SYN/ACK to be marked rather than dropped. the SYN/ACK to be marked rather than dropped.
The percent of SYN/ACK packets on a link can be quite high. In The percent of SYN/ACK packets on a link can be quite high. In
particular, measurements on links dominated by Web traffic indicate particular, measurements on links dominated by web traffic indicate
that 15-20% of the packets can be SYN/ACK packets [SCJO01]. that 15-20% of the packets can be SYN/ACK packets [SCJO01].
The benefit of adding ECN-capability to SYN/ACK packets depends in The benefit of adding ECN-capability to SYN/ACK packets depends in
part on the size of the data transfer. The drop of a SYN/ACK packet part on the size of the data transfer. The drop of a SYN/ACK packet
can increase the download time of a short file by an order of can increase the download time of a short file by an order of
magnitude, by requiring a three-second 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.
The question that arises of course is what fraction of connections One question that arises is what fraction of connections would see
would see the benefit from making SYN/ACK packets ECN-capable, in a the benefit from making SYN/ACK packets ECN-capable, in a particular
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 of those (2) Of those SYN/ACK packets that are dropped, what fraction of those
drops would have been ECN-marks instead of drops if the SYN/ACK drops would have been ECN-marks instead of drops if the SYN/ACK
packets had 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 3 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
skipping to change at page 12, line 40 skipping to change at page 14, line 8
e.g., 10%, even if the packets are ECN-capable. For a router with e.g., 10%, even if the packets are ECN-capable. For a router with
such an AQM mechanism, when congestion is sufficiently severe to such an AQM mechanism, when congestion is sufficiently severe to
cause a high drop/mark rate, some SYN/ACK packets would be dropped cause a high drop/mark rate, some SYN/ACK packets would be dropped
instead of marked whether or not they were ECN-capable. instead of marked whether or not they were ECN-capable.
Thus, the degree of benefit of adding ECN-Capability to SYN/ACK Thus, the degree of benefit of adding ECN-Capability to SYN/ACK
packets depends not only on the overall packet drop rate in the packets depends not only on the overall packet drop rate in the
network, but also on the queue management architecture at the network, but also on the queue management architecture at the
congested link. congested link.
5.2. An Evaluation of Different Responses to ECN-Marked SYN/ACK 6.2. An Evaluation of Different Responses to ECN-Marked SYN/ACK Packets
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 packet, instead of its possible default value of two to four to one segment, instead of its possible default value of two to four
packets. However, in Section 3 we discussed another possible segments. We call this ECN+ with NoWaiting. However, in Section 3
response to an ECN-marked SYN/ACK packet, of the end-node waiting an discussed another possible response to an ECN-marked SYN/ACK packet,
RTT before sending a data packet. Future work will include a of the end-node waiting an RTT before sending a data packet. We call
comparative evaluation of these two methods. this approach ECN+ with Waiting.
6. Security Considerations Simulations comparing the performance with Standard ECN (without ECN-
marked SYN/ACK packets), ECN+ with NoWaiting, and ECN+ with Waiting
show little difference, in terms of aggregate congestion, between
ECN+ with NoWaiting and ECN+ with Waiting. The details are given in
Appendix A below. Our conclusions are that ECN+ with NoWaiting is
perfectly safe, and there are no congestion-related reasons for
preferring ECN+ with Waiting over ECN+ with NoWaiting. That is,
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
ECN-marked SYN/ACK packet.
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" middleboxes: "Bad" routers or middleboxes:
There is a small but decreasing number of middleboxes that drop or There is a small but decreasing number of routers or middleboxes that
reset SYN and SYN/ACK packets based on the ECN-related flags in the drop or reset SYN and SYN/ACK packets based on the ECN-related flags
TCP header [MAF05], [RFC3360]. While there is no evidence that any in the TCP header [MAF05], [RFC3360]. While there is no evidence
middleboxes drop SYN/ACK packets that contain an ECN-Capable that any middleboxes drop SYN/ACK packets that contain an ECN-Capable
codepoint in the *IP header*, such behavior cannot be excluded. or CE codepoint in the *IP header*, such behavior cannot be excluded.
Thus, as specified in Section 2, if a SYN/ACK packet with the ECT Thus, as specified in Section 2, if a SYN/ACK packet with the ECT or
codepoint is dropped, the TCP node SHOULD resend the SYN/ACK packet CE codepoint is dropped, the TCP node SHOULD resend the SYN/ACK
without the ECN-Capable codepoint. packet without the ECN-Capable codepoint.
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. This is not a problem because after highly congested scenarios. However, after learning that a SYN/ACK
learning that the SYN/ACK packet was ECN-marked, the sender of that packet was ECN-marked, the sender of that packet will only send one
packet will only send one data packet; in the case that this data data packet; if this data packet is ECN-marked, the sender will then
packet is ECN-marked, the sender will wait for a retransmission wait for a retransmission timeout. In addition, routers are free to
timeout. In addition, routers are free to drop rather than mark drop rather than mark arriving packets in times of high congestion,
arriving packets in times of high congestion, regardless of whether regardless of whether the packets are ECN-capable. When congestion
the packets are ECN-capable. is very high and a router's buffer is full, the router has no choice
but to drop rather than to mark an arriving packet.
7. Conclusions The simulations reported in Appendix A show that even with demanding
traffic mixes dominated by short flows and high levels of congestion,
the aggregate packet dropping rates are not significantly different
with Standard ECN, ECN+ with NoWaiting, or ECN+ with Waiting. In
particular, the simulations show that in periods of very high
congestion the packet-marking rate is low with or without ECN+, and
the use of ECN+ does not significantly increase the number of dropped
or marked packets.
The simulations show that ECN+ is most effective in times of moderate
congestion. In these moderate-congested scenarios, the use of ECN+
increases the number of ECN-marked packets, because ECN+ allows
SYN/ACK packets to be ECN-marked. At the same time, in these times
of moderate congestion, the use of ECN+ instead of Standard ECN does
not significantly affect the overall levels of congestion.
The simulations show that the use of ECN+ is less effective in times
of high congestion; the simulations show that in times of high
congestion more packets are dropped instead of marked, both with
Standard ECN and with ECN+. In times of high congestion, the buffer
can overflow, even with Active Queue Management and ECN; when the
buffer is full arriving packets are dropped rather than marked,
whether the packets are ECN-capable or not. Thus while ECN+ is less
effective in times of high congestion, it still doesn't result in a
significant increase in the level of congestion. More details are
given in the appendix.
8. Conclusions
This draft specifies a modification to RFC 3168 to allow TCP nodes to This draft specifies a modification to RFC 3168 to allow TCP nodes to
send SYN/ACK packets as being ECN-Capable. Making the SYN/ACK packet send SYN/ACK packets as being ECN-Capable. Making the SYN/ACK packet
ECN-Capable avoids the high cost to a TCP transfer when a SYN/ACK ECN-Capable avoids the high cost to a TCP transfer when a SYN/ACK
packet is dropped by a congested router, by avoiding the resulting packet is dropped by a congested router, by avoiding the resulting
retransmit timeout. This improves the throughput of short retransmit timeout. This improves the throughput of short
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
skipping to change at page 14, line 6 skipping to change at page 16, line 12
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- Future work will address the more general question of adding ECN-
Capability to relevant handshake packets in other protocols that use Capability to relevant handshake packets in other protocols that use
retransmission-based reliability in their setup phase (e.g., SCTP, retransmission-based reliability in their setup phase (e.g., SCTP,
DCCP, HIP, and the like). DCCP, HIP, and the like).
8. Acknowledgements 9. Acknowledgements
We thank Mark Allman, Wesley Eddy, Janardhan Iyengar, and Pasi We thank Anil Agarwal, Mark Allman, Wesley Eddy, Janardhan Iyengar,
Sarolahti for feedback on earlier versions of this draft. and Pasi Sarolahti for feedback on earlier versions of this draft.
9. Normative References A. Report on Simulations
This section reports on simulations showing the costs of adding ECN+
in highly-congested scenarios. This section also reports on
simulations for a comparative evaluation between ECN+ with NoWaiting
and ECN+ with Waiting.
The simulations are run with a range of file-size distributions. As
a baseline, they use the empirical heavy-tailed distribution reported
in [SCJO01], with a mean file size of around 7 KBytes. This flow-
size distribution is manipulated by skewing the flow sizes towards
lower and higher values to get distributions with mean file sizes of
3 KBytes, 5 KBytes, 14 KBytes and 17 KBytes. 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
an ECN-marked SYN/ACK packet. With ECN+ with NoWaiting, the TCP node
sends a data packet immediately (with an initial congestion window of
one segment). With the alternative ECN+ with Waiting, the TCP node
waits a round-trip time before sending a data packet; the sender
already has one measurement of the round-trip time when the
acknowledgement for the SYN/ACK packet is received.
In the tables below, ECN+ refers to ECN+ with NoWaiting, where the
sender starts transmitting immediately, and ECN+/wait refers to ECN+
with Waiting, where the sender waits a round-trip time before sending
a data packet into the network.
The simulation scripts are available on [ECN-SYN], along with graphs
showing the distribution of response times for the TCP connections.
A.1. Simulations with RED in Packet Mode
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
adds little benefit in times of high congestion. The simulations
show a minimal increase in levels of congestion with either ECN+ with
Waiting or ECN+ with NoWaiting, either in terms of packet dropping or
marking rates or in terms of the distribution of responses times.
Thus, the simulations show no problems with ECN+ in times of high
congestion, and no reason to use ECN+ with Waiting instead of ECN+
with NoWaiting.
Table 3 shows the congestion levels for simulations with RED in
packet mode, with a queue in packets. To explore a worst-case
scenario, these simulations use a traffic mix with an unrealistically
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
number of packets dropped, the number of packets ECN-marked, and the
aggregate packet drop rate, and the three columns show the
simulations with Standard ECN, ECN+ (NoWaiting) and ECN+/wait.
The usefulness of ECN+: The first thing to observe is that for the
simulations with the somewhat moderate load of 95%, with packet drop
rates of 5-6%, the use of ECN+ or ECN+/wait more than doubled the
number of packets marked. This indicates that with ECN+ or
ECN+/wait, many SYN/ACK packets are marked instead of dropped.
No increase in congestion: The second thing to observe is that in all
of the simulations, the use of ECN+ or ECN+/wait does not
significantly increase the aggregate packet drop rate.
Comparing ECN+ and ECN+/wait: The third thing to observe is that
there is little difference between ECN+ and ECN+/wait in terms of the
aggregate packet drop rate. Thus, there is no congestion-related
reason to prefer ECN+/wait over ECN+.
Traffic Load = 95%:
ECN ECN+ ECN+/wait
------- ------- -------
Dropped 74,645 64,034 64,983
Marked 7,639 17,681 16,914
Loss rate 6.05% 5.26% 5.33%
Traffic Load = 110%:
ECN ECN+ ECN+/wait
------- ------- -------
Dropped 161,644 163,620 165,196
Marked 4,375 6,653 6,144
Loss rate 10.38% 10.45% 10.53%
Traffic Load = 125%:
ECN ECN+ ECN+/wait
------- ------- -------
Dropped 257,671 268,161 264,437
Marked 2,885 3,712 3,359
Loss rate 14.52% 15.00% 14.83%
Traffic Load = 150%:
ECN ECN+ ECN+/wait
------- ------- -------
Loss rate 24.36% 24.61% 24.46%
Traffic Load = 200%:
ECN ECN+ ECN+/wait
------- ------- -------
Loss rate 29.99% 30.22% 30.23%
Table 3: Simulations with an average flow size of 3 Kbytes, RED in
packet mode, queue in packets.
A.2. Simulations with RED in Byte Mode
Table 4 below shows simulations with RED in byte mode and the queue
in bytes. Like the simulations with RED in packet mode, there is no
significant increase in aggregate congestion with the use of ECN+ or
ECN+/wait, and no congestion-related reason to prefer ECN+/wait over
ECN+.
However, unlike the simulations with RED in packet mode, the
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+/wait is not much different than the packet marking rate with
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
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
to be dropped or marked.
Traffic Load = 95%:
ECN ECN+ ECN+/wait
------- ------- -------
Dropped 13,044 13,323 14,855
Marked 18,880 19,175 19,049
Loss rate 1.13% 1.16% 1.29%
Traffic Load = 110%:
ECN ECN+ ECN+/wait
------- ------- -------
Dropped 84,809 83,013 83,564
Marked 4,086 4,644 4,826
Loss rate 5.90% 5.78% 5.81%
Traffic Load = 125%:
ECN ECN+ ECN+/wait
------- ------- -------
Dropped 157,305 157,435 158,368
Marked 2,183 2,363 2,663
Loss rate 9.89% 9.87% 9.93%
Table 4: Simulations with an average flow size of 3 Kbytes, RED in
byte mode, queue in bytes.
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.
[RFC3390] M. Allman, S. Floyd, and C. Partridge, Increasing TCP's Informative References
Initial Window, RFC 3390, October 2002.
10. 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.
[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, INFOCOM, Improved Controllers for AQM Routers Supporting TCP Flows, April
June 2001. 1998.
[RED] S. Floyd and V. Jacobson, Random Early Detection Gateways for [RED] Floyd, S., and Jacobson, V. Random Early Detection gateways
Congestion Avoidance, IEEE/ACM Transactions on Networking, V.1, N.4, for Congestion Avoidance . IEEE/ACM Transactions on Networking, V.1
1993. N.4, August 1993.
[REM] S. Athuraliya, V. Li, S. Low, and Q Yin, REM: Active Queue [REM] S. Athuraliya, V. H. Li, S. H. Low and Q. Yin, REM: Active
Management, IEEE Network, V.15, N. 3, May 2001. Queue Management, IEEE Network, May 2001.
[RFC2309] B. Braden et al., Recommendations on Queue Management and [RFC2309] B. Braden et al., Recommendations on Queue Management and
Congestion Avoidance in the Internet, RFC 2309, April 1998. Congestion Avoidance in the Internet, RFC 2309, April 1998.
[RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion [RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion
Control, RFC 2581, April 1999. Control, RFC 2581, April 1999.
[RFC2988] V. Paxson and M. Allman, Computing TCP's Retransmission [RFC2988] V. Paxson and M. Allman, Computing TCP's Retransmission
Timer, RFC 2988, November 2000. Timer, RFC 2988, November 2000.
[RFC3042] M. Allman, H. Balakrishnan, and S. Floyd, Enhancing TCP's [RFC3042] M. Allman, H. Balakrishnan, and S. Floyd, Enhancing TCP's
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
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>
[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-02, work in progress, June 2006. tools-03, work in progress, December 2006.
11. 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@northwestern.edu Email: akuzma at northwestern.edu
URL: http://cs.northwestern.edu/~a URL: http://cs.northwestern.edu/~a
Amit Mondal
Northwestern University
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@icir.org Email: floyd at 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@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
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The IETF Trust (2007).
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on This document is subject to the rights, licenses and restrictions
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE contained in BCP 78, and except as set forth therein, the authors
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE retain all their rights.
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed to
to pertain to the implementation or use of the technology described pertain to the implementation or use of the technology described in
in this document or the extent to which any license under such this document or the extent to which any license under such rights
rights might or might not be available; nor does it represent that might or might not be available; nor does it represent that it has
it has made any independent effort to identify any such rights. made any independent effort to identify any such rights. Information
Information on the procedures with respect to rights in RFC on the procedures with respect to rights in RFC documents can be
documents can be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use of
of such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository at
at http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
 End of changes. 63 change blocks. 
131 lines changed or deleted 378 lines changed or added

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