tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 4782

 Errata 
Experimental
Pages: 82
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: TSVWG

Quick-Start for TCP and IP

Part 1 of 4, p. 1 to 17
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                           S. Floyd
Request for Comments: 4782                                     M. Allman
Category: Experimental                                              ICIR
                                                                 A. Jain
                                                             F5 Networks
                                                            P. Sarolahti
                                                   Nokia Research Center
                                                            January 2007


                       Quick-Start for TCP and IP

Status of This Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document specifies an optional Quick-Start mechanism for
   transport protocols, in cooperation with routers, to determine an
   allowed sending rate at the start and, at times, in the middle of a
   data transfer (e.g., after an idle period).  While Quick-Start is
   designed to be used by a range of transport protocols, in this
   document we only specify its use with TCP.  Quick-Start is designed
   to allow connections to use higher sending rates when there is
   significant unused bandwidth along the path, and the sender and all
   of the routers along the path approve the Quick-Start Request.

   This document describes many paths where Quick-Start Requests would
   not be approved.  These paths include all paths containing routers,
   IP tunnels, MPLS paths, and the like that do not support Quick-
   Start.  These paths also include paths with routers or middleboxes
   that drop packets containing IP options.  Quick-Start Requests could
   be difficult to approve over paths that include multi-access layer-
   two networks.  This document also describes environments where the
   Quick-Start process could fail with false positives, with the sender
   incorrectly assuming that the Quick-Start Request had been approved
   by all of the routers along the path.  As a result of these concerns,
   and as a result of the difficulties and seeming absence of motivation
   for routers, such as core routers to deploy Quick-Start, Quick-Start
   is being proposed as a mechanism that could be of use in controlled

Page 2 
   environments, and not as a mechanism that would be intended or
   appropriate for ubiquitous deployment in the global Internet.

Table of Contents

   1. Introduction ....................................................4
      1.1. Conventions and Terminology ................................5
   2. Assumptions and General Principles ..............................6
      2.1. Overview of Quick-Start ....................................7
   3. The Quick-Start Option in IP ...................................10
      3.1. The Quick-Start Option for IPv4 ...........................10
      3.2. The Quick-Start Option for IPv6 ...........................13
      3.3. Processing the Quick-Start Request at Routers .............14
           3.3.1. Processing the Report of Approved Rate .............15
      3.4. The QS Nonce ..............................................16
   4. The Quick-Start Mechanisms in TCP ..............................18
      4.1. Sending the Quick-Start Request ...........................19
      4.2. The Quick-Start Response Option in the TCP header .........20
      4.3. TCP: Sending the Quick-Start Response .....................21
      4.4. TCP: Receiving and Using the Quick-Start Response Packet ..22
      4.5. TCP: Controlling Acknowledgement Traffic on the
           Reverse Path ..............................................24
      4.6. TCP: Responding to a Loss of a Quick-Start Packet .........26
      4.7. TCP: A Quick-Start Request for a Larger Initial Window ....26
           4.7.1. Interactions with Path MTU Discovery ...............26
           4.7.2. Quick-Start Request Packets that are
                  Discarded by Routers or Middleboxes ................27
      4.8. TCP: A Quick-Start Request in the Middle of a Connection ..28
      4.9. An Example Quick-Start Scenario with TCP ..................29
   5. Quick-Start and IPsec AH .......................................30
   6. Quick-Start in IP Tunnels and MPLS .............................31
      6.1. Simple Tunnels that Are Compatible with Quick-Start .......33
           6.1.1. Simple Tunnels that Are Aware of Quick-Start .......33
      6.2. Simple Tunnels that Are Not Compatible with Quick-Start ...34
      6.3. Tunnels That Support Quick-Start ..........................35
      6.4. Quick-Start and MPLS ......................................35
   7. The Quick-Start Mechanism in Other Transport Protocols .........36
   8. Using Quick-Start ..............................................37
      8.1. Determining the Rate to Request ...........................37
      8.2. Deciding the Permitted Rate Request at a Router ...........37
   9. Evaluation of Quick-Start ......................................38
      9.1. Benefits of Quick-Start ...................................38
      9.2. Costs of Quick-Start ......................................39
      9.3. Quick-Start with QoS-Enabled Traffic ......................41
      9.4. Protection against Misbehaving Nodes ......................41
           9.4.1. Misbehaving Senders ................................41
           9.4.2. Receivers Lying about Whether the Request
                  was Approved .......................................43

