draft-ietf-tsvwg-quickstart-05.txt   draft-ietf-tsvwg-quickstart-06.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-05.txt ICIR draft-ietf-tsvwg-quickstart-06.txt ICIR
Expires: January 2007 A. Jain Expires: February 2007 A. Jain
F5 Networks F5 Networks
P. Sarolahti P. Sarolahti
Nokia Research Center Nokia Research Center
30 August 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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 34 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 January 2007. This Internet-Draft will expire on February 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-05:
* Minor editing in response to AD feedback from
Lars Eggert.
This includes changing one "should" to "SHOULD",
and changing formating of the IANA Considerations
section.
* Clarifying in the Introduction that the QS router
does not give preferential treatment to QS packets.
In response to email from Fil Dickinson.
* Added a discussion of interactions between
Quick-Start and draft-ietf-pmtud-method. In
response to AD Feedback from Lars Eggert.
* Deleted Appendix F on "Feedback from Bob Briscoe".
From AD feedback about deleting unnecessary
appendices.
* Added a paragraph to the Introduction about which
sections contain normative references, and which
sections are general discussion. From AD feedback.
* Added a discussion about congestion control for
TCP's reverse-path traffic. From feedback from
Mitchell Erblich.
Changes from draft-ietf-tsvwg-quickstart-04: Changes from draft-ietf-tsvwg-quickstart-04:
* Reformatted references so that "[RFC2581, RFC3390]" * Reformatted references so that "[RFC2581, RFC3390]"
is instead "([RFC2581], [RFC3390])", to eliminate is instead "([RFC2581], [RFC3390])", to eliminate
bug reports from the idnits tool. From feedback bug reports from the idnits tool. From feedback
from Dan Romascanu. from Dan Romascanu.
* Rephrased beginning of second paragraph in the * Rephrased beginning of second paragraph in the
Abstract. From feedback from James Polk. Abstract. From feedback from James Polk.
skipping to change at page 6, line 17 skipping to change at page 6, line 44
- Section 4.4, revised the explanation for reducing the - Section 4.4, revised the explanation for reducing the
congestion window when the first ACK for a Quick-Start congestion window when the first ACK for a Quick-Start
packet is received. packet is received.
- Section 6.4, deleted the last sentence. - Section 6.4, deleted the last sentence.
- Minor editing changes. - Minor editing changes.
- Revised Section 4.6.2 to say that sender SHOULD send one packet - Revised Section 4.6.2 to say that sender SHOULD send one packet
with an initial RTO of three seconds. with an initial RTO of three seconds.
- Revised Section 4.6.3 to say that the TCP sender SHOULD use an - Revised Section 4.6.3 to say that the TCP sender SHOULD use an
initial RTO setting of three seconds. initial RTO setting of three seconds.
- Added text to Section 6.2 on Multiple Paths, discussing - Added text to Section 6.2 on Multiple Paths, discussing
multi-path routing. multipath routing.
- Clarified about GPRS round-trip times. - Clarified about GPRS round-trip times.
- Clarified about PMTUD and the first window of data. - Clarified about PMTUD and the first window of data.
- A small reorganization, rearranging sections. - A small reorganization, rearranging sections.
* Changes from feedback from Martin Duke: * Changes from feedback from Martin Duke:
- Revised text about the size of QS requests. - Revised text about the size of QS requests.
- Added some text to Section 4.1, about when to send QS requests. - Added some text to Section 4.1, about when to send QS requests.
Changes from draft-amit-quick-start-04.txt: Changes from draft-amit-quick-start-04.txt:
* A significant amount of general editing. * A significant amount of general editing.
* Because the Rate Request field only uses four bits, specified * Because the Rate Request field only uses four bits, specified
skipping to change at page 8, line 7 skipping to change at page 9, line 7
* Added a section on "The Quick-Start Request: Packets or Bytes?" * Added a section on "The Quick-Start Request: Packets or Bytes?"
Changes from draft-amit-quick-start-00.txt: Changes from draft-amit-quick-start-00.txt:
* The addition of a citation to [KHR02]. * The addition of a citation to [KHR02].
* The addition of a Related Work section. * The addition of a Related Work section.
* Deleted the QS Nonce, in favor of a random initial value for the * Deleted the QS Nonce, in favor of a random initial value for the
QS TTL. QS TTL.
Table of Contents Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1. Conventions and Terminology. . . . . . . . . . . . . . . 12 1.1. Conventions and Terminology. . . . . . . . . . . . . . . 14
2. Assumptions and General Principles. . . . . . . . . . . . . . 12 2. Assumptions and General Principles. . . . . . . . . . . . . . 14
2.1. Overview of Quick-Start. . . . . . . . . . . . . . . . . 13 2.1. Overview of Quick-Start. . . . . . . . . . . . . . . . . 15
3. The Quick-Start Option in IP. . . . . . . . . . . . . . . . . 16 3. The Quick-Start Option in IP. . . . . . . . . . . . . . . . . 17
3.1. The Quick-Start Option for IPv4. . . . . . . . . . . . . 16 3.1. The Quick-Start Option for IPv4. . . . . . . . . . . . . 17
3.2. The Quick-Start Option for IPv6. . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.1. Processing the Report of Approved 3.3.1. Processing the Report of Approved
Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4. The QS Nonce . . . . . . . . . . . . . . . . . . . . . . 23 3.4. The QS Nonce . . . . . . . . . . . . . . . . . . . . . . 24
4. The Quick-Start Mechanisms in TCP . . . . . . . . . . . . . . 25 4. The Quick-Start Mechanisms in TCP . . . . . . . . . . . . . . 26
4.1. Sending the Quick-Start Request. . . . . . . . . . . . . 26 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 header. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3. TCP: Sending the Quick-Start Response. . . . . . . . . . 29 4.3. TCP: Sending the Quick-Start Response. . . . . . . . . . 30
4.4. TCP: Receiving and Using the Quick-Start 4.4. TCP: Receiving and Using the Quick-Start
Response Packet . . . . . . . . . . . . . . . . . . . . . . . 29 Response Packet . . . . . . . . . . . . . . . . . . . . . . . 30
4.5. TCP: Responding to a Loss of a Quick-Start 4.5. TCP: Controlling Acknowledgement Traffic on
Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 the Reverse Path . . . . . . . . . . . . . . . . . . . . . . 33
4.6. TCP: A Quick-Start Request for a Larger Ini- 4.6. TCP: Responding to a Loss of a Quick-Start
tial Window . . . . . . . . . . . . . . . . . . . . . . . . . 32 Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.6.1. Interactions with Path MTU Discovery. . . . . . . . 33 4.7. TCP: A Quick-Start Request for a Larger Ini-
4.6.2. Quick-Start Request Packets that are tial Window . . . . . . . . . . . . . . . . . . . . . . . . . 35
Discarded by Routers or Middleboxes. . . . . . . . . . . . 33 4.7.1. Interactions with Path MTU Discovery. . . . . . . . 35
4.7. TCP: A Quick-Start Request in the Middle of 4.7.2. Quick-Start Request Packets that are
a Connection. . . . . . . . . . . . . . . . . . . . . . . . . 34 Discarded by Routers or Middleboxes. . . . . . . . . . . . 36
4.8. An Example Quick-Start Scenario with TCP . . . . . . . . 35 4.8. TCP: A Quick-Start Request in the Middle of
5. Quick-Start and IPsec AH. . . . . . . . . . . . . . . . . . . 36 a Connection. . . . . . . . . . . . . . . . . . . . . . . . . 37
6. Quick-Start in IP Tunnels and MPLS. . . . . . . . . . . . . . 37 4.9. An Example Quick-Start Scenario with TCP . . . . . . . . 38
5. Quick-Start and IPsec AH. . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . 39 Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.1.1. Simple Tunnels that are Aware of Quick- 6.1.1. Simple Tunnels that are Aware of Quick-
Start. . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Start. . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.2. Simple Tunnels That Are Not Compatible with 6.2. Simple Tunnels That Are Not Compatible with
Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 40 Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.3. Tunnels That Support Quick-Start . . . . . . . . . . . . 41 6.3. Tunnels That Support Quick-Start . . . . . . . . . . . . 43
6.4. Quick-Start and MPLS . . . . . . . . . . . . . . . . . . 42 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8. Using Quick-Start . . . . . . . . . . . . . . . . . . . . . . 43 8. Using Quick-Start . . . . . . . . . . . . . . . . . . . . . . 46
8.1. Determining the Rate to Request. . . . . . . . . . . . . 43 8.1. Determining the Rate to Request. . . . . . . . . . . . . 46
8.2. Deciding the Permitted Rate Request at a 8.2. Deciding the Permitted Rate Request at a
Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9. Evaluation of Quick-Start . . . . . . . . . . . . . . . . . . 45 9. Evaluation of Quick-Start . . . . . . . . . . . . . . . . . . 47
9.1. Benefits of Quick-Start. . . . . . . . . . . . . . . . . 45 9.1. Benefits of Quick-Start. . . . . . . . . . . . . . . . . 47
9.2. Costs of Quick-Start . . . . . . . . . . . . . . . . . . 45 9.2. Costs of Quick-Start . . . . . . . . . . . . . . . . . . 48
9.3. Quick-Start with QoS-enabled Traffic . . . . . . . . . . 47 9.3. Quick-Start with QoS-enabled Traffic . . . . . . . . . . 49
9.4. Protection against Misbehaving Nodes . . . . . . . . . . 47 9.4. Protection against Misbehaving Nodes . . . . . . . . . . 50
9.4.1. Misbehaving Senders . . . . . . . . . . . . . . . . 47 9.4.1. Misbehaving Senders . . . . . . . . . . . . . . . . 50
9.4.2. Receivers Lying about Whether the 9.4.2. Receivers Lying about Whether the
Request was Approved . . . . . . . . . . . . . . . . . . . 49 Request was Approved . . . . . . . . . . . . . . . . . . . 51
9.4.3. Receivers Lying about the Approved 9.4.3. Receivers Lying about the Approved
Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
9.4.4. Collusion between Misbehaving Routers . . . . . . . 51 9.4.4. Collusion between Misbehaving Routers . . . . . . . 53
9.5. Misbehaving Middleboxes and the IP TTL . . . . . . . . . 52 9.5. Misbehaving Middleboxes and the IP TTL . . . . . . . . . 54
9.6. Attacks on Quick-Start . . . . . . . . . . . . . . . . . 52 9.6. Attacks on Quick-Start . . . . . . . . . . . . . . . . . 55
9.7. Simulations with Quick-Start . . . . . . . . . . . . . . 53 9.7. Simulations with Quick-Start . . . . . . . . . . . . . . 55
10. Implementation and Deployment Issues . . . . . . . . . . . . 53 10. Implementation and Deployment Issues . . . . . . . . . . . . 56
10.1. Implementation Issues for Sending Quick- 10.1. Implementation Issues for Sending Quick-
Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 54 Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 56
10.2. Implementation Issues for Processing Quick- 10.2. Implementation Issues for Processing Quick-
Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 54 Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 57
10.3. Possible Deployment Scenarios . . . . . . . . . . . . . 55 10.3. Possible Deployment Scenarios . . . . . . . . . . . . . 57
10.4. A Comparison with the Deployment Problems 10.4. A Comparison with the Deployment Problems
of ECN. . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 of ECN. . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
11. Security Considerations. . . . . . . . . . . . . . . . . . . 57 11. Security Considerations. . . . . . . . . . . . . . . . . . . 59
12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 58 12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 60
12.1. IP Option . . . . . . . . . . . . . . . . . . . . . . . 58 12.1. IP Option . . . . . . . . . . . . . . . . . . . . . . . 60
12.2. TCP Option. . . . . . . . . . . . . . . . . . . . . . . 58 12.2. TCP Option. . . . . . . . . . . . . . . . . . . . . . . 61
13. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . 58 13. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . 61
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 59 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 61
A. Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 59 A. Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 62
A.1. Fast Start-ups without Explicit Information A.1. Fast Start-ups without Explicit Information
from Routers. . . . . . . . . . . . . . . . . . . . . . . . . 59 from Routers. . . . . . . . . . . . . . . . . . . . . . . . . 63
A.2. Optimistic Sending without Explicit Informa- A.2. Optimistic Sending without Explicit Informa-
tion from Routers . . . . . . . . . . . . . . . . . . . . . . 61 tion from Routers . . . . . . . . . . . . . . . . . . . . . . 64
A.3. Fast Start-ups with other Information from A.3. Fast Start-ups with other Information from
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 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 . . . . . . . . . . . . . . . . . . . . . . 63 back from Routers . . . . . . . . . . . . . . . . . . . . . . 66
A.5. Fast Start-ups with Lower-Than-Best-Effort A.5. Fast Start-ups with Lower-Than-Best-Effort
Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
B. Design Decisions. . . . . . . . . . . . . . . . . . . . . . . 64 B. Design Decisions. . . . . . . . . . . . . . . . . . . . . . . 67
B.1. Alternate Mechanisms for the Quick-Start B.1. Alternate Mechanisms for the Quick-Start
Request: ICMP and RSVP. . . . . . . . . . . . . . . . . . . . 64 Request: ICMP and RSVP. . . . . . . . . . . . . . . . . . . . 67
B.1.1. ICMP. . . . . . . . . . . . . . . . . . . . . . . . 64 B.1.1. ICMP. . . . . . . . . . . . . . . . . . . . . . . . 67
B.1.2. RSVP. . . . . . . . . . . . . . . . . . . . . . . . 65 B.1.2. RSVP. . . . . . . . . . . . . . . . . . . . . . . . 69
B.2. Alternate Encoding Functions . . . . . . . . . . . . . . 66 B.2. Alternate Encoding Functions . . . . . . . . . . . . . . 70
B.3. The Quick-Start Request: Packets or Bytes? . . . . . . . 68 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?. . . . . . . . . . . . . . . . . . . . . . . . . 69 tional Rate?. . . . . . . . . . . . . . . . . . . . . . . . . 73
B.5. Alternate Responses to the Loss of a Quick- B.5. Alternate Responses to the Loss of a Quick-
Start Packet. . . . . . . . . . . . . . . . . . . . . . . . . 71 Start Packet. . . . . . . . . . . . . . . . . . . . . . . . . 74
B.6. Why Not Include More Functionality?. . . . . . . . . . . 71 B.6. Why Not Include More Functionality?. . . . . . . . . . . 74
B.7. Alternate Implementations for a QuickStart B.7. Alternate Implementations for a Quick-Start
Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
B.7.1. An Alternate Proposal for the Quick- B.7.1. An Alternate Proposal for the Quick-
Start Nonce. . . . . . . . . . . . . . . . . . . . . . . . 75 Start Nonce. . . . . . . . . . . . . . . . . . . . . . . . 78
B.7.2. The Earlier Request-Approved QuickStart B.7.2. The Earlier Request-Approved Quick-
Nonce. . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Start Nonce. . . . . . . . . . . . . . . . . . . . . . . . 78
C. Quick-Start with DCCP . . . . . . . . . . . . . . . . . . . . 76 C. Quick-Start with DCCP . . . . . . . . . . . . . . . . . . . . 79
D. Possible Router Algorithm . . . . . . . . . . . . . . . . . . 78 D. Possible Router Algorithm . . . . . . . . . . . . . . . . . . 81
E. Possible Additional Uses for the Quick-Start E. Possible Additional Uses for the Quick-Start
Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
F. Feedback from Bob Briscoe . . . . . . . . . . . . . . . . . . 81 Normative References . . . . . . . . . . . . . . . . . . . . . . 84
F.1. Potential Deployment Scenarios . . . . . . . . . . . . . 81 Informative References . . . . . . . . . . . . . . . . . . . . . 84
F.2. Misbehaving Senders and Receivers. . . . . . . . . . . . 81 AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 89
F.3. Fairness . . . . . . . . . . . . . . . . . . . . . . . . 83 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 91
F.4. Models of Under-Utilization. . . . . . . . . . . . . . . 83 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 91
F.5. Router Algorithms as Local Policy. . . . . . . . . . . . 84
F.6. An Alternate Proposal. . . . . . . . . . . . . . . . . . 84
Normative References . . . . . . . . . . . . . . . . . . . . . . 85
Informative References . . . . . . . . . . . . . . . . . . . . . 85
AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 90
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 92
Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 92
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 11, line 30 skipping to change at page 12, line 30
networks with large bandwidth or long delays. It may take a number networks with large bandwidth or long delays. It may take a number
of RTTs in slow-start before the TCP connection begins to fully use of RTTs in slow-start before the TCP connection begins to fully use
the available bandwidth of the network. For instance, it takes the available bandwidth of the network. For instance, it takes
log_2(N) - 2 round-trip times to build cwnd up to N segments, log_2(N) - 2 round-trip times to build cwnd up to N segments,
assuming an initial congestion window of 4 segments. This time in assuming an initial congestion window of 4 segments. This time in
slow-start is not a problem for large file transfers, where the slow-start is not a problem for large file transfers, where the
slow-start stage is only a fraction of the total transfer time. slow-start stage is only a fraction of the total transfer time.
However, in the case of moderate-sized transfers the connection However, in the case of moderate-sized transfers the connection
might carry out its entire transfer in the slow-start phase, taking might carry out its entire transfer in the slow-start phase, taking
many round-trip times, where one or two RTTs might have been many round-trip times, where one or two RTTs might have been
appropriate in the current network conditions. sufficient when using the currently available bandwidth along the
path.
A fair amount of work has already been done to address the issue of A fair amount of work has already been done to address the issue of
choosing the initial congestion window for TCP, with RFC 3390 choosing the initial congestion window for TCP, with RFC 3390
allowing an initial window of up to four segments based on the MSS allowing an initial window of up to four segments based on the MSS
used by the connection [RFC3390]. Our underlying premise is that used by the connection [RFC3390]. Our underlying premise is that
explicit feedback from all of the routers along the path would be explicit feedback from all of the routers along the path would be
required, in the current architecture, for best-effort connections required, in the current architecture, for best-effort connections
to use initial windows significantly larger than those allowed by to use initial windows significantly larger than those allowed by
[RFC3390], in the absence of other information about the path. [RFC3390], in the absence of other information about the path.
In using Quick-Start, a TCP host, say, host A, would indicate its In using Quick-Start, a TCP host, say, host A, would indicate its
desired sending rate in bytes per second, using a Quick Start option desired sending rate in bytes per second, using a Quick-Start option
in the IP header of a TCP packet. Each router along the path could, in the IP header of a TCP packet. Each router along the path could,
in turn, either approve the requested rate, reduce the requested in turn, either approve the requested rate, reduce the requested
rate, or indicate that the Quick-Start request is not approved. (We rate, or indicate that the Quick-Start request is not approved. (We
note that the `routers' referred to in this document also include note that the `routers' referred to in this document also include
the IP-layer processing of the Quick-Start request at the sender.) the IP-layer processing of the Quick-Start request at the sender.)
If the Quick-Start request is not approved, then the sender would In approving a Quick-Start request, a router does not give
use the default congestion control mechanisms. The Quick-Start preferential treatment to subsequent packets from that connection;
mechanism can determine if there are routers along the path that do the router is only asserting that it is currently underutilized and
not understand the Quick-Start option, or have not agreed to the believes there is sufficient available bandwidth to accommodate the
Quick-Start rate request. TCP host B communicates the final rate sender's requested rate. The Quick-Start mechanism can determine if
request to TCP host A in a transport-level Quick-Start Response in there are routers along the path that do not understand the Quick-
an answering TCP packet. Start option, or have not agreed to the Quick-Start rate request.
TCP host B communicates the final rate request to TCP host A in a
transport-level Quick-Start Response in an answering TCP packet.
If the Quick-Start request is approved by all routers along the
path, then the TCP host can send at up to the approved rate for a
window of data. Subsequent transmissions will be governed by the
default TCP congestion control mechanisms of that connection. If
the Quick-Start request is not approved, then the sender would use
the default congestion control mechanisms.
Quick-Start would not be the first mechanism for explicit Quick-Start would not be the first mechanism for explicit
communication from routers to transport protocols about sending communication from routers to transport protocols about sending
rates. Explicit Congestion Notification (ECN) gives explicit rates. Explicit Congestion Notification (ECN) gives explicit
congestion control feedback from routers to transport protocols, congestion control feedback from routers to transport protocols,
based on the router detecting congestion before buffer overflow based on the router detecting congestion before buffer overflow
[RFC3168]. In contrast, routers would not use Quick-Start to give [RFC3168]. In contrast, routers would not use Quick-Start to give
congestion information, but instead would use Quick-Start as an congestion information, but instead would use Quick-Start as an
optional mechanism to give permission to transport protocols to use optional mechanism to give permission to transport protocols to use
higher sending rates, based on the ability of all the routers along higher sending rates, based on the ability of all the routers along
the path to determine if their respective output links are the path to determine if their respective output links are
significantly underutilized. significantly underutilized.
Section 2 gives an overview of Quick-Start. The formal
specifications for Quick-Start are contained in Sections 3, 4,
6.1.1, and 6.3. In particular, Quick-Start is specified for IPv4
and for IPv6 in Section 3, and is specified for TCP in Section 4.
Section 6 consists mostly of a non-normative discussion of
interactions of Quick-Start with IP tunnels and MPLS; however,
Section 6.1.1 and 6.3 specify behavior for IP tunnels that are aware
of Quick-Start.
The rest of the document is non-normative, as follows. Section 5
shows that Quick-Start is compatible with IPsec AH (Authentication
Header). Section 7 gives a non-normative set of guidelines for
specifying Quick-Start in other transport protocols, and Section 8
discusses using Quick-Start in transport end-nodes and in routers.
Section 9 gives an evaluation of the costs and benefits of Quick-
Start, and Section 10 discusses implementation and deployment
issues. The appendices discuss related work, Quick-Start design
decisions, and possible router algorithms.
1.1. Conventions and Terminology 1.1. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Assumptions and General Principles 2. Assumptions and General Principles
This section describes the assumptions and general principles behind This section describes the assumptions and general principles behind
the design of the Quick-Start mechanism. the design of the Quick-Start mechanism.
skipping to change at page 22, line 41 skipping to change at page 23, line 41
connection will not change the current under-utilized state of the connection will not change the current under-utilized state of the
router. router.
A non-participating router forwards the Quick-Start Request A non-participating router forwards the Quick-Start Request
unchanged, without decrementing the QS TTL. The non-participating unchanged, without decrementing the QS TTL. The non-participating
router still decrements the TTL field in the IP header, as is router still decrements the TTL field in the IP header, as is
required for all routers [RFC1812]. As a result, the sender will be required for all routers [RFC1812]. As a result, the sender will be
able to detect that the Quick-Start Request had not been understood able to detect that the Quick-Start Request had not been understood
or approved by all of the routers along the path. or approved by all of the routers along the path.
A router that uses multipath routing for packets within a single
connection MUST NOT approve a Quick-Start request. This is
discussed in more detail in Section 9.2.
3.3.1. Processing the Report of Approved Rate 3.3.1. Processing the Report of Approved Rate
If the Quick-Start Option has the Function field set to "1000", then If the Quick-Start Option has the Function field set to "1000", then
this is a Report of Approved Rate, rather than a Rate Request. The this is a Report of Approved Rate, rather than a Rate Request. The
router MAY ignore such an option, and in any case it MUST NOT modify router MAY ignore such an option, and in any case it MUST NOT modify
the contents of the option for a Report of Approved Rate. However, the contents of the option for a Report of Approved Rate. However,
the router MAY use the Approved Rate report to check that the sender the router MAY use the Approved Rate report to check that the sender
is not lying about the approved rate. If the reported Approved Rate is not lying about the approved rate. If the reported Approved Rate
is higher than the rate that the router actually approved for this is higher than the rate that the router actually approved for this
connection in the previous round-trip time, then the router may connection in the previous round-trip time, then the router may
skipping to change at page 23, line 23 skipping to change at page 24, line 27
3.4. The QS Nonce 3.4. The QS Nonce
The QS Nonce gives the Quick-Start sender some protection against The QS Nonce gives the Quick-Start sender some protection against
receivers lying about the value of the received Rate Request. This receivers lying about the value of the received Rate Request. This
is particularly important if the receiver knows the original value is particularly important if the receiver knows the original value
of the Rate Request (e.g., when the sender always requests the same of the Rate Request (e.g., when the sender always requests the same
value, and the receiver has a long history of communication with value, and the receiver has a long history of communication with
that sender). Without the QS Nonce, there is nothing to prevent the that sender). Without the QS Nonce, there is nothing to prevent the
receiver from reporting back to the sender a Rate Request of K, when receiver from reporting back to the sender a Rate Request of K, when
the received Rate Request was in fact less than K. This version of the received Rate Request was in fact less than K.
the nonce is based on a proposal from Guohan Lu [L05]. Initial
versions of this document contained an eight-bit QS Nonce, and
subsequent versions discussed the possibility of a four-bit QS
Nonce.
Table 2 gives the format for the 30-bit QS Nonce. Table 2 gives the format for the 30-bit QS Nonce.
Bits Purpose Bits Purpose
--------- ------------------ --------- ------------------
Bits 0-1: Rate 15 -> Rate 14 Bits 0-1: Rate 15 -> Rate 14
Bits 2-3: Rate 14 -> Rate 13 Bits 2-3: Rate 14 -> Rate 13
Bits 4-5: Rate 13 -> Rate 12 Bits 4-5: Rate 13 -> Rate 12
Bits 6-7: Rate 12 -> Rate 11 Bits 6-7: Rate 12 -> Rate 11
Bits 8-9: Rate 11 -> Rate 10 Bits 8-9: Rate 11 -> Rate 10
skipping to change at page 25, line 40 skipping to change at page 26, line 40
This section describes how the Quick-Start mechanism would be used This section describes how the Quick-Start mechanism would be used
in TCP. We first sketch the procedure and then tightly define it in in TCP. We first sketch the procedure and then tightly define it in
the subsequent subsections. the subsequent subsections.
If a TCP sender, say host A, would like to use Quick-Start, the TCP If a TCP sender, say host A, would like to use Quick-Start, the TCP
sender puts the requested sending rate in bits per second, sender puts the requested sending rate in bits per second,
appropriately formatted, in the Quick-Start option in the IP header appropriately formatted, in the Quick-Start option in the IP header
of the TCP packet, called the Quick-Start request packet. (We will of the TCP packet, called the Quick-Start request packet. (We will
be somewhat loose in our use of "packet" vs. "segment" in this be somewhat loose in our use of "packet" vs. "segment" in this
section.) When used for initial start-up, the Quick-Start request section.) When used for initial start-up, the Quick-Start request
packet can be either the SYN or SYN/ACK packet, as described above. packet can be either the SYN or SYN/ACK packet, as illustrated in
The requested rate includes an estimate for the transport and IP Figure 1. The requested rate includes an estimate for the transport
header overhead. The TCP receiver, say host B, returns the Quick- and IP header overhead. The TCP receiver, say host B, returns the
Start Response option in the TCP header in the responding SYN/ACK Quick-Start Response option in the TCP header in the responding
packet or ACK packet, called the Quick-Start response packet, SYN/ACK packet or ACK packet, called the Quick-Start response
informing host A of the results of their request. packet, informing host A of the results of their request.
If the acknowledging packet does not contain a Quick-Start Response, If the acknowledging packet does not contain a Quick-Start Response,
or contains a Quick-Start Response with the wrong value for the TTL or contains a Quick-Start Response with the wrong value for the TTL
Diff or the QS Nonce, then host A MUST assume that its Quick-Start Diff or the QS Nonce, then host A MUST assume that its Quick-Start
request failed. In this case, host A sends a Report of Approved request failed. In this case, host A sends a Report of Approved
Rate with a Rate Report of zero, and uses TCP's default congestion Rate with a Rate Report of zero, and uses TCP's default congestion
control procedure. For initial start-up, host A uses the default control procedure. For initial start-up, host A uses the default
initial congestion window [RFC2581]. initial congestion window ([RFC2581], [RFC3390]).
If the returning packet contains a valid Quick-Start Response, then If the returning packet contains a valid Quick-Start Response, then
host A uses the information in the response, along with its host A uses the information in the response, along with its
measurement of the round-trip time, to determine the Quick-Start measurement of the round-trip time, to determine the Quick-Start
congestion window (QS-cwnd). Quick-Start data packets are defined congestion window (QS-cwnd). Quick-Start data packets are defined
as data packets sent as the result of a successful Quick-Start as data packets sent as the result of a successful Quick-Start
request, up to the time when the first Quick-Start packet is request, up to the time when the first Quick-Start packet is
acknowledged. The sender also sends a Report of Approved Rate. In acknowledged. The sender also sends a Report of Approved Rate. In
order to use Quick-Start, the TCP host MUST use rate-based pacing to order to use Quick-Start, the TCP host MUST use rate-based pacing
transmit Quick-Start packets at the rate indicated in the Quick- [VH97] to transmit Quick-Start packets at the rate indicated in the
Start Response, at the level of granularity possible by the sending Quick-Start Response, at the level of granularity possible by the
host. We note that the limitations of interrupt timing on computers sending host. We note that the limitations of interrupt timing on
can limit the ability of the TCP host in rate-pacing the outgoing computers can limit the ability of the TCP host in rate-pacing the
packets. outgoing packets.
The two TCP end-hosts can independently decide whether to request The two TCP end-hosts can independently decide whether to request
Quick-Start. For example, host A could sent a Quick-Start Request Quick-Start. For example, host A could sent a Quick-Start Request
in the SYN packet, and host B could also send a Quick-Start Request in the SYN packet, and host B could also send a Quick-Start Request
in the SYN/ACK packet. in the SYN/ACK packet.
4.1. Sending the Quick-Start Request 4.1. Sending the Quick-Start Request
When sending a Quick-Start Request, the TCP sender SHOULD send the When sending a Quick-Start Request, the TCP sender SHOULD send the
request on a packet that requires an acknowledgement, such as a SYN, request on a packet that requires an acknowledgement, such as a SYN,
skipping to change at page 28, line 5 skipping to change at page 29, line 5
Of the above, this document recommends that a TCP sender MAY attempt Of the above, this document recommends that a TCP sender MAY attempt
to use Quick-Start in cases (1) and (2). It is NOT RECOMMENDED that to use Quick-Start in cases (1) and (2). It is NOT RECOMMENDED that
a TCP sender use Quick-Start for case (3) at the current time. Case a TCP sender use Quick-Start for case (3) at the current time. Case
(3) requires external notifications not presently defined for TCP or (3) requires external notifications not presently defined for TCP or
other transport protocols. Finally, a TCP SHOULD NOT use Quick- other transport protocols. Finally, a TCP SHOULD NOT use Quick-
Start for case (4) at the current time. Case (4) requires further Start for case (4) at the current time. Case (4) requires further
thought and investigation with regard to how the transport protocol thought and investigation with regard to how the transport protocol
could determine it was in a situation that would warrant could determine it was in a situation that would warrant
transmitting a Quick-Start Request. transmitting a Quick-Start Request.
As a general guideline, a TCP sender SHOULD NOT send a Quick-Start As a general guideline, a TCP sender SHOULD NOT request a sending
request until it has confirmed that is ready to transmit enough data rate larger than it is able to use over the next round-trip time of
to use the requested rate over the round-trip time of the connection the connection (or over 100 ms, if the round-trip time is not
(or over 100 ms, if the round-trip time is not known). In any known), except as required to round up the desired sending rate to
circumstances, the sender MUST NOT make a QS request if it has made the next-highest allowable request.
a QS request within the most recent round-trip time.
Section 4.6 discusses some of the issues of using Quick-Start at In any circumstances, the sender MUST NOT make a QS request if it
connection initiation, and Section 4.7 discusses issues that arise has made a QS request within the most recent round-trip time.
Section 4.7 discusses some of the issues of using Quick-Start at
connection initiation, and Section 4.8 discusses issues that arise
when Quick-Start is used to request a larger sending rate after an when Quick-Start is used to request a larger sending rate after an
idle period. idle period.
4.2. The Quick-Start Response Option in the TCP header 4.2. The Quick-Start Response Option in the TCP header
In order to approve the use of Quick-Start, the TCP receiver In order to approve the use of Quick-Start, the TCP receiver
responds to the receipt of a Quick-Start Request with a Quick-Start responds to the receipt of a Quick-Start Request with a Quick-Start
Response, using the Quick-Start Response Option in the TCP header. Response, using 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:
skipping to change at page 30, line 4 skipping to change at page 31, line 7
Start Request. Start Request.
4.4. TCP: Receiving and Using the Quick-Start Response Packet 4.4. TCP: Receiving and Using the Quick-Start Response Packet
A TCP host, say TCP host A, that sent a Quick-Start Request and A TCP host, say TCP host A, that sent a Quick-Start Request and
receives a Quick-Start Response in an acknowledgement first checks receives a Quick-Start Response in an acknowledgement first checks
that the Quick-Start Response is valid. The Quick-Start Response is that the Quick-Start Response is valid. The Quick-Start Response is
valid if it contains the correct value for the TTL Diff, and an valid if it contains the correct value for the TTL Diff, and an
equal or lesser value for the Rate Request than that transmitted in equal or lesser value for the Rate Request than that transmitted in
the Quick-Start Request. In addition, if the received Rate Request the Quick-Start Request. In addition, if the received Rate Request
is K, then the the rightmost 2K bits of the QS Nonce must match is K, then the rightmost 2K bits of the QS Nonce must match those
those bits in the QS Nonce sent in the Quick-Start Request. If bits in the QS Nonce sent in the Quick-Start Request. If these
these checks are not successful, then the Quick-Start request checks are not successful, then the Quick-Start request failed, and
failed, and the TCP host MUST use the default TCP congestion window the TCP host MUST use the default TCP congestion window that it
that it would have used without Quick-Start. If the rightmost 2K would have used without Quick-Start. If the rightmost 2K bits of
bits of the QS Nonce do not match those bits in the QS Nonce sent in the QS Nonce do not match those bits in the QS Nonce sent in the
the Quick-Start Request, for a received Rate Request of K, then the Quick-Start Request, for a received Rate Request of K, then the TCP
TCP host MUST NOT send additional Quick-Start requests during the host MUST NOT send additional Quick-Start requests during the life
life of the connection. Whether the Quick-Start request was of the connection. Whether the Quick-Start request was successful
successful or not, the host receiving the Quick-Start Response MUST or not, the host receiving the Quick-Start Response MUST send a
send a Report of Approved Rate. Similarly, if the packet containing Report of Approved Rate. Similarly, if the packet containing the
the Quick-Start Request is acknowledged, but the acknowledgement Quick-Start Request is acknowledged, but the acknowledgement does
does not include a Quick-Start Response, then the sender MUST send a not include a Quick-Start Response, then the sender MUST send a
Report of Approved Rate. Report of Approved Rate.
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,
and the TCP host is going to use the Quick-Start Request, it MUST and the TCP host is going to use the Quick-Start Request, it MUST
start using it within one round-trip time of receiving the Quick- start using it within one round-trip time of receiving the Quick-
Start Response, or within three seconds, whichever is smaller. To Start Response, or within three seconds, whichever is smaller. To
use the Quick-Start Request, the host sets its Quick-Start use the Quick-Start Request, the host sets its Quick-Start
congestion window (in terms of MSS-sized segments), QS-cwnd, as congestion window (in terms of MSS-sized segments), QS-cwnd, as
follows: follows:
skipping to change at page 32, line 10 skipping to change at page 33, line 13
any packet marks or losses have been reported, the TCP host MAY use any packet marks or losses have been reported, the TCP host MAY use
the reported Rate Request to set the slow-start threshold to a the reported Rate Request to set the slow-start threshold to a
desired value, e.g., to some small multiple of the congestion desired value, e.g., to some small multiple of the congestion
window. A possible future research topic is how the sender might window. A possible future research topic is how the sender might
modify the show-start threshold at the beginning of a connection to modify the show-start threshold at the beginning of a connection to
avoid overshooting the path capacity. (The initial value of avoid overshooting the path capacity. (The initial value of
ssthresh is allowed to be arbitrarily high, and some TCP ssthresh is allowed to be arbitrarily high, and some TCP
implementations use the size of the advertised window for ssthresh implementations use the size of the advertised window for ssthresh
[RFC2581].) [RFC2581].)
4.5. TCP: Responding to a Loss of a Quick-Start Packet 4.5. TCP: Controlling Acknowledgement Traffic on the Reverse Path
When a Quick-Start Request is approved for a TCP sender, the
resulting Quick-Start data traffic can result in a sudden increase
in traffic for pure ACK packets on the reverse path. For example,
for the largest Quick-Start request of 1.3 Gbps, given a TCP sender
with 1500-byte packets and a TCP receiver with delayed
acknowledgements acking every other packet, this could result in
17.3 Mbps of acknowledgement traffic on the reverse path.
One possibility, in cases with large Quick-Start requests, would be
for TCP receivers to send Quick-Start requests to request bandwidth
for the acknowledgement traffic on the reverse path. However, in
our view, a better approach would be for TCP receivers to simply
control the rate of sending acknowledgement traffic. The optimal
future solution would involve the explicit use of congestion control
for TCP acknowledgement traffic, as is done now for the
acknowledgement traffic in DCCP's CCID2 [RFC4341].
In the absence of congestion control for acknowledgement traffic,
the TCP receiver could limit its sending rate for ACK packets sent
in response to Quick-Start data packets. The following information
is needed by the TCP receiver:
* The RTT: TCP naturally measures the RTT of the path and therefore
should have a sample of the RTT. If the TCP receiver does not
have a measurement of the round-trip time, it can use the time
between the receipt of the Quick-Start Request and the Quick-Start
Response packets.
* The Approved Rate Request (R): When the TCP receiver receives the
Quick-Start Response packet, the receiver knows the value of the
approved Rate Request.
* The MSS: TCP advertises the MSS during the initial three-way
handshake and therefore the receiver should have an understanding
of the packet size the sender will be using. If the receiver does
not have such an understanding or wishes to confirm the negotiated
MSS, the size of the first data packet can be used.
With this set of information the TCP receiver can restrict its
sending rate for pure acknowledgment traffic to at most 100 pure ACK
packets per RTT by sending at most one ACK for every K data packets,
for the ACK Ratio K set to R*RTT/(100*8*MSS). The receiver would
acknowledge the first Quick-Start data packet, and every succeeding
K data packets. Thus, for a somewhat extreme case of R=1.3 Gbps,
RTT=0.2 seconds, and MSS=1500 bytes, K would be set to 216, and the
receiver would acknowledge every 216 data packets. From [RFC2581],
the ACK Ratio K should have a minimum value of two. When the ACK
Ratio is greater than two, and the TCP sender receives
acknowledgements each acknowledging more than two data packets, the
TCP sender may want to use rate-based pacing to control the
burstiness of its outgoing data traffic.
In the absence of explicit congestion control mechanisms, the TCP
end nodes cannot determine the packet drop rate for pure
acknowledgement traffic. This is true with or without Quick-Start.
However, the TCP receiver could limit its increase in the sending
rate for pure ACK packets by at most doubling the sending rate for
pure ACK packets from one round-trip time to the next. The TCP
receiver would do this by halving the ACK Ratio each round-trip
time.
Note that the above is one particular mechanism that could be used
to control the ACK stream. Future work that investigates this
scheme and others in detail is encouraged.
4.6. TCP: Responding to a Loss of a Quick-Start Packet
For TCP, we have defined a ``Quick-Start packet'' as one of the 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 or ECN-marking of a Quick- Start request. After detecting the loss or ECN-marking of a Quick-
Start packet, TCP MUST revert to the default congestion control Start packet, TCP MUST revert to the default congestion control
procedures that would have been used if the Quick-Start request had procedures that would have been used if the Quick-Start request had
not been approved. For example, if Quick-Start is used for setting not been approved. For example, if Quick-Start is used for setting
the initial window, and a packet from the initial window is lost or the initial window, and a packet from the initial window is lost or
marked, then the TCP sender MUST then slow-start with the default marked, then the TCP sender MUST then slow-start with the default
initial window that would have been used if Quick-Start had not been initial window that would have been used if Quick-Start had not been
skipping to change at page 32, line 37 skipping to change at page 35, line 14
If a Quick-Start packet is lost or ECN-marked, then the sender If a Quick-Start packet is lost or ECN-marked, then the sender
SHOULD NOT make future Quick-Start requests for this connection. SHOULD NOT make future Quick-Start requests for this connection.
We note that ECN [RFC3168] MAY be used with Quick-Start. As is We note that ECN [RFC3168] MAY be used with Quick-Start. As is
always the case with ECN, the sender's congestion control response always the case with ECN, the sender's congestion control response
to an ECN-marked Quick-Start packet is the same as the response to a to an ECN-marked Quick-Start packet is the same as the response to a
dropped Quick-Start packet, thus reverting to slow start in the case dropped Quick-Start packet, thus reverting to slow start in the case
of Quick-Start packets marked as experiencing congestion. of Quick-Start packets marked as experiencing congestion.
4.6. TCP: A Quick-Start Request for a Larger Initial Window 4.7. TCP: A Quick-Start Request for a Larger Initial Window
Some of the issues of using Quick-Start are related to the specific 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) interactions with Path MTU request a larger initial window: (1) interactions with Path MTU
Discovery (PMTUD); and (2) Quick-Start request packets that are Discovery (PMTUD); and (2) Quick-Start request packets that are
discarded by middleboxes. discarded by middleboxes.
4.6.1. Interactions with Path MTU Discovery 4.7.1. Interactions with Path MTU Discovery
One issue when Quick-Start is used to request a large initial window One issue when Quick-Start is used to request a large initial window
concerns the interactions between the large initial window and Path concerns the interactions between the large initial window and Path
MTU Discovery. Some of the issues are discussed in RFC 3390: MTU Discovery. Some of the issues are discussed in RFC 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
set the "Don't Fragment" (DF) bit in one of the segments. It is set the "Don't Fragment" (DF) bit in one of the segments. It is
an open question as to which of these two alternatives is best." an open question as to which of these two alternatives is best."
If the sender knows the Path MTU when the initial window is sent If the sender knows the Path MTU when the initial window is sent
(e.g., from a PMTUD cache or from some other IETF-approved method), (e.g., from a PMTUD cache or from some other IETF-approved method),
then the sender should use that MTU for segments in the initial then the sender SHOULD use that MTU for segments in the initial
window. Unfortunately, the sender doesn't necessarily know the Path window. Unfortunately, the sender doesn't necessarily know the Path
MTU when it sends packets in the initial window. In this case, the MTU when it sends packets in the initial window. In this case, the
sender should be conservative in the packet size used. Sending a sender should be conservative in the packet size used. Sending a
large number of overly-large packets with the DF bit set is not large number of overly-large packets with the DF bit set is not
desirable, but sending a large number of packets that are fragmented desirable, but sending a large number of packets that are fragmented
in the network can be equally undesirable. in the network can be equally undesirable.
The sender SHOULD send one large packet in the initial window with If the sender doesn't know the Path MTU when the initial window is
the DF bit set, and send the remaining packets in the initial window sent, the sender SHOULD send one large packet in the initial window
with a smaller MTU of 576 bytes (or 1280 bytes with IPv6). with the DF bit set, and send the remaining packets in the initial
window with a smaller MTU of 576 bytes (or 1280 bytes with IPv6).
A second possibility would be for the sender to delay sending the A second possibility would be for the sender to delay sending the
Quick-Start Request for one round-trip time, sending the Quick-Start Quick-Start Request for one round-trip time, sending the Quick-Start
Request with the first window of data while also doing Path MTU Request with the first window of data while also doing Path MTU
Discovery. Discovery.
4.6.2. Quick-Start Request Packets that are Discarded by Routers or The sender may be using an iterative approach such as Packetization
Layer Path MTU Discovery (PLPMTUD) [MH06] for Path MTU Discovery,
where the sender tests successively larger MTUs. If a probe is
successfully delivered then the MTU can be raised to reflect the
value used in that probe. We would note that PLPMTUD does not allow
the sender to determine the Path MTU before sending the initial
window of data.
4.7.2. Quick-Start Request Packets that are Discarded by Routers or
Middleboxes Middleboxes
It is always possible for a TCP SYN packet carrying a Quick-Start It is always possible for a TCP SYN packet carrying a Quick-Start
request to be dropped in the network due to congestion, or to be request to be dropped in the network due to congestion, or to be
blocked due to interactions with routers or middleboxes, where a blocked due to interactions with routers or middleboxes, where a
middlebox is defined as any intermediary box performing functions middlebox is defined as any intermediary box performing functions
apart from normal, standard functions of an IP router on the data apart from normal, standard functions of an IP router on the data
path between a source host and destination host [RFC3234]. path between a source host and destination host [RFC3234].
Measurement studies of interactions between transport protocols and Measurement studies of interactions between transport protocols and
middleboxes [MAF04] show that for 70% of the web servers middleboxes [MAF04] show that for 70% of the web servers
skipping to change at page 34, line 36 skipping to change at page 37, line 16
In this case, the sender could resend the dropped packet without In this case, the sender could resend the dropped packet without
either the Quick-Start or the ECN requests. Alternately, the sender either the Quick-Start or the ECN requests. Alternately, the sender
could resend the dropped packet with only the ECN request in the TCP could resend the dropped packet with only the ECN request in the TCP
header, resending the TCP SYN packet without either the Quick-Start header, resending the TCP SYN packet without either the Quick-Start
or the ECN requests if the second TCP SYN packet is dropped. The or the ECN requests if the second TCP SYN packet is dropped. The
second choice seems reasonable, given that a TCP SYN packet today is second choice seems reasonable, given that a TCP SYN packet today is
more likely to be blocked due to policies that discard packets with more likely to be blocked due to policies that discard packets with
IP Options than due to policies that discard packets with ECN IP Options than due to policies that discard packets with ECN
requests in the TCP header [MAF04]. requests in the TCP header [MAF04].
4.7. TCP: A Quick-Start Request in the Middle of a Connection 4.8. TCP: A Quick-Start Request in the Middle of a Connection
This section discusses the following issues that arise when Quick- This section discusses the following issues that arise when Quick-
Start is used by TCP to request a larger window in the middle of a Start is used by TCP to request a larger window in the middle of a
connection, such as after an idle period: (1) determining the rate connection, such as after an idle period: (1) determining the rate
to request; (2) when to make a request; and (3) the response if to request; (2) when to make a request; and (3) the response if
Quick-Start packets are dropped; Quick-Start packets are dropped;
(1) Determining the rate to request: (1) Determining the rate to request:
For a connection that has not yet had a congestion event (that is, a For a connection that has not yet had a congestion event (that is, a
marked or dropped packet), the TCP sender is not restricted in the marked or dropped packet), the TCP sender is not restricted in the
skipping to change at page 35, line 20 skipping to change at page 37, line 47
was reduced, for example during an idle period. was reduced, for example during an idle period.
A Quick-Start Request sent in the middle of a TCP connection SHOULD A Quick-Start Request sent in the middle of a TCP connection SHOULD
be sent on a data packet. be sent on a data packet.
(2) When to make a request: (2) When to make a request:
A TCP connection MAY make a Quick-Start request before the A TCP connection MAY make a Quick-Start request before the
connection has experienced a congestion event, or after an idle connection has experienced a congestion event, or after an idle
period of at least one RTO. period of at least one RTO.
(2) Response if Quick-Start packets are dropped: (3) Response if Quick-Start packets are dropped:
If Quick-Start packets are dropped in the middle of connection, then If Quick-Start packets are dropped in the middle of connection, then
the sender MUST revert to half of the Quick-Start window, or to the the sender MUST revert to half of the Quick-Start window, or to the
congestion window that the sender would have used if the Quick-Start congestion window that the sender would have used if the Quick-Start
request had not been approved, whichever is smaller. request had not been approved, whichever is smaller.
4.8. An Example Quick-Start Scenario with TCP 4.9. An Example Quick-Start Scenario with TCP
The following is an example scenario in the case when both hosts The following is an example scenario in the case when both hosts
request Quick-Start for setting their initial windows. This is request Quick-Start for setting their initial windows. This is
similar to Figures 1 and 2 in Section 2.1, except that it similar to Figures 1 and 2 in Section 2.1, except that it
illustrates a TCP connection with both TCP hosts sending Quick-Start illustrates a TCP connection with both TCP hosts sending Quick-Start
Requests. Requests.
* The TCP SYN packet from Host A contains a Quick-Start Request in * The TCP SYN packet from Host A contains a Quick-Start Request in
the IP header. the IP header.
skipping to change at page 36, line 30 skipping to change at page 39, line 10
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], [2402bis]). Changes to the authentication and integrity ([RFC2402], [RFC4302]). 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 2402 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
skipping to change at page 37, line 8 skipping to change at page 39, line 35
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 2402 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], [2401bis]), IP in IP [RFC2003], tunnels, including IPsec ([RFC2401], [RFC4301]), IP in IP [RFC2003],
GRE [RFC2784], and others. This section also considers interactions GRE [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.
skipping to change at page 43, line 40 skipping to change at page 46, line 26
appropriately. For example, the sender might have information about appropriately. For example, the sender might have information about
the bandwidth of the last-mile hop, the size of the local socket the bandwidth of the last-mile hop, the size of the local socket
buffer, or of the TCP receive window, and could use this information buffer, or of the TCP receive window, and could use this information
in determining the rate to request. Web servers that mostly have in determining the rate to request. Web servers that mostly have
small objects to transfer might decide not to use Quick-Start at small objects to transfer might decide not to use Quick-Start at
all, since Quick-Start would be of little benefit to them. all, since Quick-Start would be of little benefit to them.
Quick-Start will be more effective if Quick-Start requests are not Quick-Start will be more effective if Quick-Start requests are not
larger than necessary; every Quick-Start request that is approved larger than necessary; every Quick-Start request that is approved
but not used (or not fully used) takes away from the bandwidth pool but not used (or not fully used) takes away from the bandwidth pool
available for granting successive Quick-Start requests. Following available for granting successive Quick-Start requests.
Section 4.1, the sender SHOULD NOT request a sending rate larger
than it is able to use over the round-trip time of the connection
(or over 100 ms, if the round-trip time is not known), except as
required to round up the desired sending rate to the next-highest
allowable request.
8.2. Deciding the Permitted Rate Request at a Router 8.2. Deciding the Permitted Rate Request at a Router
In this section we briefly outline how a router might decide whether In this section we briefly outline how a router might decide whether
or not to approve a Quick-Start Request. The router should ask the or not to approve a Quick-Start Request. The router should ask the
following questions: following questions:
* Has the router's output link been underutilized for some time * Has the router's output link been underutilized for some time
(e.g., several seconds). (e.g., several seconds).
skipping to change at page 44, line 38 skipping to change at page 47, line 14
the total aggregate Rate Requests that have been approved in the the total aggregate Rate Requests that have been approved in the
current time interval [T1, T2], and one for the total aggregate Rate current time interval [T1, T2], and one for the total aggregate Rate
Requests approved over a previous time interval [T0, T1]. However, Requests approved over a previous time interval [T0, T1]. However,
this document doesn't specify router algorithms for approving Quick- this document doesn't specify router algorithms for approving Quick-
Start requests, or make requirements for the appropriate time Start requests, or make requirements for the appropriate time
intervals for remembering the aggregate approved Quick-Start intervals for remembering the aggregate approved Quick-Start
bandwidth. A possible router algorithm is given in Appendix E, and bandwidth. A possible router algorithm is given in Appendix E, and
more discussion of these issues is available in [SAF06].) more discussion of these issues is available in [SAF06].)
* If the router's output link has been underutilized and the * If the router's output link has been underutilized and the
aggregate of the Quick Start Request Rate options granted is low aggregate of the Quick-Start Request Rate options granted is low
enough to prevent a near-term bandwidth shortage, then the router enough to prevent a near-term bandwidth shortage, then the router
could approve the Quick-Start Request. could approve the Quick-Start Request.
Section 10.2 discusses some of the implementation issues in Section 10.2 discusses some of the implementation issues in
processing Quick-Start requests at routers. [SAF06] discusses the processing Quick-Start requests at routers. [SAF06] discusses the
range of possible Quick-Start algorithms at the router for deciding range of possible Quick-Start algorithms at the router for deciding
whether to approve a Quick-Start request. In order to explore the whether to approve a Quick-Start request. In order to explore the
limits of the possible functionality at routers, [SAF06] also limits of the possible functionality at routers, [SAF06] also
discusses Extreme Quick-Start mechanisms at routers, where the discusses Extreme Quick-Start mechanisms at routers, where the
router would keep per-flow state concerning approved Quick-Start router would keep per-flow state concerning approved Quick-Start
skipping to change at page 46, line 24 skipping to change at page 48, line 48
prevent the addition of other competing functionality to routers. prevent the addition of other competing functionality to routers.
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,
particularly in the beginning of Quick-Start's deployment in the particularly in the beginning of Quick-Start's deployment in the
Internet. This would mean some extra delay for the end hosts, and Internet. This would mean some extra delay for the end hosts, and
extra processing burden for the routers. However, as discussed in extra processing burden for the routers. However, as discussed in
Sections 4.1 and 4.6, not all packets would carry the Quick-Start Sections 4.1 and 4.7, not all packets would carry the Quick-Start
option. In addition, for the underutilized links where Quick-Start option. In addition, for the underutilized links where Quick-Start
Requests could actually be approved, or in typical environments Requests could actually be approved, or in typical environments
where most of the packets belong to large flows, the burden of the where most of the packets belong to large flows, the burden of the
Quick-Start Option on routers would be considerably reduced. Quick-Start Option on routers would be considerably reduced.
Nevertheless, it is still conceivable, in the worst case, that many Nevertheless, it is still conceivable, in the worst case, that many
packets would carry Quick-Start requests; this could slow down the packets would carry Quick-Start requests; this could slow down the
processing of Quick-Start packets in routers considerably. As processing of Quick-Start packets in routers considerably. As
discussed in Section 9.6, routers can easily protect against this by discussed in Section 9.6, routers can easily protect against this by
enforcing a limit on the rate at which Quick-Start requests will be enforcing a limit on the rate at which Quick-Start requests will be
considered. [RW03] and [RW04] contain measurements of the impact of considered. [RW03] and [RW04] contain measurements of the impact of
IP Option Processing on packet round-trip times. IP Option Processing on packet round-trip times.
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
skipping to change at page 46, line 52 skipping to change at page 49, line 28
path that was already congested, or that became congested as a path that was already congested, or that became congested as a
result of this connection. Thus, Quick-Start could give poor result of this connection. Thus, Quick-Start could give poor
performance when there is a routing change immediately after the performance when there is a routing change immediately after the
Quick-Start request is approved, and the Quick-Start data packets Quick-Start request is approved, and the Quick-Start data packets
follow a different path from that of the original Quick-Start follow a different path from that of the original Quick-Start
Request. This is, however, similar to what would happen, for a Request. This is, however, similar to what would happen, for a
connection with sufficient data, if the connection's path was connection with sufficient data, if the connection's path was
changed in the middle of the connection, when the connection had changed in the middle of the connection, when the connection had
already established the allowed initial rate. already established the allowed initial rate.
A router that uses multipath routing for packets within a single As specified in Section 3.3, a router that uses multipath routing
connection MUST NOT approve a Quick-Start request. Quick-Start for packets within a single connection must not approve a Quick-
would not perform robustly in an environment with multipath routing, Start request. Quick-Start would not perform robustly in an
where different packets in a connection routinely follow different environment with multipath routing, where different packets in a
paths. In such an environment, the Quick-Start request and some connection routinely follow different paths. In such an
fraction of the packets in the connection might take an environment, the Quick-Start request and some fraction of the
underutilized path, while the rest of the packets take an alternate, packets in the connection might take an underutilized path, while
congested path. the rest of the packets take an alternate, congested path.
Non-IP queues: Non-IP queues:
A problem of any mechanism for feedback from routers at the IP level A problem of any mechanism for feedback from routers at the IP level
is that there can be queues and bottlenecks in the end-to-end path is that there can be queues and bottlenecks in the end-to-end path
that are not in IP-level routers. As an example, these include that are not in IP-level routers. As an example, these include
queues in layer-two Ethernet or ATM networks. One possibility would queues in layer-two Ethernet or ATM networks. One possibility would
be that an IP-level router adjacent to such a non-IP queue or be that an IP-level router adjacent to such a non-IP queue or
bottleneck would be configured to reject Quick-Start requests if bottleneck would be configured to reject Quick-Start requests if
that was appropriate. One would hope that in general, IP networks that was appropriate. One would hope that in general, IP networks
are configured so that non-IP queues between IP routers do not end are configured so that non-IP queues between IP routers do not end
skipping to change at page 48, line 27 skipping to change at page 50, line 49
required to use Approved Rate reports to check if senders are required to use Approved Rate reports to check if senders are
cheating; this is at the discretion of the router. cheating; this is at the discretion of the router.
If a router sees a Report of Approved Rate, and did not see an If a router sees a Report of Approved Rate, and did not see an
earlier Quick-Start request, then either the sender could be earlier Quick-Start request, then either the sender could be
cheating, or the connection's path could have changed since the cheating, or the connection's path could have changed since the
Quick-Start request was sent. In either case, the router could Quick-Start request was sent. In either case, the router could
decide to deny future Quick-Start requests for this connection. In decide to deny future Quick-Start requests for this connection. In
particular, it is reasonable for the router to deny a Quick-Start particular, it is reasonable for the router to deny a Quick-Start
request if either the sender is cheating, or if the connection path request if either the sender is cheating, or if the connection path
suffers from path changes or multi-pathing. suffers from path changes or multipathing.
If a router approved a Quick-Start Request, but does not see a If a router approved a Quick-Start Request, but does not see a
subsequent Approved Rate report, then there are several subsequent Approved Rate report, then there are several
possibilities: (1) the request was denied and/or dropped downstream possibilities: (1) the request was denied and/or dropped downstream
and the sender did not send a Report of Approved Rate; (2) the and the sender did not send a Report of Approved Rate; (2) the
request was approved but the sender did not send a Report of request was approved but the sender did not send a Report of
Approved Rate; (3) the Approved Rate report was dropped in the Approved Rate; (3) the Approved Rate report was dropped in the
network; or (4) the Approved Rate report took a different path from network; or (4) the Approved Rate report took a different path from
the Quick-Start Request. In any of these cases, the router would be the Quick-Start Request. In any of these cases, the router would be
justified in denying future Quick-Start Requests for this justified in denying future Quick-Start Requests for this
skipping to change at page 54, line 9 skipping to change at page 56, line 30
This section discusses some of the implementation issues with Quick- This section discusses some of the implementation issues with Quick-
Start. This section also discusses some of the key deployment Start. This section also discusses some of the key deployment
issues, such as the chicken-and-egg deployment problems of issues, such as the chicken-and-egg deployment problems of
mechanisms that have to be deployed in both routers and end nodes in mechanisms that have to be deployed in both routers and end nodes in
order to work, and the problems posed by the wide deployment of order to work, and the problems posed by the wide deployment of
middleboxes today that block the use of known or unknown IP Options. middleboxes today that block the use of known or unknown IP Options.
10.1. Implementation Issues for Sending Quick-Start Requests 10.1. Implementation Issues for Sending Quick-Start Requests
Section 4.6 discusses some of the issues with deciding the initial Section 4.7 discusses some of the issues with deciding the initial
sending rate to request. Quick-Start raises additional issues about sending rate to request. Quick-Start raises additional issues about
the communication between the transport protocol and the the communication between the transport protocol and the
application, and about the use of the past history with Quick-Start application, and about the use of the past history with Quick-Start
in the end node. in the end node.
One possibility is that a protocol implementation could provide an One possibility is that a protocol implementation could provide an
API for applications to indicate when they want to request Quick- API for applications to indicate when they want to request Quick-
Start, and what rate they would like to request. In the Start, and what rate they would like to request. In the
conventional socket API this could be a socket option that is set conventional socket API this could be a socket option that is set
before a connection is established. Some applications, such as before a connection is established. Some applications, such as
skipping to change at page 57, line 28 skipping to change at page 59, line 49
congestion could also be part of a Denial of Service attack. congestion could also be part of a Denial of Service attack.
Section 9.6 discusses a potential attack on the routers' processing Section 9.6 discusses a potential attack on the routers' processing
and state load from an attack of Quick-Start Requests. Section 9.6 and state load from an attack of Quick-Start Requests. Section 9.6
also discusses a potential attack on the available Quick-Start also discusses a potential attack on the available Quick-Start
bandwidth by sending bogus Quick-Start requests for bandwidth that bandwidth by sending bogus Quick-Start requests for bandwidth that
will not in fact be used. While this impacts the global usability will not in fact be used. While this impacts the global usability
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.6.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
MUST be treated as a mutable IPv4 option, and hence completely is a mutable IPv4 option, and hence completely zeroed for AH ICV
zeroed for AH ICV calculation purposes; this is also the treatment calculation purposes; this is also the treatment required by RFC
required by RFC 2402 for unrecognized IPv4 options. The IPv6 Quick- 2402 for unrecognized IPv4 options. The IPv6 Quick-Start option's
Start option's IANA-allocated option type indicates that it is a IANA-allocated option type indicates that it is a mutable option,
mutable option, hence, according to RFC 2402, its option data MUST hence, according to RFC 2402, its option data is required to be
be zeroed for AH ICV computation purposes. See RFC 2402 for further zeroed for AH ICV computation purposes. See RFC 2402 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 58, line 13 skipping to change at page 60, line 36
Quick-Start does not remove TCP's basic congestion control Quick-Start does not remove TCP's basic congestion control
mechanisms and these will kick in when the network is heavily mechanisms and these will kick in when the network is heavily
loaded, relegating any Quick-Start mistake to a transient. loaded, relegating any Quick-Start mistake to a transient.
12. IANA Considerations 12. IANA Considerations
Quick-Start requires an IP Option and a TCP Option. Quick-Start requires an IP Option and a TCP Option.
12.1. IP Option 12.1. IP Option
Quick-Start requires that both an IPv4 and an IPv6 Option Number be Quick-Start requires both an IPv4 Option Number (Section 3.1) and an
allocated. The IPv4 Option would have a copied flag of 0, a class IPv6 Option Number (Section 3.2).
field of 00, and the assigned five-bit option number. The IPv6
Option would have the first three bits of "001" [RFC2460, Section
4.2], with the first two bits indicating that the IPv6 node skip
over this option and continue processing the header if it doesn't
recognize the option type, and the third bit indicating that the
Option Data may change en-route.
In both cases the name of the option would be "QS - Quick-Start", IPv4 Option Number:
with this document as the reference document.
Copy Class Number Value Name
---- ----- ------ ----- ----
0 00 TBD1 TBD2 QS - Quick-Start
IPv6 Option Number [RFC2460]:
HEX act chg rest
--- --- --- -----
TBD3 00 1 TBD4 Quick-Start
For the IPv6 Option Number, the first two bits indicate that the
IPv6 node skip over this option and continue processing the header
if it doesn't recognize the option type, and the third bit indicates
that the Option Data may change en-route.
In both cases this document should be listed as the reference
document.
12.2. TCP Option 12.2. TCP Option
Quick-Start also requires that a TCP Option Number be allocated. Quick-Start requires a TCP Option Number (Section 4.2).
The Length would be 4, and the Meaning would be "Quick-Start
Request", with this document as the reference document. TCP Option Number:
Kind Length Meaning
---- ------ ------------------------------
TBD5 8 Quick-Start Response
This document should be listed as the reference document.
13. Conclusions 13. Conclusions
We are presenting the Quick-Start mechanism as a simple, We are presenting the Quick-Start mechanism as a simple,
understandable, and incrementally-deployable mechanism that would be understandable, and incrementally-deployable mechanism that would be
sufficient to allow some connections to start up with large initial sufficient to allow some connections to start up with large initial
rates, or large initial congestion windows, in overprovisioned, rates, or large initial congestion windows, in overprovisioned,
high-bandwidth environments. We expect there will be an increasing high-bandwidth environments. We expect there will be an increasing
number of overprovisioned, high-bandwidth environments where the number of overprovisioned, high-bandwidth environments where the
Quick-Start mechanism, or another mechanism of similar power, could Quick-Start mechanism, or another mechanism of similar power, could
skipping to change at page 59, line 14 skipping to change at page 62, line 9
14. Acknowledgements 14. 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. Many thanks to David Black and Joe the initial simulation study. Many thanks to David Black and Joe
Touch for extensive feedback on QuickStart and IP tunnels. We also Touch for extensive feedback on Quick-Start and IP tunnels. We also
thank Mohammed Ashraf, John Border, Bob Briscoe, Martin Duke, Tom thank Mohammed Ashraf, John Border, Bob Briscoe, Martin Duke, Tom
Dunigan, Gorry Fairhurst, John Heidemann, Paul Hyder, Dina Katabi Dunigan, Mitchell Erblich, Gorry Fairhurst, John Heidemann, Paul
and Vern Paxson for feedback. Thanks also to Gorry Fairhurst for Hyder, Dina Katabi and Vern Paxson for feedback. Thanks also to
the suggestion of adding the QS Nonce to the Report of Approved Gorry Fairhurst for the suggestion of adding the QS Nonce to the
Rate. This draft builds upon the concepts described in [RFC3390], Report of Approved Rate.
[AHO98], [RFC2415], and [RFC3168]. Some of the text on Quick-Start
in tunnels was borrowed directly from RFC 3168. The version of the QS Nonce in this document is based on a proposal
from Guohan Lu [L05]. Earlier versions of this document contained
an eight-bit QS Nonce, and subsequent versions discussed the
possibility of a four-bit QS Nonce.
This draft builds upon the concepts described in [RFC3390], [AHO98],
[RFC2415], and [RFC3168]. Some of the text on Quick-Start in
tunnels was borrowed directly from RFC 3168.
This document is the development of a proposal originally by Amit This document is the development of a proposal originally by Amit
Jain for Initial Window Discovery. Jain for Initial Window Discovery.
A. Related Work A. Related Work
The Quick-Start proposal, taken together with HighSpeed TCP The Quick-Start proposal, taken together with HighSpeed TCP
[RFC3649] or other transport protocols for high-bandwidth transfers, [RFC3649] or other transport protocols for high-bandwidth transfers,
could go a significant way towards extending the range of could go a significant way towards extending the range of
performance for best-effort traffic in the Internet. However, there performance for best-effort traffic in the Internet. However, there
skipping to change at page 71, line 7 skipping to change at page 74, line 7
each rate request, over and above the current sending rate, then it each rate request, over and above the current sending rate, then it
is in a connection's interest to send as many rate requests as is in a connection's interest to send as many rate requests as
possible, even if very few of them are in fact granted. possible, even if very few of them are in fact granted.
Appendix E discusses a Report of Current Sending Rate as one Appendix E discusses a Report of Current Sending Rate as one
possible function in the Quick-Start Option. However, we have not possible function in the Quick-Start Option. However, we have not
standardized this possible use at this time. standardized this possible use at this time.
B.5. Alternate Responses to the Loss of a Quick-Start Packet B.5. Alternate Responses to the Loss of a Quick-Start Packet
Section 4.5 discusses TCP's response to the loss of a Quick-Start Section 4.6 discusses TCP's response to the loss of a Quick-Start
packet in the initial window. This section discusses several packet in the initial window. This section discusses several
alternate responses. alternate responses.
One possible alternative to reverting to the default slow-start One possible alternative to reverting to the default slow-start
after the loss of a Quick-Start packet from the initial window would after the loss of a Quick-Start packet from the initial window would
have been to halve the congestion window and continue in congestion have been to halve the congestion window and continue in congestion
avoidance. However, we note that this would not have been a avoidance. However, we note that this would not have been a
desirable response for either the connection or for the network as a desirable response for either the connection or for the network as a
whole. The packet loss in the initial window indicates that Quick- whole. The packet loss in the initial window indicates that Quick-
Start failed in finding an appropriate congestion window, meaning Start failed in finding an appropriate congestion window, meaning
skipping to change at page 73, line 4 skipping to change at page 76, line 4
We would argue that even if more fine-grained per-packet feedback We would argue that even if more fine-grained per-packet feedback
from routers was implemented, it is reasonable to have a separate from routers was implemented, it is reasonable to have a separate
mechanism such as Quick-Start for indicating an allowed initial mechanism such as Quick-Start for indicating an allowed initial
sending rate, or an allowed total sending rate after an idle or sending rate, or an allowed total sending rate after an idle or
underutilized period. underutilized period.
One difference between Quick-Start and current proposals for fine- One difference between Quick-Start and current proposals for fine-
grained per-packet feedback such as XCP is that XCP is designed to grained per-packet feedback such as XCP is that XCP is designed to
give robust performance even in the case where different packets give robust performance even in the case where different packets
within a connection routinely follow different paths. XCP achieves within a connection routinely follow different paths. XCP achieves
relatively robust performance in the presence of multi-path routing relatively robust performance in the presence of multipath routing
by using per-packet feedback, where the feedback carried in a single by using per-packet feedback, where the feedback carried in a single
packet is about the relative increase or decrease in the rate or packet is about the relative increase or decrease in the rate or
window to take effect when that particular packet is acknowledged, window to take effect when that particular packet is acknowledged,
not about the allowed sending rate for the connection as a whole. not about the allowed sending rate for the connection as a whole.
In contrast, Quick-Start sends a single Quick-Start request, and the In contrast, Quick-Start sends a single Quick-Start request, and the
answer to that request gives the allowed sending rate for an entire answer to that request gives the allowed sending rate for an entire
window of data. As a result, Quick-Start could be problematic in an window of data. As a result, Quick-Start could be problematic in an
environment where some fraction of the packets in a window of data environment where some fraction of the packets in a window of data
take path A, and the rest of the packets take path B; for example, take path A, and the rest of the packets take path B; for example,
skipping to change at page 74, line 44 skipping to change at page 77, line 44
needs for new congestion control mechanisms. This could be viewed needs for new congestion control mechanisms. This could be viewed
as a positive step towards meeting some of the more pressing current as a positive step towards meeting some of the more pressing current
needs with a simple and reasonably deployable mechanism, or needs with a simple and reasonably deployable mechanism, or
alternately, as a negative step of unnecessarily delaying more alternately, as a negative step of unnecessarily delaying more
fundamental changes. Without answering this question, we would note fundamental changes. Without answering this question, we would note
that our own approach tends to favor the incremental deployment of that our own approach tends to favor the incremental deployment of
relatively simple mechanisms, as long as the simple mechanisms are relatively simple mechanisms, as long as the simple mechanisms are
not short-term hacks but mechanisms that lead the overall not short-term hacks but mechanisms that lead the overall
architecture in the fundamentally correct direction. architecture in the fundamentally correct direction.
B.7. Alternate Implementations for a QuickStart Nonce B.7. Alternate Implementations for a Quick-Start Nonce
B.7.1. An Alternate Proposal for the QuickStart Nonce B.7.1. An Alternate Proposal for the Quick-Start Nonce
An alternate proposal for the Quick-Start Nonce from [B05] would be An alternate proposal for the Quick-Start Nonce from [B05] would be
for an n-bit field for the QS Nonce, with the sender generating a for an n-bit field for the QS Nonce, with the sender generating a
random nonce when it generates a Quick-Start Request. Each router random nonce when it generates a Quick-Start Request. Each router
that reduces the Rate Request by r would hash the QS nonce r times, that reduces the Rate Request by r would hash the QS nonce r times,
using a one-way hash function such as MD5 [RFC1321] or the secure using a one-way hash function such as MD5 [RFC1321] or the secure
hash 1 [SHA1]. The receiver returns the QS nonce to the sender. hash 1 [SHA1]. The receiver returns the QS nonce to the sender.
Because the sender knows the original value for the nonce, and the Because the sender knows the original value for the nonce, and the
original rate request, the sender knows the total number of steps s original rate request, the sender knows the total number of steps s
that the rate has been reduced. The sender then hashes the original that the rate has been reduced. The sender then hashes the original
skipping to change at page 75, line 32 skipping to change at page 78, line 32
Quick-Start request, and from the sender in verifying the nonce Quick-Start request, and from the sender in verifying the nonce
returned by the receiver. As reported in [B05], routers could returned by the receiver. As reported in [B05], routers could
protect themselves from processor exhaustion attacks by limiting the protect themselves from processor exhaustion attacks by limiting the
rate at which they will approve reductions of Quick-Start requests. rate at which they will approve reductions of Quick-Start requests.
Both the Function field and the Reserved field in the Quick-Start Both the Function field and the Reserved field in the Quick-Start
Option would allow the extension of Quick-Start to use Quick-Start Option would allow the extension of Quick-Start to use Quick-Start
requests with the alternate proposal for the Quick-Start Nonce, if requests with the alternate proposal for the Quick-Start Nonce, if
it was ever desired. it was ever desired.
B.7.2. The Earlier Request-Approved QuickStart Nonce B.7.2. The Earlier Request-Approved Quick-Start Nonce
An earlier version of this document included a Request-Approved An earlier version of this document included a Request-Approved
QuickStart Nonce (QS Nonce) that was initialized by the sender to a Quick-Start Nonce (QS Nonce) that was initialized by the sender to a
non-zero, `random' eight-bit number, along with a QS TTL that was non-zero, `random' eight-bit number, along with a QS TTL that was
initialized to the same value as the TTL in the IP header. The initialized to the same value as the TTL in the IP header. The
Request-Approved QuickStart Nonce would have been returned by the Request-Approved Quick-Start Nonce would have been returned by the
transport receiver to the transport sender in the Quick-Start transport receiver to the transport 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 that might downstream routers, or against misbehaving TCP receivers that might
be inclined to lie about whether the Rate Request was approved. be inclined to lie about whether the Rate Request was approved.
This protection is now provided by the QS Nonce, by the use of a This protection is now provided by the QS Nonce, by the use of a
random initial value for the QS TTL field, and by Quick-Start- random initial value for the QS TTL field, and by Quick-Start-
capable routers hopefully either deleting the Quick-Start Option or capable routers hopefully either deleting the Quick-Start Option or
zeroing the QS TTL and QS Nonce fields when they deny a request. zeroing the QS TTL and QS Nonce fields when they deny a request.
With the old Request-Approved QuickStart Nonce, along with the QS With the old Request-Approved Quick-Start Nonce, along with the QS
TTL field set to the same value as the TTL field in the IP header, TTL field set to the same value as the TTL field in the IP header,
the Quick-Start Request mechanism would have been self-terminating; the Quick-Start Request mechanism would have been self-terminating;
the Quick-Start Request would terminate at the first participating the Quick-Start Request would terminate at the first participating
router after a non-participating router had been encountered on the router after a non-participating router had been encountered on the
path. This minimizes unnecessary overhead incurred by routers path. This minimizes unnecessary overhead incurred by routers
because of option processing for the Quick-Start Request. In the because of option processing for the Quick-Start Request. In the
current specification, this "self-terminating" property is provided current specification, this "self-terminating" property is provided
by Quick-Start-capable routers hopefully either deleting the Quick- by Quick-Start-capable routers hopefully either deleting the Quick-
Start Option or zeroing the Rate Request field when they deny a Start Option or zeroing the Rate Request field when they deny a
request. Because the current specification uses a random initial request. Because the current specification uses a random initial
skipping to change at page 76, line 28 skipping to change at page 79, line 28
C. Quick-Start with DCCP C. Quick-Start with DCCP
DCCP is a new transport protocol for congestion-controlled, DCCP is a new transport protocol for congestion-controlled,
unreliable datagrams, intended for applications such as streaming unreliable datagrams, intended for applications such as streaming
media, Internet telephony, and on-line games. In DCCP, the media, Internet telephony, and on-line games. In DCCP, the
application has a choice of congestion control mechanisms, with the application has a choice of congestion control mechanisms, with the
currently-specified Congestion Control Identifiers (CCIDs) being currently-specified Congestion Control Identifiers (CCIDs) being
CCID 2 for TCP-like congestion control, and CCID 3 for TFRC, an CCID 2 for TCP-like congestion control, and CCID 3 for TFRC, an
equation-based form of congestion control. We refer the reader to equation-based form of congestion control. We refer the reader to
[KHF05] for a more detailed description of DCCP, and of the [RFC4340] for a more detailed description of DCCP, and of the
congestion control mechanisms. congestion control mechanisms.
Because CCID 3 uses a rate-based congestion control mechanism, it Because CCID 3 uses a rate-based congestion control mechanism, it
raises some new issues about the use of Quick-Start with transport raises some new issues about the use of Quick-Start with transport
protocols. In this document we don't attempt to specify the use of protocols. In this document we don't attempt to specify the use of
Quick-Start with DCCP. However, we do discuss some of the issues Quick-Start with DCCP. However, we do discuss some of the issues
that might arise. that might arise.
In considering the use of Quick-Start with CCID 3 for requesting a In considering the use of Quick-Start with CCID 3 for requesting a
higher initial sending rate, the following questions arise: higher initial sending rate, the following questions arise:
skipping to change at page 80, line 8 skipping to change at page 83, line 8
Report of Current Sending Rate: A Quick-Start Request with the Report of Current Sending Rate: A Quick-Start Request with the
`Report of Current Sending Rate' codepoint set in the Function field `Report of Current Sending Rate' codepoint set in the Function field
would be using the Rate Request field to report the current would be using the Rate Request field to report the current
estimated sending rate for that connection. This could accompany a estimated sending rate for that connection. This could accompany a
second Quick-Start Request in the same packet containing a standard second Quick-Start Request in the same packet containing a standard
rate request, for a connection that is using Quick-Start to increase rate request, for a connection that is using Quick-Start to increase
its current sending rate. its current sending rate.
Request to Increase Sending Rate: A codepoint for `Request to Request to Increase Sending Rate: A codepoint for `Request to
Increase Sending Rate' in the Function field would indicate that the Increase Sending Rate' in the Function field would indicate that the
connection is not idle or just starting up, but is attemmpting to connection is not idle or just starting up, but is attempting to use
use Quick-Start to increase its current sending rate. This Quick-Start to increase its current sending rate. This codepoint
codepoint would not change the semantics of the Rate Request field. would not change the semantics of the Rate Request field.
RTT Estimate: If a codepoint for `RTT Estimate' was used, a field RTT Estimate: If a codepoint for `RTT Estimate' was used, a field
for the RTT Estimate would contain one or more bits giving the for the RTT Estimate would contain one or more bits giving the
sender's rough estimate of the round-trip time, if known. E.g., the sender's rough estimate of the round-trip time, if known. E.g., the
sender could estimate whether the RTT was greater or less than 200 sender could estimate whether the RTT was greater or less than 200
ms. Alternately, if the sender had an estimate of the RTT when it ms. Alternately, if the sender had an estimate of the RTT when it
sends the Rate Request, the two-bit Reserved field at the end of the sends the Rate Request, the two-bit Reserved field at the end of the
Quick-Start Option could be used for a coarse-grained encoding of Quick-Start Option could be used for a coarse-grained encoding of
the RTT. the RTT.
skipping to change at page 81, line 5 skipping to change at page 84, line 5
Do Not Decrement: A Do Not Decrement codepoint could be used for a Do Not Decrement: A Do Not Decrement codepoint could be used for a
Quick-Start request where the sender would rather have the request Quick-Start request where the sender would rather have the request
denied than to have the rate request decremented in the network. denied than to have the rate request decremented in the network.
This could be used if the sender was only interested in using Quick- This could be used if the sender was only interested in using Quick-
Start if the original rate request was approved. Start if the original rate request was approved.
Temporary Bandwidth Use: A Temporary codepoint has been proposed to Temporary Bandwidth Use: A Temporary codepoint has been proposed to
indicate that a connection would only use the requested bandwidth indicate that a connection would only use the requested bandwidth
for a single time interval. for a single time interval.
F. Feedback from Bob Briscoe
[B05] is a review of an earlier version of the Quick-Start proposal
that discusses a number of potential problems with Quick-Start, and
argues for an alternate approach for policing congestion in networks
using re-feedback ([BJCG+05], [BJS05]). However, [B05] didn't
oppose the move to Quick-Start to experimental status as long as its
applicability is made clear.
F.1. Potential Deployment Scenarios
[B05] argues that because the sender's trustworthiness is not
necessarily verified, Quick-Start, if it is remain stateless, should
be confined to environments where every source is trusted. Section
3.2 of [B05] argues that either (1) Quick-Start should be
recommended for deployment only in trusted environments, or (2)
Quick-Start could be recommended for deployment also in untrusted
environments, with flow state required at some or all routers.
Since [B05], we have added the Report of Approved Rate as a required
part of Quick-Start, and discussed ways that this could be used by
routers or by traffic policers, if desired, to check on the use of
Quick-Start by senders. We also note that senders can send at an
initial high rate even in the absence of Quick-Start, in the current
network; that is, in our view, Quick-Start does not change the
dangers to the network from malicious senders. Thus, while we are
clearly not recommending Quick-Start for widespread deployment in
the global Internet, we also don't feel the need to explicitly
restrict its deployment to environments where every source is
trusted, or to explicitly require per-flow state at Quick-Start
routers. We assume that Quick-Start will only be enabled at routers
if the system administrators feel either that they have sufficient
trust in senders, sufficient policing mechanisms for checking for
misbehaving nodes, or sufficient oversite to disable Quick-Start if
it is determined to be causisng problems..
F.2. Misbehaving Senders and Receivers
Some of the criticisms of Quick-Start in [B05] are criticisms for
mechanisms that allocate rates to senders, but this is not what
Quick-Start does. Quick-Start requests apply to individual
connections, not to unique addresses or unique tuples of addresses.
Further, the approval by routers of Quick-Start requests does not
result in an allocation of bandwidth for the sender making that
request; the approval by routers does not result in any allocation
of bandwidth at all. The state used by routers from past Quick-
Start approvals is used only to guide the router in its approval or
rejection of future Quick-Start requests. We have added text to
this document to make this quite explicit.
[B05] discusses the dangers of sender spoofing and identity
splitting. Identify splitting would not be a problem with Quick-
Start, because Quick-Start requests apply to individual connections,
not to unique addresses or unique tuples of addresses. Because
Quick-Start does not allocate rates to senders, sender-spoofing is
also not a critical issue (except as it would make it more difficult
for those Quick-Start routers that maintain per-flow state to
identify senders that send Quick-Start requests that are not in fact
used, due either to malicious requests or due to requests denied
downstream).
In Section 3.3, [B05] says that "the lack of a secure binding
between a request and subsequent traffic means that any other node
could send a burst of traffic and claim it requests it, with no-one
being able to prove it didn't." In the current Internet, any node
can send a burst of traffic any time it would like, even without
Quick-Start. However, in the absense of Quick-Start, sending at a
high rate is not always in the sender's interest, as the packets
that are sent might have a high probability of being dropped in the
network, particularly in the absense of Quick-Start. The addition
of the Report of Approved Rate to Quick-Start gives traffic policers
the ability to check on some of the potential abuses of Quick-Start,
if they so desire.
In Section 3.8, [B05] states that "not only do Quick-Start senders
have to be trusted, but also other senders who could claim their
data had been authorised by a Quick-Start response when it hadn't
(Section 3.3)." In response, we would again clarify that with Quick-
Start, the Quick-Start request makes no difference in how the
subsequent Quick-Start data packets are treated at the router,
compared to non-Quick-Start data packets. Thus, a sender's claim
that its data results from a previous Quick-Start request should
make no difference in how those data packets are treated at routers.
The approval of a Quick-Start request is not a promise by the router
that the subsequent data packets will receive differential treatment
at the router; it is only a statement from the router that the
router believes that the Quick-Start data packets will not change
the current under-utilized state of the router. We have clarified
this in Section 3.3 of this document.
F.3. Fairness
In its abstract, [B05] says the following: "Because traffic variance
will always blur the boundary, we argue that under-utilisation
should be treated as the extreme of a spectrum where fairness is
always an issue to some extent."
The specification for Quick-Start now says in section 2 the
following: "A router should only approve a Quick-Start request if
the output link is underutilized, and if the router judges that the
output link will continue to be underutilized if the request is
approved."
We changed the quote "for a mechanism for requesting an initial
sending rate in an underutilized environment, the fairness issues of
a general congestion control mechanism go away" to the following:
"because Quick-Start is a mechanism for requesting an initial
sending rate in an underutilized environment, its fairness issues
are less severe than those of a general congestion control
mechanism" in section B.6 However, we did not add the sentence
recommended in section 3.4 of [B05], that "Quick-Start is targeted
at an experimental environment where the more intractable issues can
be set aside". In particular, we don't agree that Quick-Start needs
to be targeted only for environments where fairness is not an issue.
F.4. Models of Under-Utilization
[B05] states that "One of the under-utilisation assumptions I had in
my head while reading the paper was that any one host is generally
able to over-fill available capacity, but that, given a high rate,
the flow would end quickly." We are sorry that this is the model
that the author inferred from the draft, but we can give assurances
that this `one big flow at a time" model was *never* the implicit or
explicit model underlying the Quick-Start design. (We would also
note that every version of this document since the first version
back in 2002 has discussed router responses when the router
experiences a flood of Quick-Start requests.)
[B05] also says the following: "By reverse engineering this
algorithm, it was possible to guess that there was an assumption
that host capacity was smaller than the network's, so meeting a
request in full would still leave a lot of spare capacity for the
next request." Again, we would like to clarify that there has been
no such assumption underlying the Quick-Start design.
F.5. Router Algorithms as Local Policy
[B05] recommends that either this document should set constraints on
possible router algorithms, or say that experiments are needed "in
order to establish constraints required on router algorithms for
interworking, robustness, fairness etc." While it is possible that
experiments will lead to an understanding of constraints that are
needed on router algorithms, we think it is more likely that there
will not be a need for explicit constraints on router algorithms for
accepting or rejecting Quick-Start requests.
Our approach is that, while the Quick-Start IETF documentation
standardizes the semantics of Quick-Start and the format of the
Quick-Start IP Option and the Quick-Start Response TCP Option, the
IETF documentation should not and does not standardize the
algorithms used at routers for approving or denying Quick-Start
request. Appendix E in this document has presented one possible
router algorithm for approving or denying Quick-Start requests, but
further discussion of the range of possibilities in router
algorithms is available elsewhere [SAF06]. As an example, the
fairness criteria that routers might apply in granting or denying
Quick-Start requests are discussed in [SAF06], but are not discussed
in the same detail in this document. This document leaves routers
free to apply any criteria they choose in accepting or denying
Quick-Start requests, modulo the requirements given in Section 3.3
above.
This approach of the Quick-Start router algorithm as a matter of
local policy is consistent with the approach in RFC 3168 on
standardizing Explicit Congestion Notification (ECN). RFC 3168
standardized the semantics of the ECN field, but did not standardize
a router's Active Queue Management mechanisms for deciding when to
set the Congestion Experienced codepoint in packets.
F.6. An Alternate Proposal
[B05] proposes an alternate to Quick-Start where endpoints allocate
rates to themselves. [B05] argues that adding rate allocation to
interior routers is not the fundamentally correct direction.
[B05] argues for an approach that associates senders with their
ingress attachment point, with routers reporting their impairment
status back to the sender [BJCG+05,BJS05]. The source declares the
impairment that it believes it will accumulate along the path, and
routers effectively subtract the local impairment status. If the
sender is reporting correctly, and the impairment has not changed
significantly from one round-trip time to the next, the reported
impairment at the egress router should be close to zero.
Normative References Normative References
[RFC793] J. Postel, Transmission Control Protocol, RFC 793, [RFC793] J. Postel, Transmission Control Protocol, RFC 793,
September 1981. September 1981.
[RFC1191] Mogul, J. and S. Deering, Path MTU Discovery, RFC 1191, [RFC1191] Mogul, J. and S. Deering, Path MTU Discovery, RFC 1191,
November 1990. November 1990.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 86, line 4 skipping to change at page 84, line 49
[RFC1812] F. Baker (ed.). Requirements for IP Version 4 Routers. RFC [RFC1812] F. Baker (ed.). Requirements for IP Version 4 Routers. RFC
1812, June 1995. 1812, June 1995.
[RFC2003] Perkins, C., IP Encapsulation within IP, RFC 2003, [RFC2003] Perkins, C., IP Encapsulation within IP, RFC 2003,
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.
[RFC2409] D. Harkins and D. Carrel, The Internet Key Exchange (IKE), [RFC2401] S. Kent and R. Atkinson, Security Architecture for the
RFC 2409, November 1998. Internet Protocol, RFC 2401, November 1998.
[RFC2401] S. Kent and R. Atkinson. Security Architecture for the
Internet Protocol. RFC 2401, November 1998.
[2401bis] S. Kent and K. Seo, Security Architecture for the Internet
Protocol, internet-draft draft-ietf-ipsec-rfc2401bis-06.txt, work-
in-progress, March 2005.
[RFC2402] S. Kent and R. Atkinson. IP Authentication Header. RFC [RFC2402] S. Kent and R. Atkinson. IP Authentication Header. RFC
2402, November 1998. 2402, November 1998.
[2402bis] S. Kent, IP Authentication Header, internet-draft draft- [RFC2409] D. Harkins and D. Carrel, The Internet Key Exchange (IKE),
ietf-ipsec-rfc2402bis-11.txt work-in-progress, March 2005. 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.
[RFC2488] M. Allman, D. Glover, and L. Sanchez. Enhancing TCP Over [RFC2488] M. Allman, D. Glover, and L. Sanchez. Enhancing TCP Over
Satellite Channels using Standard Mechanisms. RFC 2488. January Satellite Channels using Standard Mechanisms. RFC 2488. January
1999. 1999.
[RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer, and P. Traina,
Generic Routing Encapsulation (GRE), RFC 2784, March 2000.
[RFC2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, and [RFC2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, and
B. Palter, Layer Two Tunneling Protocol "L2TP", RFC 2661, August B. Palter, Layer Two Tunneling Protocol "L2TP", RFC 2661, August
1999. 1999.
[RFC2960] R. Stewart, et. al. Stream Control Transmission Protocol. [RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer, and P. Traina,
Generic Routing Encapsulation (GRE), RFC 2784, March 2000.
[RFC2960] R. Stewart, et al. Stream Control Transmission Protocol.
RFC 2960, October 2000. RFC 2960, October 2000.
[RFC3031] E. Rosen, A. Viswanathan, and R. Callon. Multiprotocol [RFC3031] E. Rosen, A. Viswanathan, and R. Callon. Multiprotocol
Label Switching Architecture. RFC 3031. January 2001. Label Switching Architecture. RFC 3031. January 2001.
[RFC3124] H. Balakrishnan and S. Seshan. The Congestion Manager. RFC [RFC3124] H. Balakrishnan and S. Seshan. The Congestion Manager. RFC
3124. June 2001. 3124. June 2001.
[RFC3234] B. Carpenter and S. Brim, Middleboxes: Taxonomy and [RFC3234] B. Carpenter and S. Brim, Middleboxes: Taxonomy and
Issues, RFC 3234, February 2002. Issues, RFC 3234, February 2002.
skipping to change at page 87, line 31 skipping to change at page 86, line 20
[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.
[RFC4301] S. Kent and K. Seo, Security Architecture for the Internet
Protocol, RFC 4301, December 2005.
[RFC4302] S. Kent, IP Authentication Header, RFC 4302, December
2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005. 4306, December 2005.
[RFC4340] E. Kohler, M. Handley, and S. Floyd, Datagram Congestion
Control Protocol (DCCP), RFC 4340, March 2006.
[RFC4341] S. Floyd and E. Kohler, Profile for Datagram Congestion
Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion
Control, RFC 4341, March 2006.
[AHO98] M. Allman, C. Hayes and S. Ostermann. An evaluation of TCP [AHO98] M. Allman, C. Hayes and S. Ostermann. An evaluation of TCP
with Larger Initial Windows. ACM Computer Communication Review, July with Larger Initial Windows. ACM Computer Communication Review, July
1998. 1998.
[B05] B. Briscoe, Review: Quick-Start for TCP and IP, internet-draft [B05] B. Briscoe, Review: Quick-Start for TCP and IP, internet-draft
draft-briscoe-tsvwg-quickstart-rvw-00, work-in-progress, URL draft-briscoe-tsvwg-quickstart-rvw-00, work-in-progress, URL
"http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html", November 2005. "http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html", November 2005.
[BJCG+05] Briscoe, B., Jacquet, A., Di Cairano-Gilfedder, C., [BJCG+05] Briscoe, B., Jacquet, A., Di Cairano-Gilfedder, C.,
Salvatori, A., Soppera, A., and M. Koyabe, "Policing Congestion Salvatori, A., Soppera, A., and M. Koyabe, "Policing Congestion
Response in an Internetwork Using Re-Feedback", SIGCOMM, August Response in an Internetwork Using Re-Feedback", SIGCOMM, August
2005. 2005.
[BJS05] Briscoe, B., Jacquet, A., and A. Salvatori, "Re-ECN: Adding
Accountability for Causing Congestion to TCP/IP", internet-draft
draft-briscoe-tsvwg-re-ecn-tcp-00.txt, work-in-progress, October
2005.
[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.
[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.
[H05] P. Hoffman, email, October 2005. Citation for acknowledgement [H05] P. Hoffman, email, October 2005. Citation for acknowledgement
skipping to change at page 88, line 40 skipping to change at page 87, line 38
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://www.icir.org/mallman/papers/". "http://www.icir.org/mallman/papers/".
[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/".
[KHF05] E. Kohler, M. Handley, and S. Floyd, Datagram Congestion
Control Protocol (DCCP), internet draft draft-ietf-dccp-spec-11.txt,
work in progress, March 2005.
[KK03] A. Kuzmanovic and E. W. Knightly. TCP-LP: A Distributed [KK03] A. Kuzmanovic and E. W. Knightly. TCP-LP: A Distributed
Algorithm for Low Priority Data Transfer. INFOCOM 2003, April 2003. Algorithm for Low Priority Data Transfer. INFOCOM 2003, April 2003.
[KSEPA04] Rajesh Krishnan, James Sterbenz, Wesley Eddy, Craig [KSEPA04] Rajesh Krishnan, James Sterbenz, Wesley Eddy, Craig
Partridge, Mark Allman. Explicit Transport Error Notification (ETEN) Partridge, Mark Allman. Explicit Transport Error Notification (ETEN)
for Error-Prone Wireless and Satellite Networks. Computer Networks, for Error-Prone Wireless and Satellite Networks. Computer Networks,
46(3), October 2004. 46(3), October 2004.
[L05] Guohan Lu, Nonce in TCP Quick Start, draft, September 2005. [L05] Guohan Lu, Nonce in TCP Quick Start, draft, September 2005.
URL "http://www.net-glyph.org/~lgh/nonce-usage.pdf". URL "http://www.net-glyph.org/~lgh/nonce-usage.pdf".
[MH06] M. Mathis and J. Heffner, Packetization Layer Path MTU
Discovery, internet-draft draft-ietf-pmtud-method-07.txt, work in
progress, June 2006.
[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/".
[MAF05] Alberto Medina, Mark Allman, and Sally Floyd. Measuring the [MAF05] Alberto Medina, Mark Allman, and Sally Floyd. Measuring the
Evolution of Transport Protocols in the Internet. Computer Evolution of Transport Protocols in the Internet. Computer
Communications Review, April 2005. Communications Review, April 2005.
[MaxNet] MaxNet Home Page, URL [MaxNet] MaxNet Home Page, URL
skipping to change at page 90, line 10 skipping to change at page 89, line 7
[SGF05] Singh, M., Guha, S., and P. Francis, "Utilizing spare [SGF05] Singh, M., Guha, S., and P. Francis, "Utilizing spare
network bandwidth to improve TCP performance", ACM SIGCOMM 2005 Work network bandwidth to improve TCP performance", ACM SIGCOMM 2005 Work
in Progress session , August 2005, in Progress session , August 2005,
https://www.guha.cc/saikat/pub/sigcomm05-lowtcp.pdf. https://www.guha.cc/saikat/pub/sigcomm05-lowtcp.pdf.
[SHA1] "Secure Hash Standard", FIPS, U.S. Department of Commerce, [SHA1] "Secure Hash Standard", FIPS, U.S. Department of Commerce,
Washington, D.C. publication 180-1, April 1995. Washington, D.C. publication 180-1, April 1995.
[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 publicly
available; citation for acknowledgement purposes only. available; citation for acknowledgement purposes only.
[V02] A. Venkataramani, R. Kokku, and M. Dahlin. TCP Nice: A [V02] A. Venkataramani, R. Kokku, and M. Dahlin. TCP Nice: A
Mechanism for Background Transfers. OSDI 2002. Mechanism for Background Transfers. OSDI 2002.
[VH97] V. Visweswaraiah and J. Heidemann, Improving Restart of Idle
TCP Connections, Technical Report 97-661, University of Southern
California, November 1997.
[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://www.welzl.at/research/publications/". "http://www.welzl.at/research/publications/".
[ZDPS01] Y. Zhang, N. Duffield, V. Paxson, and S. Shenker, On the [ZDPS01] Y. Zhang, N. Duffield, V. Paxson, and S. Shenker, On the
Constancy of Internet Path Properties, Proc. ACM SIGCOMM Internet Constancy of Internet Path Properties, Proc. ACM SIGCOMM Internet
Measurement Workshop, November 2001. Measurement Workshop, November 2001.
 End of changes. 90 change blocks. 
426 lines changed or deleted 398 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/