RFC 4782
Quick-Start for TCP and IP
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
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
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
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
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].
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.
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.
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.
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.
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)
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.
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
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.
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
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
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.
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 page on part 2)
