[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-ietf-tsvwg-ecnsyn) 00 01 02 03 04 05 06 07 08 09 10 RFC 5562

Internet Engineering Task Force                            A. Kuzmanovic
INTERNET DRAFT                                   Northwestern University
draft-ietf-tcpm-ecnsyn-00.txt                                  S. Floyd
                                                                    ICIR
                                                       K.K. Ramakrishnan
                                                                    AT&T
                                                           January, 2006



   Adding Explicit Congestion Notification (ECN) Capability to TCP's
                            SYN/ACK Packets



Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   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
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 2006.

Abstract

   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
   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
   having a SYN/ACK packet dropped, with the resulting retransmit
   timeout, this document is specifying the use of ECN for the SYN/ACK



Kuzmanovic                   Standards Track                    [Page 1]

draft-ietf-tcpm-ecnsyn-00.txt                               January 2006


   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.
   Setting TCP SYN/ACK packets as ECN-Capable can be of great benefit to
   the TCP connection, avoiding the severe penalty of a retransmit
   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
   mark by reducing its initial congestion window from two, three, or
   four segments to one segment, reducing the subsequent load from that
   connection on the network.

   NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION.

   Changes from draft-ietf-twvsg-ecnsyn:

   * Changed name of draft to draft-ietf-tcpm-ecnsyn.

   * Added a discussion in Section 3 of "Response to
     ECN-marking of SYN/ACK packets".  Based on
     suggestions from Mark Allman.

   * Added a discussion to the Conclusions about adding
     ECN-capability to relevant set-up packets in other
     protocols.  From a suggestion from Wesley Eddy.

   * Added a description of SYN exchanges with SYN cookies.
     From a suggestion from Wesley Eddy.

   * Added a discussion of one-way data transfers, where the
     host sending the SYN/ACK packet sends no data packets.

   * Minor editing, from feedback from Mark Allman and Janardhan
     Iyengar.

   * Future work: a look at the costs of adding
     ECN-Capability in a worst-case scenario.
     From feedback from Mark Allman and Janardhan Iyengar.

   * Future work: a comparative evaluation of two
     possible responses to an ECN-marked SYN/ACK packet.

   Changes from draft-kuzmanovic-ecn-syn-00.txt:

   * Changed name of draft to draft-ietf-twvsg-ecnsyn.

   END OF NOTE TO RFC EDITOR.






Kuzmanovic                   Standards Track                    [Page 2]

draft-ietf-tcpm-ecnsyn-00.txt                               January 2006


1.  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].

1.  Introduction

   TCP's congestion control mechanism has primarily used packet loss as
   the congestion indication, with packets dropped when buffers
   overflow.  With such tail-drop mechanisms, the packet delay can be
   high, as the queue at bottleneck routers can be fairly large.
   Dropping packets only when the queue overflows, and having TCP react
   only to such losses, results in:
   1) significantly higher packet delay;
   2) unnecessarily many packet losses; and
   3) unfairness due to synchronization effects.

   The adoption of Active Queue Management (AQM) mechanisms allows
   better control of bottleneck queues [RFC2309].  This use of AQM has
   the following potential benefits:
   1) better control of the queue, with reduced queueing delay;
   2) fewer packet drops; and
   3) better fairness because of fewer synchronization effects.

   With the adoption of ECN, performance may be further improved.  When
   the router detects congestion before buffer overflow, the router can
   provide a congestion indication either by dropping a packet, or by
   setting the Congestion Experienced (CE) codepoint in the  Explicit
   Congestion Notification (ECN) field in the IP header [RFC3168].  The
   IETF has standardized the use of the Congestion Experienced (CE)
   codepoint in the IP header for routers to indicate congestion.  For
   incremental deployment and backwards compatibility, the RFC on ECN
   [RFC 3168] specifies that routers may mark ECN-capable packets that
   would otherwise have been dropped, using the Congestion Experienced
   codepoint in the ECN field.  The use of ECN allows TCP to react to
   congestion while avoiding unnecessary retransmissions and, in some
   cases, unnecessary retransmit timeouts.  Thus, using ECN has several
   benefits:

   1) For short transfers, a TCP connection's congestion window may be
   small.  For example, if the current window contains only one packet,
   and that packet is dropped, TCP will have to wait for a retransmit
   timeout to recover, reducing its overall throughput.  Similarly, if
   the current window contains only a few packets and one of those
   packets is dropped, there might not be enough duplicate
   acknowledgements for a fast retransmission, and the sender might have
   to wait for a delay of several round-trip times using Limited



