tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4782

 
 
 

Quick-Start for TCP and IP

Part 2 of 4, p. 18 to 37
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 18 
4.  The Quick-Start Mechanisms in TCP

   This section describes how the Quick-Start mechanism would be used in
   TCP.  We first sketch the procedure and then tightly define it in the
   subsequent subsections.

   If a TCP sender (say, host A) would like to use Quick-Start, the TCP
   sender puts the requested sending rate in bits per second,
   appropriately formatted, in the Quick-Start Option in the IP header
   of the TCP packet, called the Quick-Start Request packet.  (We will
   be somewhat loose in our use of "packet" vs. "segment" in this
   section.)  When used for initial start-up, the Quick-Start Request
   packet can be either the SYN or SYN/ACK packet, as illustrated in
   Figure 1.  The requested rate includes an estimate for the transport
   and IP header overhead.  The TCP receiver (say, host B) returns the
   Quick-Start Response option in the TCP header in the responding
   SYN/ACK packet or ACK packet, called the Quick-Start Response packet,
   informing host A of the results of their request.

   If the acknowledging packet does not contain a Quick-Start Response,
   or contains a Quick-Start Response with the wrong value for the TTL
   Diff or the QS Nonce, then host A MUST assume that its Quick-Start
   request failed.  In this case, host A sends a Report of Approved Rate
   with a Rate Report of zero, and uses TCP's default congestion control
   procedure.  For initial start-up, host A uses the default initial
   congestion window ([RFC2581], [RFC3390]).

   If the returning packet contains a valid Quick-Start Response, then
   host A uses the information in the response, along with its
   measurement of the round-trip time, to determine the Quick-Start
   congestion window (QS-cwnd).  Quick-Start data packets are defined as
   data packets sent as the result of a successful Quick-Start request,
   up to the time when the first Quick-Start packet is acknowledged.
   The sender also sends a Report of Approved Rate.  In order to use
   Quick-Start, the TCP host MUST use rate-based pacing [VH97] to
   transmit Quick-Start packets at the rate indicated in the Quick-Start
   Response, at the level of granularity possible by the sending host.
   We note that the limitations of interrupt timing on computers can
   limit the ability of the TCP host in rate-pacing the outgoing
   packets.

   The two TCP end-hosts can independently decide whether to request
   Quick-Start.  For example, host A could send a Quick-Start Request in
   the SYN packet, and host B could also send a Quick-Start Request in
   the SYN/ACK packet.

Top      Up      ToC       Page 19 
4.1.  Sending the Quick-Start Request

   When sending a Quick-Start Request, the TCP sender SHOULD send the
   request on a packet that requires an acknowledgement, such as a SYN,
   SYN/ACK, or data packet.  In this case, if the packet is acknowledged
   but no Quick-Start Response is included, then the sender knows that
   the Quick-Start Request has been denied, and can send a Report of
   Approved Rate.

   In addition to the use of Quick-Start when a connection is
   established, there are several additional points in a connection when
   a transport protocol may want to issue a Rate Request.  We first
   reiterate the notion that Quick-Start is a coarse-grained mechanism.
   That is, Quick-Start's Rate Requests are not meant to be used for
   fine-grained control of the transport's sending rate.  Rather, the
   transport MAY issue a Rate Request when no information about the
   appropriate sending rate is available, and the default congestion
   control mechanisms might be significantly underestimating the
   appropriate sending rate.

   The following are potential points where Quick-Start may be useful:

   (1) At or soon after connection initiation, when the transport has no
       idea of the capacity of the network path, as discussed above.  (A
       transport that uses TCP Control Block sharing [RFC2140], the
       Congestion Manager [RFC3124], or other mechanisms for sharing
       congestion information may not need Quick-Start to determine an
       appropriate rate.)

   (2) After an idle period when the transport no longer has a validated
       estimate of the available bandwidth for this flow.  (An example
       could be a persistent-HTTP connection when a new HTTP request is
       received after an idle period.)

   (3) After a host has received explicit indications that one of the
       endpoints has moved its point of network attachment.  This can
       happen due to some underlying mobility mechanism like Mobile IP
       ([RFC3344], [RFC3775]).  Some transports, such as Steam Control
       Transmission Protocol (SCTP) [RFC2960], may associate with
       multiple IP addresses and can switch addresses (and therefore
       network paths) in mid-connection.  If the transport has concrete
       knowledge of a changing network path, then the current sending
       rate may not be appropriate, and the transport sender may use
       Quick-Start to probe the network to see if it can send at a
       higher rate.  (Alternatively, traditional slow-start should be
       used in this case when Quick-Start is not available.)

