< draft-amit-quick-start-03.txt   draft-amit-quick-start-04.txt >
Internet Engineering Task Force A. Jain Internet Engineering Task Force A. Jain
INTERNET-DRAFT F5 Networks INTERNET-DRAFT F5 Networks
draft-amit-quick-start-03.txt S. Floyd draft-amit-quick-start-04.txt S. Floyd
Expires: March 2005 M. Allman Expires: August 2005 M. Allman
ICIR ICIR
P. Sarolahti P. Sarolahti
Nokia / Univ. Helsinki Nokia / Univ. Helsinki
25 September 2004 20 February 2005
Quick-Start for TCP and IP Quick-Start for TCP and IP
Status of this Memo Status of this Memo
By submitting this Internet-Draft, we certify that any applicable By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which we are aware have been patent or other IPR claims of which we are aware have been
disclosed, or will be disclosed, and any of which we become aware disclosed, or will be disclosed, and any of which we become aware
will be disclosed, in accordance with RFC 3668 (BCP 79). will be disclosed, in accordance with RFC 3668 (BCP 79).
skipping to change at page 3, line 6 skipping to change at page 3, line 6
there are routers along the path that do not understand the Quick- there are routers along the path that do not understand the Quick-
Start Request option, or have not agreed to the Quick-Start rate Start Request option, or have not agreed to the Quick-Start rate
request. TCP host B communicates the final rate request to TCP host request. TCP host B communicates the final rate request to TCP host
A in a transport-level Quick-Start Response in an answering TCP A in a transport-level Quick-Start Response in an answering TCP
packet. Quick-Start is designed to allow connections to use higher packet. Quick-Start is designed to allow connections to use higher
sending rates when there is significant unused bandwidth along the sending rates when there is significant unused bandwidth along the
path, and all of the routers along the path support the Quick-Start path, and all of the routers along the path support the Quick-Start
Request. Request.
TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION:
Changes from draft-amit-quick-start-03.txt:
* Added a citation to the paper on "Evaluating Quick-Start for
TCP", and added pointers to the work in that paper.
This work includes:
- Discussions of router algorithms.
- Discussions of sizing Quick-Start requests.
* Added sections on "Misbehaving Middleboxes", and on "Attacks on
Quick-Start".
Changes from draft-amit-quick-start-02.txt: Changes from draft-amit-quick-start-02.txt:
* Added a discussion on Using Quick-Start in the Middle of a * Added a discussion on Using Quick-Start in the Middle of a
Connection. The request would be on the total rate, Connection. The request would be on the total rate,
not on the additional rate. not on the additional rate.
* Changed name "Initial Rate" to "Rate Request", and changed * Changed name "Initial Rate" to "Rate Request", and changed
the units from packets per second to bytes per second. the units from packets per second to bytes per second.
* The following sections are new: * The following sections are new:
- The Quick-Start Request Option for IPv6 - The Quick-Start Request Option for IPv6
- Quick-Start in IP Tunnels - Quick-Start in IP Tunnels
skipping to change at page 4, line 24 skipping to change at page 4, line 24
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4. Deciding the Permitted Rate Request at a 3.4. Deciding the Permitted Rate Request at a
Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5. Quick-Start in IP Tunnels. . . . . . . . . . . . . . . . 15 3.5. Quick-Start in IP Tunnels. . . . . . . . . . . . . . . . 15
4. The Quick-Start Mechanisms in TCP . . . . . . . . . . . . . . 17 4. The Quick-Start Mechanisms in TCP . . . . . . . . . . . . . . 17
4.1. When to Use Quick-Start. . . . . . . . . . . . . . . . . 18 4.1. When to Use Quick-Start. . . . . . . . . . . . . . . . . 18
4.2. The Quick-Start Response Option in the TCP 4.2. The Quick-Start Response Option in the TCP
header. . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 header. . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3. TCP: Sending the Quick-Start Response. . . . . . . . . . 20 4.3. TCP: Sending the Quick-Start Response. . . . . . . . . . 20
4.4. TCP: Receiving and Using the Quick-Start 4.4. TCP: Receiving and Using the Quick-Start
Response Packet . . . . . . . . . . . . . . . . . . . . . . . 20 Response Packet . . . . . . . . . . . . . . . . . . . . . . . 21
4.5. TCP: Responding to a Loss of a Quick-Start 4.5. TCP: Responding to a Loss of a Quick-Start
Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.6. TCP: A Quick-Start Request for a Larger Ini- 4.6. TCP: A Quick-Start Request for a Larger Ini-
tial Window . . . . . . . . . . . . . . . . . . . . . . . . . 22 tial Window . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.7. TCP: A Quick-Start Request after an Idle 4.7. TCP: A Quick-Start Request after an Idle
Period. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Period. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.8. An Example Quick-Start Scenario with TCP . . . . . . . . 25 4.8. An Example Quick-Start Scenario with TCP . . . . . . . . 25
5. The Quick-Start Mechanism in other Transport Pro- 5. The Quick-Start Mechanism in other Transport Pro-
tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1. Quick-Start with DCCP. . . . . . . . . . . . . . . . . . 26 5.1. Quick-Start with DCCP. . . . . . . . . . . . . . . . . . 27
6. Evaluation of Quick-Start . . . . . . . . . . . . . . . . . . 28 6. Evaluation of Quick-Start . . . . . . . . . . . . . . . . . . 28
6.1. Benefits of Quick-Start. . . . . . . . . . . . . . . . . 28 6.1. Benefits of Quick-Start. . . . . . . . . . . . . . . . . 29
6.2. Costs of Quick-Start . . . . . . . . . . . . . . . . . . 29 6.2. Costs of Quick-Start . . . . . . . . . . . . . . . . . . 29
6.3. Protection against Misbehaving Nodes . . . . . . . . . . 30 6.3. Protection against Misbehaving Nodes . . . . . . . . . . 31
6.4. Quick-Start with QoS-enabled Traffic . . . . . . . . . . 33 6.4. Quick-Start with QoS-enabled Traffic . . . . . . . . . . 33
6.5. Limitations of Quick-Start . . . . . . . . . . . . . . . 33 6.5. Limitations of Quick-Start . . . . . . . . . . . . . . . 34
6.6. Simulations with Quick-Start . . . . . . . . . . . . . . 34 6.6. Attacks on Quick-Start . . . . . . . . . . . . . . . . . 34
7. Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 34 6.7. Simulations with Quick-Start . . . . . . . . . . . . . . 34
7. Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 35
7.1. Fast Start-ups without Explicit Information 7.1. Fast Start-ups without Explicit Information
from Routers. . . . . . . . . . . . . . . . . . . . . . . . . 34 from Routers. . . . . . . . . . . . . . . . . . . . . . . . . 35
7.2. Optimistic Sending without Explicit Informa- 7.2. Optimistic Sending without Explicit Informa-
tion from Routers . . . . . . . . . . . . . . . . . . . . . . 35 tion from Routers . . . . . . . . . . . . . . . . . . . . . . 36
7.3. Fast Start-ups with other Information from 7.3. Fast Start-ups with other Information from
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.4. Fast Start-ups with more Fine-Grained Feed- 7.4. Fast Start-ups with more Fine-Grained Feed-
back from Routers . . . . . . . . . . . . . . . . . . . . . . 37 back from Routers . . . . . . . . . . . . . . . . . . . . . . 38
8. Implementation and Deployment Issues. . . . . . . . . . . . . 37 8. Implementation and Deployment Issues. . . . . . . . . . . . . 38
8.1. Implementation Issues for Sending Quick- 8.1. Implementation Issues for Sending Quick-
Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 38 Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 39
8.2. Implementation Issues for Processing Quick- 8.2. Implementation Issues for Processing Quick-
Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 38 Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 39
8.3. Possible Deployment Scenarios. . . . . . . . . . . . . . 38 8.3. Possible Deployment Scenarios. . . . . . . . . . . . . . 40
8.4. Would QuickStart packets take the slow path 8.4. Would QuickStart packets take the slow path
in routers? . . . . . . . . . . . . . . . . . . . . . . . . . 39 in routers? . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.5. A Comparison with the Deployment Problems of 8.5. A Comparison with the Deployment Problems of
ECN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 ECN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 9. Security Considerations . . . . . . . . . . . . . . . . . . . 41
10. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . 40 10. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . 41
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
A. Design Decisions. . . . . . . . . . . . . . . . . . . . . . . 41 A. Design Decisions. . . . . . . . . . . . . . . . . . . . . . . 42
A.1. Alternate Mechanisms for the Quick-Start A.1. Alternate Mechanisms for the Quick-Start
Request: ICMP and RSVP. . . . . . . . . . . . . . . . . . . . 41 Request: ICMP and RSVP. . . . . . . . . . . . . . . . . . . . 42
A.1.1. ICMP. . . . . . . . . . . . . . . . . . . . . . . . 41 A.1.1. ICMP. . . . . . . . . . . . . . . . . . . . . . . . 42
A.1.2. RSVP. . . . . . . . . . . . . . . . . . . . . . . . 42 A.1.2. RSVP. . . . . . . . . . . . . . . . . . . . . . . . 43
A.2. Alternate Encoding Functions . . . . . . . . . . . . . . 43 A.2. Alternate Encoding Functions . . . . . . . . . . . . . . 44
A.3. The Quick-Start Request: Packets or Bytes? . . . . . . . 44 A.3. The Quick-Start Request: Packets or Bytes? . . . . . . . 45
A.4. Quick-Start Semantics: Total Rate or Addi- A.4. Quick-Start Semantics: Total Rate or Addi-
tional Rate?. . . . . . . . . . . . . . . . . . . . . . . . . 46 tional Rate?. . . . . . . . . . . . . . . . . . . . . . . . . 47
A.5. Alternate Responses to the Loss of a Quick- A.5. Alternate Responses to the Loss of a Quick-
Start Packet. . . . . . . . . . . . . . . . . . . . . . . . . 46 Start Packet. . . . . . . . . . . . . . . . . . . . . . . . . 47
A.6. Why Not Include More Functionality?. . . . . . . . . . . 47 A.6. Why Not Include More Functionality?. . . . . . . . . . . 48
A.7. A QuickStart Nonce?. . . . . . . . . . . . . . . . . . . 49 A.7. A QuickStart Nonce?. . . . . . . . . . . . . . . . . . . 51
Normative References . . . . . . . . . . . . . . . . . . . . . . 50 Normative References . . . . . . . . . . . . . . . . . . . . . . 51
Informative References . . . . . . . . . . . . . . . . . . . . . 51 Informative References . . . . . . . . . . . . . . . . . . . . . 52
IANA Considerations. . . . . . . . . . . . . . . . . . . . . . . 53 IANA Considerations. . . . . . . . . . . . . . . . . . . . . . . 55
AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 54 AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 55
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 54 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 55
Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 54 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
Each TCP connection begins with a question: "What is the appropriate Each TCP connection begins with a question: "What is the appropriate
sending rate for the current network path?" The question is not sending rate for the current network path?" The question is not
answered explicitly for TCP, but each TCP connection determines the answered explicitly for TCP, but each TCP connection determines the
sending rate by probing the network path and altering the congestion sending rate by probing the network path and altering the congestion
window (cwnd) based on perceived congestion. Each connection starts window (cwnd) based on perceived congestion. Each connection starts
with a pre-configured initial congestion window (ICW). Currently, with a pre-configured initial congestion window (ICW). Currently,
TCP allows an initial window of between one and four MSS-sized TCP allows an initial window of between one and four MSS-sized
skipping to change at page 15, line 32 skipping to change at page 15, line 32
the total aggregate Rate Requests that have been approved over the the total aggregate Rate Requests that have been approved over the
recent interval of time, and one for the total aggregate Rate recent interval of time, and one for the total aggregate Rate
Requests approved over the previous interval of time. Thus, if an Requests approved over the previous interval of time. Thus, if an
underutilized router experiences a SYN flood, then the router would underutilized router experiences a SYN flood, then the router would
begin to deny Rate Request requests, even if the router remains begin to deny Rate Request requests, even if the router remains
underutilized. underutilized.
* If the router's output link has been underutilized and the * If the router's output link has been underutilized and the
aggregate Quick Start Request Rate options granted is low enough to aggregate Quick Start Request Rate options granted is low enough to
prevent a near-term bandwidth shortage, then the router could prevent a near-term bandwidth shortage, then the router could
approve the Quick-Start Request. The router could allow an Rate approve the Quick-Start Request.
Request that was a small fraction of the available unused bandwidth
of the output link. Section 8.2 discusses some of the implementation issues in
processing Quick-Start requests at routers. [SAF05] discusses the
range of possible Quick-Start algorithms at the router for deciding
whether to approve a Quick-Start request. In order to explore the
limits of the possible functionality at routers, [SAF05] also
discusses Extreme Quick-Start mechanisms at routers, where the
router would keep per-flow state concerning approved Quick-Start
requests.
3.5. Quick-Start in IP Tunnels 3.5. Quick-Start in IP Tunnels
In this section we consider the effect of IP tunnels on Quick-Start. In this section we consider the effect of IP tunnels on Quick-Start.
In the discussion, we use TTL Diff, defined earlier as the In the discussion, we use TTL Diff, defined earlier as the
difference between the IP TTL and the Quick-Start TTL, mod 256. difference between the IP TTL and the Quick-Start TTL, mod 256.
Recall that the sender considers the Quick-Start request approved if Recall that the sender considers the Quick-Start request approved if
the value of TTL Diff for the packet entering the network is the 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. same as the value of TTL Diff for the packet exiting the network.
skipping to change at page 19, line 29 skipping to change at page 19, line 37
assess the available capacity on the network path. assess the available capacity on the network path.
Of the above, this document recommends that a TCP MAY attempt to use Of the above, this document recommends that a TCP MAY attempt to use
Quick-Start in cases (1) and (2). Cases (3) and (4) require Quick-Start in cases (1) and (2). Cases (3) and (4) require
external notifications not presently defined for TCP or other external notifications not presently defined for TCP or other
transport protocols. Case (5) requires further thought and transport protocols. Case (5) requires further thought and
investigation with regard to how the transport protocol could detect investigation with regard to how the transport protocol could detect
it was in a situation that would warrant transmitting a Quick-Start it was in a situation that would warrant transmitting a Quick-Start
Rate Request. Rate Request.
Section 4.6 discusses some of the issues of using Quick-Start at
connection initiation, and Section 4.7 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 4.2. The Quick-Start Response Option in the TCP header
TCP's Quick-Start Response option is defined as follows: TCP's Quick-Start Response option is defined as follows:
0 1 2 3 0 1 2 3
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| Kind | Length=4 | Rate | TTL | | Kind | Length=4 | Rate | TTL |
| | | Request | Diff | | | | Request | Diff |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
skipping to change at page 21, line 4 skipping to change at page 21, line 19
first checks that the Quick-Start Response is valid. The Quick- first checks that the Quick-Start Response is valid. The Quick-
Start Response is valid if it contains the correct value for the TTL 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 Diff, and an equal or lesser value for the Rate Request than that
transmitted in the Quick-Start Request. If this check is not transmitted in the Quick-Start Request. If this check is not
successful, then the Quick-Start request failed, and the TCP host successful, then the Quick-Start request failed, and the TCP host
MUST use the default TCP congestion window that it would have used MUST use the default TCP congestion window that it would have used
without Quick-Start. without Quick-Start.
If the checks of the TTL Diff and the Rate Request are successful, If the checks of the TTL Diff and the Rate Request are successful,
then the TCP host sets its Quick-Start congestion window (in terms then the TCP host sets its Quick-Start congestion window (in terms
of MSS-sized segments), QS_cwnd, as follows: of MSS-sized segments), QS-cwnd, as follows:
QS_cwnd = (R * T) / (MSS + H) (2) QS-cwnd = (R * T) / (MSS + H) (2)
where R the Rate Request in bytes per second, T the measured round- where R the Rate Request in bytes per second, T the measured round-
trip time in seconds, and H the estimated header size in bytes trip time in seconds, and H the estimated header size in bytes
(e.g., 40 bytes). [Derivation: the sender gets R bytes per second (e.g., 40 bytes). [Derivation: the sender gets R bytes per second
including packet headers, but only R*MSS/(MSS+H) 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 or equivalently R*T*MSS/(MSS+H) bytes per round-trip time, of
application data.] The TCP host sets its congestion window cwnd to application data.] The TCP host sets its congestion window cwnd to
QS-cwnd only if QS-cwnd is greater than cwnd; otherwise QS-cwnd is 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 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 uses Quick-Start mode, and while in Quick-Start mode the TCP sender uses
skipping to change at page 21, line 40 skipping to change at page 22, line 6
If the Quick-Start mode ends with all Quick-Start packets being If the Quick-Start mode ends with all Quick-Start packets being
successfully acknowledged, the TCP sender returns to using the successfully acknowledged, the TCP sender returns to using the
default congestion control mechanisms. After all the packets are default congestion control mechanisms. After all the packets are
acknowledged from a Quick-Start request for an initial window, for acknowledged from a Quick-Start request for an initial window, for
example, the TCP sender remains in slow-start, if permitted by example, the TCP sender remains in slow-start, if permitted by
ssthresh, continuing to increase its congestion window rather ssthresh, continuing to increase its congestion window rather
aggressively from one round-trip time to the next. To add aggressively from one round-trip time to the next. To add
robustness, the TCP sender is required to use Limited Slow-Start robustness, the TCP sender is required to use Limited Slow-Start
along with Quick-Start. With Limited Slow-Start, the TCP sender along with Quick-Start. With Limited Slow-Start, the TCP sender
limits the number of packets by which the congestion window is limits the number of packets by which the congestion window is
increased for one window of data during slow-start [F02a]. increased for one window of data during slow-start [F04].
4.5. TCP: Responding to a Loss of a Quick-Start Packet 4.5. TCP: Responding to a Loss of a Quick-Start Packet
For TCP, we have defined a ``Quick-Start packet'' as one of the For TCP, we have defined a ``Quick-Start packet'' as one of the
packets sent in the window immediately following a successful Quick- packets sent in the window immediately following a successful Quick-
Start request. After detecting the loss of a Quick-Start packet, Start request. After detecting the loss of a Quick-Start packet,
TCP MUST revert to the default congestion control procedures that TCP MUST revert to the default congestion control procedures that
would have been used if the Quick-Start request had not been would have been used if the Quick-Start request had not been
approved. For example, if Quick-Start is used for setting the approved. For example, if Quick-Start is used for setting the
initial window, and a packet from the initial window is lost, then initial window, and a packet from the initial window is lost, then
skipping to change at page 22, line 23 skipping to change at page 22, line 36
4.6. TCP: A Quick-Start Request for a Larger Initial Window 4.6. TCP: A Quick-Start Request for a Larger Initial Window
Some of the issues of using Quick-Start are related to the specific Some of the issues of using Quick-Start are related to the specific
scenario in which Quick-Start is used. This section discusses the scenario in which Quick-Start is used. This section discusses the
following issues that arise when Quick-Start is used by TCP to following issues that arise when Quick-Start is used by TCP to
request a larger initial window: (1) determining the rate to request a larger initial window: (1) determining the rate to
request; (2) interactions with Path MTU Discovery; and (3) Quick- request; (2) interactions with Path MTU Discovery; and (3) Quick-
Start request packets that are eaten by middleboxes. Start request packets that are eaten by middleboxes.
(1) Determining the rate to request: (1) Determining the rate to request:
When Quick-Start is requested by TCP connections at web servers (or As discussed in [SAF05], the data sender does not necessarily have
at server-related middleboxes), the web server knows the amount of information about the size of the data transfer at connection
data ready to be transferred, along with the history of successful initiation; for example, in request-response protocols such as HTTP,
and unsuccessful Quick-Start requests, and can use this information the server doesn't know the size or name of the requested object
in choosing Rate Requests. In the absence of other information, during connection initiation. [SAF05] explores some of the
there could be a configured value for the Quick-Start Rate Request. performance implications of overly-large Quick-Start requests, and
Quick-Start will be more effective if Quick-Start requests are not discusses heuristics that end-nodes could use to size their requests
larger than necessary; every Quick-Start request that is approved appropriately.
but not used takes away from the bandwidth pool available for
granting successive Quick-Start requests. Therefore, it is In the absence of other information, there could be a configured
recommended that the request for the initial sending rate be value for the Quick-Start Rate Request. Quick-Start will be more
somewhat conservative, in order to improve the chances for more effective if Quick-Start requests are not larger than necessary;
Quick-Start requests to be approved. every Quick-Start request that is approved but not used takes away
from the bandwidth pool available for granting successive Quick-
Start requests. Therefore, it is recommended that the request for
the initial sending rate be somewhat conservative, in order to
improve the chances for more Quick-Start requests to be approved.
(2) Interactions with Path MTU Discovery: (2) Interactions with Path MTU Discovery:
A second issue when Quick-Start is used to request a large initial A second issue when Quick-Start is used to request a large initial
window concerns the interactions between the large initial window window concerns the interactions between the large initial window
and Path MTU Discovery. Some of the issues are discussed in RFC and Path MTU Discovery. Some of the issues are discussed in RFC
3390: 3390:
"When larger initial windows are implemented along with Path MTU "When larger initial windows are implemented along with Path MTU
Discovery [RFC1191], alternatives are to set the "Don't Discovery [RFC1191], alternatives are to set the "Don't
Fragment" (DF) bit in all segments in the initial window, or to Fragment" (DF) bit in all segments in the initial window, or to
skipping to change at page 30, line 4 skipping to change at page 30, line 22
Thus, careful thought would have to be given to the addition of Thus, careful thought would have to be given to the addition of
Quick-Start to IP. Quick-Start to IP.
The slow path in routers: The slow path in routers:
Another drawback of Quick-Start is that packets containing the Another drawback of Quick-Start is that packets containing the
Quick-Start Request message might not take the fast path in routers. Quick-Start Request message might not take the fast path in routers.
This would mean extra delay for the end hosts, and extra processing This would mean extra delay for the end hosts, and extra processing
burden for the routers. This extra burden is mitigated somewhat by burden for the routers. This extra burden is mitigated somewhat by
the following factors: only very few packets would carry the Quick- the following factors: only very few packets would carry the Quick-
Start Request option; very small flows of, say, one to five packets Start Request option; very small flows of, say, one to five packets
would receive little benefit from Quick-Start, and presumeably would would receive little benefit from Quick-Start, and presumably would
not use the Quick-Start Request; flows from end hosts with low- not use the Quick-Start Request; flows from end hosts with low-
bandwidth access links would receive little benefit from Quick- bandwidth access links would receive little benefit from Quick-
Start, and hopefully could be configured not to use the Quick-Start Start, and hopefully could be configured not to use the Quick-Start
Request. In addition, in typical environments where most of the Request. In addition, in typical environments where most of the
packets belong to large flows, the burden of the Quick-Start Option packets belong to large flows, the burden of the Quick-Start Option
on routers would be considerably reduced. Nevertheless, it is still on routers would be considerably reduced. Nevertheless, it is still
conceiveable, in the worst case, that up to 10% of the packets were conceivable, in the worst case, that up to 10% of the packets were
Quick-Start packets, and this could slow down the processing of Quick-Start packets, and this could slow down the processing of
Quick-Start packets in routers considerably. In particular, because Quick-Start packets in routers considerably. In particular, because
many Quick-Start packets are likely to be TCP SYN or SYN/ACK many Quick-Start packets are likely to be TCP SYN or SYN/ACK
packets, the slow processing of Quick-Start packets would slow down packets, the slow processing of Quick-Start packets would slow down
the establishment of the corresponding TCP connections. the establishment of the corresponding TCP connections.
Multiple paths: Multiple paths:
One limitation of Quick-Start is that it presumes that the data One limitation of Quick-Start is that it presumes that the data
packets of a connection will follow the same path as the Quick-Start packets of a connection will follow the same path as the Quick-Start
request packet. If this is not the case, then the connection could request packet. If this is not the case, then the connection could
skipping to change at page 33, line 17 skipping to change at page 33, line 34
Of course, if the congested router was ECN-capable, and the Of course, if the congested router was ECN-capable, and the
colluding ingress and egress routers were lying about ECN-capability colluding ingress and egress routers were lying about ECN-capability
as well as about Quick-Start, then the result could be that the as well as about Quick-Start, then the result could be that the
Quick-Start request falsely appears to the sender to have been Quick-Start request falsely appears to the sender to have been
approved, the Quick-Start packets falsely appear to the congested approved, the Quick-Start packets falsely appear to the congested
router to be ECN-capable, and the colluding routers succeed in router to be ECN-capable, and the colluding routers succeed in
giving a competitive advantage to the traffic protected by their giving a competitive advantage to the traffic protected by their
collusion. collusion.
Misbehaving middleboxes:
A separate possibility is that of traffic normalizers or other
middleboxes along that path that re-write IP TTLs, in order to foil
other kinds of attacks in the network. If such a traffic normalizer
re-wrote the IP TTL, but did not adjust the Quick-Start TTL by the
same amount, then the sender's mechanism for determining if the
request was approved by all routers along the path would no longer
be reliable. Re-writing the IP TTL could result in false positives
(with the sender incorrectly believing that the Quick-Start request
was approved) as well as false negatives (with the sender
incorrectly believing that the Quick-Start request was denied).
6.4. Quick-Start with QoS-enabled Traffic 6.4. Quick-Start with QoS-enabled Traffic
The discussion in this paper has largely been of Quick-Start with The discussion in this paper has largely been of Quick-Start with
default, best-effort traffic. However, Quick-Start could also be default, best-effort traffic. However, Quick-Start could also be
used by traffic using some form of differentiated services, and used by traffic using some form of differentiated services, and
routers could take the traffic class into account when deciding routers could take the traffic class into account when deciding
whether or not to grant the Quick-Start request. We don't address whether or not to grant the Quick-Start request. We don't address
this context further in this paper, since it is orthogonal to the this context further in this paper, since it is orthogonal to the
specification of Quick-Start. However, we note that routers should specification of Quick-Start. However, we note that routers should
be discouraged from granting Quick-Start requests for higher- be discouraged from granting Quick-Start requests for higher-
priority traffic when this is likely to result in significant packet priority traffic when this is likely to result in significant packet
loss for lower-priority traffic. loss for lower-priority traffic.
6.5. Limitations of Quick-Start 6.5. Limitations of Quick-Start
The Quick-Start proposal, taken together with the recent proposal The Quick-Start proposal, taken together with the recent proposal
for HighSpeed TCP [F02], could go a significant way towards for HighSpeed TCP [F03], could go a significant way towards
extending the range of performance for best-effort traffic in the extending the range of performance for best-effort traffic in the
Internet. However, there are many things that the Quick-Start Internet. However, there are many things that the Quick-Start
proposal would not accomplish. Quick-Start is not a congestion proposal would not accomplish. Quick-Start is not a congestion
control mechanism, and would not help in making more precise use of control mechanism, and would not help in making more precise use of
the available bandwidth, that is, of achieving the goal of very high the available bandwidth, that is, of achieving the goal of very high
throughput with very low delay and very low packet loss rates. throughput with very low delay and very low packet loss rates.
Quick-Start would not give routers more control over the decrease Quick-Start would not give routers more control over the decrease
rates of active connections. One of the open questions addressed rates of active connections. One of the open questions addressed
later in this document is whether the limited capabilities of Quick- later in this document is whether the limited capabilities of Quick-
Start are sufficient to warrant standardization and deployment, or Start are sufficient to warrant standardization and deployment, or
whether more work is needed to explore the space of potential whether more work is needed to explore the space of potential
mechanisms. mechanisms.
6.6. Simulations with Quick-Start 6.6. Attacks on Quick-Start
As discussed in [SAF05], Quick-Start is vulnerable to two kinds of
Quick-Start attacks: (1) attacks to increase the routers'
processing and state load; and (2) attacks with bogus Quick-Start
requests to temporarily tie up available Quick-Start bandwidth,
preventing routers from approving Quick-Start requests from other
connections. Routers can protect against the first kind of attack
by applying a simple limit on the rate at which Quick-Start requests
will be considered by the router. The second kind of attack, which
is more difficult to defend against, is discussed in more detail in
[SAF05].
6.7. Simulations with Quick-Start
Quick-Start was added to the NS simulator [SH02] by Srikanth Quick-Start was added to the NS simulator [SH02] by Srikanth
Sundarrajan, and additional functionality was added by Pasi Sundarrajan, and additional functionality was added by Pasi
Sarolahti. The validation test is at `test-all-quickstart' in the Sarolahti. The validation test is at `test-all-quickstart' in the
'tcl/test' directory in NS. The initial simulation studies from 'tcl/test' directory in NS. The initial simulation studies from
[SH02] show a significant performance improvement using Quick-Start [SH02] show a significant performance improvement using Quick-Start
for moderate-sized flows (between 4KB and 128KB) in under-utilized for moderate-sized flows (between 4KB and 128KB) in under-utilized
environments. These studies are of file transfers, with the environments. These studies are of file transfers, with the
improvement measured as the relative increase in the overall improvement measured as the relative increase in the overall
throughput for the file transfer. The study shows that potential throughput for the file transfer. The study shows that potential
improvement from Quick-Start is proportional to the delay-bandwidth improvement from Quick-Start is proportional to the delay-bandwidth
product of the path. product of the path.
The Quick-Start simulations in [SAF05] explore the following: the
potential benefit of Quick-Start for the connection; the relative
benefits of different router-based algorithms for approving Quick-
Start requests; and the effectiveness of Quick-Start as a function
of the senders' algorithms for choosing the size of the rate
request. [SAF05] also consideres the potential of Extreme Quick-
Start algorithms at routers, which keep per-flow state at routers
for Quick-Start connections, in protecting the availability of
Quick-Start bandwidth in the face of frequent overly-larqe Quick-
Start requests.
7. Related Work 7. Related Work
Any evaluation of Quick-Start must include a discussion of the Any evaluation of Quick-Start must include a discussion of the
relative benefits of approaches that use no explicit information relative benefits of approaches that use no explicit information
from routers, and of approaches that use more fine-grained feedback from routers, and of approaches that use more fine-grained feedback
from routers as part of a larger congestion control mechanism. We from routers as part of a larger congestion control mechanism. We
discuss three classes of proposals (no explicit feedback from discuss three classes of proposals (no explicit feedback from
routers; explicit feedback about the initial rate; and more fine- routers; explicit feedback about the initial rate; and more fine-
grained feedback from routers) in the sections below. grained feedback from routers) in the sections below.
skipping to change at page 38, line 27 skipping to change at page 39, line 27
before a connection is established. Some applications, such those before a connection is established. Some applications, such those
that use TCP for bulk transfers, do not have interest in the that use TCP for bulk transfers, do not have interest in the
transmission rate, but they might know the amount of data that can transmission rate, but they might know the amount of data that can
be sent immediately. Based on this, the sender implementation could be sent immediately. Based on this, the sender implementation could
decide whether Quick-Start would be useful, and what rate should be decide whether Quick-Start would be useful, and what rate should be
requested. Datagram-based real-time streaming applications, on the requested. Datagram-based real-time streaming applications, on the
other hand, may have a specific preference on the transmission rate other hand, may have a specific preference on the transmission rate
and they could indicate the required rate explicitly to the and they could indicate the required rate explicitly to the
transport protocol to be used in the Quick-Start Request. transport protocol to be used in the Quick-Start Request.
We note that when Quick-Start is used, the TCP sender is required to
implement an additional timer for the paced transmission of Quick-
Start packets.
8.2. Implementation Issues for Processing Quick-Start Requests 8.2. Implementation Issues for Processing Quick-Start Requests
A router or other network host must be able to determine the A router or other network host must be able to determine the
approximate bandwidth of its outbound network interfaces in order to approximate bandwidth of its outbound network interfaces in order to
process incoming Quick-Start rate requests, including those that process incoming Quick-Start rate requests, including those that
originate from the host itself. One possibility would be for hosts originate from the host itself. One possibility would be for hosts
to rely on configuration information to determine link bandwidths; to rely on configuration information to determine link bandwidths;
this has the drawback of not being robust to errors in this has the drawback of not being robust to errors in
configuration. Another possibility would be for network device configuration. Another possibility would be for network device
drivers to infer the bandwidth for the interface and to communicate drivers to infer the bandwidth for the interface and to communicate
skipping to change at page 41, line 14 skipping to change at page 42, line 15
11. Acknowledgements 11. Acknowledgements
The authors wish to thank Mark Handley for discussions of these The authors wish to thank Mark Handley for discussions of these
issues. The authors also thank the End-to-End Research Group, the issues. The authors also thank the End-to-End Research Group, the
Transport Services Working Group, and members of IPAM's program on Transport Services Working Group, and members of IPAM's program on
Large Scale Communication Networks for both positive and negative Large Scale Communication Networks for both positive and negative
feedback on this proposal. We thank Srikanth Sundarrajan for the feedback on this proposal. We thank Srikanth Sundarrajan for the
initial implementation of Quick-Start in the NS simulator, and for initial implementation of Quick-Start in the NS simulator, and for
the initial simulation study. We also thank Mohammed Ashraf, John the initial simulation study. We also thank Mohammed Ashraf, John
Border, Tom Dunigan, John Heidemann, Dina Katabi, and Vern Paxson Border, Tom Dunigan, John Heidemann, Paul Hyder, Dina Katabi, and
for feedback. This draft builds upon the concepts described in Vern Paxson for feedback. This draft builds upon the concepts
[RFC3390], [AHO98], [RFC2415], and [RFC3168]. described in [RFC3390], [AHO98], [RFC2415], and [RFC3168].
This is a modification of a draft originally by Amit Jain for This is a modification of a draft originally by Amit Jain for
Initial Window Discovery. Initial Window Discovery.
A. Design Decisions A. Design Decisions
A.1. Alternate Mechanisms for the Quick-Start Request: ICMP and RSVP A.1. Alternate Mechanisms for the Quick-Start Request: ICMP and RSVP
This document has proposed using an IP Option for the Quick-Start This document has proposed using an IP Option for the Quick-Start
Request from the sender to the receiver, and using transport Request from the sender to the receiver, and using transport
skipping to change at page 49, line 48 skipping to change at page 51, line 10
tends to favor the incremental deployment of relatively simple tends to favor the incremental deployment of relatively simple
mechanisms, as long as the simple mechanisms are not short-term mechanisms, as long as the simple mechanisms are not short-term
hacks but mechanisms that lead the overall architecture in the hacks but mechanisms that lead the overall architecture in the
fundamentally correct direction. fundamentally correct direction.
A.7. A QuickStart Nonce? A.7. A QuickStart Nonce?
An earlier version of this document included a QuickStart Nonce that An earlier version of this document included a QuickStart Nonce that
was initialized by the sender to a non-zero, `random' eight-bit was initialized by the sender to a non-zero, `random' eight-bit
number, along with a QS TTL that was initialized to the same value number, along with a QS TTL that was initialized to the same value
at the TTL in the IP header. The QuickStart Nonce would have been as the TTL in the IP header. The QuickStart Nonce would have been
returned by the TCP receiver to the TCP sender in the Quick-Start returned by the TCP receiver to the TCP sender in the Quick-Start
Response. A router could deny the Quick-Start request by failing to Response. A router could deny the Quick-Start request by failing to
decrement the QS TTL field, by zeroing the QS Nonce field, or by decrement the QS TTL field, by zeroing the QS Nonce field, or by
deleting the Quick-Start Request from the packet header. The QS deleting the Quick-Start Request from the packet header. The QS
Nonce was included to provide some protection against broken Nonce was included to provide some protection against broken
downstream routers, or against misbehaving TCP receivers who might downstream routers, or against misbehaving TCP receivers who might
be inclined to lie about the Rate Request. This protection is now be inclined to lie about the Rate Request. This protection is now
provided by the use of a random initial value for the QS TTL field. provided by the use of a random initial value for the QS TTL field.
With the old QuickStart Nonce, along with the QS TTL field set to With the old QuickStart Nonce, along with the QS TTL field set to
skipping to change at page 52, line 20 skipping to change at page 53, line 24
1998. 1998.
[BW97] G. Brasche and B. Walke. Concepts, Services and Protocols of [BW97] G. Brasche and B. Walke. Concepts, Services and Protocols of
the new GSM Phase 2+ General Packet Radio Service. IEEE the new GSM Phase 2+ General Packet Radio Service. IEEE
Communications Magazine, pages 94--104, August 1997. Communications Magazine, pages 94--104, August 1997.
[FF99] Floyd, S., and Fall, K., Promoting the Use of End-to-End [FF99] Floyd, S., and Fall, K., Promoting the Use of End-to-End
Congestion Control in the Internet, IEEE/ACM Transactions on Congestion Control in the Internet, IEEE/ACM Transactions on
Networking, August 1999. Networking, August 1999.
[F02] Floyd, S., HighSpeed TCP for Large Congestion Windows, [F03] Floyd, S., HighSpeed TCP for Large Congestion Windows, RFC
internet-draft draft-floyd-tcp-highspeed-01.txt, work in progress, 3649, December 2003.
August 2002.
[F02a] Floyd, S., Limited Slow-Start for TCP with Large Congestion [F04] Floyd, S., Limited Slow-Start for TCP with Large Congestion
Windows, internet-draft draft draft-floyd-tcp-slowstart-01.txt, work Windows, RFC 3742, Experimental, March 2004.
in progress, August 2002.
[GPAR02] A. Gurtov, M. Passoja, O. Aalto, and M. Raitola. Multi- [GPAR02] A. Gurtov, M. Passoja, O. Aalto, and M. Raitola. Multi-
Layer Protocol Tracing in a GPRS Network. In Proceedings of the IEEE Layer Protocol Tracing in a GPRS Network. In Proceedings of the IEEE
Vehicular Technology Conference (Fall VTC2002), Vancouver, Canada, Vehicular Technology Conference (Fall VTC2002), Vancouver, Canada,
September 2002. September 2002.
[Jac88] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM [Jac88] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM
[JD02] Manish Jain, Constantinos Dovrolis, End-to-End Available [JD02] Manish Jain, Constantinos Dovrolis, End-to-End Available
Bandwidth: Measurement Methodology, Dynamics, and Relation with TCP Bandwidth: Measurement Methodology, Dynamics, and Relation with TCP
Throughput, SIGCOMM 2002. Throughput, SIGCOMM 2002.
[KHR02] Dina Katabi, Mark Handley, and Charles Rohrs, Internet [KHR02] Dina Katabi, Mark Handley, and Charles Rohrs, Internet
Congestion Control for Future High Bandwidth-Delay Product Congestion Control for Future High Bandwidth-Delay Product
Environments. ACM Sigcomm 2002, August 2002. URL Environments. ACM Sigcomm 2002, August 2002. URL
"http://ana.lcs.mit.edu/dina/XCP/". "http://ana.lcs.mit.edu/dina/XCP/".
[KHF04] E. Kohler, M. Handley, and S. Floyd, Datagram Congestion [KHF04] E. Kohler, M. Handley, and S. Floyd, Datagram Congestion
Control Protocol (DCCP), internet draft draft-ietf-dccp-spec-07.txt, Control Protocol (DCCP), internet draft draft-ietf-dccp-spec-09.txt,
work in progress, July 2004. work in progress, November 2004.
[K03] S. Kunniyur, "AntiECN Marking: A Marking Scheme for High [K03] S. Kunniyur, "AntiECN Marking: A Marking Scheme for High
Bandwidth Delay Connections", Proceedings, IEEE ICC '03, May 2003. Bandwidth Delay Connections", Proceedings, IEEE ICC '03, May 2003.
URL "http://www.seas.upenn.edu/~kunniyur/". URL "http://www.seas.upenn.edu/~kunniyur/".
[KAPS02] Rajesh Krishnan, Mark Allman, Craig Partridge, James P.G. [KAPS02] Rajesh Krishnan, Mark Allman, Craig Partridge, James P.G.
Sterbenz. Explicit Transport Error Notification (ETEN) for Error- Sterbenz. Explicit Transport Error Notification (ETEN) for Error-
Prone Wireless and Satellite Networks. Technical Report No. 8333, Prone Wireless and Satellite Networks. Technical Report No. 8333,
BBN Technologies, March 2002. URL BBN Technologies, March 2002. URL
"http://roland.lerc.nasa.gov/~mallman/papers/". "http://roland.lerc.nasa.gov/~mallman/papers/".
[MAF04] Alberto Medina, Mark Allman, and Sally Floyd, Measuring [MAF04] Alberto Medina, Mark Allman, and Sally Floyd, Measuring
Interactions Between Transport Protocols and Middleboxes, Internet Interactions Between Transport Protocols and Middleboxes, Internet
Measurement Conference 2004, August 2004. URL Measurement Conference 2004, August 2004. URL
"http://www.icir.org/tbit/". "http://www.icir.org/tbit/".
skipping to change at page 53, line 31 skipping to change at page 54, line 34
acknowledgement purposes only. acknowledgement purposes only.
[PRAKS02] Craig Partridge, Dennis Rockwell, Mark Allman, Rajesh [PRAKS02] Craig Partridge, Dennis Rockwell, Mark Allman, Rajesh
Krishnan, James P.G. Sterbenz. A Swifter Start for TCP. Technical Krishnan, James P.G. Sterbenz. A Swifter Start for TCP. Technical
Report No. 8339, BBN Technologies, March 2002. URL Report No. 8339, BBN Technologies, March 2002. URL
"http://roland.lerc.nasa.gov/~mallman/papers/". "http://roland.lerc.nasa.gov/~mallman/papers/".
[S02] Ion Stoica, private communication, 2002. Citation for [S02] Ion Stoica, private communication, 2002. Citation for
acknowledgement purposes only. acknowledgement purposes only.
[SAF05] Pasi Sarolahti, Mark Allman, and Sally Floyd. Evaluating
Quick-Start for TCP. Under submission, February 2005. URL
"http://www.icir.org/floyd/quickstart.html".
[SH02] Srikanth Sundarrajan and John Heidemann. Study of TCP Quick [SH02] Srikanth Sundarrajan and John Heidemann. Study of TCP Quick
Start with NS-2. Class Project, December 2002. Not publically Start with NS-2. Class Project, December 2002. Not publically
available; citation for acknowledgement purposes only. available; citation for acknowledgement purposes only.
[W00] Michael Welzl: PTP: Better Feedback for Adaptive Distributed [W00] Michael Welzl: PTP: Better Feedback for Adaptive Distributed
Multimedia Applications on the Internet, IPCCC 2000 (19th IEEE Multimedia Applications on the Internet, IPCCC 2000 (19th IEEE
International Performance, Computing, And Communications International Performance, Computing, And Communications
Conference), Phoenix, Arizona, USA, 20-22 February 2000. URL Conference), Phoenix, Arizona, USA, 20-22 February 2000. URL
"http://informatik.uibk.ac.at/users/c70370/research/publications/". "http://informatik.uibk.ac.at/users/c70370/research/publications/".
 End of changes. 41 change blocks. 
77 lines changed or deleted 144 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/