Kuzmanovic                   Standards Track                    [Page 3]

draft-ietf-tcpm-ecnsyn-00.txt                               January 2006


   Transmit [RFC3042].  With the use of ECN, short flows are less likely
   to have packets dropped, sometimes avoiding unnecessary delays or
   costly retransmit timeouts.

   2) While longer flows may not see substantially improved throughput
   with the use of ECN, they experience lower loss. This may benefit TCP
   applications that are latency- and loss-sensitive, because of the
   avoidance of retransmissions.

   RFC 3168 only specified marking the Congestion Experienced codepoint
   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-
   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
   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
   packet dropped, with the resulting retransmit timeout, this document
   is specifying the use of ECN for the SYN/ACK packet itself.  This can
   be of great benefit to the TCP connection, avoiding the severe
   penalty of a retransmit 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 mark by reducing its initial congestion
   window from two, three, or four segments to one segment, reducing the
   subsequent load from that connection on the network.

   The use of ECN for SYN/ACK packets has the following potential
   benefits:
   1) Avoidance of a retransmit timeout;
   2) Improvement in the throughput of short connections.

   This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK
   packets to be ECN-Capable.  Section 2 contains the specification of
   the change, while Section 3 discusses some of the issues, and Section
   4 discusses related work.  Section 5 contains an evaluation of the
   proposed change.

2.  Proposal

   This section specifies the modification to RFC 3168 to allow TCP
   SYN/ACK packets to be ECN-Capable.  We use the following terminology
   from RFC 3168:

   The ECN field in the IP header:
   o  CE: the Congestion Experienced codepoint; and
   o  ECT: either one of the two ECN-Capable Transport codepoints.

   The ECN flags in the TCP header:
   o  CWR: the Congestion Window Reduced flag; and



Kuzmanovic                   Standards Track                    [Page 4]