Top      Up      ToC       Page 20 
   (4) After an application-limited period, when the sender has been
       using only a small amount of its appropriate share of the network
       capacity and has no valid estimate for its fair share.  In this
       case, Quick-Start may be an appropriate mechanism to determine if
       the sender can send at a higher rate.  For instance, consider an
       application that steadily exchanges low- rate control messages
       and suddenly needs to transmit a large amount of data.

   Of the above, this document recommends that a TCP sender MAY attempt
   to use Quick-Start in cases (1) and (2).  It is NOT RECOMMENDED that
   a TCP sender use Quick-Start for case (3) at the current time.  Case
   (3) requires external notifications not presently defined for TCP or
   other transport protocols.  Finally, a TCP SHOULD NOT use Quick-
   Start for case (4) at the current time.  Case (4) requires further
   thought and investigation with regard to how the transport protocol
   could determine it was in a situation that would warrant transmitting
   a Quick-Start Request.

   As a general guideline, a TCP sender SHOULD NOT request a sending
   rate larger than it is able to use over the next round-trip time of
   the connection (or over 100 ms, if the round-trip time is not known),
   except as required to round up the desired sending rate to the next-
   highest allowable request.

   In any circumstances, the sender MUST NOT make a QS request if it has
   made a QS request within the most recent round-trip time.

   Section 4.7 discusses some of the issues of using Quick-Start at
   connection initiation, and Section 4.8 discusses issues that arise
   when Quick-Start is used to request a larger sending rate after an
   idle period.

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

   In order to approve the use of Quick-Start, the TCP receiver responds
   to the receipt of a Quick-Start Request with a Quick-Start Response,
   using the Quick-Start Response Option in the TCP header.  TCP's
   Quick-Start Response option is defined as follows:

Top      Up      ToC       Page 21 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Kind      |  Length=8     | Resv. | Rate  |   TTL Diff    |
   |               |               |       |Request|               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   QS Nonce                                | R |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 5: 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
   option length in bytes.  The length field MUST be set to 8 bytes.

   The third byte of the Quick-Start Response option contains a four-
   bit Reserved field, and the four-bit allowed Rate Request, formatted
   as in the Quick-Start Rate Request option.

   The fourth byte of the TCP option contains the TTL Diff.  The TTL
   Diff contains the difference between the IP TTL and QS TTL fields in
   the received Quick-Start Request packet, as calculated in equations
   (1) or (2) (depending on whether IPv4 or IPv6 is used).

   Bytes 5-8 of the TCP option contain the 30-bit QS Nonce and a two-
   bit Reserved field.

   We note that, while there are limitations on the potential size of
   the Quick-Start Response Option, a Quick-Start Response Option of
   eight bytes should not be a problem.  The TCP Options field can
   contain up to 40 bytes.  Other TCP options that might be used in a
   SYN or SYN/ACK packet include Maximum Segment Size (four bytes), Time
   Stamp (ten bytes), Window Scale (three bytes), and Selective
   Acknowledgments Permitted (two bytes).

4.3.  TCP: Sending the Quick-Start Response

   An end host (say, host B) that receives an IP packet containing a
   Quick-Start Request passes the Quick-Start Request, along with the
   value in the IP TTL field, to the receiving TCP layer.

   If the TCP host is willing to permit the Quick-Start Request, then a
   Quick-Start Response option is included in the TCP header of the
   corresponding acknowledgement packet.  The Rate Request in the
   Quick-Start Response option is set to the received value of the Rate
   Request in the Quick-Start Option, or to a lower value if the TCP

Top      Up      ToC       Page 22 
   receiver is only willing to allow a lower Rate Request.  The TTL Diff
   in the Quick-Start Response is set to the difference between the IP
   TTL value and the QS TTL value as given in equation (1) or (2)
   (depending on whether IPv4 or IPv6 is used).  The QS Nonce in the
   Response is set to the received value of the QS Nonce in the Quick-
   Start Option.

   If an end host receives an IP packet with a Quick-Start Request with
   a rate request of zero, then that host SHOULD NOT send a Quick-Start
   Response.

   The Quick-Start Response MUST NOT be resent if it is lost in the
   network.  Packet loss could be an indication of congestion on the
   return path, in which case it is better not to approve the Quick-
   Start Request.

4.4.  TCP: Receiving and Using the Quick-Start Response Packet

   A TCP host (say, TCP host A) that sent a Quick-Start Request and
   receives a Quick-Start Response in an acknowledgement first checks
   that the Quick-Start Response is valid.  The Quick-Start Response is
   valid if it contains the correct value for the TTL Diff, and an equal
   or lesser value for the Rate Request than that transmitted in the
   Quick-Start Request.  In addition, if the received Rate Request is K,
   then the rightmost 2K bits of the QS Nonce must match those bits in
   the QS Nonce sent in the Quick-Start Request.  If these checks are
   not successful, then the Quick-Start Request failed, and the TCP host
   MUST use the default TCP congestion window that it would have used
   without Quick-Start.  If the rightmost 2K bits of the QS Nonce do not
   match those bits in the QS Nonce sent in the Quick-Start Request, for
   a received Rate Request of K, then the TCP host MUST NOT send
   additional Quick-Start Requests during the life of the connection.
   Whether or not the Quick-Start Request was successful, the host
   receiving the Quick-Start Response MUST send a Report of Approved
   Rate.  Similarly, if the packet containing the Quick-Start Request is
   acknowledged, but the acknowledgement does not include a Quick-Start
   Response, then the sender MUST send a Report of Approved Rate.

   If the checks of the TTL Diff and the Rate Request are successful,
   and the TCP host is going to use the Quick-Start Request, it MUST
   start using it within one round-trip time of receiving the Quick-
   Start Response, or within three seconds, whichever is smaller.  To
   use the Quick-Start Request, the host sets its Quick-Start congestion
   window (in terms of MSS-sized segments), QS-cwnd, as follows:

   QS-cwnd = (R * T) / (MSS + H)                                (3)

