1. Introduction

   Each connection begins with a question: "What is the appropriate
   sending rate for the current network path?"  The question is not
   answered explicitly, but each TCP connection determines the sending
   rate by probing the network path and altering the congestion window
   (cwnd) based on perceived congestion.  Each TCP connection starts
   with a pre-configured initial congestion window (ICW).  Currently,
   TCP allows an initial window of between one and four segments of
   maximum segment size (MSS) ([RFC2581], [RFC3390]).  The TCP
   connection then probes the network for available bandwidth using the
   slow-start procedure ([Jac88], [RFC2581]), doubling cwnd during each
   congestion-free round-trip time (RTT).

   The slow-start algorithm can be time-consuming --- especially over
   networks with large bandwidth or long delays.  It may take a number
   of RTTs in slow-start before the TCP connection begins to fully use
   the available bandwidth of the network.  For instance, it takes
   log_2(N) - 2 round-trip times to build cwnd up to N segments,
   assuming an initial congestion window of 4 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 transfers, the connection
   might carry out its entire transfer in the slow-start phase, taking
   many round-trip times, where one or two RTTs might have been
   sufficient when using the currently available bandwidth along the
   path.

   A fair amount of work has already been done to address the issue of
   choosing the initial congestion window for TCP, with RFC 3390prop
   allowing an initial window of up to four segments based on the MSS
   used by the connection [RFC3390].  Our underlying premise is that
   explicit feedback from all the routers along the path would be
   required, in the current architecture, for best-effort connections to
   use initial windows significantly larger than those allowed by
   [RFC3390], in the absence of other information about the path.

   In using Quick-Start, a TCP host (say, host A) would indicate its
   desired sending rate in bytes per second, using a Quick-Start Option
   in the IP header of a TCP packet.  Each router along the path could,
   in turn, either approve the requested rate, reduce the requested
   rate, or indicate that the Quick-Start Request is not approved.  (We
   note that the `routers' referred to in this document also include the
   IP-layer processing of the Quick-Start Request at the sender.)  In
   approving a Quick-Start Request, a router does not give preferential
   treatment to subsequent packets from that connection; the router is
   only asserting that it is currently underutilized and believes there
   is sufficient available bandwidth to accommodate the sender's

   requested rate.  The Quick-Start mechanism can determine if there are
   routers along the path that do not understand the Quick-Start Option,
   or have not agreed to the Quick-Start rate request.  TCP host B
   communicates the final rate request to TCP host A in a transport-
   level Quick-Start Response in an answering TCP packet.

   If the Quick-Start Request is approved by all routers along the path,
   then the TCP host can send at up to the approved rate for a window of
   data.  Subsequent transmissions will be governed by the default TCP
   congestion control mechanisms of that connection.  If the Quick-Start
   Request is not approved, then the sender would use the default
   congestion control mechanisms.

   Quick-Start would not be the first mechanism for explicit
   communication from routers to transport protocols about sending
   rates.  Explicit Congestion Notification (ECN) gives explicit
   congestion control feedback from routers to transport protocols,
   based on the router detecting congestion before buffer overflow
   [RFC3168].  In contrast, routers would not use Quick-Start to give
   congestion information, but instead would use Quick-Start as an
   optional mechanism to give permission to transport protocols to use
   higher sending rates, based on the ability of all the routers along
   the path to determine if their respective output links are
   significantly underutilized.

   Section 2 gives an overview of Quick-Start.  The formal
   specifications for Quick-Start are contained in Sections 3, 4, 6.1.1,
   and 6.3.  In particular, Quick-Start is specified for IPv4 and for
   IPv6 in Section 3, and is specified for TCP in Section 4.  Section 6
   consists mostly of a non-normative discussion of interactions of
   Quick-Start with IP tunnels and MPLS; however, Section 6.1.1 and 6.3
   specify behavior for IP tunnels that are aware of Quick-Start.

   The rest of the document is non-normative, as follows.  Section 5
   shows that Quick-Start is compatible with IPsec AH (Authentication
   Header).  Section 7 gives a non-normative set of guidelines for
   specifying Quick-Start in other transport protocols, and Section 8
   discusses using Quick-Start in transport end-nodes and routers.
   Section 9 gives an evaluation of the costs and benefits of Quick-
   Start, and Section 10 discusses implementation and deployment issues.
   The appendices discuss related work, Quick-Start design decisions,
   and possible router algorithms.

1.1. Conventions and Terminology

   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 [RFC2119].