draft-ietf-tcpm-ecnsyn-00.txt                               January 2006


   o  ECE: the ECN-Echo flag.

   ECN-setup packets:
   o  ECN-setup SYN packet: a SYN packet with the ECE and CWR flags;
   o  ECN-setup SYN-ACK packet: a SYN-ACK packet with ECE but not CWR.

   RFC 3168 in Section 6.1.1. states that "A host MUST NOT set ECT on
   SYN or SYN-ACK packets." In this section, we specify that a TCP node
   MAY respond to an ECN-setup SYN packet by setting ECT in the
   responding ECN-setup SYN/ACK packet, indicating to routers that the
   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
   indication of congestion.

   Assume that TCP node A transmits to TCP node B an ECN-setup SYN
   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
   responds with an ECN-setup SYN-ACK packet.

   Table 1 shows an interchange with the SYN/ACK packet dropped by a
   congested router.  Node B waits for a retransmit timeout, and then
   retransmits the SYN/ACK packet.


     ---------------------------------------------------------------
        TCP Node A             Router                  TCP Node B
        ----------             ------                  ----------

        ECN-setup SYN packet --->
                                         ECN-setup SYN packet --->

                              <--- ECN-setup SYN/ACK, possibly ECT
                                                3-second timer set
                            SYN/ACK dropped               .
                                                          .
                                                          .
                                            3-second timer expires
                                   <--- ECN-setup SYN/ACK, not ECT
        <--- ECN-setup SYN/ACK
        Data/ACK --->
                                                     Data/ACK --->
                                  <--- Data (one to four segments)
     ---------------------------------------------------------------

        Table 1: SYN exchange with the SYN/ACK packet dropped.


   If the SYN/ACK packet is dropped in the network, the TCP host (node



Kuzmanovic                   Standards Track                    [Page 5]

draft-ietf-tcpm-ecnsyn-00.txt                               January 2006


   B) responds by waiting three seconds for the retransmit timer to
   expire [RFC2988].  If a SYN/ACK packet with the ECT codepoint is
   dropped, the TCP node SHOULD resend the SYN/ACK packet without the
   ECN-Capable codepoint.  (Although we are not aware of any middleboxes
   that drop SYN/ACK packets that contain an ECN-Capable codepoint in
   the IP header, we have learned to design our protocols defensively in
   this regard [RFC3360].)

   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
   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
   SYN packet in order to trigger another SYN-ACK.

   Table 2 shows an interchange with the SYN/ACK packet sent as ECN-
   Capable, and ECN-marked instead of dropped at the congested router.


     ---------------------------------------------------------------
        TCP Node A             Router                  TCP Node B
        ----------             ------                  ----------

        ECN-setup SYN packet --->
                                        ECN-setup SYN packet --->

                                      <--- ECN-setup SYN/ACK, ECT
                           <--- Sets CE on SYN/ACK
        <--- ECN-setup SYN/ACK, CE

        Data/ACK, ECN-Echo --->
                                          Data/ACK, ECN-Echo --->
                                   Window reduced to one segment.
                                <--- Data, CWR (one segment only)
     ---------------------------------------------------------------

        Table 2: SYN exchange with the SYN/ACK packet marked.


   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
   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
   receiving node continues to set the ECN-Echo flag in packets until it
   receives a packet with the CWR flag set.

   When the sending node (node B) receives the ECN-Echo packet reporting
   the Congestion Experienced indication in the SYN/ACK packet, the node
   MUST set the initial congestion window to one segment, instead of two



Kuzmanovic                   Standards Track                    [Page 6]

draft-ietf-tcpm-ecnsyn-00.txt                               January 2006


   segments as allowed by [RFC2581], or three or four segments allowed
   by [RFC3390].  If the sending node (node B) was going to use an
   initial window of one segment, and receives an ECN-Echo packet
   informing it of a Congestion Experienced indication on its SYN/ACK
   packet, the sending node MAY continue to send with an initial window
   of one segment, without waiting for a retransmit timeout.  We note
   that this updates RFC 3168, which specifies that "the sending TCP
   MUST reset the retransmit timer on receiving the ECN-Echo packet when
   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
   data packet sent, to acknowledge its receipt of and reaction to the
   ECN-Echo flag.

   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
   data packets, waiting for the CWR flag from Node B acknowledging a
   response to the ECN-Echo flag.

3.  Discussion

   Motivation:
   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,
   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
   ECN-Capable codepoints in the IP header in the responding TCP SYN/ACK
   packet.

   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
   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
   occurence of three-second retransmit timeouts resulting from the drop
   of SYN/ACK packets.

   Flooding attacks:
   Setting an ECN-Capable codepoint in the responding TCP SYN/ACK
   packets does not raise any novel security vulnerabilities.  For
   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
   greatly inefficient.  Third parties would immediately drop such
   packets, since they would know that they didn't generate the TCP SYN
   packets in the first place.  Moreover, such SYN/ACK attacks would
   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
   certain link would also be highly inefficient because SYN ACK packets
   are small in size.




Kuzmanovic                   Standards Track                    [Page 7]