Top      Up      ToC       Page 23 
   where R is the Rate Request in bytes per second, T is the measured
   round-trip time in seconds, and H is the estimated TCP/IP header size
   in bytes (e.g., 40 bytes).

   Derivation: the sender is allowed to transmit at R bytes per second
   including packet headers, but only R*MSS/(MSS+H) bytes per second, or
   equivalently R*T*MSS/(MSS+H) bytes per round-trip time, of
   application data.

   The TCP host SHOULD set its congestion window cwnd to QS-cwnd only if
   QS-cwnd is greater than cwnd; otherwise, QS-cwnd is ignored.  If
   QS-cwnd is used, the TCP host sets a flag that it is in Quick-Start
   mode, and while in Quick-Start mode, the TCP sender MUST use rate-
   based pacing to pace out Quick-Start packets at the approved rate.
   If, during Quick-Start mode, the TCP sender receives ACKs for packets
   sent before this Quick-Start mode was entered, these ACKs are
   processed as usual, following the default congestion control
   mechanisms.  Quick-Start mode ends when the TCP host receives an ACK
   for one of the Quick-Start packets.

   If the congestion window has not been fully used when the first ack
   arrives ending the Quick-Start mode, then the congestion window is
   decreased to the amount that has actually been used so far.  This is
   necessary because when the Quick-Start Response is received, the TCP
   sender's round-trip-time estimate might be longer than for succeeding
   round-trip times, e.g., because of delays at routers processing the
   IP Quick-Start Option, or because of delays at the receiver in
   responding to the Quick-Start Request packet.  In this case, an
   overly large round-trip-time estimate could have caused the TCP
   sender to translate the approved Quick-Start sending rate in bytes
   per second into a congestion window that is larger than needed, with
   the TCP sender receiving an ACK for the first Quick- Start packet
   before the entire congestion window has been used.  Thus, when the
   TCP sender receives the first ACK for a Quick-Start packet, the
   sender MUST reduce the congestion window to the amount that has
   actually been used.

   As an example, a TCP sender with an approved Quick-Start Request of R
   KBps, B-byte packets including headers, and an RTT estimate of T
   seconds, would translate the Rate Request of R KBps to a congestion
   window of R*T/B packets.  The TCP sender would send the Quick-Start
   packets rate-paced at R KBps.  However, if the actual current round-
   trip time was T/2 seconds instead of T seconds, then the sender would
   begin to receive acknowledgements for Quick-Start packets after T/2
   seconds.  Following the paragraph above, the TCP sender would then
   reduce its congestion window from R*T/B to approximately R*T/(B*2)
   packets, the actual number of packets that were needed to fill the
   pipe at a sending rate of R KBps.  (Note: this is just an

Top      Up      ToC       Page 24 
   illustration; the congestion window is actually set to the amount of
   data sent before the ACK arrives and not based on equations above.)

   After Quick-Start mode is exited and the congestion window adjusted
   if necessary, the TCP sender returns to using the default congestion-
   control mechanisms, processing further incoming ACK packets as
   specified by those congestion control mechanisms.  For example, if
   the TCP sender was in slow-start prior to the Quick-Start Request,
   and no packets were lost or marked since that time, then the sender
   continues in slow-start after exiting Quick-Start mode, as allowed by
   ssthresh.

   To add robustness, the TCP sender MUST use Limited Slow-Start
   [RFC3742] along with Quick-Start.  With Limited Slow-Start, the TCP
   sender limits the number of packets by which the congestion window is
   increased for one window of data during slow-start.

   When Quick-Start is used at the beginning of a connection, before any
   packet marks or losses have been reported, the TCP host MAY use the
   reported Rate Request to set the slow-start threshold to a desired
   value, e.g., to some small multiple of the congestion window.  A
   possible future research topic is how the sender might modify the
   slow-start threshold at the beginning of a connection to avoid
   overshooting the path capacity.  (The initial value of ssthresh is
   allowed to be arbitrarily high, and some TCP implementations use the
   size of the advertised window for ssthresh [RFC2581].)

4.5.  TCP: Controlling Acknowledgement Traffic on the Reverse Path

   When a Quick-Start Request is approved for a TCP sender, the
   resulting Quick-Start data traffic can result in a sudden increase in
   traffic for pure ACK packets on the reverse path.  For example, for
   the largest Quick-Start Request of 1.3 Gbps, given a TCP sender with
   1500-byte packets and a TCP receiver with delayed acknowledgements
   acking every other packet, this could result in 17.3 Mbps of
   acknowledgement traffic on the reverse path.

   One possibility, in cases with large Quick-Start Requests, would be
   for TCP receivers to send Quick-Start Requests to request bandwidth
   for the acknowledgement traffic on the reverse path.  However, in our
   view, a better approach would be for TCP receivers to simply control
   the rate of sending acknowledgement traffic.  The optimal future
   solution would involve the explicit use of congestion control for TCP
   acknowledgement traffic, as is done now for the acknowledgement
   traffic in DCCP's CCID2 [RFC4341].