Top      ToC       Page 3 
           9.4.3. Receivers Lying about the Approved Rate ............43
           9.4.4. Collusion between Misbehaving Routers ..............44
      9.5. Misbehaving Middleboxes and the IP TTL ....................46
      9.6. Attacks on Quick-Start ....................................46
      9.7. Simulations with Quick-Start ..............................47
   10. Implementation and Deployment Issues ..........................47
      10.1. Implementation Issues for Sending Quick-Start Requests ...47
      10.2. Implementation Issues for Processing Quick-Start
            Requests .................................................48
      10.3. Possible Deployment Scenarios ............................48
      10.4. A Comparison with the Deployment Problems of ECN .........50
   11. Security Considerations .......................................50
   12. IANA Considerations ...........................................52
      12.1. IP Option ................................................52
      12.2. TCP Option ...............................................52
   13. Conclusions ...................................................53
   14. Acknowledgements ..............................................53
   Appendix A. Related Work ..........................................54
      A.1. Fast Start-Ups without Explicit Information from Routers ..54
      A.2. Optimistic Sending without Explicit Information from
           Routers ...................................................56
      A.3. Fast Start-Ups with Other Information from Routers ........56
      A.4. Fast Start-Ups with More Fine-Grained Feedback from
           Routers ...................................................57
      A.5. Fast Start-ups with Lower-Than-Best-Effort Service ........58
   Appendix B. Design Decisions ......................................59
      B.1. Alternate Mechanisms for the Quick-Start Request:
           ICMP and RSVP .............................................59
           B.1.1. ICMP ...............................................59
           B.1.2. RSVP ...............................................60
      B.2. Alternate Encoding Functions ..............................61
      B.3. The Quick-Start Request: Packets or Bytes? ................63
      B.4. Quick-Start Semantics: Total Rate or Additional Rate? .....64
      B.5. Alternate Responses to the Loss of a Quick-Start Packet ...65
      B.6. Why Not Include More Functionality? .......................66
      B.7. Alternate Implementations for a Quick-Start Nonce .........69
           B.7.1. An Alternate Proposal for the Quick-Start Nonce ....69
           B.7.2. The Earlier Request-Approved Quick-Start Nonce .....69
   Appendix C. Quick-Start with DCCP .................................70
   Appendix D. Possible Router Algorithm .............................72
   Appendix E. Possible Additional Uses for the Quick-Start ..........74
   Normative References ..............................................75
   Informative References ............................................75

Top      ToC       Page 4 
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 3390
   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

Top      ToC       Page 5 
   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].

Top      ToC       Page 6 
2.  Assumptions and General Principles

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

   Assumptions:

   * 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 sending rate would have to be
     used independently for each direction.

   * The path between the two endpoints is relatively stable, such that
     the path used by the Quick-Start Request is generally the same path
     used by the Quick-Start packets one round-trip time later.
     [ZDPS01] shows this assumption should be generally valid.  However,
     [RFC3819] discusses a range of Bandwidth on Demand subnets that
     could cause the characteristics of the path to change over time.

   * Any new mechanism must be incrementally deployable and might not be
     supported by all 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.  We
     note that, while Quick-Start is incrementally deployable in this
     sense, a Quick-Start Request cannot be approved for a particular
     connection unless both end-nodes and all the routers along the path
     have been configured to support Quick-Start.

   General Principles:

   * 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.

   * A router should only approve a Quick-Start Request if the output
     link is underutilized.  Any other approach will result in either
     per-flow state at the router, or the possibility of a (possibly
     transient) queue at the router.

   * No per-flow state should be required at the router.  Note that,
     while per-flow state is not required, we also do not preclude a
     router from storing per-flow state for making Quick-Start decisions
     or for checking for misbehaving nodes.

