[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04

Internet Engineering Task Force                      Amit K. Jain
INTERNET DRAFT                                          Netscaler
draft-amit-quick-start-00.txt                         Sally Floyd
                                                             ICIR
                                                       June, 2002



                       Quick-Start for TCP and IP



                          Status of this Memo


   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.

Abstract

   This draft outlines an optional Quick-Start mechanism for transport
   protocols to determine an optional allowed initial congestion window
   or initial sending rate at the start of a data transfer.  This
   mechanism is designed to be used by a range of transport protocols;
   however, in this document we only describe its use with TCP and IPv4.
   By using Quick-Start, a TCP host, say, host A, would indicate its
   desired initial sending rate in packets per second in a Quick Start
   Request option in the IP header of the initial TCP SYN or SYN/ACK
   packet. Each router in turn could either approve the specified
   initial rate, reduce the specified initial rate, or indicate that
   nothing above the default initial rate for that protocol would be
   allowed.  The Quick-Start mechanism also can determine if there are
   routers along the path that do not understand the Quick Start Request



Jain                                                            [Page 1]


draft-amit-quick-start-00b.txt                                 June 2002


   option, or have not agreed to the initial rate described in the
   option. If all of the routers along the path have agreed to the
   initial rate in the Quick-Start Request, then TCP host B communicates
   this to TCP host A in a transport-level Quick-Start Response in the
   answering SYN/ACK or ACK packet.  Quick-Start is designed to allow
   TCP connections to use high initial windows in circumstances when
   there is significant unused bandwidth along the path, and all of the
   routers along the path support the Quick-Start Request.  We note that
   this is currently not a mature proposal, but an outline of one
   possible path of development in the IP protocol, and a request for
   feedback from the community.

1. Introduction

   The life of a TCP connection begins with a question, that is, "With
   what rate I can transfer the data?" The question is not answered
   explicitly for TCP, but each TCP connection figures out the answer
   for itself. This is done by each connection starting with an initial
   congestion window (called cwnd) of from one to four MSS-sized
   segments, for an MSS the Maximum Segment Size in bytes. Currently,
   the TCP protocol allows an initial window of up to two segments
   [RFC2581], with an experimental proposal for an initial window of
   three or four segments [RFC2414]. The TCP connection then probes the
   network for available bandwidth using the slow-start procedure,
   essentially doubling its congestion window each round-trip time.

   The probing mechanism of slow-start is time-consuming and causes an
   overhead in terms of queueing delay.  It may take a number of round-
   trip times in slow-start before the TCP connection begins to fully
   use the available bandwidth of the network; it takes log N round-trip
   times to build up to a congestion window of N segments.  This time in
   slow-start is not a problem for large file transfers, where the slow-
   start stage is only a fraction of the total transfer time.  However,
   in the case of moderate-sized web transfers the connection might
   carry out its entire transfer in the slow-start phase.  In an
   underutilized, high-bandwidth network, such a transfer can end up
   taking log N round-trip times to transfer the data, where one or two
   round-trip times might have sufficed.

   A fair amount of work has already been done to address the issue of
   choosing the initial window for TCP, with RFC 2414 proposing an
   initial window of up to four segments [RFC2414].  Our underlying
   premise is that explicit feedback from all of the routers along the
   path would be required for best-effort connections to use initial
   windows higher than four segments.

   The Congestion Manager proposes sharing congestion information among
   multiple TCP connections with the same endpoints [RFC2140].  With the



Jain                                                            [Page 2]


draft-amit-quick-start-00b.txt                                 June 2002


   Congestion Manager, a new TCP connection could start with a high
   initial window if it was sharing the path with a pre-existing TCP
   connection, with a high congestion window, to the same destination.
   It is also possible that a newly-starting TCP connection could make
   use of congestion information from a recently-terminated TCP
   connection to the same destination.  However, neither of these
   approaches are of any use for a connection to a new destination when
   there is no existing or recent connection to that destination.

   Active Queue Management and Explicit Congestion Notification (ECN)
   are both based on the router detecting congestion before buffer
   overflow [RFC3168].  In a similar but somewhat simpler fashion,
   Quick-Start is based on the ability of the router to determine
   whether or not the output link is significantly underutilized.

2. Assumptions, General Principles, and Open Questions

   This section describes the assumptions and general principles behind
   the design of the Quick-Start mechanism.

   Assumptions:

   * A router can determine reasonably easily if the output link has
   been significantly underutilized over a period of time.

   * The data transfer in the two directions of a connection traverses
   different queues, and possibly even different routers.  Thus, any
   mechanism for determining the allowed initial window or initial
   sending rate would have to be used independently for each direction.

   * Any new mechanism must be incrementally deployed, and may not be
   supported by all of the routers and/or end-hosts.  Thus, any new
   mechanism must be able to accommodate non-supporting routers or end-
   hosts without disturbing the current Internet semantics.

   * After the initial SYN exchange, a TCP data sender would be able to
   translate an initial sending rate in packets per second into an
   initial congestion window of MSS-sized segments.

   General Principles:

   * In order for best-effort connections to use initial windows higher
   than four segments, explicit feedback from all of the routers along
   the path would be required.

   * A router should only allow an initial sending rate higher than the
   transport protocol's default initial rate if the router is
   significantly underutilized.  Any other approach will result in



Jain                                                            [Page 3]


draft-amit-quick-start-00b.txt                                 June 2002


   either per-flow state at the router, or the possibility of either a
   (possibly transient) queue or of underutilization of the output link.

   * No per-flow state is kept at the router for this mechanism.  In
   Quick-Start, the only state kept at the router is the aggregate
   initial sending rate authorized over the most recent interval of time
   (e.g., quarter of a second).

   There are also a number of open questions regarding the Quick-Start
   mechanism outlined in this draft.

   Open Questions:

   * Would be benefits of the Quick-Start mechanism be worth the added
   complexity?

   One drawback of the Quick-Start mechanism is that the SYN and SYN/ACK
   packets containing the Quick-Start option would presumeably be
   processed in the slow path in routers.  This would reduce the
   capacity of routers to handle Quick-Start requests, and delay the
   initial SYN exchange for the connection.

   Another drawback is that Quick-Start would require functionality in
   the router to estimate the current link utilization, and to keep
   track of the aggregate Quick-Start rate authorized over the last
   interval of time.  Adding new functionality to routers should not be
   done lightly, and any mechanisms that would require new functionality
   in routers would have to be carefully considered.

   * Apart from the merits and shortcomings of the Quick-Start
   mechanism, is there likely to be a compelling need to add explicit
   congestion-related feedback from routers over and above the one-bit
   feedback from ECN?

   * If the answer to the question above is yes, should we be
   considering mechanisms that, while more complex, are also
   sufficiently more powerful than Quick-Start?

   There are a number of such mechanisms that have been proposed in the
   literature for more fine-grained congestion-related feedback from
   routers.  Quick-Start is extremely coarse-grained, in that in its
   current form it only applies to the initial window of the connection.
   Quick-Start also focuses in on the specific issue of allowing very
   high initial sending rates for connections over underutilized, high-
   bandwidth paths.  Quick-Start might first be deployed, for example,
   in an overprovisioned high-bandwidth Intranet, to allow much quicker
   transfers of best-effort traffic.




Jain                                                            [Page 4]


draft-amit-quick-start-00b.txt                                 June 2002


3. The Quick-Start Request in IPv4.

   Quick-Start would require end-points and routers to work together,
   with end-points requesting a higher initial sending rate in the
   Quick-Start Request (QSR) option in IP, and routers along the path
   approving, modifying, or discarding or ignoring (and therefore
   disallowing) the Quick-Start Request.  The receiver would check the
   validity of the received Quick-Start Request, and if valid, would use
   transport-level mechanisms to inform the sender of the status of the
   Quick-Start Request.  We note that the Quick-Start Request implicitly
   assumes a unicast transport protocol; we have not considered the use
   of the Quick-Start Request for multicast traffic.

3.1. The Quick-Start Request Option for IPv4

   The Quick-Start Request for IPv4 would be defined as follows:

           0          1          2          3          4
      +----------+----------+----------+----------+----------+
      | Option   | Length=5 |  QS TTL  | Initial  | QS Nonce |
      |          |          |          | Rate     |          |
      +----------+----------+----------+----------+----------+

      Figure 1.  The Quick-Start Request Option for IPv4.

   The first byte contains the option field, which includes the one-bit
   copy flag, the 2-bit class field, and the 5-bit option number.

   The second byte contains the length field, which indicates an option
   length of five bytes.

   The third byte contains the Quick-Start TTL (QS TTL) field.  If the
   sender decides to use Quick-Start, then the sender sets the QS TTL
   field to the same value as the TTL field in the IPv4 header.  Routers
   that approve the Quick-Start Request decrement the QS TTL.  The QS
   TTL is used by the receiver, and by downstream routers, to detect if
   there have been upstream routers that do not understand, or do not
   approve of, the Quick-Start option.

   If a router receives a Quick-Start Request with a QS TTL field
   different from the TTL field in the IP header, then this Quick-Start
   Request is not valid, and should be ignored by the router.  If it
   desires, the router could delete this option when it forwards the
   packet, thus saving unnecessary delay for the packet at downstream
   routers.  If the Quick-Start Request is not approved, then the sender
   uses the default initial rate or initial window for that transport
   protocol.




Jain                                                            [Page 5]


draft-amit-quick-start-00b.txt                                 June 2002


   The fourth byte is the requested Initial Rate (IR) field.  The sender
   initializes the Initial Rate to the desired initial sending rate,
   formatted in packets per 0.1 sec.  Routers can approve the Quick-
   Start Request for a lower Initial Rate by decreasing the Initial Rate
   in the Quick-Start Request.

   Note that the one-byte Initial Rate field limits the Initial Rate to
   at most 2560 packets/sec.  For 1500-byte packets, this corresponds to
   an initial rate of 30 Mbps.  A larger option field, or a different
   encoding for the one-byte requested Initial Rate option, would be
   needed to allow a higher range for the requested initial rate.

   The fifth byte contains the QS Nonce.  The sender initializes this
   value to a non-zero, `random' eight-bit number.  A router can deny
   the Quick-Start request by failing to decrement the QS TTL field, by
   zeroing the QS Nonce field, or by deleting the Quick-Start Request
   from the packet header.  The QS Nonce is included to provide some
   protection against broken downstream routers, or against misbehaving
   TCP receivers who might be inclined to lie about the Initial Rate.

   A router that modifies or deletes the Quick-Start Request in the IPv4
   header also has to update the IPv4 Header checksum.

3.2.  Processing the Quick-Start Request at a Participating Router

   Each participating router can either terminate or forward the Quick-
   Start Request.  The router terminates the Quick-Start Request if:

   * The QS TTL doesn't match the TTL field in the IP header.

   * The router is not underutilized, and therefore has decided not to
   grant the Quick-Start Request.

   The preferable method for a router to terminate the Quick-Start
   Request is to delete the Quick-Start Request from the IP header.  A
   less preferable but possibly more efficient method is to simply
   forward the packet with the Quick-Start Request unchanged, or with
   the QS Nonce zeroed.

   If the participating router has decided to approve the Quick-Start
   Request, it does the following:

   * It decrements the QS TTL by one.

   * If the router is only willing to approve an Initial Rate less than
   that in the Quick-Start Request, then the router puts the new Initial
   Rate in that field of the Quick-Start Request.




Jain                                                            [Page 6]


draft-amit-quick-start-00b.txt                                 June 2002


   A non-participating router forwards the Quick-Start Request
   unchanged, without decrementing the QS TTL.  Of course, the non-
   participating router still decrements the TTL field in the IP header,
   as is required for all routers.  As a result, any subsequent routers
   and the receiving end-host can detect that the Quick-Start Request is
   not valid.

3.3. Deciding the Permitted Initial Rate at a Router

   In this section we briefly outline how a router might decide whether
   or not to approve a Quick-Start Request.  As an example, the router
   could ask the following questions:

   * Has the router's output link been underutilized for some time
   (e.g., several seconds).

   * Would the output link remain underutilized if the arrival rate was
   to increase by the aggregate initial rate that the router has
   approved over the last fraction of a second?

   Answering this question requires that the router have some knowledge
   of the available bandwidth on the output link for that output queue.
   It also requires that the router keep a counter indicating the total
   aggregate Initial Rates that have been approved over the recent
   interval of time.  Thus, if an underutilized router experiences a SYN
   flood, then the router would begin to deny Initial Rate requests,
   even if the router remains underutilized.

   * If the answer to both of the previous questions is Yes, then the
   router could approve the Quick-Start Request.  The router could allow
   an Initial Rate that was a small fraction of the available unused
   bandwidth of the output link.

4. The Quick-Start Mechanisms in TCP.

   This section describes how the Quick-Start mechanism would be used in
   TCP.  If a TCP sender, say host A, would like to request Quick-Start,
   the TCP sender puts the requested initial sending rate in packets per
   second in the Quick-Start Request option in the IP header of the SYN
   or SYN/ACK packet, as described above.  The TCP host B returns the
   Quick-Start Response option in the TCP header in the responding
   SYN/ACK packet or ACK packet, respectively, informing host A of the
   results of their request.

   If the returning packet does not contain a Quick-Start Response, then
   host A has to assume that its Quick-Start request failed.  In this
   case, host A uses TCP's default initial window.




Jain                                                            [Page 7]


draft-amit-quick-start-00b.txt                                 June 2002


   If the returning packet does contain a Quick-Start Response, then
   host A uses the information in the response, along with its
   measurement of the round-trip time, to determine the initial
   congestion window.  In order to use Quick-Start, the TCP host would
   also be required to use rate-based pacing to pace out the packets in
   the initial window at the rate indicated in the Quick-Start Response.

   In a similar manner, if TCP host B requests Quick-Start in the IP
   header of the TCP SYN/ACK packet, then TCP host A returns the Quick-
   Start Response in the TCP header of the answering ACK packet.  The
   two TCP end-hosts can independently decide whether to request Quick-
   Start.

4.1. The Quick-Start Response Option in the TCP header

   The Quick-Start Response option is as follows:

           0          1          2          3
      +----------+----------+----------+----------+
      |  Kind    | Length=4 | Initial  | QS Nonce |
      |          |          |  Rate    |          |
      +----------+----------+----------+----------+

      Figure 2.  The Quick-Start Response option in the TCP header.

   The first byte of the Quick-Start Response option contains the option
   kind, identifying the TCP option.

   The second byte of the Quick-Start Response option contains the
   length field, specifying the option length in bytes.  The length
   field is set to four bytes.

   The third byte of the Quick-Start Response option contains the
   allowed Initial Rate, formatted as in the Quick-Start Request option.

   The fourth byte of the TCP option contains the QS Nonce.  The TCP
   end-node returns the QS Nonce exactly as it was received in the
   Quick-Start Request option.

4.2.  Sending the Quick-Start Response

   An end host, say host B, that receives a TCP SYN or SYN/ACK packet
   containing a Quick-Start Request first has to determine if the Quick-
   Start Request is valid.  The request is valid if the QS TTL field in
   the Quick-Start Request matches the TTL field in the IP header.  A
   valid Quick-Start Request is passed to the receiving TCP layer.

   If the TCP host is willing to permit the Quick-Start request, then a



Jain                                                            [Page 8]


draft-amit-quick-start-00b.txt                                 June 2002


   Quick-Start Response option is included in the TCP header of the
   answering acknowledgement packet.  The Initial Rate in the Quick-
   Start Response option is set to the received value of the Initial
   Rate in the Quick-Start Request option, or to a lower value if the
   TCP receiver is only willing to allow a lower Initial Rate.
   Similarly, the QS Nonce value in the Quick-Start Response is set to
   the value of the QS Nonce received in the Quick-Start Request.

   If the Quick-Start Response is being sent on the SYN/ACK, in response
   to a Quick-Start Request on the SYN, then the Quick-Start Response
   will be resent if the SYN/ACK has to be retransmitted.  If the Quick-
   Start Response is being sent on the ACK, in response to the Quick-
   Start Request on the SYN/ACK, then the Quick-Start Response has to be
   resent on data packets until that TCP host receives an
   acknowledgement for a data packet from the other end.

4.3.  Receiving and Using the Quick-Start Response

   A TCP host, say TCP host A, that sent a Quick-Start Request in a SYN
   or SYN/ACK, and receives an answering Quick-Start Response in the
   acknowledgement, first checks that the Quick-Start Response is valid.
   The Quick-Start Response is valid if it contains the same value for
   the QS Nonce as was sent in the Request, and an equal or lesser value
   for the Initial Rate.  If this check is not successful, then the
   Quick-Start request failed, and the TCP host uses the default TCP
   initial window.

   If the checks of the QS Nonce and the Initial Rate are successful,
   then the TCP host sets its initial congestion window to R*T*MSS
   bytes, for R the Initial Rate in packets per second and T the
   measured round-trip time in seconds.  The TCP host sets a flag that
   it is in Quick-Start mode, and while in Quick-Start mode the TCP
   sender uses rate-based pacing, pacing out packets at the specified
   Initial Rate.

   Because the initial SYN packet with the Quick-Start Request was not
   able to use the fast path in routers, the initial round-trip time
   measurement might be unnecessarily large.  The Quick-Start mode ends
   when the TCP host first receives an ACK for one of the data packets.
   If the initial congestion window has not been fully used, then the
   initial congestion window is decreased to the amount that has
   actually been used so far.  This should address the problem of an
   overly-large congestion window from an overly-large initial
   measurement of the round-trip time.







Jain                                                            [Page 9]


draft-amit-quick-start-00b.txt                                 June 2002


4.4.  An Example Quick-Start Scenario with TCP

   The following is an example scenario in the case when both hosts
   request Quick-Start:

   * The TCP SYN packet from Host A contains a Quick-Start Request in
   the IP header.

   * Routers along the forward path modify the Quick-Start Request as
   appropriate.

   * Host B receives the Quick-Start Request in the SYN packet, and
   verifies that the QS TTL matches the TTL in the IP header.  If it
   does, and Host B approves the Quick-Start Request, then Host B sends
   a Quick-Start Response in the TCP header of the SYN/ACK packet.  Host
   B also sends a Quick-Start Request in the IP header of the SYN/ACK
   packet.

   * Routers along the reverse path modify the Quick-Start Request as
   appropriate.

   * Host A receives the Quick-Start Response in the SYN/ACK packet, and
   checks the QS Nonce and Initial Rate for validity.  If they are
   valid, then Host A sets its initial congestion window appropriately,
   and sets up rate-based pacing to be used with the initial window.  If
   the Quick-Start Response is not valid, then Host A uses TCP's default
   initial window.

   Host A also checks the QS TTL in the Quick-Start Request in the
   incoming SYN/ACK packet, and if it is valid, sends a Quick-Start
   Response in the TCP header of the ACK packet.

   * Host A repeats sending the Quick-Start Response in data packets at
   least once per round-trip time until it receives an acknowledgement
   from Host B for one of those data packets.

   * Host B receives the Quick-Start Response in an ACK packet, and
   checks the QS Nonce and Initial Rate for validity.  If the Quick-
   Start Response is valid, then Host B sets its initial congestion
   window appropriately, and sets up rate-based pacing to be used with
   the initial window.  If the Quick-Start Response is not valid, then
   Host B uses TCP's default initial window.

   Note that the Quick-Start Request mechanism is self-terminating, and
   it terminates at the first participating router after a non-
   participating router has been encountered on the path.  This
   minimizes unnecessary overhead incurred by routers because of option
   processing for the Quick-Start Request.



Jain                                                           [Page 10]


draft-amit-quick-start-00b.txt                                 June 2002


5.  Evaluation of Quick-Start

   The main benefit of Quick-Start is to the transport connection
   itself.  For a small TCP transfer of one to five packets, Quick-Start
   is probably of very little benefit;  at best, it might shorten the
   connection lifetime from three to two round-trip times (including the
   round-trip time for connection establishment).  Similarly, for a very
   large transfer, where the slow-start phase would have been only a
   small fraction of the connection lifetime, Quick-Start would be of
   limited benefit.  Quick-Start would not significantly shorten the
   connection lifetime, but it might eliminate or at least shorten the
   start-up phase.  However, for moderate-sized connections of N packets
   in well-provisioned environments that allow Quick-Start requests of M
   packets per second, the use of Quick-Start could shorten the
   connection lifetime from log N round-trip times to N/M + 1 round-trip
   times.  For large values of N and M, this would be a dramatic
   shortening of the connection lifetime.

   The main cost of Quick-Start concerns the costs of added complexity
   at the routers.  The added complexity at the end-points is moderate,
   and might easily be outweighed by the benefit of Quick-Start to the
   end hosts.  The added complexity at the routers is also somewhat
   moderate, in that it involves estimating the unused bandwidth on the
   output link over the last several seconds, and keeping a counter of
   the aggregate Quick-Start rate approved over the last fraction of a
   second.  However, this added complexity at the routers adds to the
   development cycle, and could prevent the addition of other competing
   functionality to routers.  Thus, careful thought would have to be
   given to the addition of Quick-Start to IP.

   Another drawback of Quick-Start is that the Quick-Start Request
   message presumeably would not take the fast path in routers.  This
   would mean extra delay for the end hosts, and extra processing burden
   for the routers.  This extra burden is mitigated somewhat by the
   following factors: only SYN and SYN-ACK packets would carry the
   Quick-Start Request option;  very small flows of, say, one to five
   packets would receive little benefit from Quick-Start, and
   presumeably would not use the Quick-Start Request;  flows from end
   hosts with low-bandwidth access links would receive little benefit
   from Quick-Start, and hopefully could be configured not to use the
   Quick-Start Request.  Nevertheless, it is still conceiveable, in the
   worst case, that up to 10% of the packets were SYN or SYN/ACK packets
   using a Quick-Start Request, and this could slow down the processing
   of SYN or SYN/ACK packets in routers considerably.

   One limitation of Quick-Start is that it presumes that the data
   packets of a connection will follow the same path as the SYN or
   SYN/ACK packet.  If this is not the case, then the connection could



Jain                                                           [Page 11]


draft-amit-quick-start-00b.txt                                 June 2002


   be sending the initial window, at the permitted initial rate, along a
   path that was already congested, or that became congested as a result
   of this connection.  This is, however, similar to what would happen
   if the connection's path was changed in the middle of the connection,
   when the connection had already established the allowed initial rate.

   A problem of any mechanism for feedback from routers at the IP level
   is that there can be queues and bottlenecks in the end-to-end path
   that are not in IP-level routers.  As an example, these include
   queues in layer-two Ethernet or ATM networks.  The hope would be that
   an IP-level router adjacent to such a non-IP queue or bottleneck
   would be configured to reject Quick-Start requests if that was
   appropriate.

   The discussion in this paper has largely been of the Quick-Start
   mechanism with default, best-effort traffic.  However, Quick-Start
   could also be used by traffic using some form of differentiated
   services, and routers could take the traffic class into account when
   deciding whether or not to grant the Quick-Start request.  However,
   we would note that routers should be discouraged from granting Quick-
   Start requests for higher-priority traffic when this is likely to
   result in significant packet loss for lower-priority traffic.

   The Quick-Start proposal, taken together with the recent proposal for
   HighSpeed TCP [F02], would go a significant way towards extending the
   range of performance for best-effort traffic in the Internet.
   However, there are many things that the Quick-Start proposal would
   not accomplish.  For example, Quick-Start would not allow flows to
   ramp-up quickly in the middle of the connection.  Quick-Start would
   not help in making more precise use of the available bandwidth, that
   is, of achieving the goal of very high throughput with very low
   packet loss rates.  Quick-Start would not give routers any additional
   power in allocating bandwidth in the interests of greater fairness,
   or in having more control over slow decrease rates of active
   connections.  One of the open questions is whether the limited
   capabilities of Quick-Start are sufficient to warrant standardization
   and deployment, or whether more work is needed to explore the space
   of potential mechanisms.

6.  Conclusions

   We are presenting the Quick-Start mechanism not as a mechanism that
   we believe is urgently needed in the current Internet, but rather as
   a straw proposal for a simple, understandable, and incrementally-
   deployable mechanism that would be sufficient to allow connections to
   start up with large initial rates, or large initial congestion
   windows, in overprovisioned, high-bandwidth environments.  We are not
   making any predictions about what we think typical environments are



Jain                                                           [Page 12]


draft-amit-quick-start-00b.txt                                 June 2002


   likely to be like in the future Internet.  However, we expect there
   will be an increasing number of overprovisioned, high-bandwidth
   environments where the Quick-Start mechanism, or another mechanism of
   similar power, could be of significant benefit to a wide range of
   traffic.  We are presenting the Quick-Start mechanism as a request
   for feedback from the Internet community in considering these issues.

7. Acknowledgements

   The authors wish to thank Mark Handley for discussions of these
   issues.  The authors also thank the End-to-End Research Group and a
   long list of other people for feedback, both positive and negative;
   we will add this list later.  This draft builds upon the concepts
   described in [RFC2414], [AHO98], [RFC2415], and [RFC3168].

   This is a modification of a draft originally by Amit Jain for Initial
   Window Discovery.

8. Normative References

   [RFC2414] M. Allman, S. Floyd, and C. Partridge. Increasing TCP's
   Initial Window. RFC 2414, September 1998.

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

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

9. Informative References

   [AHO98] M. Allman, C. Hayes and S. Ostermann. An evaluation of TCP
   with Larger Initial Windows. ACM Computer Communication Review, July
   1998.

   [FF99] Floyd, S., and Fall, K., Promoting the Use of End-to-End
   Congestion Control in the Internet, IEEE/ACM Transactions on
   Networking, August 1999.

   [F02] Floyd, S., HighSpeed TCP for Large Congestion Windows,
   internet-draft draft-floyd-tcp-highspeed-00.txt, work in progress,
   June 2002.

   [PK98] Venkata N. Padmanabhan and Randy H. Katz, TCP Fast Start: A
   Technique For Speeding Up Web Transfers, IEEE GLOBECOM '98, November
   1998.




Jain                                                           [Page 13]


draft-amit-quick-start-00b.txt                                 June 2002


   [RFC2140] J. Touch. TCP Control Block Interdependence.  RFC 2140.
   April 1997

   [RFC2309] B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, D.
   Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L.
   Peterson, K.  Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang,
   Recommendations on Queue Management and Congestion Avoidance in the
   Internet, RFC 2309, April 1998.

   [RFC2415] K. Poduri and K. Nichols. Simulation Studies of Increased
   Initial TCP Window Size. RFC 2415. September 1998.

   [RFC2416] T. Shepard and C. Partridge.  When TCP Starts Up With Four
   Packets Into Only Three Buffers.  RFC 2416. September 1998.

10. Security Considerations

   The only security consideration would be if the use of Quick-Start
   resulted in the sender using an Initial Rate that was inappropriately
   large, resulting in congestion along the path.  Such congestion would
   result in an unacceptable level of packet drops along the path.  Such
   congestion could also be part of a Denial of Service attack.

   A misbehaving TCP sender could use a non-conformant initial
   congestion window even without the use of Quick-Start, so we restrict
   our attention to problems with Quick-Start with conformant TCP
   senders.  (We also note that if the TCP sender is a busy web server,
   then the TCP sender has some incentive to be conformant in this
   regard.)

   If a router that understands the Quick-Start Request deletes the
   Request, or zeroes the QS Nonce in the request, then the chances of a
   downstream router or misbehaving receiver guessing the value of the
   QS Nonce is at most 1/256.  Thus, deleting the Quick-Start Request
   makes it unlikely that the receiver would be able to send a valid
   Quick-Start Response back to the sender.

   If there are routers along the path that do not understand or approve
   of the Quick-Start Request, and that forward the Quick-Start Request
   unchanged, it would be easy for a downstream router or the receiver
   to cheat and modify the QS TTL field so that the request was
   considered valid.

   It would also be easy for routers or for the receiver to increase the
   Initial Rate, making the Initial Rate be higher than that approved by
   an upstream router.  However, this higher Initial Rate will only be
   considered valid by the TCP sender if it is no higher than the
   Initial Rate originally requested by the sender.



Jain                                                           [Page 14]


draft-amit-quick-start-00b.txt                                 June 2002


11. IANA Considerations

   The only IANA Considerations would be the addition of an IP option to
   the list of IP options, and the addition of a TCP option to the list
   of TCP options.

   AUTHORS' ADDRESSES


      Amit Jain
      Netscaler
      Email: ajain@netscaler.com

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

      This draft was created in June 2002.































Jain                                                           [Page 15]


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