Top      Up      ToC       Page 25 
   In the absence of congestion control for acknowledgement traffic, the
   TCP receiver could limit its sending rate for ACK packets sent in
   response to Quick-Start data packets.  The following information is
   needed by the TCP receiver:

   * The RTT: TCP naturally measures the RTT of the path and therefore
     should have a sample of the RTT.  If the TCP receiver does not have
     a measurement of the round-trip time, it can use the time between
     the receipt of the Quick-Start Request and the Report of Approved
     Rate.

   * The Approved Rate Request (R): When the TCP receiver receives the
     Quick-Start Response packet, the receiver knows the value of the
     approved Rate Request.

   * The MSS: TCP advertises the MSS during the initial three-way
     handshake; therefore, the receiver should have an understanding of
     the packet size the sender will be using.  If the receiver does not
     have such an understanding or wishes to confirm the negotiated MSS,
     the size of the first data packet can be used.

   With this set of information, the TCP receiver can restrict its
   sending rate for pure acknowledgment traffic to at most 100 pure ACK
   packets per RTT by sending at most one ACK for every K data packets,
   for the ACK Ratio K set to R*RTT/(100*8*MSS).  The receiver would
   acknowledge the first Quick-Start data packet, and every succeeding K
   data packets.  Thus, for a somewhat extreme case of R=1.3 Gbps,
   RTT=0.2 seconds, and MSS=1500 bytes, K would be set to 216, and the
   receiver would acknowledge every 216 data packets.  From [RFC2581],
   the ACK Ratio K should have a minimum value of two.  When the ACK
   Ratio is greater than two, and the TCP sender receives
   acknowledgements each acknowledging more than two data packets, the
   TCP sender may want to use rate-based pacing to control the
   burstiness of its outgoing data traffic.

   In the absence of explicit congestion control mechanisms, the TCP end
   nodes cannot determine the packet drop rate for pure acknowledgement
   traffic.  This is true with or without Quick-Start.  However, the TCP
   receiver could limit its increase in the sending rate for pure ACK
   packets by at most doubling the sending rate for pure ACK packets
   from one round-trip time to the next.  The TCP receiver would do this
   by halving the ACK Ratio each round-trip time.

   Note that the above is one particular mechanism that could be used to
   control the ACK stream.  Future work that investigates this scheme
   and others in detail is encouraged.

Top      Up      ToC       Page 26 
4.6.  TCP: Responding to a Loss of a Quick-Start Packet

   For TCP, we have defined a "Quick-Start packet" as one of the packets
   sent in the window immediately following a successful Quick-Start
   Request.  After detecting the loss or ECN-marking of a Quick-Start
   packet, TCP MUST revert to the default congestion control procedures
   that would have been used if the Quick-Start Request had not been
   approved.  For example, if Quick-Start is used for setting the
   initial window, and a packet from the initial window is lost or
   marked, then the TCP sender MUST then slow-start with the default
   initial window that would have been used if Quick-Start had not been
   used.  In addition to reverting to the default congestion control
   mechanisms, the sender MUST take into account that the Quick-Start
   congestion window was too large.  Thus, the sender SHOULD decrease
   ssthresh to, at most, half the number of Quick-Start packets that
   were successfully transmitted.  Appendix B.5 discusses possible
   alternatives in responding to the loss of a Quick-Start packet.

   If a Quick-Start packet is lost or ECN-marked, then the sender SHOULD
   NOT make future Quick-Start Requests for this connection.

   We note that ECN [RFC3168] MAY be used with Quick-Start.  As is
   always the case with ECN, the sender's congestion control response to
   an ECN-marked Quick-Start packet is the same as the response to a
   dropped Quick-Start packet, thus reverting to slow start in the case
   of Quick-Start packets marked as experiencing congestion.

4.7.  TCP: A Quick-Start Request for a Larger Initial Window

   Some of the issues of using Quick-Start are related to the specific
   scenario in which Quick-Start is used.  This section discusses the
   following issues that arise when Quick-Start is used by TCP to
   request a larger initial window: (1) interactions with Path MTU
   Discovery (PMTUD); and (2) Quick-Start Request packets that are
   discarded by middleboxes.

4.7.1.  Interactions with Path MTU Discovery

   One issue when Quick-Start is used to request a large initial window
   concerns the interactions between the large initial window and Path
   MTU Discovery.  Some of the issues are discussed in RFC 3390:

   "When larger initial windows are implemented along with Path MTU
   Discovery [RFC1191], alternatives are to set the `Don't Fragment'
   (DF) bit in all segments in the initial window, or to set the `Don't
   Fragment' (DF) bit in one of the segments.  It is an open question as
   to which of these two alternatives is best."

Top      Up      ToC       Page 27 
   If the sender knows the Path MTU when the initial window is sent
   (e.g., from a PMTUD cache or from some other IETF-approved method),
   then the sender SHOULD use that MTU for segments in the initial
   window.  Unfortunately, the sender doesn't necessarily know the Path
   MTU when it sends packets in the initial window.  In this case, the
   sender should be conservative in the packet size used.  Sending a
   large number of overly large packets with the DF bit set is not
   desirable, but sending a large number of packets that are fragmented
   in the network can be equally undesirable.

   If the sender doesn't know the Path MTU when the initial window is
   sent, the sender SHOULD send one large packet in the initial window
   with the DF bit set, and send the remaining packets in the initial
   window with a smaller MTU of 576 bytes (or 1280 bytes with IPv6).

   A second possibility would be for the sender to delay sending the
   Quick-Start Request for one round-trip time by sending the Quick-
   Start Request with the first window of data, while also doing Path
   MTU Discovery.

   The sender may be using an iterative approach such as Packetization
   Layer Path MTU Discovery (PLPMTUD) [MH06] for Path MTU Discovery,
   where the sender tests successively larger MTUs.  If a probe is
   successfully delivered, then the MTU can be raised to reflect the
   value used in that probe.  We would note that PLPMTUD does not allow
   the sender to determine the Path MTU before sending the initial
   window of data.

