draft-ietf-tsvwg-quickstart-06.txt   draft-ietf-tsvwg-quickstart-07.txt 
Internet Engineering Task Force S. Floyd Internet Engineering Task Force S. Floyd
INTERNET-DRAFT M. Allman INTERNET-DRAFT M. Allman
draft-ietf-tsvwg-quickstart-06.txt ICIR draft-ietf-tsvwg-quickstart-07.txt ICIR
Expires: February 2007 A. Jain Expires: April 2007 A. Jain
F5 Networks F5 Networks
P. Sarolahti P. Sarolahti
Nokia Research Center Nokia Research Center
30 August 2006 9 October 2006
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, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 2007. This Internet-Draft will expire on April 2007.
Abstract Abstract
This document specifies an optional Quick-Start mechanism for This document specifies an optional Quick-Start mechanism for
transport protocols, in cooperation with routers, to determine an transport protocols, in cooperation with routers, to determine an
allowed sending rate at the start and at times in the middle of a 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 data transfer (e.g., after an idle period). While Quick-Start is
designed to be used by a range of transport protocols, in this designed to be used by a range of transport protocols, in this
document we only specify its use with TCP. Quick-Start is designed document we only specify its use with TCP. Quick-Start is designed
to allow connections to use higher sending rates when there is to allow connections to use higher sending rates when there is
skipping to change at page 3, line 7 skipping to change at page 3, line 7
by all of the routers along the path. As a result of these 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 concerns, and as a result of the difficulties and seeming absence of
motivation for routers such as core routers to deploy Quick-Start, 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 Quick-Start is being proposed as a mechanism that could be of use in
controlled environments, and not as a mechanism that would be controlled environments, and not as a mechanism that would be
intended or appropriate for ubiquitous deployment in the global intended or appropriate for ubiquitous deployment in the global
Internet. Internet.
TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION:
Changes from draft-ietf-tsvwg-quickstart-06:
* Changes in reponse to the review from the
General Area Review Team:
- Added text to Overview about the role of TCP feedback.
- Updated the flow label discussion from RFC2460 to RFC3697.
- Instead of saying that the router SHOULD remove the QS Option
when denying a request, but MAY zero fields instead,
said that the router SHOULD either remove the QS option
or zero the fields.
- Fixed typos and clarified some text.
* Still needs feedback from the ipv6 or v6ops community;
- perhaps also have IPv6 people read the discussion of
end-point address changes in Section 4.1.
Changes from draft-ietf-tsvwg-quickstart-05: Changes from draft-ietf-tsvwg-quickstart-05:
* Minor editing in response to AD feedback from * Minor editing in response to AD feedback from
Lars Eggert. Lars Eggert.
This includes changing one "should" to "SHOULD", This includes changing one "should" to "SHOULD",
and changing formating of the IANA Considerations and changing formatting of the IANA Considerations
section. section.
* Clarifying in the Introduction that the QS router * Clarifying in the Introduction that the QS router
does not give preferential treatment to QS packets. does not give preferential treatment to QS packets.
In response to email from Fil Dickinson. In response to email from Fil Dickinson.
* Added a discussion of interactions between * Added a discussion of interactions between
Quick-Start and draft-ietf-pmtud-method. In Quick-Start and draft-ietf-pmtud-method. In
response to AD Feedback from Lars Eggert. response to AD Feedback from Lars Eggert.
skipping to change at page 9, line 22 skipping to change at page 9, line 22
3.1. The Quick-Start Option for IPv4. . . . . . . . . . . . . 17 3.1. The Quick-Start Option for IPv4. . . . . . . . . . . . . 17
3.2. The Quick-Start Option for IPv6. . . . . . . . . . . . . 21 3.2. The Quick-Start Option for IPv6. . . . . . . . . . . . . 21
3.3. Processing the Quick-Start Request at 3.3. Processing the Quick-Start Request at
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.1. Processing the Report of Approved 3.3.1. Processing the Report of Approved
Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4. The QS Nonce . . . . . . . . . . . . . . . . . . . . . . 24 3.4. The QS Nonce . . . . . . . . . . . . . . . . . . . . . . 24
4. The Quick-Start Mechanisms in TCP . . . . . . . . . . . . . . 26 4. The Quick-Start Mechanisms in TCP . . . . . . . . . . . . . . 26
4.1. Sending the Quick-Start Request. . . . . . . . . . . . . 27 4.1. Sending the Quick-Start Request. . . . . . . . . . . . . 27
4.2. The Quick-Start Response Option in the TCP 4.2. The Quick-Start Response Option in the TCP
header. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 header. . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3. TCP: Sending the Quick-Start Response. . . . . . . . . . 30 4.3. TCP: Sending the Quick-Start Response. . . . . . . . . . 29
4.4. TCP: Receiving and Using the Quick-Start 4.4. TCP: Receiving and Using the Quick-Start
Response Packet . . . . . . . . . . . . . . . . . . . . . . . 30 Response Packet . . . . . . . . . . . . . . . . . . . . . . . 30
4.5. TCP: Controlling Acknowledgement Traffic on 4.5. TCP: Controlling Acknowledgement Traffic on
the Reverse Path . . . . . . . . . . . . . . . . . . . . . . 33 the Reverse Path . . . . . . . . . . . . . . . . . . . . . . 32
4.6. TCP: Responding to a Loss of a Quick-Start 4.6. TCP: Responding to a Loss of a Quick-Start
Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.7. TCP: A Quick-Start Request for a Larger Ini- 4.7. TCP: A Quick-Start Request for a Larger Ini-
tial Window . . . . . . . . . . . . . . . . . . . . . . . . . 35 tial Window . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.7.1. Interactions with Path MTU Discovery. . . . . . . . 35 4.7.1. Interactions with Path MTU Discovery. . . . . . . . 34
4.7.2. Quick-Start Request Packets that are 4.7.2. Quick-Start Request Packets that are
Discarded by Routers or Middleboxes. . . . . . . . . . . . 36 Discarded by Routers or Middleboxes. . . . . . . . . . . . 35
4.8. TCP: A Quick-Start Request in the Middle of 4.8. TCP: A Quick-Start Request in the Middle of
a Connection. . . . . . . . . . . . . . . . . . . . . . . . . 37 a Connection. . . . . . . . . . . . . . . . . . . . . . . . . 36
4.9. An Example Quick-Start Scenario with TCP . . . . . . . . 38 4.9. An Example Quick-Start Scenario with TCP . . . . . . . . 37
5. Quick-Start and IPsec AH. . . . . . . . . . . . . . . . . . . 39 5. Quick-Start and IPsec AH. . . . . . . . . . . . . . . . . . . 38
6. Quick-Start in IP Tunnels and MPLS. . . . . . . . . . . . . . 39 6. Quick-Start in IP Tunnels and MPLS. . . . . . . . . . . . . . 39
6.1. Simple Tunnels That Are Compatible with 6.1. Simple Tunnels That Are Compatible with
Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 41 Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.1.1. Simple Tunnels that are Aware of Quick- 6.1.1. Simple Tunnels that are Aware of Quick-
Start. . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Start. . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.2. Simple Tunnels That Are Not Compatible with 6.2. Simple Tunnels That Are Not Compatible with
Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 42 Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.3. Tunnels That Support Quick-Start . . . . . . . . . . . . 43 6.3. Tunnels That Support Quick-Start . . . . . . . . . . . . 43
6.4. Quick-Start and MPLS . . . . . . . . . . . . . . . . . . 44 6.4. Quick-Start and MPLS . . . . . . . . . . . . . . . . . . 44
7. The Quick-Start Mechanism in other Transport Pro- 7. The Quick-Start Mechanism in other Transport Pro-
tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
8. Using Quick-Start . . . . . . . . . . . . . . . . . . . . . . 46 8. Using Quick-Start . . . . . . . . . . . . . . . . . . . . . . 45
8.1. Determining the Rate to Request. . . . . . . . . . . . . 46 8.1. Determining the Rate to Request. . . . . . . . . . . . . 45
8.2. Deciding the Permitted Rate Request at a 8.2. Deciding the Permitted Rate Request at a
Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
9. Evaluation of Quick-Start . . . . . . . . . . . . . . . . . . 47 9. Evaluation of Quick-Start . . . . . . . . . . . . . . . . . . 46
9.1. Benefits of Quick-Start. . . . . . . . . . . . . . . . . 47 9.1. Benefits of Quick-Start. . . . . . . . . . . . . . . . . 46
9.2. Costs of Quick-Start . . . . . . . . . . . . . . . . . . 48 9.2. Costs of Quick-Start . . . . . . . . . . . . . . . . . . 47
9.3. Quick-Start with QoS-enabled Traffic . . . . . . . . . . 49 9.3. Quick-Start with QoS-enabled Traffic . . . . . . . . . . 49
9.4. Protection against Misbehaving Nodes . . . . . . . . . . 50 9.4. Protection against Misbehaving Nodes . . . . . . . . . . 49
9.4.1. Misbehaving Senders . . . . . . . . . . . . . . . . 50 9.4.1. Misbehaving Senders . . . . . . . . . . . . . . . . 49
9.4.2. Receivers Lying about Whether the 9.4.2. Receivers Lying about Whether the
Request was Approved . . . . . . . . . . . . . . . . . . . 51 Request was Approved . . . . . . . . . . . . . . . . . . . 51
9.4.3. Receivers Lying about the Approved 9.4.3. Receivers Lying about the Approved
Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
9.4.4. Collusion between Misbehaving Routers . . . . . . . 53 9.4.4. Collusion between Misbehaving Routers . . . . . . . 53
9.5. Misbehaving Middleboxes and the IP TTL . . . . . . . . . 54 9.5. Misbehaving Middleboxes and the IP TTL . . . . . . . . . 54
9.6. Attacks on Quick-Start . . . . . . . . . . . . . . . . . 55 9.6. Attacks on Quick-Start . . . . . . . . . . . . . . . . . 54
9.7. Simulations with Quick-Start . . . . . . . . . . . . . . 55 9.7. Simulations with Quick-Start . . . . . . . . . . . . . . 55
10. Implementation and Deployment Issues . . . . . . . . . . . . 56 10. Implementation and Deployment Issues . . . . . . . . . . . . 55
10.1. Implementation Issues for Sending Quick- 10.1. Implementation Issues for Sending Quick-
Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 56 Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 56
10.2. Implementation Issues for Processing Quick- 10.2. Implementation Issues for Processing Quick-
Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 57 Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 56
10.3. Possible Deployment Scenarios . . . . . . . . . . . . . 57 10.3. Possible Deployment Scenarios . . . . . . . . . . . . . 57
10.4. A Comparison with the Deployment Problems 10.4. A Comparison with the Deployment Problems
of ECN. . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 of ECN. . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
11. Security Considerations. . . . . . . . . . . . . . . . . . . 59 11. Security Considerations. . . . . . . . . . . . . . . . . . . 58
12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 60 12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 60
12.1. IP Option . . . . . . . . . . . . . . . . . . . . . . . 60 12.1. IP Option . . . . . . . . . . . . . . . . . . . . . . . 60
12.2. TCP Option. . . . . . . . . . . . . . . . . . . . . . . 61 12.2. TCP Option. . . . . . . . . . . . . . . . . . . . . . . 60
13. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . 61 13. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . 61
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 61 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 61
A. Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 62 A. Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 62
A.1. Fast Start-ups without Explicit Information A.1. Fast Start-ups without Explicit Information
from Routers. . . . . . . . . . . . . . . . . . . . . . . . . 63 from Routers. . . . . . . . . . . . . . . . . . . . . . . . . 62
A.2. Optimistic Sending without Explicit Informa- A.2. Optimistic Sending without Explicit Informa-
tion from Routers . . . . . . . . . . . . . . . . . . . . . . 64 tion from Routers . . . . . . . . . . . . . . . . . . . . . . 64
A.3. Fast Start-ups with other Information from A.3. Fast Start-ups with other Information from
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
A.4. Fast Start-ups with more Fine-Grained Feed- A.4. Fast Start-ups with more Fine-Grained Feed-
back from Routers . . . . . . . . . . . . . . . . . . . . . . 66 back from Routers . . . . . . . . . . . . . . . . . . . . . . 65
A.5. Fast Start-ups with Lower-Than-Best-Effort A.5. Fast Start-ups with Lower-Than-Best-Effort
Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
B. Design Decisions. . . . . . . . . . . . . . . . . . . . . . . 67 B. Design Decisions. . . . . . . . . . . . . . . . . . . . . . . 66
B.1. Alternate Mechanisms for the Quick-Start B.1. Alternate Mechanisms for the Quick-Start
Request: ICMP and RSVP. . . . . . . . . . . . . . . . . . . . 67 Request: ICMP and RSVP. . . . . . . . . . . . . . . . . . . . 67
B.1.1. ICMP. . . . . . . . . . . . . . . . . . . . . . . . 67 B.1.1. ICMP. . . . . . . . . . . . . . . . . . . . . . . . 67
B.1.2. RSVP. . . . . . . . . . . . . . . . . . . . . . . . 69 B.1.2. RSVP. . . . . . . . . . . . . . . . . . . . . . . . 68
B.2. Alternate Encoding Functions . . . . . . . . . . . . . . 70 B.2. Alternate Encoding Functions . . . . . . . . . . . . . . 69
B.3. The Quick-Start Request: Packets or Bytes? . . . . . . . 71 B.3. The Quick-Start Request: Packets or Bytes? . . . . . . . 71
B.4. Quick-Start Semantics: Total Rate or Addi- B.4. Quick-Start Semantics: Total Rate or Addi-
tional Rate?. . . . . . . . . . . . . . . . . . . . . . . . . 73 tional Rate?. . . . . . . . . . . . . . . . . . . . . . . . . 72
B.5. Alternate Responses to the Loss of a Quick- B.5. Alternate Responses to the Loss of a Quick-
Start Packet. . . . . . . . . . . . . . . . . . . . . . . . . 74 Start Packet. . . . . . . . . . . . . . . . . . . . . . . . . 73
B.6. Why Not Include More Functionality?. . . . . . . . . . . 74 B.6. Why Not Include More Functionality?. . . . . . . . . . . 74
B.7. Alternate Implementations for a Quick-Start B.7. Alternate Implementations for a Quick-Start
Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
B.7.1. An Alternate Proposal for the Quick- B.7.1. An Alternate Proposal for the Quick-
Start Nonce. . . . . . . . . . . . . . . . . . . . . . . . 78 Start Nonce. . . . . . . . . . . . . . . . . . . . . . . . 77
B.7.2. The Earlier Request-Approved Quick- B.7.2. The Earlier Request-Approved Quick-
Start Nonce. . . . . . . . . . . . . . . . . . . . . . . . 78 Start Nonce. . . . . . . . . . . . . . . . . . . . . . . . 78
C. Quick-Start with DCCP . . . . . . . . . . . . . . . . . . . . 79 C. Quick-Start with DCCP . . . . . . . . . . . . . . . . . . . . 79
D. Possible Router Algorithm . . . . . . . . . . . . . . . . . . 81 D. Possible Router Algorithm . . . . . . . . . . . . . . . . . . 80
E. Possible Additional Uses for the Quick-Start E. Possible Additional Uses for the Quick-Start
Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Normative References . . . . . . . . . . . . . . . . . . . . . . 84 Normative References . . . . . . . . . . . . . . . . . . . . . . 83
Informative References . . . . . . . . . . . . . . . . . . . . . 84 Informative References . . . . . . . . . . . . . . . . . . . . . 84
AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 89 AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 89
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 91 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 90
Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 91 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 90
1. Introduction 1. Introduction
Each connection begins with a question: "What is the appropriate Each 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, but each TCP connection determines the sending answered explicitly, but each TCP connection determines the sending
rate by probing the network path and altering the congestion window rate by probing the network path and altering the congestion window
(cwnd) based on perceived congestion. Each TCP connection starts (cwnd) based on perceived congestion. Each TCP 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 25 skipping to change at page 15, line 25
with IP and TCP follows in Sections 3 and 4. Quick-Start could be 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 used in the middle of a connection, e.g., after an idle or
underutilized period, as well as for the initial sending rate; these underutilized period, as well as for the initial sending rate; these
uses of Quick-Start are discussed later in the document. uses of Quick-Start are discussed later in the document.
Quick-Start requires end-points and routers to work together, with Quick-Start requires end-points and routers to work together, with
end-points requesting a higher sending rate in the Quick-Start (QS) end-points requesting a higher sending rate in the Quick-Start (QS)
option in IP, and routers along the path approving, modifying, option in IP, and routers along the path approving, modifying,
discarding or ignoring (and therefore disallowing) the Quick-Start discarding or ignoring (and therefore disallowing) the Quick-Start
Request. The receiver uses reliable, transport-level mechanisms to Request. The receiver uses reliable, transport-level mechanisms to
inform the sender of the status of the Quick-Start Request. In 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 addition, Quick-Start assumes a unicast, congestion-controlled
transport protocol; we do not consider the use of Quick-Start for transport protocol; we do not consider the use of Quick-Start for
multicast traffic. multicast traffic.
When sent as a request, the Quick-Start Option includes a request When sent as a request, the Quick-Start Option includes a request
for a sending rate in bits per second, and a Quick-Start TTL (QS for a sending rate in bits per second, and a Quick-Start TTL (QS
TTL) to be decremented by every router along the path that TTL) to be decremented by every router along the path that
understands the option and approves the request. The Quick-Start understands the option and approves the request. The Quick-Start
TTL is initialized by the sender to a random value. The transport TTL is initialized by the sender to a random value. The transport
receiver returns the rate, information about the TTL and the Quick- receiver returns the rate, information about the TTL and the Quick-
Start Nonce to the sender using transport-level mechanisms. In Start Nonce to the sender using transport-level mechanisms; for TCP,
particular, the receiver computes the difference between the Quick- the receiver sends this information in the Quick-Start Response in
Start TTL and the IP TTL (the TTL in the IP header) of the Quick- the TCP header. In particular, the receiver computes the difference
Start request packet, and returns this in the Quick-Start response. between the Quick-Start TTL and the IP TTL (the TTL in the IP
The sender uses this information to determine if all of the routers header) of the Quick-Start request packet, and returns this in the
along the path decremented the Quick-Start TTL, approving the Quick- Quick-Start response. The sender uses the TTL difference to
Start Request. determine if all of the routers along the path decremented the
Quick-Start TTL, approving the Quick-Start Request.
If the request is approved by all of the routers along the path, If the request is approved by all of the routers along the path,
then the TCP sender combines this allowed rate with the measurement then the TCP sender combines this allowed rate with the measurement
of the round-trip time, and ends up with an allowed TCP congestion 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 window. This window is sent rate-paced over the next round-trip
time, or until an ACK packet is received. time, or until an ACK packet is received.
Figure 1 shows a successful use of Quick-Start, with the sender's IP 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 layer and both routers along the path approving the Quick-Start
Request. In this example, Quick-Start is used by TCP to establish Request, and the TCP receiver using the Quick-Start Response to
the initial congestion window. 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 Sender Router 1 Router 2 Receiver
------ -------- -------- -------- ------ -------- -------- --------
| <IP TTL: 63> | <IP TTL: 63>
| <QS TTL: 91> | <QS TTL: 91>
| <TTL Diff: 28> | <TTL Diff: 28>
| Quick-Start Request | Quick-Start Request
| in SYN or SYN/ACK. | in SYN or SYN/ACK.
| IP: Decrement QS TTL | IP: Decrement QS TTL
| to approve request --> | to approve request -->
skipping to change at page 16, line 32 skipping to change at page 16, line 36
| Decrement | Decrement
| QS TTL | QS TTL
| to approve | to approve
| request --> | request -->
| |
| <IP TTL: 60> | <IP TTL: 60>
| <QS TTL: 88> | <QS TTL: 88>
| <TTL Diff: 28> | <TTL Diff: 28>
| Return Quick-Start | Return Quick-Start
| info to sender in | info to sender in
| <-- TCP ACK packet. | Quick-Start Response
| <-- in TCP ACK packet.
| |
| <TTL Diff: 28> | <TTL Diff: 28>
| Quick-Start approved, | Quick-Start approved,
| translate to cwnd. | translate to cwnd.
| Report Approved Rate. | Report Approved Rate.
V Send cwnd paced over one RTT. --> V Send cwnd paced over one RTT. -->
Figure 1: A successful Quick-Start Request. Figure 1: A successful Quick-Start Request.
Figure 2 shows an unsuccessful use of Quick-Start, with one of the Figure 2 shows an unsuccessful use of Quick-Start, with one of the
skipping to change at page 17, line 29 skipping to change at page 17, line 31
| |
| Forward packet | Forward packet
| without modifying | without modifying
| Quick-Start Option. --> | Quick-Start Option. -->
| |
| <IP TTL: 60> | <IP TTL: 60>
| <QS TTL: 89> | <QS TTL: 89>
| <TTL Diff: 29> | <TTL Diff: 29>
| Return Quick-Start | Return Quick-Start
| info to sender in | info to sender in
| <-- TCP ACK packet. | Quick-Start Response
| <-- in TCP ACK packet.
| |
| <TTL Diff: 29> | <TTL Diff: 29>
| Quick-Start not approved. | Quick-Start not approved.
| Report Approved Rate. | Report Approved Rate.
V Use default initial cwnd. --> V Use default initial cwnd. -->
Figure 2: An unsuccessful Quick-Start Request. Figure 2: An unsuccessful Quick-Start Request.
3. The Quick-Start Option in IP 3. The Quick-Start Option in IP
skipping to change at page 20, line 45 skipping to change at page 20, line 45
the network. If the packet contained the Quick-Start Request is the network. If the packet contained the Quick-Start Request is
acknowledged, but the acknowledgement packet does not contain a acknowledged, but the acknowledgement packet does not contain a
Quick-Start Response, then the sender MUST assume that the Quick- Quick-Start Response, then the sender MUST assume that the Quick-
Start Request was denied, and set a Report of Approved Rate with a 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 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. 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 Alternately, some routers that use the Report of Approved Rate may
choose to match the QS Nonce, masked by the approved rate, with the choose to match the QS Nonce, masked by the approved rate, with the
QS Nonce seen in the original request. QS Nonce seen in the original request.
If the Rate Request is denied, the sender MUST sent a Report of If the Rate Request is denied, the sender MUST send a Report of
Approved Rate with the Rate Report field set to zero. Approved Rate with the Rate Report field set to zero.
We note that unlike a Quick-Start Request sent at the beginning of a 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, when a Quick-Start Request is sent in the middle of a
connection, the connection could already have an established connection, the connection could already have an established
congestion window or sending rate. The Rate Request is the congestion window or sending rate. The Rate Request is the
requested total rate for the connection, including the current rate requested total rate for the connection, including the current rate
of the connection; the Rate Request is *not* a request for an of the connection; the Rate Request is *not* a request for an
additional sending rate over and above the current sending rate. If additional sending rate over and above the current sending rate. If
the Rate Request is denied, or lowered to a value below the the Rate Request is denied, or lowered to a value below the
skipping to change at page 21, line 41 skipping to change at page 21, line 41
That is, TTL Diff MUST be calculated and stored as follows: That is, TTL Diff MUST be calculated and stored as follows:
TTL Diff = ( IPv6 Hop Limit - QS TTL ) mod 256 (2) TTL Diff = ( IPv6 Hop Limit - QS TTL ) mod 256 (2)
Unlike IPv4, modifying or deleting the Quick-Start IPv6 Option does Unlike IPv4, modifying or deleting the Quick-Start IPv6 Option does
not require checksum re-calculation, because the IPv6 header does not require checksum re-calculation, because the IPv6 header does
not have a checksum field, and modifying the Quick-Start Request in 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- the IPv6 Hop-by-Hop options header does not affect the IPv6 pseudo-
header checksum used in upper-layer checksum calculations. header checksum used in upper-layer checksum calculations.
Note that [RFC2460] specifies that when a specific flow label has Appendix A of RFC 2460 requires that all packets with the same flow
been assigned to packets, the contents of the Hop-by-Hop options, label must be originated with the same hop-by-hop header contents,
excluding the next header field, must originate with the same which would be incompatible with Quick-Start. However, a later IPv6
contents throughout the IP flow lifetime. However, the Quick-Start flow label specification [RFC3697] updates the use of flow labels in
option would be included in only a small fraction of the packets IPv6 and removes this restriction. Therefore Quick-Start is
during a flow lifetime. Thus, Quick-Start SHOULD NOT be used in an compatible with the current IPv6 specifications.
IPv6 connection that uses flow labels unless the experimental
specification of flow labels in Appendix A of RFC 2460 is changed.
We note that RFC 2460 states that the use of the flow label field in
IPv6 "is, at the time of writing, still experimental and subject to
change as the requirements for flow support in the Internet become
clearer" [RFC2460].
3.3. Processing the Quick-Start Request at Routers 3.3. Processing the Quick-Start Request at Routers
The Quick-Start Request does not report the current sending rate of The Quick-Start Request does not report the current sending rate of
the connection sending the request; in the default case of a router the connection sending the request; in the default case of a router
(or IP layer implementation at an end-node) that does not maintain (or IP layer implementation at an end-node) that does not maintain
per-flow state, a router makes the conservative assumption that the per-flow state, a router makes the conservative assumption that the
flow's current sending rate is zero. Each participating router can flow's current sending rate is zero. Each participating router can
either terminate or approve the Quick-Start Request. A router MUST either terminate or approve the Quick-Start Request. A router MUST
only approve a Quick-Start request if the output link is only approve a Quick-Start request if the output link is
skipping to change at page 22, line 30 skipping to change at page 22, line 28
While the paragraph above defines the *semantics* of approving a While the paragraph above defines the *semantics* of approving a
Quick-Start request, this document does not specify the specific Quick-Start request, this document does not specify the specific
algorithms to be used by routers in processing Quick-Start Requests algorithms to be used by routers in processing Quick-Start Requests
or Reports. This is similar to RFC 3168, which specifics the or Reports. This is similar to RFC 3168, which specifics the
semantics of the ECN codepoints in the IP header, but does not semantics of the ECN codepoints in the IP header, but does not
specify specific algorithms for routers to use in deciding when to specify specific algorithms for routers to use in deciding when to
drop or mark packets before buffer overflow. drop or mark packets before buffer overflow.
A router that wishes to terminate the Quick-Start Request SHOULD A router that wishes to terminate the Quick-Start Request SHOULD
delete the Quick-Start Request from the IP header. This saves either delete the Quick-Start Request from the IP header or zero the
resources because downstream routers will have no option to process. QS TTL, QS Nonce, and Rate Request fields. Deleting the Quick-Start
If a Quick-Start-capable router wishes to deny the request but Request saves resources because downstream routers will have no
doesn't delete the Quick-Start Request from the IP header, then the option to process, but zeroing the Rate Request field may be more
router SHOULD zero the QS TTL, QS Nonce, and Rate Request fields. efficient for routers to implement. As suggested in [B05], future
Zeroing the Rate Request field may be more efficient for routers to additions to Quick-Start could define error codes for routers to
implement than deleting the Quick-Start option. As suggested in insert into the QS Nonce field to report back to the sender the
[B05], future additions to Quick-Start could define error codes for reason that the Quick-Start request was denied, e.g., that the
routers to insert into the QS Nonce field to report back to the router is denying all Quick-Start requests at this time, or that
sender the reason that the Quick-Start request was denied, e.g., this router as a matter of policy does not grant Quick-Start
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 requests. A router that doesn't understand the Quick-Start option
will simply forward the packet with the Quick-Start Request will simply forward the packet with the Quick-Start Request
unchanged (ensuring that the TTL Diff will not match and Quick-Start unchanged (ensuring that the TTL Diff will not match and Quick-Start
will not be used). will not be used).
If the participating router has decided to approve the Quick-Start If the participating router has decided to approve the Quick-Start
Request, it does the following: Request, it does the following:
* The router MUST decrement the QS TTL by the amount the IP TTL is * The router MUST decrement the QS TTL by the amount the IP TTL is
decremented (usually one). decremented (usually one).
skipping to change at page 26, line 10 skipping to change at page 25, line 33
Rate K". Thus, the receiver has a 1/16 chance in successfully lying Rate K". Thus, the receiver has a 1/16 chance in successfully lying
and saying that the received rate request was K+2 instead of K. 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 We note that the protection offered by the QS Nonce is the same
whether one router makes all of the decrements in the rate request, whether one router makes all of the decrements in the rate request,
or whether they are made at different routers along the path. or whether they are made at different routers along the path.
The requirements for randomization for the sender and routers in The requirements for randomization for the sender and routers in
setting `random' values in the QS Nonce are not stringent - almost setting `random' values in the QS Nonce are not stringent - almost
any form of pseudo-random numbers would do. The requirement is that any form of pseudo-random numbers would do. The requirement is that
the original value for the QS Nonce is not easily guessable by the the original value for the QS Nonce is not easily predictable by the
receiver, and in particular, the nonce MUST NOT be easily determined receiver, and in particular, the nonce MUST NOT be easily determined
from inspection of the rest of the packet or from previous packets. 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 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 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 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. 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 An additional requirement is that the receiver cannot be able to
tell, from the QS Nonce itself, which numbers in the QS Nonce were tell, from the QS Nonce itself, which numbers in the QS Nonce were
generated by the sender, and which were generated by routers along generated by the sender, and which were generated by routers along
skipping to change at page 33, line 40 skipping to change at page 33, line 17
acknowledgement traffic in DCCP's CCID2 [RFC4341]. acknowledgement traffic in DCCP's CCID2 [RFC4341].
In the absence of congestion control for acknowledgement traffic, In the absence of congestion control for acknowledgement traffic,
the TCP receiver could limit its sending rate for ACK packets sent the TCP receiver could limit its sending rate for ACK packets sent
in response to Quick-Start data packets. The following information in response to Quick-Start data packets. The following information
is needed by the TCP receiver: is needed by the TCP receiver:
* The RTT: TCP naturally measures the RTT of the path and therefore * The RTT: TCP naturally measures the RTT of the path and therefore
should have a sample of the RTT. If the TCP receiver does not should have a sample of the RTT. If the TCP receiver does not
have a measurement of the round-trip time, it can use the time have a measurement of the round-trip time, it can use the time
between the receipt of the Quick-Start Request and the Quick-Start between the receipt of the Quick-Start Request and the Report
Response packets. of Approved Rate.
* The Approved Rate Request (R): When the TCP receiver receives the * The Approved Rate Request (R): When the TCP receiver receives the
Quick-Start Response packet, the receiver knows the value of the Quick-Start Response packet, the receiver knows the value of the
approved Rate Request. approved Rate Request.
* The MSS: TCP advertises the MSS during the initial three-way * The MSS: TCP advertises the MSS during the initial three-way
handshake and therefore the receiver should have an understanding handshake and therefore the receiver should have an understanding
of the packet size the sender will be using. If the receiver does of the packet size the sender will be using. If the receiver does
not have such an understanding or wishes to confirm the negotiated not have such an understanding or wishes to confirm the negotiated
MSS, the size of the first data packet can be used. MSS, the size of the first data packet can be used.
skipping to change at page 39, line 10 skipping to change at page 38, line 28
congestion window appropriately, and sets up rate-based pacing to be congestion window appropriately, and sets up rate-based pacing to be
used with its initial window. If the Quick-Start Response is not used with its initial window. If the Quick-Start Response is not
valid, then Host B uses TCP's default initial window. In either valid, then Host B uses TCP's default initial window. In either
case, Host B sends a Report of Approved Rate. case, Host B sends a Report of Approved Rate.
5. Quick-Start and IPsec AH 5. Quick-Start and IPsec AH
This section shows that Quick-Start is compatible with IPsec AH This section shows that Quick-Start is compatible with IPsec AH
(Authentication Header). AH uses an Integrity Check Value (ICV) in (Authentication Header). AH uses an Integrity Check Value (ICV) in
the IPsec Authentication Header to verify both message the IPsec Authentication Header to verify both message
authentication and integrity ([RFC2402], [RFC4302]). Changes to the authentication and integrity ([RFC4302], page 85). Changes to the
Quick-Start option in the IP header do not affect this AH ICV. The Quick-Start option in the IP header do not affect this AH ICV. The
tunnel considerations in Section 6 below apply to all IPsec tunnels, tunnel considerations in Section 6 below apply to all IPsec tunnels,
regardless of what IPsec headers or processing are used in regardless of what IPsec headers or processing are used in
conjunction with the tunnel. conjunction with the tunnel.
Because the contents of the Quick-Start option can change along the Because the contents of the Quick-Start option can change along the
path, it is important that these changes not affect the IPsec path, it is important that these changes not affect the IPsec
Authentication Header Integrity Check Value (AH ICV). For IPv4, RFC Authentication Header Integrity Check Value (AH ICV). For IPv4, RFC
2402 requires that unrecognized IPv4 options be zeroed for AH ICV 4302 requires that unrecognized IPv4 options be zeroed for AH ICV
computation purposes, so Quick-Start IP Option data changing en computation purposes, so Quick-Start IP Option data changing en
route does not cause problems with existing IPsec AH implementations route does not cause problems with existing IPsec AH implementations
for IPv4. If the Quick-Start option is recognized, it MUST be for IPv4. If the Quick-Start option is recognized, it MUST be
treated as a mutable IPv4 option, and hence be completely zeroed for treated as a mutable IPv4 option, and hence be completely zeroed for
AH ICV calculation purposes. IPv6 option numbers explicitly AH ICV calculation purposes. IPv6 option numbers explicitly
indicate whether the option is mutable; the 3rd highest order bit in indicate whether the option is mutable; the 3rd highest order bit in
the IANA-allocated option type has the value 1 to indicate that the the IANA-allocated option type has the value 1 to indicate that the
Quick-Start option data can change en route. RFC 2402 requires that Quick-Start option data can change en route. RFC 4302 requires that
the option data of any such option be zeroed for AH ICV computation the option data of any such option be zeroed for AH ICV computation
purposes. Therefore changes to the Quick-Start option in the IP purposes. Therefore changes to the Quick-Start option in the IP
header do not affect the calculation of the AH ICV. header do not affect the calculation of the AH ICV.
6. Quick-Start in IP Tunnels and MPLS 6. Quick-Start in IP Tunnels and MPLS
This section considers interactions between Quick-Start and IP This section considers interactions between Quick-Start and IP
tunnels, including IPsec ([RFC2401], [RFC4301]), IP in IP [RFC2003], tunnels, including IPsec ([RFC4301]), IP in IP [RFC2003], GRE
GRE [RFC2784], and others. This section also considers interactions [RFC2784], and others. This section also considers interactions
between Quick-Start and MPLS [RFC3031]. between Quick-Start and MPLS [RFC3031].
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 Recall that the sender considers the Quick-Start request approved
only if the value of TTL Diff for the packet entering the network is only if the value of TTL Diff for the packet entering the network is
the same as the value of TTL Diff for the packet exiting the the same as the value of TTL Diff for the packet exiting the
network. network.
Simple tunnels: IP tunnel modes are generally based on adding a new Simple tunnels: IP tunnel modes are generally based on adding a new
skipping to change at page 43, line 9 skipping to change at page 42, line 29
Quick-Start, a valid Quick-Start Request with unchanged TTL Diff Quick-Start, a valid Quick-Start Request with unchanged TTL Diff
traverses in the inner header, while the outer header most likely traverses in the inner header, while the outer header most likely
does not carry a Quick-Start Request. If the tunnel egress also does not carry a Quick-Start Request. If the tunnel egress also
does not support Quick-Start, it remains possible that the Quick- does not support Quick-Start, it remains possible that the Quick-
Start Request would be falsely approved, because the packet is Start Request would be falsely approved, because the packet is
decapsulated using the Quick-Start request from the inner header, decapsulated using the Quick-Start request from the inner header,
and the value of TTL Diff echoed to the sender remains unchanged. and the value of TTL Diff echoed to the sender remains unchanged.
For example, such a scenario can occur with a Bump-In-The-Stack For example, such a scenario can occur with a Bump-In-The-Stack
(BITS), an IPSec encryption implementation where the data encryption (BITS), an IPSec encryption implementation where the data encryption
occurs between the network drivers and the TCP/IP protocol stack occurs between the network drivers and the TCP/IP protocol stack
[RFC2401]. [RFC4301].
As one example, if a remote access VPN client uses a BITS structure, As one example, if a remote access VPN client uses a BITS structure,
then Quick-Start obstacles between the client and the VPN gateway then Quick-Start obstacles between the client and the VPN gateway
won't be seen. This is a particular problem because the path won't be seen. This is a particular problem because the path
between the client and the VPN gateway is likely to contain the most between the client and the VPN gateway is likely to contain the most
congested part of the path. Because most VPN clients are reported congested part of the path. Because most VPN clients are reported
to use BITS [H05], we will explore this in more detail. to use BITS [H05], we will explore this in more detail.
A Bump-In-The-Wire (BITW) is an IPSec encryption implementation A Bump-In-The-Wire (BITW) is an IPSec encryption implementation
where the encryption occurs on an outboard processor, offloading the where the encryption occurs on an outboard processor, offloading the
encryption processing overhead from the host or router [RFC2401]. encryption processing overhead from the host or router [RFC4301].
The BITW device is usually IP addressable, which means that the IP The BITW device is usually IP addressable, which means that the IP
TTL is decremented before the packet is passed to the BITW. If the TTL is decremented before the packet is passed to the BITW. If the
QS TTL is not decremented, then the value of TTL Diff is changed, QS TTL is not decremented, then the value of TTL Diff is changed,
and the Quick-Start request will be denied. However, if the BITW and the Quick-Start request will be denied. However, if the BITW
supports a host and does not have its own IP address, then the IP supports a host and does not have its own IP address, then the IP
TTL is not decremented before the packet is passed from the host to TTL is not decremented before the packet is passed from the host to
the BITW, and a false positive could occur. the BITW, and a false positive could occur.
Other tunnels that need to be looked at are IP tunnels over non- Other tunnels that need to be looked at are IP tunnels over non-
network protocols, such as IP over TCP and IP over UDP [RFC3948], network protocols, such as IP over TCP and IP over UDP [RFC3948],
skipping to change at page 55, line 42 skipping to change at page 55, line 16
significantly when Quick-Start was deployed in a controlled significantly when Quick-Start was deployed in a controlled
environment such as an Intranet, where there was some form of environment such as an Intranet, where there was some form of
centralized control over the users in the system. We also note that centralized control over the users in the system. We also note that
this form of attack could potentially make Quick-Start unusable, but this form of attack could potentially make Quick-Start unusable, but
it would not do any further damage; in the worst case, the network it would not do any further damage; in the worst case, the network
would function as a network without Quick-Start. would function as a network without Quick-Start.
[SAF06] considers the potential of Extreme Quick-Start algorithms at [SAF06] considers the potential of Extreme Quick-Start algorithms at
routers, which keep per-flow state for Quick-Start connections, in routers, which keep per-flow state for Quick-Start connections, in
protecting the availability of Quick-Start bandwidth in the face of protecting the availability of Quick-Start bandwidth in the face of
frequent overly-larqe Quick-Start requests. frequent overly-large Quick-Start requests.
9.7. Simulations with Quick-Start 9.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
skipping to change at page 60, line 9 skipping to change at page 59, line 30
of Quick-Start it does not endanger the network as a whole since TCP of Quick-Start it does not endanger the network as a whole since TCP
uses standard congestion control if Quick-Start is not available. uses standard congestion control if Quick-Start is not available.
Section 4.7.2 discusses the potential problem of packets with Quick- Section 4.7.2 discusses the potential problem of packets with Quick-
Start Requests dropped by middleboxes along the path. Start Requests dropped by middleboxes along the path.
As discussed in Section 5, for IPv4 IPsec Authentication Header As discussed in Section 5, for IPv4 IPsec Authentication Header
Integrity Check Value (AH ICV) calculation, the Quick-Start option Integrity Check Value (AH ICV) calculation, the Quick-Start option
is a mutable IPv4 option, and hence completely zeroed for AH ICV is a mutable IPv4 option, and hence completely zeroed for AH ICV
calculation purposes; this is also the treatment required by RFC calculation purposes; this is also the treatment required by RFC
2402 for unrecognized IPv4 options. The IPv6 Quick-Start option's 4302 for unrecognized IPv4 options. The IPv6 Quick-Start option's
IANA-allocated option type indicates that it is a mutable option, IANA-allocated option type indicates that it is a mutable option,
hence, according to RFC 2402, its option data is required to be hence, according to RFC 4302, its option data is required to be
zeroed for AH ICV computation purposes. See RFC 2402 for further zeroed for AH ICV computation purposes. See RFC 4302 for further
explanation. explanation.
Section 6.2 discusses possible problems of Quick-Start used by Section 6.2 discusses possible problems of Quick-Start used by
connections carried over simple tunnels that are not compatible with connections carried over simple tunnels that are not compatible with
Quick-Start. In this case it is possible that a Quick-Start Quick-Start. In this case it is possible that a Quick-Start
Request is erroneously considered approved by the sender without the Request is erroneously considered approved by the sender without the
routers in the tunnel having individually approved the request, routers in the tunnel having individually approved the request,
causing a false positive. causing a false positive.
We note two high-order points here. First, the Quick-Start Nonce We note two high-order points here. First, the Quick-Start Nonce
skipping to change at page 65, line 22 skipping to change at page 64, line 40
(2) Congestion collapse: (2) Congestion collapse:
There could also be concerns about congestion collapse if many flows There could also be concerns about congestion collapse if many flows
used large initial windows, many packets were dropped from used large initial windows, many packets were dropped from
optimistic initial windows, and many congested links ended up optimistic initial windows, and many congested links ended up
carrying packets that are only going to be dropped downstream. carrying packets that are only going to be dropped downstream.
(3) Distributed Denial of Service attacks: (3) Distributed Denial of Service attacks:
A third question would be the potential role of optimistic senders A third question would be the potential role of optimistic senders
in amplifying the damage done by a Distributed Denial of Service in amplifying the damage done by a Distributed Denial of Service
(DDoS) attack (assuming attackers use conformant congestion control (DDoS) attack (assuming attackers use compliant congestion control
in the hopes of "flying under the radar"). in the hopes of "flying under the radar").
(4) Performance hits if a packet is dropped: (4) Performance hits if a packet is dropped:
A fourth issue would be to quantify the performance hit to the A fourth issue would be to quantify the performance hit to the
connection when a packet is dropped from one of the initial windows. connection when a packet is dropped from one of the initial windows.
A.3. Fast Start-ups with other Information from Routers A.3. Fast Start-ups with other Information from Routers
There have been several proposals somewhat similar to Quick-Start, There have been several proposals somewhat similar to Quick-Start,
where the transport protocol collects explicit information from the where the transport protocol collects explicit information from the
skipping to change at page 68, line 27 skipping to change at page 68, line 4
One benefit of using ICMP would be that the delivery of the TCP SYN One benefit of using ICMP would be that the delivery of the TCP SYN
packet or other initial packet would not be delayed by IP option packet or other initial packet would not be delayed by IP option
processing at routers. A greater advantage is that if middleboxes processing at routers. A greater advantage is that if middleboxes
were blocking packets with Quick-Start Requests, using the Quick- were blocking packets with Quick-Start Requests, using the Quick-
Start Request in a separate ICMP packet would mean that the Start Request in a separate ICMP packet would mean that the
middlebox behavior would not affect the connection as a whole. (To middlebox behavior would not affect the connection as a whole. (To
get this robustness to middleboxes with TCP using an IP Quick-Start get this robustness to middleboxes with TCP using an IP Quick-Start
Option, one would have to have a TCP-level Quick-Start Request Option, one would have to have a TCP-level Quick-Start Request
packet that could be sent concurrently but separately from the TCP packet that could be sent concurrently but separately from the TCP
SYN packet.) SYN packet.)
However, there are a number of disadvantages to using ICMP. Some However, there are a number of disadvantages to using ICMP. Some
firewalls and middleboxes may not forward the ICMP Quick-Start firewalls and middleboxes may not forward the ICMP Quick-Start
Request packets. (If an ICMP Reply packet from a router to the Request packets. (If an ICMP Reply packet from a router to the
sender is dropped in the network, the sender would still know that sender is dropped in the network, the sender would still know that
the request was not approved, as stated earlier, so this would not the request was not approved, as stated earlier, so this would not
be as serious of a problem.) In addition, it would be difficult, if be as serious of a problem.) In addition, it would be difficult, if
not impossible, for a router in the middle of an IP tunnel to not impossible, for a router in the middle of an IP tunnel to
deliver an ICMP Reply packet to the actual source, for example when deliver an ICMP Reply packet to the actual source, for example when
the inner IP header is encrypted as in IPsec tunnel mode [RFC2401]. the inner IP header is encrypted as in IPsec ESP tunnel mode
Again, however, the ICMP Reply packet would not be essential to the [RFC4301]. Again, however, the ICMP Reply packet would not be
correct operation of ICMP Quick-Start. essential to the correct operation of ICMP Quick-Start.
Unauthenticated out-of-band ICMP messages could enable some types of Unauthenticated out-of-band ICMP messages could enable some types of
attacks by third-party malicious hosts that are not possible when attacks by third-party malicious hosts that are not possible when
the control information is carried in-band with the IP packets that the control information is carried in-band with the IP packets that
can only be altered by the routers on the connection path. Finally, can only be altered by the routers on the connection path. Finally,
as a minor concern, using ICMP would cause a small amount of as a minor concern, using ICMP would cause a small amount of
additional traffic in the network, which is not the case when using additional traffic in the network, which is not the case when using
IP options. IP options.
B.1.2. RSVP B.1.2. RSVP
skipping to change at page 70, line 47 skipping to change at page 70, line 19
request is 1.3 Gbps. It seems to us that an upper limit of 1.3 Gbps request is 1.3 Gbps. It seems to us that an upper limit of 1.3 Gbps
would be fine for the Quick-Start rate request, and that connections would be fine for the Quick-Start rate request, and that connections
wishing to start up with a higher initial sending rate should be wishing to start up with a higher initial sending rate should be
encouraged to use other mechanisms, such as the explicit reservation encouraged to use other mechanisms, such as the explicit reservation
of bandwidth. If an upper limit of 1.3 Gbps was not acceptable, of bandwidth. If an upper limit of 1.3 Gbps was not acceptable,
then five or six bits could be used for the Rate Request field. then five or six bits could be used for the Rate Request field.
The lower limit of 80 Kbps could be useful for flows with round-trip The lower limit of 80 Kbps could be useful for flows with round-trip
times of a second or more. For a flow with a round-trip time of one times of a second or more. For a flow with a round-trip time of one
second, as is typical in some wireless networks, the TCP initial second, as is typical in some wireless networks, the TCP initial
window of 4380 bytes allowed by RFC 3390 (given appropriate packet window of 4380 bytes allowed by [RFC3390] (given appropriate packet
sizes) would translate to an initial sending rate of 35 Kbps. Thus, sizes) would translate to an initial sending rate of 35 Kbps. Thus,
for TCP flows, a rate request of 80 Kbps could be useful for some for TCP flows, a rate request of 80 Kbps could be useful for some
flows with large round-trip times. flows with large round-trip times.
The lower limit of 80 Kbps could also be useful for some non-TCP The lower limit of 80 Kbps could also be useful for some non-TCP
flows that send small packets, with at most one small packet every flows that send small packets, with at most one small packet every
10 ms. A rate request of 80 Kbps would translate to a rate of a 10 ms. A rate request of 80 Kbps would translate to a rate of a
hundred 100-byte packets per second (including packet headers). hundred 100-byte packets per second (including packet headers).
While some small-packet flows with large round-trip times might find While some small-packet flows with large round-trip times might find
a smaller rate request of 40 Kbps to be useful, our assumption is a smaller rate request of 40 Kbps to be useful, our assumption is
skipping to change at page 72, line 30 skipping to change at page 71, line 49
approximation on the part of the sender; the transport-level sender approximation on the part of the sender; the transport-level sender
might not know the size of the transport and IP headers in bytes, might not know the size of the transport and IP headers in bytes,
and might know nothing at all about the separate headers added in IP and might know nothing at all about the separate headers added in IP
tunnels downstream. This rough estimate seems sufficient, however, tunnels downstream. This rough estimate seems sufficient, however,
given the overall lack of fine precision in Quick-Start given the overall lack of fine precision in Quick-Start
functionality. functionality.
It has been suggested that the router could possibly use information It has been suggested that the router could possibly use information
from the MSS option in the TCP packet header of the SYN packet to from the MSS option in the TCP packet header of the SYN packet to
convert the Quick-Start Request from packets per second to bytes per convert the Quick-Start Request from packets per second to bytes per
second, or vice versa. The MSS option is defined as the maximum MSS second, or vice versa. This would be problematic for several
that the TCP sender expects to receive, not the maximum MSS that the reasons. First, if IPsec is used, the TCP header will be encrypted.
TCP sender plans to send [RFC793]. However, it is probably often
the case that this MSS also applies as an upper bound on the MSS Second, the MSS option is defined as the maximum MSS that the TCP
used by the TCP sender in sending. sender expects to receive, not the maximum MSS that the TCP sender
plans to send [RFC793]. However, it is probably often the case that
this MSS also applies as an upper bound on the MSS used by the TCP
sender in sending.
We note that the sender does not necessarily know the Path MTU when We note that the sender does not necessarily know the Path MTU when
the Quick-Start Request is sent, or when the initial window of data the Quick-Start Request is sent, or when the initial window of data
is sent. Thus, with IPv4, packets from the initial window could end is sent. Thus, with IPv4, packets from the initial window could end
up being fragmented in the network if the "Don't Fragment" (DF) bit up being fragmented in the network if the "Don't Fragment" (DF) bit
is not set [RFC1191]. A Rate Request in bytes per second is is not set [RFC1191]. A Rate Request in bytes per second is
reasonably robust to fragmentation. Clearly a Rate Request in reasonably robust to fragmentation. Clearly a Rate Request in
packets per second is less robust in the presence of fragmentation. packets per second is less robust in the presence of fragmentation.
Interactions between larger initial windows and Path MTU Discovery Interactions between larger initial windows and Path MTU Discovery
are discussed in more detail in RFC 3390 [RFC3390]. are discussed in more detail in RFC 3390 [RFC3390].
skipping to change at page 81, line 44 skipping to change at page 81, line 36
Second, we define the "target" algorithm for processing incoming Second, we define the "target" algorithm for processing incoming
Quick-Start Rate Requests (also from [SAF06]). The algorithm relies Quick-Start Rate Requests (also from [SAF06]). The algorithm relies
on knowing the bandwidth of the outgoing link (which in many cases on knowing the bandwidth of the outgoing link (which in many cases
can be easily configured), the utilization of the outgoing link can be easily configured), the utilization of the outgoing link
(from an estimation technique such as given above) and an estimate (from an estimation technique such as given above) and an estimate
of the potential bandwidth from recent Quick-Start approvals. of the potential bandwidth from recent Quick-Start approvals.
Tracking the potential bandwidth from recent Quick-Start approvals Tracking the potential bandwidth from recent Quick-Start approvals
is another case where local policy dictates how it should be done. is another case where local policy dictates how it should be done.
The simpliest method, outlined in Section 8.2, is for the router to The simplest method, outlined in Section 8.2, is for the router to
keep track of the aggregate Quick-Start rate requests approved in keep track of the aggregate Quick-Start rate requests approved in
the most recent two or more time intervals, including the current the most recent two or more time intervals, including the current
time interval, and to use the sum of the aggregate rate requests time interval, and to use the sum of the aggregate rate requests
over these time intervals as the estimate of the approved Rate over these time intervals as the estimate of the approved Rate
Requests. The experiments in [SAF06] keep track of the aggregate Requests. The experiments in [SAF06] keep track of the aggregate
approved Rate Requests over the most recent two time intervals, for approved Rate Requests over the most recent two time intervals, for
intervals of 150~msec. intervals of 150~msec.
The target algorithm also depends on a threshold (qs_thresh) that is The target algorithm also depends on a threshold (qs_thresh) that is
the fraction of the outgoing link bandwidth that represents the the fraction of the outgoing link bandwidth that represents the
skipping to change at page 85, line 6 skipping to change at page 84, line 43
October 1996. October 1996.
[RFC2113] D. Katz. P Router Alert Option. RFC 2113, February 1997. [RFC2113] D. Katz. P Router Alert Option. RFC 2113, February 1997.
[RFC2140] J. Touch. TCP Control Block Interdependence. RFC 2140. [RFC2140] J. Touch. TCP Control Block Interdependence. RFC 2140.
April 1997. April 1997.
[RFC2205] R. Braden, et al. Resource ReSerVation Protocol (RSVP) -- [RFC2205] R. Braden, et al. Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification. RFC 2205, September 1997. Version 1 Functional Specification. RFC 2205, September 1997.
[RFC2401] S. Kent and R. Atkinson, Security Architecture for the
Internet Protocol, RFC 2401, November 1998.
[RFC2402] S. Kent and R. Atkinson. IP Authentication Header. RFC
2402, November 1998.
[RFC2409] D. Harkins and D. Carrel, The Internet Key Exchange (IKE), [RFC2409] D. Harkins and D. Carrel, The Internet Key Exchange (IKE),
RFC 2409, November 1998. RFC 2409, November 1998.
[RFC2415] K. Poduri and K. Nichols. Simulation Studies of Increased [RFC2415] K. Poduri and K. Nichols. Simulation Studies of Increased
Initial TCP Window Size. RFC 2415. September 1998. Initial TCP Window Size. RFC 2415. September 1998.
[RFC2463] A. Conta and S. Deering. Internet Control Message Protocol [RFC2463] A. Conta and S. Deering. Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification.
RFC 2463, December 1998. RFC 2463, December 1998.
skipping to change at page 86, line 10 skipping to change at page 85, line 41
[RFC3360] S. Floyd. Inappropriate TCP Resets Considered Harmful. [RFC3360] S. Floyd. Inappropriate TCP Resets Considered Harmful.
RFC 3360, August 2002. RFC 3360, August 2002.
[RFC3649] Floyd, S., HighSpeed TCP for Large Congestion Windows, RFC [RFC3649] Floyd, S., HighSpeed TCP for Large Congestion Windows, RFC
3649, December 2003. 3649, December 2003.
[RFC3662] R. Bless, K. Nichols, and K. Wehrle. A Lower Effort Per- [RFC3662] R. Bless, K. Nichols, and K. Wehrle. A Lower Effort Per-
Domain Behavior (PDB) for Differentiated Services. RFC 3662, Domain Behavior (PDB) for Differentiated Services. RFC 3662,
December 2003. December 2003.
[RFC3697] J. Rajahalme, A. Conta, B. Carpenter, and S. Deering. IPv6
Flow Label Specification. RFC 3697, March 2004.
[RFC3775] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in [RFC3775] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in
IPv6. RFC 3775, June 2004. IPv6. RFC 3775, June 2004.
[RFC3819] P. Karn et al., "Advice for Internet Subnetwork [RFC3819] P. Karn et al., "Advice for Internet Subnetwork
Designers", July 2004. Designers", July 2004.
[RFC3948] A. Huttunen, B. Swander, V. Volpe, L. DiBurro, and M. [RFC3948] A. Huttunen, B. Swander, V. Volpe, L. DiBurro, and M.
Stenberg, UDP Encapsulation of IPsec ESP Packets, RFC 3948, January Stenberg, UDP Encapsulation of IPsec ESP Packets, RFC 3948, January
2005. 2005.
skipping to change at page 91, line 7 skipping to change at page 90, line 7
Pasi Sarolahti Pasi Sarolahti
Nokia Research Center Nokia Research Center
P.O. Box 407 P.O. Box 407
FI-00045 NOKIA GROUP FI-00045 NOKIA GROUP
Finland Finland
Phone: +358 50 4876607 Phone: +358 50 4876607
Email: pasi.sarolahti@iki.fi Email: pasi.sarolahti@iki.fi
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society 2006. This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 57 change blocks. 
112 lines changed or deleted 125 lines changed or added

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