draft-ietf-tcpm-ecnsyn-00.txt                               January 2006


   However, the addition of ECN-Capability to SYN/ACK packets could
   allow SYN/ACK packets to persist for more hops along a network path
   before being dropped, thus adding somewhat to the ability of a
   SYN/ACK attack to flood a network link.

   The TCP SYN packet:
   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
   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
   able to understand and react if the ECN CE codepoint was set by a
   congested router.

   Second, the ECN-Capable codepoint in TCP SYN packets could be misused
   by malicious clients to `improve' the well-known TCP SYN attack. By
   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
   potentially congested ECN-enabled router, congesting it even further.

   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.

   Backwards compatibility:
   If there are some older TCP implementations that don't respond to the
   Congestion Experienced codepoint in a SYN/ACK packet, that 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
   subsequent CE indications on data packets later on in the connection.

   SYN/ACK packets and packet size:
   There are a number of router buffer architectures that have smaller
   dropping rates for small (SYN) packets than for large (data) packets.
   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,
   small and large packets are equally likely to be dropped.  However,
   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
   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
   dropped or marked is proportional to the packet size in bytes.

   For a congested router with an AQM mechanism in byte mode, where a
   packet's chance of being dropped or marked is proportional to the
   packet size in bytes, the drop or marking rate for TCP SYN/ACK
   packets should generally be low.  In this case, the benefit of making
   SYN/ACK packets ECN-Capable should be similarly moderate.  However,



Kuzmanovic                   Standards Track                    [Page 8]

draft-ietf-tcpm-ecnsyn-00.txt                               January 2006


   for a congested router with a Drop Tail queue in units of packets or
   with an AQM mechanism in packet mode, and with no priority queueing
   for smaller packets, small and large packets should have the same
   probability of being dropped or marked.  In such a case, making
   SYN/ACK packets ECN-Capable should be of significant benefit.

   We believe that there are a wide range of behaviors in the real world
   in terms of the drop or mark behavior at routers as a function of
   packet size [Tools, Section 10].  We note that all of these
   alternatives listed above are available in the NS simulator (Drop
   Tail queues are by default in units of packets, while the default for
   RED queue management has been changed from packet mode to byte mode).

   Response to ECN-marking of SYN/ACK packets:
   One question is why TCP SYN/ACK packets should be treated differently
   from other packets in terms of the packet sender's response to an
   ECN-marked packet.  Section 5 of RFC 3168 specifies the following:

   "Upon the receipt by an ECN-Capable transport of a single CE packet,
   the congestion control algorithms followed at the end-systems MUST be
   essentially the same as the congestion control response to a *single*
   dropped packet.  For example, for ECN-Capable TCP the source TCP is
   required to halve its congestion window for any window of data
   containing either a packet drop or an ECN indication."

   In particular, Section 6.1.2 of RFC 3168 specifies that when the TCP
   congestion window consists of a single packet and that packet is ECN-
   marked in the network, then the sender must reduce the sending rate
   below one packet per round-trip time, by waiting for one RTO before
   sending another packet.  If the RTO was set to the average round-trip
   time, this would result in halving the sending rate; because the RTO
   is in fact larger than the average round-trip time, the sending rate
   is reduced to less than half of its previous value.

   TCP's congestion control response to the *dropping* of a SYN/ACK
   packet is to wait a default time before sending another packet.  This
   document argues that ECN gives end-systems a wider range of possible
   responses to the *marking* of a SYN/ACK packet, and that waiting a
   default time before sending a data packet is not the desired
   response.

   On the conservative end, one could assume an effective congestion
   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
   every two round-trip times.  As an approximation, the TCP end-node
   could measure the round-trip time T between the sending of the
   SYN/ACK packet and the receipt of the acknowledgement, and reply to
   the acknowledgement of the ECN-marked SYN/ACK packet by waiting T



Kuzmanovic                   Standards Track                    [Page 9]

draft-ietf-tcpm-ecnsyn-00.txt                               January 2006


   seconds before sending a data packet.  However, we note that for an
   ECN-marked SYN/ACK packet, halving the *congestion window* is not the
   same as halving the *sending rate*; there is no `sending rate'
   associated with an ECN-Capable SYN/ACK packet, as such packets are
   only sent as the first packet in a 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
   of setting the initial congestion window to one packet, instead of
   its allowed default value of two, three, or four packets, with the
   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
   will wait an RTO before sending another packet.  This document argues
   that such an approach is useful to users, with no dangers of
   congestion collapse or of starvation of competing traffic.

   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
   responses to an ECN-marked SYN/ACK packet outlined above.  In either
   case, Node B sends no data packets, only sending acknowledgement
   packets in response to received data packets.