4.7.2.  Quick-Start Request Packets that are Discarded by Routers or
        Middleboxes

   It is always possible for a TCP SYN packet carrying a Quick-Start
   request to be dropped in the network due to congestion, or to be
   blocked due to interactions with routers or middleboxes, where a
   middlebox is defined as any intermediary box performing functions
   apart from normal, standard functions of an IP router on the data
   path between a source host and destination host [RFC3234].
   Measurement studies of interactions between transport protocols and
   middleboxes [MAF04] show that for 70% of the Web servers
   investigated, no connection is established if the TCP SYN packet
   contains an unknown IP option (and for 43% of the Web servers, no
   connection is established if the TCP SYN packet contains an IP
   TimeStamp Option).  In both cases, this is presumably due to routers
   or middleboxes along that path.

   If the TCP sender doesn't receive a response to the SYN or SYN/ACK
   packet containing the Quick-Start Request, then the TCP sender SHOULD
   resend the SYN or SYN/ACK packet without the Quick-Start Request.

Top      Up      ToC       Page 28 
   Similarly, if the TCP sender receives a TCP reset in response to the
   SYN or SYN/ACK packet containing the Quick-Start Request, then the
   TCP sender SHOULD resend the SYN or SYN/ACK packet without the
   Quick-Start Request [RFC3360].

   RFCs 1122 and 2988 specify that the sender should set the initial RTO
   (retransmission timeout) to three seconds, though many TCP
   implementations set the initial RTO to one second.  For a TCP SYN
   packet sent with a Quick-Start request, the TCP sender SHOULD use an
   initial RTO of three seconds.

   We note that if the TCP SYN packet is using the IP Quick-Start Option
   for a Quick-Start Request, and it is also using bits in the TCP
   header to negotiate ECN-capability with the TCP host at the other
   end, then the drop of a TCP SYN packet could be due to congestion, a
   router or middlebox dropping the packet because of the IP Option, or
   a router or middlebox dropping the packet because of the information
   in the TCP header negotiating ECN.  In this case, the sender could
   resend the dropped packet without either the Quick-Start or the ECN
   requests.  Alternately, the sender could resend the dropped packet
   with only the ECN request in the TCP header, resending the TCP SYN
   packet without either the Quick-Start or the ECN requests if the
   second TCP SYN packet is dropped.  The second choice seems
   reasonable, given that a TCP SYN packet today is more likely to be
   blocked due to policies that discard packets with IP Options than due
   to policies that discard packets with ECN requests in the TCP header
   [MAF04].

4.8.  TCP: A Quick-Start Request in the Middle of a Connection

   This section discusses the following issues that arise when Quick-
   Start is used by TCP to request a larger window in the middle of a
   connection, such as after an idle period: (1) determining the rate to
   request; (2) when to make a request; and (3) the response if Quick-
   Start packets are dropped.

   (1) Determining the rate to request:
       For a connection that has not yet had a congestion event (that
       is, a marked or dropped packet), the TCP sender is not restricted
       in the rate that it requests.  As an example, a server might wait
       and send a Quick-Start Request after a short interaction with the
       client.

       To use a Quick-Start Request in a connection that has already
       experienced a congestion event, and that has not had a recent
       mobility event, the TCP sender can determine the largest
       congestion window that the TCP connection achieved since the last
       packet drop and translate this to a sending rate to get the

Top      Up      ToC       Page 29 
       maximum allowed request rate.  If the request is granted, then
       the sender essentially restarts with its old congestion window
       from before it was reduced, for example, during an idle period.

       A Quick-Start Request sent in the middle of a TCP connection
       SHOULD be sent on a data packet.

   (2) When to make a request:
       A TCP connection MAY make a Quick-Start Request before the
       connection has experienced a congestion event, or after an idle
       period of at least one RTO.

   (3) Response if Quick-Start packets are dropped:
       If Quick-Start packets are dropped in the middle of connection,
       then the sender MUST revert to half the Quick-Start window, or to
       the congestion window that the sender would have used if the
       Quick-Start request had not been approved, whichever is smaller.

4.9.  An Example Quick-Start Scenario with TCP

   The following is an example scenario of when both hosts request
   Quick-Start for setting their initial windows.  This is similar to
   Figures 1 and 2 in Section 2.1, except that it illustrates a TCP
   connection with both TCP hosts sending Quick-Start Requests.

   * 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
     calculates the TTL Diff.  If 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 TTL Diff, Rate Request, and QS Nonce 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.  In either case, Host A
     sends a Report of Approved Rate.