Top      ToC       Page 7 
2.1.  Overview of Quick-Start

   In this section, we give an overview of the use of Quick-Start with
   TCP to request a higher congestion window.  The description in this
   section is non-normative; the normative description of Quick-Start
   with IP and TCP follows in Sections 3 and 4.  Quick-Start could be
   used in the middle of a connection, e.g., after an idle or
   underutilized period, as well as for the initial sending rate; these
   uses of Quick-Start are discussed later in the document.

   Quick-Start requires end-points and routers to work together, with
   end-points requesting a higher sending rate in the Quick-Start (QS)
   option in IP, and routers along the path approving, modifying,
   discarding, or ignoring (and therefore disallowing) the Quick-Start
   Request.  The receiver uses reliable, transport-level mechanisms to
   inform the sender of the status of the Quick-Start Request.  For
   example, when TCP is used, the TCP receiver sends feedback to the
   sender using a Quick-Start Response option in the TCP header.  In
   addition, Quick-Start assumes a unicast, congestion-controlled
   transport protocol; we do not consider the use of Quick-Start for
   multicast traffic.

   When sent as a request, the Quick-Start Option includes a request for
   a sending rate in bits per second, and a Quick-Start Time to Live (QS
   TTL) to be decremented by every router along the path that
   understands the option and approves the request.  The Quick-Start TTL
   is initialized by the sender to a random value.  The transport
   receiver returns the rate, information about the TTL, and the Quick-
   Start Nonce to the sender using transport-level mechanisms; for TCP,
   the receiver sends this information in the Quick-Start Response in
   the TCP header.  In particular, the receiver computes the difference
   between the Quick-Start TTL and the IP TTL (the TTL in the IP header)
   of the Quick-Start Request packet, and returns this in the Quick-
   Start Response.  The sender uses the TTL difference to determine if
   all the routers along the path decremented the Quick-Start TTL,
   approving the Quick-Start Request.

   If the request is approved by all the routers along the path, then
   the TCP sender combines this allowed rate with the measurement of the
   round-trip time, and ends up with an allowed TCP congestion window.
   This window is sent rate-paced over the next round-trip time, or
   until an ACK packet is received.

   Figure 1 shows a successful use of Quick-Start, with the sender's IP
   layer and both routers along the path approving the Quick-Start
   Request, and the TCP receiver using the Quick-Start Response to
   return information to the TCP sender.  In this example, Quick-Start
   is used by TCP to establish the initial congestion window.

Top      ToC       Page 8 
   Sender        Router 1       Router 2          Receiver
   ------        --------       --------          --------
   | <IP TTL: 63>
   | <QS TTL: 91>
   | <TTL Diff: 28>
   | Quick-Start Request
   | in SYN or SYN/ACK.
   | IP: Decrement QS TTL
   | to approve request -->
   |
   |               Decrement
   |               QS TTL
   |               to approve
   |               request -->
   |
   |                              Decrement
   |                              QS TTL
   |                              to approve
   |                              request -->
   |
   |                                           <IP TTL: 60>
   |                                           <QS TTL: 88>
   |                                           <TTL Diff: 28>
   |                                           Return Quick-Start
   |                                            info to sender in
   |                                           Quick-Start Response
   |                                          <-- in TCP ACK packet.
   |
   | <TTL Diff: 28>
   | Quick-Start approved,
   | translate to cwnd.
   | Report Approved Rate.
   V Send cwnd paced over one RTT. -->

                Figure 1: A Successful Quick-Start Request.

   Figure 2 shows an unsuccessful use of Quick-Start, with one of the
   routers along the path not approving the Quick-Start Request.  If the
   Quick-Start Request is not approved, then the sender uses the default
   congestion control mechanisms for that transport protocol, including
   the default initial congestion window, response to idle periods, etc.

Top      ToC       Page 9 
   Sender        Router 1       Router 2          Receiver
   ------        --------       --------          --------
   | <IP TTL: 63>
   | <QS TTL: 91>
   | <TTL Diff: 28>
   | Quick-Start Request
   | in SYN or SYN/ACK.
   | IP: Decrement QS TTL
   | to approve request -->
   |
   |               Decrement
   |               QS TTL
   |               to approve
   |               request -->
   |
   |                              Forward packet
   |                              without modifying
   |                              Quick-Start Option. -->
   |
   |                                           <IP TTL: 60>
   |                                           <QS TTL: 89>
   |                                           <TTL Diff: 29>
   |                                           Return Quick-Start
   |                                            info to sender in
   |                                           Quick-Start Response
   |                                          <-- in TCP ACK packet.
   |
   | <TTL Diff: 29>
   | Quick-Start not approved.
   | Report approved rate.
   V Use default initial cwnd. -->

              Figure 2: An Unsuccessful Quick-Start Request.