4.  Related Work

   The addition of ECN-capability to TCP's SYN/ACK packets was proposed
   in [ECN+].  The paper includes an extensive set of simulation and
   testbed experiments to evaluate the effects of the proposal, using
   several Active Queue Management (AQM) mechanisms, including Random
   Early Detection (RED) [RED], Random Exponential Marking (REM) [REM],
   and Proportional Integrator (PI) [PI].  The performance measures were
   the end-to-end response times for each request/response pair, and the
   aggregate throughput on the bottleneck link.  The end-to-end response
   time was computed as the time from the moment when the request for
   the file is sent to the server, until that file is successfully
   downloaded by the client.

   The measurements from [ECN+] showed that setting an ECN-Capable
   codepoint in the IP packet header in TCP SYN/ACK packets
   systematically improves performance with all evaluated AQM schemes.
   When SYN/ACK packets at a congested router are ECN-marked instead of
   dropped, this can avoid a long initial retransmit timeout, improving
   the response time for the affected flow dramatically.

   [ECN+] showed that the impact on aggregate throughput can also be
   quite significant, because marking SYN ACK packets can prevent larger
   flows from suffering long timeouts before being "admitted" into the
   network.  In addition, the testbed measurements from [ECN+] showed



Kuzmanovic                   Standards Track                   [Page 10]

draft-ietf-tcpm-ecnsyn-00.txt                               January 2006


   that Web servers setting the ECN-Capable codepoint in TCP SYN/ACK
   packets could serve more requests.

   As a final step, [ECN+] explored the co-existence of flows that do
   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
   some performance degradation for flows that don't apply the change.
   Flows that apply the change improve their end-to-end performance.  At
   the same time, the performance degradation for flows that don't apply
   the change, as a result of the flows that do apply the change,
   increases as a greater fraction of flows apply the change.

5.  Performance Evaluation