Top      Up      ToC       Page 30 
     Host A also calculates the TTL Diff for the Quick-Start Request in
     the incoming SYN/ACK packet, and sends a Quick-Start Response in
     the TCP header of the ACK packet.

   * Host B receives the Quick-Start Response in an ACK packet, and
     checks the TTL Diff, Rate Request, and QS Nonce 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 its initial window.  If the Quick-Start Response is
     not valid, then Host B uses TCP's default initial window.  In
     either case, Host B sends a Report of Approved Rate.

5.  Quick-Start and IPsec AH

   This section shows that Quick-Start is compatible with IPsec
   Authentication Header (AH).  AH uses an Integrity Check Value (ICV)
   in the IPsec Authentication Header to verify both message
   authentication and integrity [RFC4302].  Changes to the Quick-Start
   Option in the IP header do not affect this AH ICV.  The tunnel
   considerations in Section 6 below apply to all IPsec tunnels,
   regardless of what IPsec headers or processing are used in
   conjunction with the tunnel.

   Because the contents of the Quick-Start Option can change along the
   path, it is important that these changes not affect the IPsec
   Authentication Header Integrity Check Value (AH ICV).  For IPv4, RFC
   4302 requires that unrecognized IPv4 options be zeroed for AH ICV
   computation purposes, so Quick-Start IP Option data changing en route
   does not cause problems with existing IPsec AH implementations for
   IPv4.  If the Quick-Start Option is recognized, it MUST be treated as
   a mutable IPv4 option, and hence be completely zeroed for AH ICV
   calculation purposes.  IPv6 option numbers explicitly indicate
   whether the option is mutable; the third-highest order bit in the
   IANA-allocated option type has the value 1 to indicate that the
   Quick-Start Option data can change en route.  RFC 4302 requires that
   the option data of any such option be zeroed for AH ICV computation
   purposes.  Therefore, changes to the Quick-Start Option in the IP
   header do not affect the calculation of the AH ICV.

Top      Up      ToC       Page 31 
6.  Quick-Start in IP Tunnels and MPLS

   This section considers interactions between Quick-Start and IP
   tunnels, including IPsec ([RFC4301]), IP in IP [RFC2003], GRE
   [RFC2784], and others.  This section also considers interactions
   between Quick-Start and MPLS [RFC3031].

   In the discussion, we use TTL Diff, defined earlier as the difference
   between the IP TTL and the Quick-Start TTL, mod 256.  Recall that the
   sender considers the Quick-Start Request approved only if the value
   of TTL Diff for the packet entering the network is the same as the
   value of TTL Diff for the packet exiting the network.

   Simple tunnels: IP tunnel modes are generally based on adding a new
   "outer" IP header that encapsulates the original or "inner" IP header
   and its associated packet.  In many cases, the new "outer" IP header
   may be added and removed at intermediate points along a path,
   enabling the network to establish a tunnel without requiring endpoint
   participation.  We denote tunnels that specify that the outer header
   be discarded at tunnel egress as "simple tunnels", and we denote
   tunnels where the egress saves and uses information from the outer
   header before discarding it as "non-simple tunnels".  An example of a
   "non-simple tunnel" would be a tunnel configured to support ECN,
   where the egress router might copy the ECN codepoint in the outer
   header to the inner header before discarding the outer header
   [RFC3168].

                       __ Tunnels Compatible with Quick-Start
                      /
   Simple Tunnels  __/
                     \
                      \__ Tunnels Not Compatible with Quick-Start
                                    (False Positives!)


                           __ Tunnels Supporting Quick-Start
                          /
                         /
   Non-Simple Tunnels __/_____ Tunnels Compatible with Quick-Start,
                        \          but Not Supporting Quick-Start
                         \
                          \__ Tunnels Not Compatible with Quick-Start?


                     Figure 6: Categories of Tunnels.

Top      Up      ToC       Page 32 
   Tunnels that are compatible with Quick-Start: We say that an IP
   tunnel `is not compatible with Quick-Start' if the use of a Quick-
   Start Request over such a tunnel allows false positives, where the
   TCP sender incorrectly believes that the Quick-Start Request was
   approved by all routers along the path.  If the use of Quick-Start
   over the tunnel does not cause false positives, we say that the IP
   tunnel `is compatible with Quick-Start'.

   If the IP TTL of the inner header is decremented during forwarding
   before tunnel encapsulation takes place, then the simple tunnel is
   compatible with Quick-Start, with Quick-Start Requests being
   rejected.  Section 6.1 describes in more detail the ways that a
   simple tunnel can be compatible with Quick-Start.

   There are some simple tunnels that are not compatible with Quick-
   Start, allowing `false positives' where the TCP sender incorrectly
   believes that the Quick-Start Request was approved by all routers
   along the path.  This is discussed in Section 6.2 below.

   One of our tasks in the future will be to investigate the occurrence
   of tunnels that are not compatible with Quick-Start, and to track the
   extent to which such tunnels are modified over time.  The evaluation
   of the problem of false positives from tunnels that are not
   compatible with Quick-Start will affect the progression of Quick-
   Start from Experimental to Proposed Standard, and will affect the
   degree of deployment of Quick-Start while in Experimental mode.

   Tunnels that support Quick-Start: We say that an IP tunnel `supports
   Quick-Start' if it allows routers along the tunnel path to process
   the Quick-Start Request and give feedback, resulting in the
   appropriate possible acceptance of the Quick-Start Request.  Some
   tunnels that are compatible with Quick-Start support Quick-Start,
   while others do not.  We note that a simple tunnel is not able to
   support Quick-Start.

   From a security point of view, the use of Quick-Start in the outer
   header of an IP tunnel might raise security concerns because an
   adversary could tamper with the Quick-Start information that
   propagates beyond the tunnel endpoint, or because the Quick-Start
   Option exposes information to network scanners.  Our approach is to
   make supporting Quick-Start an option for IP tunnels.  That is, in
   environments or tunneling protocols where the risks of using Quick-
   Start are judged to outweigh its benefits, the tunnel can simply
   delete the Quick-Start Option or zero the Quick-Start rate request
   and QS TTL fields before encapsulation.  The result is that there are
   two viable options for IP tunnels to be compatible with Quick-Start.
   The first option is the simple tunnel described above and in Section
   6.1, where the tunnel is compatible with Quick-Start but does not