Top      ToC       Page 10 
3.  The Quick-Start Option in IP

3.1.  The Quick-Start Option for IPv4

   The Quick-Start Request for IPv4 is defined as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Option      |  Length=8     | Func. | Rate  |   QS TTL      |
   |               |               | 0000  |Request|               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        QS Nonce                           | R |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 3: The Quick-Start Option for IPv4.
                          A Quick-Start Request.

   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, indicating an option
   length of eight bytes.

   The third byte includes a four-bit Function field.  If the Function
   field is set to "0000", then the Quick-Start Option is a Rate
   Request.  In this case, the second half of the third byte is a four-
   bit Rate Request field.

   For a Rate Request, the fourth byte contains the Quick-Start TTL (QS
   TTL) field.  The sender MUST set the QS TTL field to a random value.
   Routers that approve the Quick-Start Request decrement the QS TTL
   (mod 256) by the same amount that they decrement the IP TTL.  (As
   elsewhere in this document, we use the term `router' imprecisely to
   also include the Quick-Start functionality at the IP layer at the
   sender.)  The QS TTL is used by the sender to detect if all the
   routers along the path understood and approved the Quick-Start
   option.

   For a Rate Request, the transport sender MUST calculate and store the
   TTL Diff, the difference between the IP TTL value, and the QS TTL
   value in the Quick-Start Request packet, as follows:

   TTL Diff = ( IP TTL - QS TTL ) mod 256                         (1)

Top      ToC       Page 11 
   For a Rate Request, bytes 5-8 contain a 30-bit QS Nonce, discussed in
   Section 3.4, and a two-bit Reserved field.  The sender SHOULD set the
   reserved field to zero, and routers and receivers SHOULD ignore the
   reserved field.  The sender SHOULD set the 30-bit QS Nonce to a
   random value.

   The sender initializes the Rate Request to the desired sending rate,
   including an estimate of the transport and IP header overhead.  The
   encoding function for the Rate Request sets the request rate to K*2^N
   bps (bits per second), for N the value in the Rate Request field, and
   for K set to 40,000.  For N=0, the rate request would be set to zero,
   regardless of the encoding function.  This is illustrated in Table 1
   below.  For the four-bit Rate Request field, the request range is
   from 80 Kbps to 1.3 Gbps.  Alternate encodings that were considered
   for the Rate Request are given in Appendix B.2.

    N     Rate Request (in Kbps)
   ---    ----------------------
    0            0
    1           80
    2          160
    3          320
    4          640
    5        1,280
    6        2,560
    7        5,120
    8       10,240
    9       20,480
   10       40,960
   11       81,920
   12      163,840
   13      327,680
   14      655,360
   15    1,310,720

   Table 1: Mapping from Rate Request Field to Rate Request in Kbps.

   Routers can approve the Quick-Start Request for a lower rate by
   decreasing the Rate Request in the Quick-Start Request.  Section 4.2
   discusses the Quick-Start Response from the TCP receiver to the TCP
   sender, and Section 4.4 discusses the TCP sender's mechanism for
   determining if a Quick-Start Request has been approved.

Top      ToC       Page 12 
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Option      |  Length=8     | Func. | Rate  |   Not Used    |
   |               |               | 1000  | Report|               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        QS Nonce                           | R |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 4: The Quick-Start Option for IPv4.
                         Report of Approved Rate.

   If the Function field in the third byte of the Quick-Start Option is
   set to "1000", then the Quick-Start Option is a Report of Approved
   Rate.  In this case, the second four bits in the third byte are the
   Rate Report field, formatted exactly as in the Rate Request field in
   a Rate Request.  For a Report of Approved Rate, the fourth byte of
   the Quick-Start Option is not used.  Bytes 5-8 contain a 30-bit QS
   Nonce and a 2-bit Reserved field.

   After an approved Rate Request, the sender MUST report the Approved
   Rate, using a Quick-Start Option configured as a Report of Approved
   Rate with the Rate Report field set to the approved rate, and the QS
   Nonce set to the QS Nonce sent in the Quick-Start Request.  The
   packet containing the Report of Approved Rate MUST be either a
   control packet sent before the first Quick-Start data packet, or a
   Quick-Start Option in the first data packet itself.  The Report of
   Approved Rate does not have to be sent reliably; for example, if the
   approved rate is reported in a separate control packet, the sender
   does not necessarily know if the control packet has been dropped in
   the network.  If the packet containing the Quick-Start Request is
   acknowledged, but the acknowledgement packet does not contain a
   Quick-Start Response, then the sender MUST assume that the Quick-
   Start Request was denied, and set a Report of Approved Rate with a
   rate of zero.  Routers may choose to ignore the Report of Approved
   Rate, or to use the Report of Approved Rate but ignore the QS Nonce.
   Alternately, some routers that use the Report of Approved Rate may
   choose to match the QS Nonce, masked by the approved rate, with the
   QS Nonce seen in the original request.

   If the Rate Request is denied, the sender MUST send a Report of
   Approved Rate with the Rate Report field set to zero.

   We note that, unlike a Quick-Start Request sent at the beginning of a
   connection, when a Quick-Start Request is sent in the middle of a
   connection, the connection could already have an established
   congestion window or sending rate.  The Rate Request is the requested
   total rate for the connection, including the current rate of the

Top      ToC       Page 13 
   connection; the Rate Request is *not* a request for an additional
   sending rate over and above the current sending rate.  If the Rate
   Request is denied, or lowered to a value below the connection's
   current sending rate, then the sender ignores the request, and
   reverts to the default congestion control mechanisms of the transport
   protocol.

   The use of the Quick-Start Option does not require the additional use
   of the Router Alert Option [RFC2113].

   We note that in IPv4, a change in IP options at routers requires
   recalculating the IP header checksum.

3.2.  The Quick-Start Option for IPv6

   The Quick-Start Option for IPv6 is placed in the Hop-by-Hop Options
   extension header that is processed at every network node along the
   communication path [RFC2460].  The option format following the
   generic Hop-by-Hop Options header is identical to the IPv4 format,
   with the exception that the Length field should exclude the common
   type and length fields in the option format and be set to 6 bytes
   instead of 8 bytes.

   For a Quick-Start Request, the transport receiver compares the
   Quick-Start TTL with the IPv6 Hop Limit field to calculate the TTL
   Diff.  (The Hop Limit in IPv6 is the equivalent of the TTL in IPv4.)
   That is, TTL Diff MUST be calculated and stored as follows:

   TTL Diff = ( IPv6 Hop Limit - QS TTL ) mod 256                  (2)

   Unlike IPv4, modifying or deleting the Quick-Start IPv6 Option does
   not require checksum re-calculation, because the IPv6 header does not
   have a checksum field, and modifying the Quick-Start Request in the
   IPv6 Hop-by-Hop options header does not affect the IPv6 pseudo-
   header checksum used in upper-layer checksum calculations.

   Appendix A of RFC 2460 requires that all packets with the same flow
   label must be originated with the same hop-by-hop header contents,
   which would be incompatible with Quick-Start.  However, a later IPv6
   flow label specification [RFC3697] updates the use of flow labels in
   IPv6 and removes this restriction.  Therefore, Quick-Start is
   compatible with the current IPv6 specifications.

Top      ToC       Page 14 
3.3.  Processing the Quick-Start Request at Routers

   The Quick-Start Request does not report the current sending rate of
   the connection sending the request; in the default case of a router
   (or IP-layer implementation at an end-node) that does not maintain
   per-flow state, a router makes the conservative assumption that the
   flow's current sending rate is zero.  Each participating router can
   either terminate or approve the Quick-Start Request.  A router MUST
   only approve a Quick-Start Request if the output link is
   underutilized, and if the router judges that the output link will
   continue to be underutilized if this and earlier approved requests
   are used by the senders.  Otherwise, the router reduces or terminates
   the Quick-Start Request.

   While the paragraph above defines the *semantics* of approving a
   Quick-Start Request, this document does not specify the specific
   algorithms to be used by routers in processing Quick-Start Requests
   or Reports.  This is similar to RFC 3168, which specifics the
   semantics of the ECN codepoints in the IP header, but does not
   specify specific algorithms for routers to use in deciding when to
   drop or mark packets before buffer overflow.

   A router that wishes to terminate the Quick-Start Request SHOULD
   either delete the Quick-Start Request from the IP header or zero the
   QS TTL, QS Nonce, and Rate Request fields.  Deleting the Quick-Start
   Request saves resources because downstream routers will have no
   option to process, but zeroing the Rate Request field may be more
   efficient for routers to implement.  As suggested in [B05], future
   additions to Quick-Start could define error codes for routers to
   insert into the QS Nonce field to report back to the sender the
   reason that the Quick-Start Request was denied, e.g., that the router
   is denying all Quick-Start Requests at this time, or that this
   router, as a matter of policy, does not grant Quick-Start requests.
   A router that doesn't understand the Quick-Start Option will simply
   forward the packet with the Quick-Start Request unchanged (ensuring
   that the TTL Diff will not match and Quick-Start will not be used).

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

   * The router MUST decrement the QS TTL by the amount the IP TTL is
     decremented (usually one).

   * If the router is only willing to approve a Rate Request less than
     that in the Quick-Start Request, then the router replaces the Rate
     Request with a smaller value.  The router MUST NOT increase the
     Rate Request in the Quick-Start Request.  If the router decreases

Top      ToC       Page 15 
     the Rate Request, the router MUST also modify the QS Nonce, as
     described in Section 3.4.

   * In IPv4, the router MUST update the IP header checksum.

   If the router approves the Quick-Start Request, this approval SHOULD
   be taken into account in the router's decision to accept or reject
   subsequent Quick-Start Requests (e.g., using a variable that tracks
   the recent aggregate of accepted Quick-Start Requests).  This
   consideration of earlier approved Quick-Start Requests is necessary
   to ensure that the router only approves a Quick-Start Request when
   the router judges that the output link will remain underutilized if
   this and earlier Quick-Start Requests are used by the senders.

   In addition, the approval of a Quick-Start Request SHOULD NOT be used
   by the router to affect the treatment of the data packets that arrive
   from this connection in the next few round-trip times.  That is, the
   approval by the router of a Quick-Start Request does not give
   differential treatment for Quick-Start data packets at that router;
   it is only a statement from the router that the router believes that
   the subsequent Quick-Start data packets from this connection will not
   change the current underutilized state of the router.

   A non-participating router forwards the Quick-Start Request
   unchanged, without decrementing the QS TTL.  The non-participating
   router still decrements the TTL field in the IP header, as is
   required for all routers [RFC1812].  As a result, the sender will be
   able to detect that the Quick-Start Request had not been understood
   or approved by all of the routers along the path.

   A router that uses multipath routing for packets within a single
   connection MUST NOT approve a Quick-Start Request.  This is discussed
   in more detail in Section 9.2.

3.3.1.  Processing the Report of Approved Rate

   If the Quick-Start Option has the Function field set to "1000", then
   this is a Report of Approved Rate, rather than a Rate Request.  The
   router MAY ignore such an option, and, in any case, it MUST NOT
   modify the contents of the option for a Report of Approved Rate.
   However, the router MAY use the Approved Rate report to check that
   the sender is not lying about the approved rate.  If the reported
   Approved Rate is higher than the rate that the router actually
   approved for this connection in the previous round-trip time, then
   the router may implement some policy for cheaters.  For instance, the
   router MAY decide to deny future Quick-Start Requests from this
   sender, including, if desired, deleting Quick-Start Requests from
   future packets from this sender.  Section 9.4.1 discusses misbehaving

Top      ToC       Page 16 
   senders in more detail.  From the Report of Approved Rate, the router
   can also learn if some of the downstream routers have approved the
   Quick-Start Request for a smaller rate or denied the use of Quick-
   Start, and adjust its bandwidth allocations accordingly.

3.4.  The QS Nonce

   The QS Nonce gives the Quick-Start sender some protection against
   receivers lying about the value of the received Rate Request.  This
   is particularly important if the receiver knows the original value of
   the Rate Request (e.g., when the sender always requests the same
   value, and the receiver has a long history of communication with that
   sender).  Without the QS Nonce, there is nothing to prevent the
   receiver from reporting back to the sender a Rate Request of K, when
   the received Rate Request was, in fact, less than K.

   Table 2 gives the format for the 30-bit QS Nonce.

   Bits         Purpose
   ---------    ------------------
   Bits 0-1:    Rate 15 -> Rate 14
   Bits 2-3:    Rate 14 -> Rate 13
   Bits 4-5:    Rate 13 -> Rate 12
   Bits 6-7:    Rate 12 -> Rate 11
   Bits 8-9:    Rate 11 -> Rate 10
   Bits 10-11:  Rate 10 -> Rate 9
   Bits 12-13:  Rate 9 -> Rate 8
   Bits 14-15:  Rate 8 -> Rate 7
   Bits 16-17:  Rate 7 -> Rate 6
   Bits 18-19:  Rate 6 -> Rate 5
   Bits 20-21:  Rate 5 -> Rate 4
   Bits 22-23:  Rate 4 -> Rate 3
   Bits 24-25:  Rate 3 -> Rate 2
   Bits 26-27:  Rate 2 -> Rate 1
   Bits 28-29:  Rate 1 -> Rate 0

   Table 2: The QS Nonce.

   The transport sender MUST initialize the QS Nonce to a random value.
   If the router reduces the Rate Request from rate K to rate K-1, then
   the router MUST set the field in the QS Nonce for "Rate K -> Rate
   K-1" to a new random value.  Similarly, if the router reduces the
   Rate Request by N steps, the router MUST set the 2N bits in the
   relevant fields in the QS Nonce to a new random value.  The receiver
   MUST report the QS Nonce back to the sender.

Top      ToC       Page 17 
   If the Rate Request was not decremented in the network, then the QS
   Nonce should have its original value.  Similarly, if the Rate Request
   was decremented by N steps in the network, and the receiver reports
   back a Rate Request of K, then the last 2K bits of the QS Nonce
   should have their original value.

   With the QS Nonce, the receiver has a 1/4 chance of cheating about
   each step change in the rate request.  Thus, if the rate request is
   reduced by two steps in the network, the receiver has a 1/16 chance
   of successfully reporting that the original request was approved, as
   this requires reporting the original value for the QS nonce.
   Similarly, if the rate request is reduced many steps in the network,
   and the receiver receives a QS Option with a rate request of K, the
   receiver has a 1/16 chance of guessing the original values for the
   fields in the QS nonce for "Rate K+2 -> Rate K+1" and "Rate K+1 ->
   Rate K".  Thus, the receiver has a 1/16 chance of successfully lying
   and saying that the received rate request was K+2 instead of K.

   We note that the protection offered by the QS Nonce is the same
   whether one router makes all the decrements in the rate request, or
   whether they are made at different routers along the path.

   The requirements for randomization for the sender and routers in
   setting `random' values in the QS Nonce are not stringent -- almost
   any form of pseudo-random numbers will do.  The requirement is that
   the original value for the QS Nonce is not easily predictable by the
   receiver, and in particular, the nonce MUST NOT be easily determined
   from inspection of the rest of the packet or from previous packets.
   In particular, the nonce MUST NOT be based only on a combination of
   specific packet header fields.  Thus, if two bits of the QS Nonce are
   changed by a router along the path, the receiver should not be able
   to guess those two bits from the other 28 bits in the QS Nonce.

   An additional requirement is that the receiver cannot be able to
   tell, from the QS Nonce itself, which numbers in the QS Nonce were
   generated by the sender, and which were generated by routers along
   the path.  This makes it harder for the receiver to infer the value
   of the original rate request, making it one step harder for the
   receiver to cheat.

   Section 9.4 also considers issues of receiver cheating in more
   detail.


Next RFC Part