5.1.  The Costs and Benefit of Adding ECN-Capability

   [ECN+] explored the costs and benefits of adding ECN-Capability to
   SYN/ACK packets with both simulations and experiments.  The addition
   of ECN-capability to SYN/ACK packets could be of significant benefit
   for those ECN connections that would have had the SYN/ACK packet
   dropped in the network, and for which the ECN-Capability would allow
   the SYN/ACK to be marked rather than dropped.

   The percent of SYN/ACK packets on a link can be quite high. In
   particular, measurements on links dominated by Web traffic indicate
   that 15-20% of the packets can be SYN/ACK packets [SCJO01].

   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
   can increase the download time of a short file by an order of
   magnitude, by requiring a three-second retransmit timeout.  For
   longer-lived flows, the effect of a dropped SYN/ACK packet on file
   download time is less dramatic.  However, even for longer-lived
   flows, the addition of ECN-capability to SYN/ACK packets can improve
   the fairness among long-lived flows, as newly-arriving flows would be
   less likely to have to wait for retransmit timeouts.

   The question that arises of course is what fraction of connections
   would see the benefit from making SYN/ACK packets ECN-capable, in a
   particular scenario?  Specifically:

   (1) What fraction of arriving SYN/ACK packets are dropped at the
   congested router when the SYN/ACK packets are not ECN-capable?

   (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
   packets had been ECN-capable?




Kuzmanovic                   Standards Track                   [Page 11]

draft-ietf-tcpm-ecnsyn-00.txt                               January 2006


   To answer (1), it is necessary to consider not only the level of
   congestion but also the queue architecture at the congested link.  As
   described in Section 3 above, for some queue architectures small
   packets are less likely to be dropped than large ones.  In such an
   environment, SYN/ACK packets would have lower packet drop rates;
   question (1) could not necessarily be inferred from the overall
   packet drop rate, but could be answered by measuring the drop rate
   for SYN/ACK packets directly.  In such an environment, adding ECN-
   capability to SYN/ACK packets would be of less dramatic benefit than
   in environments where all packets are equally likely to be dropped
   regardless of packet size.

   As question (2) implies, even if all of the SYN/ACK packets were ECN-
   capable, there could still be some SYN/ACK packets dropped instead of
   marked at the congested link; the full answer to question (2) depends
   on the details of the queue management mechanism at the router.  If
   congestion is sufficiently bad, and the queue management mechanism
   cannot prevent the buffer from overflowing, then SYN/ACK packets will
   be dropped rather than marked upon buffer overflow whether or not
   they are ECN-capable.

   For some AQM mechanisms, ECN-capable packets are marked instead of
   dropped any time this is possible, that is, any time the buffer is
   not yet full.  For other AQM mechanisms however, such as the RED
   mechanism as recommended in [RED], packets are dropped rather than
   marked when the packet drop/mark rate exceeds a certain threshold,
   e.g., 10%, even if the packets are ECN-capable.  For a router with
   such an AQM mechanism, when congestion is sufficiently severe to
   cause a high drop/mark rate, some SYN/ACK packets would be dropped
   instead of marked whether or not they were ECN-capable.

   Thus, the degree of benefit of adding ECN-Capability to SYN/ACK
   packets depends not only on the overall packet drop rate in the
   network, but also on the queue management architecture at the
   congested link.

5.2.  An Evaluation of Different Responses to ECN-Marked SYN/ACK
Packets.

   This document specifies that the end-node responds to the report of
   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
   packets.  However, in Section 3 we discussed another possible
   response to an ECN-marked SYN/ACK packet, of the end-node waiting an
   RTT before sending a data packet.  Future work will include a
   comparative evaluation of these two methods.





Kuzmanovic                   Standards Track                   [Page 12]

draft-ietf-tcpm-ecnsyn-00.txt                               January 2006


6.  Security Considerations

   TCP packets carrying the ECT codepoint in IP headers can be marked
   rather than dropped by ECN-capable routers. This raises several
   security concerns that we discuss below.

   "Bad" middleboxes:
   There is a small but decreasing number of middleboxes that drop or
   reset SYN and SYN/ACK packets based on the ECN-related flags in the
   TCP header [MAF05,RFC3360].  While there is no evidence that any
   middleboxes drop SYN/ACK packets that contain an ECN-Capable
   codepoint in the *IP header*, such behavior cannot be excluded.
   Thus, as specified in Section 2, if a SYN/ACK packet with the ECT
   codepoint is dropped, the TCP node SHOULD resend the SYN/ACK packet
   without the ECN-Capable codepoint.

   Congestion collapse:
   Because TCP SYN/ACK packets carrying an ECT codepoint could be ECN-
   marked instead of dropped at an ECN-capable router, the concern is
   whether this can either invoke congestion, or worsen performance in
   highly congested scenarios.  This is not a problem because after
   learning that the SYN/ACK packet was ECN-marked, the sender of that
   packet will only send one data packet; in the case that this data
   packet is ECN-marked, the sender will wait for a retransmission
   timeout.  In addition, routers are free to drop rather than mark
   arriving packets in times of high congestion, regardless of whether
   the packets are ECN-capable.

7.  Conclusions

   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
   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
   retransmit timeout.  This improves the throughput of short
   connections.  The sender of the SYN/ACK packet responds to an ECN
   mark by reducing its initial congestion window from two, three, or
   four segments to one segment, reducing the subsequent load from that
   connection on the network.  The addition of ECN-capability to SYN/ACK
   packets is particularly beneficial in the server-to-client direction,
   where congestion is more likely to occur.  In this case, the initial
   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 network.

   Future work will address the more general question of adding ECN-
   Capability to relevant handshake packets in other protocols that use
   retransmission-based reliability in their setup phase (e.g., SCTP,



Kuzmanovic                   Standards Track                   [Page 13]

draft-ietf-tcpm-ecnsyn-00.txt                               January 2006


   DCCP, HIP, and the like).

8.  Acknowledgements

   We thank Mark Allman, Wesley Eddy, Janardhan Iyengar, and Pasi
   Sarolahti for feedback on earlier versions of this draft.

9.  Normative References

   [RFC3168] K.K. Ramakrishnan, S. Floyd, and D. Black, The Addition of
   Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed
   Standard, September 2001.

   [RFC3390] M. Allman, S. Floyd, and C. Partridge, Increasing TCP's
   Initial Window, RFC 3390, October 2002.

10.  Informative References

   [ECN+] A. Kuzmanovic, The Power of Explicit Congestion Notification,
   SIGCOMM 2005.

   [MAF05] A. Medina, M. Allman, and S. Floyd.  Measuring the Evolution
   of Transport Protocols in the Internet, ACM CCR, April 2005.

   [PI] C. Hollot, V. Misra, W. Gong, and D. Towsley, On Designing
   Improved Controllers for AQM Routers Supporting TCP Flows, INFOCOM,
   June 2001.

   [RED] S. Floyd and V. Jacobson, Random Early Detection Gateways for
   Congestion Avoidance, IEEE/ACM Transactions on Networking, V.1, N.4,
   1993.

   [REM] S. Athuraliya, V. Li, S. Low, and Q Yin, REM: Active Queue
   Management, IEEE Network, V.15, N. 3, May 2001.

   [RFC2309] B. Braden et al., Recommendations on Queue Management and
   Congestion Avoidance in the Internet, RFC 2309, April 1998.

   [RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion
   Control, RFC 2581, April 1999.

   [RFC2988] V. Paxson and M. Allman, Computing TCP's Retransmission
   Timer, RFC 2988, November 2000.

   [RFC3042] M. Allman, H. Balakrishnan, and S. Floyd, Enhancing TCP's
   Loss Recovery Using Limited Transmit, RFC 3042, Proposed Standard,
   January 2001.




Kuzmanovic                   Standards Track                   [Page 14]

draft-ietf-tcpm-ecnsyn-00.txt                               January 2006


   [RFC3360] S. Floyd, Inappropriate TCP Resets Considered Harmful, RFC
   3360, August 2002.

   [SCJO01] F. Smith, F. Campos, K. Jeffay, D. Ott, What {TCP/IP}
   Protocol Headers Can Tell us about the Web, SIGMETRICS, June 2001.

   [SYN-COOK]   Dan J. Bernstein, SYN cookies, 1997, see also
   <http://cr.yp.to/syncookies.html>

   [Tools] S. Floyd and E. Kohler, Tools for the Evaluation of
   Simulation and Testbed Scenarios, Internet-draft draft-irtf-tmrg-
   tools-00, work in progress, September 2005.

11.  IANA Considerations

   There are no IANA considerations regarding this document.

   AUTHORS' ADDRESSES


      Aleksandar Kuzmanovic
      Phone: +1 (847) 467-5519
      Northwestern University
      Email: akuzma@northwestern.edu
      URL: http://cs.northwestern.edu/~a

      Sally Floyd
      Phone: +1 (510) 666-2989
      ICIR (ICSI Center for Internet Research)
      Email: floyd@icir.org
      URL: http://www.icir.org/floyd/

      K. K. Ramakrishnan
      Phone: +1 (973) 360-8764
      AT&T Labs Research
      Email: kkrama@research.att.com
      URL: http://www.research.att.com/info/kkrama

Full Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   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
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR



Kuzmanovic                   Standards Track                   [Page 15]

draft-ietf-tcpm-ecnsyn-00.txt                               January 2006


   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology described
   in this document or the extent to which any license under such
   rights might or might not be available; nor does it represent that
   it has made any independent effort to identify any such rights.
   Information on the procedures with respect to rights in RFC
   documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.
   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

























Kuzmanovic                   Standards Track                   [Page 16]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/