Top      Up      ToC       Page 33 
   support Quick-Start, where all Quick-Start Requests along the path
   will be rejected.  The second approach is a Quick-Start-capable mode,
   described in Section 6.3, where the tunnel actively supports Quick-
   Start.

6.1.  Simple Tunnels that Are Compatible with Quick-Start

   This section describes the ways that a simple tunnel can be
   compatible with Quick-Start but not support Quick-Start, resulting in
   the rejection of all Quick-Start Requests that traverse the tunnel.

   If the tunnel ingress for the simple tunnel is at a router, the IP
   TTL of the inner header is generally decremented during forwarding
   before tunnel encapsulation takes place.  In this case, TTL Diff will
   be changed, correctly causing the Quick-Start Request to be rejected.
   For a simple tunnel, it is preferable if the Quick-Start Request is
   not copied to the outer header, saving the routers within the tunnel
   from unnecessarily processing the Quick-Start Request.  However, the
   Quick-Start Request will be rejected correctly in this case whether
   or not the Quick-Start Request is copied to the outer header.

6.1.1.  Simple Tunnels that Are Aware of Quick-Start

   If a tunnel ingress is aware of Quick-Start, but does not want to
   support Quick-Start, then the tunnel ingress MUST either zero the
   Quick-Start rate request, QS TTL, and QS Nonce fields, or remove the
   Quick-Start Option from the inner header before encapsulation.
   Section 6.3 describes the procedures for a tunnel that does want to
   support Quick-Start.

   Deleting the Quick-Start Option or zeroing the Quick-Start rate
   request *after decapsulation* also serves to prevent the propagation
   of Quick-Start information, and is compatible with Quick-Start.  If
   the outer header does not contain a Quick-Start Request, a Quick-
   Start-aware tunnel egress MUST reject the inner Quick-Start Request
   by zeroing the Rate Request field in the inner header, or by deleting
   the Quick-Start Option.

   If the tunnel ingress is at a sending host or router where the IP TTL
   is not decremented prior to encapsulation, and neither tunnel
   endpoint is aware of Quick-Start, then this allows false positives,
   described in the section below.

Top      Up      ToC       Page 34 
6.2.  Simple Tunnels that Are Not Compatible with Quick-Start

   Sometimes a tunnel implementation that does not support Quick-Start
   is independent of the TCP sender or a router implementation that
   supports Quick-Start.  In these cases, it is possible that a Quick-
   Start Request gets erroneously approved without the routers in the
   tunnel having individually approved the request, causing a false
   positive.

   If a tunnel ingress is a separate component from the TCP sender or IP
   forwarding, it is possible that a packet with a Quick-Start option is
   encapsulated without the IP TTL being decremented first, or with both
   IP TTL and QS TTL being decremented before the tunnel encapsulation
   takes place.  If the tunnel ingress does not know about Quick-Start,
   a valid Quick-Start Request with unchanged TTL Diff traverses in the
   inner header, while the outer header most likely does not carry a
   Quick-Start Request.  If the tunnel egress also does not support
   Quick-Start, it remains possible that the Quick-Start Request would
   be falsely approved, because the packet is decapsulated using the
   Quick-Start Request from the inner header, and the value of TTL Diff
   echoed to the sender remains unchanged.  For example, such a scenario
   can occur with a Bump-In-The-Stack (BITS), an IPsec encryption
   implementation where the data encryption occurs between the network
   drivers and the TCP/IP protocol stack [RFC4301].

   As one example, if a remote access VPN client uses a BITS structure,
   then Quick-Start obstacles between the client and the VPN gateway
   won't be seen.  This is a particular problem because the path between
   the client and the VPN gateway is likely to contain the most
   congested part of the path.  Because most VPN clients are reported to
   use BITS [H05], we will explore this in more detail.

   A Bump-In-The-Wire (BITW) is an IPsec encryption implementation where
   the encryption occurs on an outboard processor, offloading the
   encryption processing overhead from the host or router [RFC4301].
   The BITW device is usually IP addressable, which means that the IP
   TTL is decremented before the packet is passed to the BITW.  If the
   QS TTL is not decremented, then the value of TTL Diff is changed, and
   the Quick-Start Request will be denied.  However, if the BITW
   supports a host and does not have its own IP address, then the IP TTL
   is not decremented before the packet is passed from the host to the
   BITW, and a false positive could occur.

   Other tunnels that need to be looked at are IP tunnels over non-
   network protocols, such as IP over TCP and IP over UDP [RFC3948], and
   tunnels using the Layer Two Tunneling Protocol [RFC2661].

Top      Up      ToC       Page 35 
   Section 9.2 discusses the related issue of non-IP queues, such as
   layer-two Ethernet or ATM (Asynchronous Transfer Mode) networks, as
   another instance of possible bottlenecks that do not participate in
   the Quick-Start feedback.

6.3.  Tunnels That Support Quick-Start

   This section discusses tunnels configured to support Quick-Start.

   If the tunnel ingress node chooses to locally approve the Quick-
   Start Request, then the ingress node MUST decrement the Quick-Start
   TTL at the same time it decrements the IP TTL, and MUST copy IP TTL
   and the Quick-Start Option from the inner IP header to the outer
   header.  During encapsulation, the tunnel ingress MUST zero the
   Quick-Start rate request field in the inner header to ensure that the
   Quick-Start Request will be rejected if the tunnel egress does not
   support Quick-Start.

   If the tunnel ingress node does not choose to locally approve the
   Quick-Start Request, then it MUST either delete the Quick-Start
   option from the inner header before encapsulation, or zero the QS TTL
   and the Rate Request fields before encapsulation.

   Upon decapsulation, if the outer header contains a Quick-Start
   option, the tunnel egress MUST copy the IP TTL and the Quick-Start
   option from the outer IP header to the inner header.

   IPsec uses the IKE (Internet Key Exchange) Protocol for security
   associations.  We do not consider the interactions between Quick-
   Start and IPsec with IKEv1 [RFC2409] in this document.  Now that the
   RFC for IKEv2 [RFC4306] is published, we plan to specify a
   modification of IPsec to allow the support of Quick-Start to be
   negotiated; this modification will specify the negotiation between
   tunnel endpoints to allow or forbid support for Quick-Start within
   the tunnel.  This was done for ECN for IPsec tunnels, with IKEv1
   [RFC3168, Section 9.2].  This negotiation of Quick-Start capability
   in an IPsec tunnel will be specified in a separate IPsec document.
   This document will also include a discussion of the potential effects
   of an adversary's modifications of the Quick-Start field (as in
   Sections 18 and 19 of RFC 3168), and of the security considerations
   of exposing the Quick-Start rate request to network scanners.

6.4.  Quick-Start and MPLS

   The behavior of Quick-Start with MPLS is similar to the behavior of
   Quick-Start with IP Tunnels.  For those MPLS paths where the IP TTL
   is decremented as part of traversing the MPLS path, these paths are
   compatible with Quick-Start, but do not support Quick-Start; Quick-

Top      Up      ToC       Page 36 
   Start Requests that are traversing these paths will be correctly
   understood by the transport sender as having been denied.  Any MPLS
   paths where the IP TTL is not decremented as part of traversing the
   MPLS path would be not compatible with Quick-Start; such paths would
   result in false positives, where the TCP sender incorrectly believes
   that the Quick-Start Request was approved by all routers along the
   path.

   For cases where the ingress node to the MPLS path is aware of Quick-
   Start, this node should either zero the Quick-Start rate request, QS
   TTL, and QS Nonce fields, or remove the Quick-Start Option from the
   IP header.

7.  The Quick-Start Mechanism in Other Transport Protocols

   The section earlier specified the use of Quick-Start in TCP.  In this
   section, we generalize this to give guidelines for the use of Quick-
   Start with other transport protocols.  We also discuss briefly how
   Quick-Start could be specified for other transport protocols.

   The general guidelines for Quick-Start in transport protocols are as
   follows:

   * Quick-Start is only specified for unicast transport protocols with
     appropriate congestion control mechanisms.  Note: Quick-Start is
     not a replacement for standard congestion control techniques, but
     meant to augment their operation.

   * A transport-level mechanism is needed for the Quick-Start Response
     from the receiver to the sender.  This response contains the Rate
     Request, TTL Diff, and QS Nonce.

   * The sender checks the validity of the Quick-Start Response.

   * The sender has an estimate of the round-trip time, and translates
     the Quick-Start Response into an allowed window or allowed sending
     rate.  The sender sends a Report of the Approved Rate.  The sender
     starts sending Quick-Start packets, rate-paced out at the approved
     sending rate.

   * After the sender receives the first acknowledgement packet for a
     Quick-Start packet, no more Quick-Start packets are sent.  The
     sender adjusts its current congestion window or sending rate to be
     consistent with the actual amount of data that was transmitted in
     that round-trip time.

Top      Up      ToC       Page 37 
   * When the last Quick-Start packet is acknowledged, the sender
     continues using the standard congestion control mechanisms of that
     protocol.

   * If one of the Quick-Start packets is lost, then the sender reverts
     to the standard congestion control method of that protocol that
     would have been used if the Quick-Start Request had not been
     approved.  In addition, the sender takes into account the
     information that the Quick-Start congestion window was too large
     (e.g., by decreasing ssthresh in TCP).



(page 37 continued on part 3)

Next RFC Part