draft-ietf-tsvwg-quickstart-03.txt   draft-ietf-tsvwg-quickstart-04.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-03.txt ICIR draft-ietf-tsvwg-quickstart-04.txt ICIR
Expires: October 2006 A. Jain Expires: December 2006 A. Jain
F5 Networks F5 Networks
P. Sarolahti P. Sarolahti
Nokia Research Center Nokia Research Center
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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 October 2006. This Internet-Draft will expire on December 2006.
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
Quick-Start request had been approved by all of the routers along Quick-Start request had been approved by all of the routers along
the path. As a result of these concerns, and as a result of the the path. As a result of these concerns, and as a result of the
difficulties and seeming absence of motivation for routers such as difficulties and seeming absence of motivation for routers such as
core routers to deploy Quick-Start, Quick-Start is being proposed as core routers to deploy Quick-Start, Quick-Start is being proposed as
a mechanism that could be of use in controlled environments, and not a mechanism that could be of use in controlled environments, and not
as a mechanism that would be intended or appropriate for ubiquitous as a mechanism that would be intended or appropriate for ubiquitous
deployment in the global Internet. deployment in the global 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-03:
* Added a discussion of the lower limit of the rate request
of 80 kbps, from feedback from Gorry Fairhurst.
* Added the QS Nonce to the QS Approved Rate.
From feedback from Gorry Fairhurst.
* Moved the Related Work section to the appendix.
From feedback from Gorry Fairhurst.
Changes from draft-ietf-tsvwg-quickstart-02: Changes from draft-ietf-tsvwg-quickstart-02:
* Some general editing. * Some general editing.
* Said that if the receiver receives a Quick-Start Request * Said that if the receiver receives a Quick-Start Request
with a rate of zero, then the receiver SHOULD NOT send with a rate of zero, then the receiver SHOULD NOT send
a Quick-Start response. And that if the sender a Quick-Start response. And that if the sender
receives an acknowledgement of its packet with no receives an acknowledgement of its packet with no
Quick-Start response, then the sender MUST assume that the Quick-Start response, then the sender MUST assume that the
request was denied, and send a Report of Approved Rate request was denied, and send a Report of Approved Rate
skipping to change at page 4, line 20 skipping to change at page 4, line 31
* Clarified in Section 3.3 on "Processing the Quick-Start * Clarified in Section 3.3 on "Processing the Quick-Start
Request at Routers" that a router will have to consider Request at Routers" that a router will have to consider
the previous Quick-Start requests in approving a new one. the previous Quick-Start requests in approving a new one.
* In Section 9.3 on "Quick-Start with QoS-enabled Traffic", * In Section 9.3 on "Quick-Start with QoS-enabled Traffic",
which says that routers are free to take into account which says that routers are free to take into account
the diff-serv codepoint in considering QS requests, clarified the diff-serv codepoint in considering QS requests, clarified
that routers are also free to take into account their own that routers are also free to take into account their own
understanding of priorities. understanding of priorities.
* Added the Temporary bit to Appendix D on "Possible Additional * Added the Temporary bit to Appendix on "Possible Additional
Uses for the Quick-Start Option". Clarified that the Quick-Start Uses for the Quick-Start Option". Clarified that the Quick-Start
mechanism is not designed to help routers achieve full link mechanism is not designed to help routers achieve full link
utilization. utilization.
* Editing from feedback from Gorry Fairhurst. * Editing from feedback from Gorry Fairhurst.
Changes from draft-ietf-tsvwg-quickstart-01: Changes from draft-ietf-tsvwg-quickstart-01:
* Added a citation to SPAND: Speeding Up Short Data Transfers. * Added a citation to SPAND: Speeding Up Short Data Transfers.
* Added a sentence in Section 8.1 on "Implementation Issues for * Added a sentence in Section 8.1 on "Implementation Issues for
Processing Quick-Start Requests" about multi-access links. Processing Quick-Start Requests" about multi-access links.
* Mentioned the IP Router Alert option, RFC 2113, in Appendix * Mentioned the IP Router Alert option, RFC 2113, in Appendix.
A.1.1.
* Added a discussion of lower-than-best-effort service. * Added a discussion of lower-than-best-effort service.
* Added a few sentences about the requirements for * Added a few sentences about the requirements for
randomness in the nonce. randomness in the nonce.
* Changed the name of the option from the Quick-Start Request * Changed the name of the option from the Quick-Start Request
Option to the Quick-Start Option. Option to the Quick-Start Option.
* Changed the semantics of the Reserved field to the Function * Changed the semantics of the Reserved field to the Function
field, adding that a Quick-Start option is only interpreted field, adding that a Quick-Start option is only interpreted
as a request if this field is zero. as a request if this field is zero.
* Changed the "Reporting Approved Rate" option from a * Changed the "Reporting Approved Rate" option from a
"Possible Use" in Appendix D to a required use in Section 3.1, "Possible Use" in Appendix to a required use in Section 3.1,
to allow routers and receivers some protection against to allow routers and receivers some protection against
misbehaving senders. misbehaving senders.
* Changes from feedback from Bob Briscoe: * Changes from feedback from Bob Briscoe:
- Added Appendix E about Sections 1-3 of - Added Appendix about Sections 1-3 of
Bob Briscoe's document. Bob Briscoe's document.
- Added a clarification that the approval of a - Added a clarification that the approval of a
Quick-Start request at a router does not affect Quick-Start request at a router does not affect
the treatment of the subsequent arriving the treatment of the subsequent arriving
Quick-Start data packets. Quick-Start data packets.
- Added the one-way hash function as an alternate - Added the one-way hash function as an alternate
implementation for the QS Nonce. implementation for the QS Nonce.
- Clarified the phrase "incrementally deployable", adding - Clarified the phrase "incrementally deployable", adding
the following: the following:
"We note that while Quick-Start is incrementally deployable "We note that while Quick-Start is incrementally deployable
in this sense, a Quick-Start request can not be approved in this sense, a Quick-Start request can not be approved
for a particular connection unless both end-nodes and all for a particular connection unless both end-nodes and all
of the routers along the path have been configured to of the routers along the path have been configured to
support Quick-Start." support Quick-Start."
- Clarified semantics about additional rate. - Clarified semantics about additional rate.
skipping to change at page 8, line 22 skipping to change at page 8, line 22
3.1. The Quick-Start Option for IPv4. . . . . . . . . . . . . 16 3.1. The Quick-Start Option for IPv4. . . . . . . . . . . . . 16
3.2. The Quick-Start Option for IPv6. . . . . . . . . . . . . 20 3.2. The Quick-Start Option for IPv6. . . . . . . . . . . . . 20
3.3. Processing the Quick-Start Request at 3.3. Processing the Quick-Start Request at
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.1. Processing the Report of Approved 3.3.1. Processing the Report of Approved
Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4. The QS Nonce . . . . . . . . . . . . . . . . . . . . . . 23 3.4. The QS Nonce . . . . . . . . . . . . . . . . . . . . . . 23
4. The Quick-Start Mechanisms in TCP . . . . . . . . . . . . . . 25 4. The Quick-Start Mechanisms in TCP . . . . . . . . . . . . . . 25
4.1. Sending the Quick-Start Request. . . . . . . . . . . . . 26 4.1. Sending the Quick-Start Request. . . . . . . . . . . . . 26
4.2. The Quick-Start Response Option in the TCP 4.2. The Quick-Start Response Option in the TCP
header. . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 header. . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3. TCP: Sending the Quick-Start Response. . . . . . . . . . 28 4.3. TCP: Sending the Quick-Start Response. . . . . . . . . . 29
4.4. TCP: Receiving and Using the Quick-Start 4.4. TCP: Receiving and Using the Quick-Start
Response Packet . . . . . . . . . . . . . . . . . . . . . . . 29 Response Packet . . . . . . . . . . . . . . . . . . . . . . . 29
4.5. TCP: Responding to a Loss of a Quick-Start 4.5. TCP: Responding to a Loss of a Quick-Start
Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.6. TCP: A Quick-Start Request for a Larger Ini- 4.6. TCP: A Quick-Start Request for a Larger Ini-
tial Window . . . . . . . . . . . . . . . . . . . . . . . . . 32 tial Window . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.6.1. Interactions with Path MTU Discovery. . . . . . . . 32 4.6.1. Interactions with Path MTU Discovery. . . . . . . . 33
4.6.2. Quick-Start Request Packets that are 4.6.2. Quick-Start Request Packets that are
Discarded by Routers or Middleboxes. . . . . . . . . . . . 33 Discarded by Routers or Middleboxes. . . . . . . . . . . . 33
4.7. TCP: A Quick-Start Request in the Middle of 4.7. TCP: A Quick-Start Request in the Middle of
a Connection. . . . . . . . . . . . . . . . . . . . . . . . . 34 a Connection. . . . . . . . . . . . . . . . . . . . . . . . . 34
4.8. An Example Quick-Start Scenario with TCP . . . . . . . . 35 4.8. An Example Quick-Start Scenario with TCP . . . . . . . . 35
5. Quick-Start and IPsec AH. . . . . . . . . . . . . . . . . . . 35 5. Quick-Start and IPsec AH. . . . . . . . . . . . . . . . . . . 36
6. Quick-Start in IP Tunnels and MPLS. . . . . . . . . . . . . . 36 6. Quick-Start in IP Tunnels and MPLS. . . . . . . . . . . . . . 37
6.1. Simple Tunnels That Are Compatible with 6.1. Simple Tunnels That Are Compatible with
Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 38 Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.1.1. Simple Tunnels that are Aware of Quick- 6.1.1. Simple Tunnels that are Aware of Quick-
Start. . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Start. . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2. Simple Tunnels That Are Not Compatible with 6.2. Simple Tunnels That Are Not Compatible with
Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 39 Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.3. Tunnels That Support Quick-Start . . . . . . . . . . . . 40 6.3. Tunnels That Support Quick-Start . . . . . . . . . . . . 41
6.4. Quick-Start and MPLS . . . . . . . . . . . . . . . . . . 41 6.4. Quick-Start and MPLS . . . . . . . . . . . . . . . . . . 42
7. The Quick-Start Mechanism in other Transport Pro- 7. The Quick-Start Mechanism in other Transport Pro-
tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8. Using Quick-Start . . . . . . . . . . . . . . . . . . . . . . 42 8. Using Quick-Start . . . . . . . . . . . . . . . . . . . . . . 43
8.1. Determining the Rate to Request. . . . . . . . . . . . . 42 8.1. Determining the Rate to Request. . . . . . . . . . . . . 43
8.2. Deciding the Permitted Rate Request at a 8.2. Deciding the Permitted Rate Request at a
Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9. Evaluation of Quick-Start . . . . . . . . . . . . . . . . . . 44 9. Evaluation of Quick-Start . . . . . . . . . . . . . . . . . . 45
9.1. Benefits of Quick-Start. . . . . . . . . . . . . . . . . 44 9.1. Benefits of Quick-Start. . . . . . . . . . . . . . . . . 45
9.2. Costs of Quick-Start . . . . . . . . . . . . . . . . . . 44 9.2. Costs of Quick-Start . . . . . . . . . . . . . . . . . . 45
9.3. Quick-Start with QoS-enabled Traffic . . . . . . . . . . 46 9.3. Quick-Start with QoS-enabled Traffic . . . . . . . . . . 47
9.4. Protection against Misbehaving Nodes . . . . . . . . . . 47 9.4. Protection against Misbehaving Nodes . . . . . . . . . . 47
9.4.1. Misbehaving Senders . . . . . . . . . . . . . . . . 47 9.4.1. Misbehaving Senders . . . . . . . . . . . . . . . . 47
9.4.2. Receivers Lying about Whether the 9.4.2. Receivers Lying about Whether the
Request was Approved . . . . . . . . . . . . . . . . . . . 48 Request was Approved . . . . . . . . . . . . . . . . . . . 49
9.4.3. Receivers Lying about the Approved 9.4.3. Receivers Lying about the Approved
Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
9.4.4. Collusion between Misbehaving Routers . . . . . . . 50 9.4.4. Collusion between Misbehaving Routers . . . . . . . 51
9.5. Misbehaving Middleboxes and the IP TTL . . . . . . . . . 51 9.5. Misbehaving Middleboxes and the IP TTL . . . . . . . . . 52
9.6. Attacks on Quick-Start . . . . . . . . . . . . . . . . . 52 9.6. Attacks on Quick-Start . . . . . . . . . . . . . . . . . 52
9.7. Simulations with Quick-Start . . . . . . . . . . . . . . 52 9.7. Simulations with Quick-Start . . . . . . . . . . . . . . 53
10. Implementation and Deployment Issues . . . . . . . . . . . . 53 10. Implementation and Deployment Issues . . . . . . . . . . . . 53
10.1. Implementation Issues for Sending Quick- 10.1. Implementation Issues for Sending Quick-
Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 53 Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 54
10.2. Implementation Issues for Processing Quick- 10.2. Implementation Issues for Processing Quick-
Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 54 Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 54
10.3. Possible Deployment Scenarios . . . . . . . . . . . . . 54 10.3. Possible Deployment Scenarios . . . . . . . . . . . . . 55
10.4. A Comparison with the Deployment Problems 10.4. A Comparison with the Deployment Problems
of ECN. . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 of ECN. . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
11. Security Considerations. . . . . . . . . . . . . . . . . . . 56 11. Security Considerations. . . . . . . . . . . . . . . . . . . 57
12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 57 12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 58
12.1. IP Option . . . . . . . . . . . . . . . . . . . . . . . 57 12.1. IP Option . . . . . . . . . . . . . . . . . . . . . . . 58
12.2. TCP Option. . . . . . . . . . . . . . . . . . . . . . . 58 12.2. TCP Option. . . . . . . . . . . . . . . . . . . . . . . 58
13. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 58 13. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . 58
13.1. Fast Start-ups without Explicit Information 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 59
from Routers. . . . . . . . . . . . . . . . . . . . . . . . . 58 A. Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 59
13.2. Optimistic Sending without Explicit Infor- A.1. Fast Start-ups without Explicit Information
mation from Routers . . . . . . . . . . . . . . . . . . . . . 60 from Routers. . . . . . . . . . . . . . . . . . . . . . . . . 59
13.3. Fast Start-ups with other Information from A.2. Optimistic Sending without Explicit Informa-
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 tion from Routers . . . . . . . . . . . . . . . . . . . . . . 61
13.4. Fast Start-ups with more Fine-Grained Feed- A.3. Fast Start-ups with other Information from
back from Routers . . . . . . . . . . . . . . . . . . . . . . 61 Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
13.5. Fast Start-ups with Lower-Than-Best-Effort A.4. Fast Start-ups with more Fine-Grained Feed-
Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 back from Routers . . . . . . . . . . . . . . . . . . . . . . 63
14. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . 63 A.5. Fast Start-ups with Lower-Than-Best-Effort
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 63 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
A. Design Decisions. . . . . . . . . . . . . . . . . . . . . . . 63 B. Design Decisions. . . . . . . . . . . . . . . . . . . . . . . 64
A.1. Alternate Mechanisms for the Quick-Start B.1. Alternate Mechanisms for the Quick-Start
Request: ICMP and RSVP. . . . . . . . . . . . . . . . . . . . 63 Request: ICMP and RSVP. . . . . . . . . . . . . . . . . . . . 64
A.1.1. ICMP. . . . . . . . . . . . . . . . . . . . . . . . 64 B.1.1. ICMP. . . . . . . . . . . . . . . . . . . . . . . . 64
A.1.2. RSVP. . . . . . . . . . . . . . . . . . . . . . . . 65 B.1.2. RSVP. . . . . . . . . . . . . . . . . . . . . . . . 65
A.2. Alternate Encoding Functions . . . . . . . . . . . . . . 66 B.2. Alternate Encoding Functions . . . . . . . . . . . . . . 66
A.3. The Quick-Start Request: Packets or Bytes? . . . . . . . 67 B.3. The Quick-Start Request: Packets or Bytes? . . . . . . . 68
A.4. Quick-Start Semantics: Total Rate or Addi- B.4. Quick-Start Semantics: Total Rate or Addi-
tional Rate?. . . . . . . . . . . . . . . . . . . . . . . . . 68 tional Rate?. . . . . . . . . . . . . . . . . . . . . . . . . 69
A.5. Alternate Responses to the Loss of a Quick- B.5. Alternate Responses to the Loss of a Quick-
Start Packet. . . . . . . . . . . . . . . . . . . . . . . . . 69 Start Packet. . . . . . . . . . . . . . . . . . . . . . . . . 71
A.6. Why Not Include More Functionality?. . . . . . . . . . . 70 B.6. Why Not Include More Functionality?. . . . . . . . . . . 71
A.7. Alternate Implementations for a QuickStart B.7. Alternate Implementations for a QuickStart
Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
A.7.1. An Alternate Proposal for the Quick- B.7.1. An Alternate Proposal for the Quick-
Start Nonce. . . . . . . . . . . . . . . . . . . . . . . . 73 Start Nonce. . . . . . . . . . . . . . . . . . . . . . . . 75
A.7.2. The Earlier Request-Approved QuickStart B.7.2. The Earlier Request-Approved QuickStart
Nonce. . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Nonce. . . . . . . . . . . . . . . . . . . . . . . . . . . 75
B. Quick-Start with DCCP . . . . . . . . . . . . . . . . . . . . 75 C. Quick-Start with DCCP . . . . . . . . . . . . . . . . . . . . 76
C. Possible Router Algorithm . . . . . . . . . . . . . . . . . . 76 D. Possible Router Algorithm . . . . . . . . . . . . . . . . . . 78
D. Possible Additional Uses for the Quick-Start E. Possible Additional Uses for the Quick-Start
Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
E. Feedback from Bob Briscoe . . . . . . . . . . . . . . . . . . 79 F. Feedback from Bob Briscoe . . . . . . . . . . . . . . . . . . 81
E.1. Potential Deployment Scenarios . . . . . . . . . . . . . 80 F.1. Potential Deployment Scenarios . . . . . . . . . . . . . 81
E.2. Misbehaving Senders and Receivers. . . . . . . . . . . . 80 F.2. Misbehaving Senders and Receivers. . . . . . . . . . . . 81
E.3. Fairness . . . . . . . . . . . . . . . . . . . . . . . . 81 F.3. Fairness . . . . . . . . . . . . . . . . . . . . . . . . 83
E.4. Models of Under-Utilization. . . . . . . . . . . . . . . 82 F.4. Models of Under-Utilization. . . . . . . . . . . . . . . 83
E.5. Router Algorithms as Local Policy. . . . . . . . . . . . 82 F.5. Router Algorithms as Local Policy. . . . . . . . . . . . 84
E.6. An Alternate Proposal. . . . . . . . . . . . . . . . . . 83 F.6. An Alternate Proposal. . . . . . . . . . . . . . . . . . 84
Normative References . . . . . . . . . . . . . . . . . . . . . . 83 Normative References . . . . . . . . . . . . . . . . . . . . . . 85
Informative References . . . . . . . . . . . . . . . . . . . . . 84 Informative References . . . . . . . . . . . . . . . . . . . . . 85
AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 89 AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 90
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 90 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 92
Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 90 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 17, line 11 skipping to change at page 17, line 11
3.1. The Quick-Start Option for IPv4 3.1. The Quick-Start Option for IPv4
The Quick-Start Request for IPv4 is defined as follows: The Quick-Start Request for IPv4 is defined as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option | Length=8 | Func. | Rate | QS TTL | | Option | Length=8 | Func. | Rate | QS TTL |
| | | 0000 |Request| | | | | 0000 |Request| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QS Nonce | | | QS Nonce | R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. The Quick-Start Option for IPv4. Figure 3. The Quick-Start Option for IPv4.
A Quick-Start Request. A Quick-Start Request.
The first byte contains the option field, which includes the one-bit The first byte contains the option field, which includes the one-bit
copy flag, the 2-bit class field, and the 5-bit option number (to be copy flag, the 2-bit class field, and the 5-bit option number (to be
assigned by IANA). assigned by IANA).
The second byte contains the length field, indicating an option The second byte contains the length field, indicating an option
skipping to change at page 17, line 45 skipping to change at page 17, line 45
sender.) The QS TTL is used by the sender to detect if all of the sender.) The QS TTL is used by the sender to detect if all of the
routers along the path understood and approved the Quick-Start routers along the path understood and approved the Quick-Start
option. option.
For a Rate Request, the transport sender MUST calculate and store For a Rate Request, the transport sender MUST calculate and store
the TTL Diff, the difference between the IP TTL value and the QS TTL the TTL Diff, the difference between the IP TTL value and the QS TTL
value in the Quick-Start request packet, as follows: value in the Quick-Start request packet, as follows:
TTL Diff = ( IP TTL - QS TTL ) mod 256 (1) TTL Diff = ( IP TTL - QS TTL ) mod 256 (1)
For a Rate Request, bytes 5-8 contain a 30-bit QS Nonce and a two- For a Rate Request, bytes 5-8 contain a 30-bit QS Nonce, discussed
bit Reserved field. The sender SHOULD set the reserved field to in Section 3.4, and a two-bit Reserved field. The sender SHOULD set
zero, and routers and receivers SHOULD ignore the reserved field. the reserved field to zero, and routers and receivers SHOULD ignore
The sender SHOULD set the 30-bit QS Nonce to a random value. the reserved field. The sender SHOULD set the 30-bit QS Nonce to a
random value.
The sender initializes the Rate Request to the desired sending rate, The sender initializes the Rate Request to the desired sending rate,
including an estimate of the transport and IP header overhead. The including an estimate of the transport and IP header overhead. The
encoding function for the Rate Request sets the request rate to encoding function for the Rate Request sets the request rate to
K*2^N bps (bits per second), for N the value in the Rate Request K*2^N bps (bits per second), for N the value in the Rate Request
field, and for K set to 40,000. For N=0, the rate request would be field, and for K set to 40,000. For N=0, the rate request would be
set to zero, regardless of the encoding function. This is set to zero, regardless of the encoding function. This is
illustrated in Table 1 below. For the four-bit Rate Request field, illustrated in Table 1 below. For the four-bit Rate Request field,
the request range is from 80 Kbps to 1.3 Gbps. Alternate encodings the request range is from 80 Kbps to 1.3 Gbps. Alternate encodings
that were considered for the Rate Request are given in Appendix A.2. that were considered for the Rate Request are given in Appendix B.2.
N Rate Request (in Kbps) N Rate Request (in Kbps)
--- ------------------- --- -------------------
0 0 0 0
1 80 1 80
2 160 2 160
3 320 3 320
4 640 4 640
5 1,280 5 1,280
6 2,560 6 2,560
skipping to change at page 19, line 11 skipping to change at page 19, line 11
discusses the Quick-Start Response from the TCP receiver to the TCP discusses the Quick-Start Response from the TCP receiver to the TCP
sender, and Section 4.4 discusses the TCP sender's mechanism for sender, and Section 4.4 discusses the TCP sender's mechanism for
determining if a Quick-Start Request has been approved. determining if a Quick-Start Request has been approved.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option | Length=8 | Func. | Rate | Not Used | | Option | Length=8 | Func. | Rate | Not Used |
| | | 1000 | Report| | | | | 1000 | Report| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Not Used | | QS Nonce | R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. The Quick-Start Option for IPv4. Figure 4. The Quick-Start Option for IPv4.
Report of Approved Rate. Report of Approved Rate.
If the Function field in the third byte of the Quick-Start Option is If the Function field in the third byte of the Quick-Start Option is
set to "1000", then the Quick-Start Option is a Report of Approved set to "1000", then the Quick-Start Option is a Report of Approved
Rate. In this case the second four bits in the third byte are the Rate. In this case the second four bits in the third byte are the
Rate Report field, formatted exactly as in the Rate Request field in Rate Report field, formatted exactly as in the Rate Request field in
a Rate Request. For a Report of Approved Rate, the last five bytes a Rate Request. For a Report of Approved Rate, the fourth byte of
of the Quick-Start Option are not used. the Quick-Start Option are not used. Bytes 5-8 contain a 30-bit QS
Nonce and a two- bit Reserved field.
After an approved Rate Request, the sender MUST report the Approved After an approved Rate Request, the sender MUST report the Approved
Rate, using a Quick-Start Option configured as a Report of Approved Rate, using a Quick-Start Option configured as a Report of Approved
Rate with the Rate Report field set to the approved rate. The Rate with the Rate Report field set to the approved rate, and the QS
Nonce set to the QS Nonce sent in the Quick-Start Request. The
packet containing the Report of Approved Rate MUST be either a packet containing the Report of Approved Rate MUST be either a
control packet sent before the first Quick-Start data packet, or a control packet sent before the first Quick-Start data packet, or a
Quick-Start Option in the first data packet itself. The Report of Quick-Start Option in the first data packet itself. The Report of
Approved Rate does not have to be sent reliably; for example, if the Approved Rate does not have to be sent reliably; for example, if the
approved rate is reported in a separate control packet, the sender approved rate is reported in a separate control packet, the sender
does not necessarily know if the control packet has been dropped in does not necessarily know if the control packet has been dropped in
the network. If the packet contained the Quick-Start Request is the network. If the packet contained the Quick-Start Request is
acknowledged, but the acknowledgement packet does not contain a acknowledged, but the acknowledgement packet does not contain a
Quick-Start Response, then the sender MUST assume that the Quick- Quick-Start Response, then the sender MUST assume that the Quick-
Start Request was denied, and set a Report of Approved Rate with a Start Request was denied, and set a Report of Approved Rate with a
rate of zero. rate of zero. Routers may choose to ignore the Report of Approved
Rate, or to use the Report of Approved Rate but ignore the QS Nonce.
Alternately, some routers that use the Report of Approved Rate may
choose to match the QS Nonce, masked by the approved rate, with the
QS Nonce seen in the original request.
If the Rate Request is denied, the sender MUST sent a Report of If the Rate Request is denied, the sender MUST sent a Report of
Approved Rate with the Rate Report field set to zero. Approved Rate with the Rate Report field set to zero.
We note that unlike a Quick-Start Request sent at the beginning of a We note that unlike a Quick-Start Request sent at the beginning of a
connection, when a Quick-Start Request is sent in the middle of a connection, when a Quick-Start Request is sent in the middle of a
connection, the connection could already have an established connection, the connection could already have an established
congestion window or sending rate. The Rate Request is the congestion window or sending rate. The Rate Request is the
requested total rate for the connection, including the current rate requested total rate for the connection, including the current rate
of the connection; the Rate Request is *not* a request for an of the connection; the Rate Request is *not* a request for an
skipping to change at page 28, line 11 skipping to change at page 28, line 30
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:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length=8 | Resv. | Rate | TTL Diff | | Kind | Length=8 | Resv. | Rate | TTL Diff |
| | | |Request| | | | | |Request| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QS Nonce | | | QS Nonce | R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. The Quick-Start Response option in the TCP header. Figure 5. The Quick-Start Response option in the TCP header.
The first byte of the Quick-Start Response option contains the The first byte of the Quick-Start Response option contains the
option kind, identifying the TCP option (to be assigned by IANA). option kind, identifying the TCP option (to be assigned by IANA).
The second byte of the Quick-Start Response option contains the The second byte of the Quick-Start Response option contains the
option length in bytes. The length field MUST be set to 8 bytes. option length in bytes. The length field MUST be set to 8 bytes.
skipping to change at page 32, line 5 skipping to change at page 32, line 25
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
used. In addition to reverting to the default congestion control used. In addition to reverting to the default congestion control
mechanisms, the sender MUST take into account that the Quick-Start mechanisms, the sender MUST take into account that the Quick-Start
congestion window was too large. Thus, the sender SHOULD decrease congestion window was too large. Thus, the sender SHOULD decrease
ssthresh to at most half the number of Quick-Start packets that were ssthresh to at most half the number of Quick-Start packets that were
successfully transmitted. Section A.5 discusses possible successfully transmitted. Section B.5 discusses possible
alternatives in responding to the loss of a Quick-Start packet. alternatives in responding to the loss of a Quick-Start packet.
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.
skipping to change at page 44, line 4 skipping to change at page 44, line 34
underutilized. underutilized.
A simple way for the router to keep track of the potential bandwidth A simple way for the router to keep track of the potential bandwidth
from recently-approved requests is to maintain two counters, one for from recently-approved requests is to maintain two counters, one for
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 D, 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
skipping to change at page 58, line 11 skipping to change at page 58, line 31
In both cases the name of the option would be "QS - Quick-Start", In both cases the name of the option would be "QS - Quick-Start",
with this document as the reference document. with this document 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 also requires that a TCP Option Number be allocated.
The Length would be 4, and the Meaning would be "Quick-Start The Length would be 4, and the Meaning would be "Quick-Start
Request", with this document as the reference document. Request", with this document as the reference document.
13. Related Work 13. Conclusions
We are presenting the Quick-Start mechanism as a simple,
understandable, and incrementally-deployable mechanism that would be
sufficient to allow some connections to start up with large initial
rates, or large initial congestion windows, in overprovisioned,
high-bandwidth environments. We expect there will be an increasing
number of overprovisioned, high-bandwidth environments where the
Quick-Start mechanism, or another mechanism of similar power, could
be of significant benefit to a wide range of traffic. We are
presenting the Quick-Start mechanism as a request for the community
to provide feedback and experimentation on issues relating to Quick-
Start.
14. Acknowledgements
The authors wish to thank Mark Handley for discussions of these
issues. The authors also thank the End-to-End Research Group, the
Transport Services Working Group, and members of IPAM's program on
Large Scale Communication Networks for both positive and negative
feedback on this proposal. We thank Srikanth Sundarrajan for the
initial implementation of Quick-Start in the NS simulator, and for
the initial simulation study. Many thanks to David Black and Joe
Touch for extensive feedback on QuickStart and IP tunnels. We also
thank Mohammed Ashraf, John Border, Bob Briscoe, Martin Duke, Tom
Dunigan, Gorry Fairhurst, John Heidemann, Paul Hyder, Dina Katabi
and Vern Paxson for feedback. Thanks also to Gorry Fairhurst for
the suggestion of adding the QS Nonce to the Report of Approved
Rate. 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
Jain for Initial Window Discovery.
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
are many things that the Quick-Start proposal would not accomplish. are many things that the Quick-Start proposal would not accomplish.
Quick-Start is not a congestion control mechanism, and would not Quick-Start is not a congestion control mechanism, and would not
help in making more precise use of the available bandwidth, that is, help in making more precise use of the available bandwidth, that is,
of achieving the goal of high throughput with low delay and low of achieving the goal of high throughput with low delay and low
packet loss rates. Quick-Start would not give routers more control packet loss rates. Quick-Start would not give routers more control
over the decrease rates of active connections. over the decrease rates of active connections.
In addition, any evaluation of Quick-Start must include a discussion In addition, any evaluation of Quick-Start must include a discussion
of the relative benefits of approaches that use no explicit of the relative benefits of approaches that use no explicit
information from routers, and of approaches that use more fine- information from routers, and of approaches that use more fine-
grained feedback from routers as part of a larger congestion control grained feedback from routers as part of a larger congestion control
mechanism. We discuss several classes of proposals in the sections mechanism. We discuss several classes of proposals in the sections
below. below.
13.1. Fast Start-ups without Explicit Information from Routers A.1. Fast Start-ups without Explicit Information from Routers
One possibility would be for senders to use information from the One possibility would be for senders to use information from the
packet streams to learn about the available bandwidth, without packet streams to learn about the available bandwidth, without
explicit information from routers. These techniques would not allow explicit information from routers. These techniques would not allow
a start-up as fast as that available from Quick-Start in an a start-up as fast as that available from Quick-Start in an
underutilized environment; one has to have sent some packets underutilized environment; one has to have sent some packets
already to use the packet stream to learn about available bandwidth. already to use the packet stream to learn about available bandwidth.
However, these techniques could allow a start-up considerably faster However, these techniques could allow a start-up considerably faster
than the current slow-start. While it seems clear that approaches than the current slow-start. While it seems clear that approaches
*without* explicit feedback from the routers will be strictly less *without* explicit feedback from the routers will be strictly less
skipping to change at page 60, line 15 skipping to change at page 61, line 31
(2) Explicit feedback is more reliable than implicit feedback: (2) Explicit feedback is more reliable than implicit feedback:
Techniques that attempt to assess the available bandwidth at Techniques that attempt to assess the available bandwidth at
connection startup using implicit techniques are more error-prone connection startup using implicit techniques are more error-prone
than techniques that involve every element in the network path. than techniques that involve every element in the network path.
While explicit information from the network can be wrong, it has a While explicit information from the network can be wrong, it has a
much better chance of being appropriate than an end-host trying to much better chance of being appropriate than an end-host trying to
*estimate* an appropriate sending rate using "block box" probing *estimate* an appropriate sending rate using "block box" probing
techniques of the entire path. techniques of the entire path.
13.2. Optimistic Sending without Explicit Information from Routers A.2. Optimistic Sending without Explicit Information from Routers
Another possibility that has been suggested [S02] is for the sender Another possibility that has been suggested [S02] is for the sender
to start with a large initial window without explicit permission to start with a large initial window without explicit permission
from the routers and without bandwidth estimation techniques, and from the routers and without bandwidth estimation techniques, and
for the first packet of the initial window to contain information for the first packet of the initial window to contain information
such as the size or sending rate of the initial window. The such as the size or sending rate of the initial window. The
proposal would be that congested routers would use this information proposal would be that congested routers would use this information
in the first data packet to drop or delay many or all of the packets in the first data packet to drop or delay many or all of the packets
from that initial window. In this way a flow's optimistically-large from that initial window. In this way a flow's optimistically-large
initial window would not force the router to drop packets from initial window would not force the router to drop packets from
skipping to change at page 61, line 9 skipping to change at page 62, line 25
(3) Distributed Denial of Service attacks: (3) Distributed Denial of Service attacks:
A third question would be the potential role of optimistic senders A third question would be the potential role of optimistic senders
in amplifying the damage done by a Distributed Denial of Service in amplifying the damage done by a Distributed Denial of Service
(DDoS) attack (assuming attackers use conformant congestion control (DDoS) attack (assuming attackers use conformant congestion control
in the hopes of "flying under the radar"). in the hopes of "flying under the radar").
(4) Performance hits if a packet is dropped: (4) Performance hits if a packet is dropped:
A fourth issue would be to quantify the performance hit to the A fourth issue would be to quantify the performance hit to the
connection when a packet is dropped from one of the initial windows. connection when a packet is dropped from one of the initial windows.
13.3. Fast Start-ups with other Information from Routers A.3. Fast Start-ups with other Information from Routers
There have been several proposals somewhat similar to Quick-Start, There have been several proposals somewhat similar to Quick-Start,
where the transport protocol collects explicit information from the where the transport protocol collects explicit information from the
routers along the path. routers along the path.
An IP Option about the free buffer size: An IP Option about the free buffer size:
In related work, [P00] investigates the use of a slightly different In related work, [P00] investigates the use of a slightly different
IP option for TCP connections to discover the available bandwidth IP option for TCP connections to discover the available bandwidth
along the path. In that proposal, the IP option would query the along the path. In that proposal, the IP option would query the
routers along the path about the smallest available free buffer routers along the path about the smallest available free buffer
skipping to change at page 61, line 39 skipping to change at page 63, line 7
bandwidth along a path. bandwidth along a path.
ETEN: ETEN:
Additional proposals for end nodes to collect explicit information Additional proposals for end nodes to collect explicit information
from routers include one variant of Explicit Transport Error from routers include one variant of Explicit Transport Error
Notification (ETEN), which includes a cumulative mechanism to notify Notification (ETEN), which includes a cumulative mechanism to notify
endpoints of aggregate congestion statistics along the path endpoints of aggregate congestion statistics along the path
[KAPS02]. (A second variant in [KSEPA04] does not depend on [KAPS02]. (A second variant in [KSEPA04] does not depend on
cumulative congestion statistics from the network.) cumulative congestion statistics from the network.)
13.4. Fast Start-ups with more Fine-Grained Feedback from Routers A.4. Fast Start-ups with more Fine-Grained Feedback from Routers
Proposals for more fine-grained congestion-related feedback from Proposals for more fine-grained congestion-related feedback from
routers include XCP [KHR02], MaxNet [MaxNet], and AntiECN marking routers include XCP [KHR02], MaxNet [MaxNet], and AntiECN marking
[K03]. Section A.6 discusses in more detail the relationship [K03]. Section B.6 discusses in more detail the relationship
between Quick-Start and proposals for more fine-grained per-packet between Quick-Start and proposals for more fine-grained per-packet
feedback from routers. feedback from routers.
XCP: XCP:
Proposals such as XCP for new congestion control mechanisms based on Proposals such as XCP for new congestion control mechanisms based on
more feedback from routers are more powerful than Quick-Start, but more feedback from routers are more powerful than Quick-Start, but
also are more complex to understand and more difficult to deploy. also are more complex to understand and more difficult to deploy.
XCP routers maintain no per-flow state, but provide more fine- XCP routers maintain no per-flow state, but provide more fine-
grained feedback to end-nodes than the one-bit congestion feedback grained feedback to end-nodes than the one-bit congestion feedback
of ECN. The per-packet feedback from XCP can be positive or of ECN. The per-packet feedback from XCP can be positive or
negative, and specifies the increase or decrease in the sender's negative, and specifies the increase or decrease in the sender's
congestion window when this packet is acknowledged. XCP is a full- congestion window when this packet is acknowledged. XCP is a full-
fledge congestion control scheme, whereas Quick-Start represents a fledge congestion control scheme, whereas Quick-Start represents a
quick check to determine if the network path is significantly quick check to determine if the network path is significantly
underutilized such that a connection can start faster and then fall underutilized such that a connection can start faster and then fall
back to TCP's standard congestion control algorithms. back to TCP's standard congestion control algorithms.
skipping to change at page 62, line 23 skipping to change at page 63, line 37
back to TCP's standard congestion control algorithms. back to TCP's standard congestion control algorithms.
AntiECN: AntiECN:
The AntiECN proposal is for a single bit in the packet header that The AntiECN proposal is for a single bit in the packet header that
routers could set to indicate that they are underutilized. For each routers could set to indicate that they are underutilized. For each
TCP ACK arriving at the sender indicating that a packet has been TCP ACK arriving at the sender indicating that a packet has been
received with the Anti-ECN bit set, the sender would be able to received with the Anti-ECN bit set, the sender would be able to
increase its congestion window by one packet, as it would during increase its congestion window by one packet, as it would during
slow-start. slow-start.
13.5. Fast Start-ups with Lower-Than-Best-Effort Service A.5. Fast Start-ups with Lower-Than-Best-Effort Service
There have been proposals for routers to provide a Lower Effort There have been proposals for routers to provide a Lower Effort
differentiated service that would be lower than best effort differentiated service that would be lower than best effort
[RFC3662]. Such a service could carry traffic for which delivery is [RFC3662]. Such a service could carry traffic for which delivery is
strictly optional, or could carry traffic that is important but that strictly optional, or could carry traffic that is important but that
has low priority in terms of time. Because it does not interfere has low priority in terms of time. Because it does not interfere
with best-effort traffic, Lower Effort services could be used by with best-effort traffic, Lower Effort services could be used by
transport protocols that start-up faster than slow-start. For transport protocols that start-up faster than slow-start. For
example, [SGF05] is a proposal for the transport sender to use low- example, [SGF05] is a proposal for the transport sender to use low-
priority traffic for much of the initial traffic, with routers priority traffic for much of the initial traffic, with routers
skipping to change at page 63, line 5 skipping to change at page 64, line 21
TCP connections to use the bandwidth unused by TCP and other traffic TCP connections to use the bandwidth unused by TCP and other traffic
in a non-intrusive fashion. Both TCP Nice and TCP Low Priority use in a non-intrusive fashion. Both TCP Nice and TCP Low Priority use
the default slow-start mechanisms of TCP. the default slow-start mechanisms of TCP.
We note that Quick-Start is quite different from either a Lower We note that Quick-Start is quite different from either a Lower
Effort service or a below-best-effort variant of TCP. Unlike these Effort service or a below-best-effort variant of TCP. Unlike these
proposals, Quick-Start is intended to be useful for best-effort proposals, Quick-Start is intended to be useful for best-effort
traffic that wishes to receive at least as much bandwidth as traffic that wishes to receive at least as much bandwidth as
competing best-effort connections. competing best-effort connections.
14. Conclusions B. Design Decisions
We are presenting the Quick-Start mechanism as a simple,
understandable, and incrementally-deployable mechanism that would be
sufficient to allow some connections to start up with large initial
rates, or large initial congestion windows, in overprovisioned,
high-bandwidth environments. We expect there will be an increasing
number of overprovisioned, high-bandwidth environments where the
Quick-Start mechanism, or another mechanism of similar power, could
be of significant benefit to a wide range of traffic. We are
presenting the Quick-Start mechanism as a request for the community
to provide feedback and experimentation on issues relating to Quick-
Start.
15. Acknowledgements
The authors wish to thank Mark Handley for discussions of these
issues. The authors also thank the End-to-End Research Group, the
Transport Services Working Group, and members of IPAM's program on
Large Scale Communication Networks for both positive and negative
feedback on this proposal. We thank Srikanth Sundarrajan for the
initial implementation of Quick-Start in the NS simulator, and for
the initial simulation study. Many thanks to David Black and Joe
Touch for extensive feedback on QuickStart and IP tunnels. We also
thank Mohammed Ashraf, John Border, Bob Briscoe, Martin Duke, Tom
Dunigan, Gorry Fairhurst, John Heidemann, Paul Hyder, Dina Katabi
and Vern Paxson for feedback. 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
Jain for Initial Window Discovery.
A. Design Decisions
A.1. Alternate Mechanisms for the Quick-Start Request: ICMP and RSVP B.1. Alternate Mechanisms for the Quick-Start Request: ICMP and RSVP
This document has proposed using an IP Option for the Quick-Start This document has proposed using an IP Option for the Quick-Start
Request from the sender to the receiver, and using transport Request from the sender to the receiver, and using transport
mechanisms for the Quick-Start Response from the receiver back to mechanisms for the Quick-Start Response from the receiver back to
the sender. In this section we discuss alternate mechanisms, and the sender. In this section we discuss alternate mechanisms, and
consider whether ICMP [RFC792, RFC2463] or RSVP [RFC2205] protocols consider whether ICMP [RFC792, RFC2463] or RSVP [RFC2205] protocols
could be used for delivering the Quick-Start Request. could be used for delivering the Quick-Start Request.
A.1.1. ICMP B.1.1. ICMP
Being a control protocol used between Internet nodes, one could Being a control protocol used between Internet nodes, one could
argue that ICMP is the ideal method for requesting a permission for argue that ICMP is the ideal method for requesting a permission for
faster startup from routers. The ICMP header is above the IP faster startup from routers. The ICMP header is above the IP
header. Quick-Start could be accomplished with ICMP as follows: If header. Quick-Start could be accomplished with ICMP as follows: If
the ICMP protocol is used to implement Quick-Start, the equivalent the ICMP protocol is used to implement Quick-Start, the equivalent
of the Quick-Start IP option would be carried in the ICMP header of of the Quick-Start IP option would be carried in the ICMP header of
the ICMP Quick-Start Request. The ICMP Quick-Start Request would the ICMP Quick-Start Request. The ICMP Quick-Start Request would
have to pass by the routers on the path to the receiver, possibly have to pass by the routers on the path to the receiver, possibly
using the IP Router Alert option [RFC2113]. A router that approves using the IP Router Alert option [RFC2113]. A router that approves
skipping to change at page 65, line 14 skipping to change at page 65, line 44
correct operation of ICMP Quick-Start. correct operation of ICMP Quick-Start.
Unauthenticated out-of-band ICMP messages could enable some types of Unauthenticated out-of-band ICMP messages could enable some types of
attacks by third-party malicious hosts that are not possible when attacks by third-party malicious hosts that are not possible when
the control information is carried in-band with the IP packets that the control information is carried in-band with the IP packets that
can only be altered by the routers on the connection path. Finally, can only be altered by the routers on the connection path. Finally,
as a minor concern, using ICMP would cause a small amount of as a minor concern, using ICMP would cause a small amount of
additional traffic in the network, which is not the case when using additional traffic in the network, which is not the case when using
IP options. IP options.
A.1.2. RSVP B.1.2. RSVP
With some modifications RSVP [RFC2205] could be used as a bearer With some modifications RSVP [RFC2205] could be used as a bearer
protocol for carrying the Quick-Start Requests. Because routers are protocol for carrying the Quick-Start Requests. Because routers are
expected to process RSVP packets more extensively than the normal expected to process RSVP packets more extensively than the normal
transport protocol IP packets, delivering a Quick-Start rate request transport protocol IP packets, delivering a Quick-Start rate request
using an RSVP packet would seem an appealing choice. However, Quick- using an RSVP packet would seem an appealing choice. However, Quick-
Start with RSVP would require a few differences from the Start with RSVP would require a few differences from the
conventional usage of RSVP. Quick-Start would not require periodical conventional usage of RSVP. Quick-Start would not require periodical
refreshing of soft state, because Quick-Start does not require per- refreshing of soft state, because Quick-Start does not require per-
connection state in routers. Quick-Start Requests would be connection state in routers. Quick-Start Requests would be
skipping to change at page 66, line 14 skipping to change at page 66, line 44
for making the Quick-Start Request also applies to the RSVP case. If for making the Quick-Start Request also applies to the RSVP case. If
the Quick-Start Request was transmitted in a separate packet instead the Quick-Start Request was transmitted in a separate packet instead
of as an IP option, the transport protocol packet delivery would not of as an IP option, the transport protocol packet delivery would not
be delayed due to IP option processing at the routers, and the be delayed due to IP option processing at the routers, and the
initial transport packets would reach their destination more initial transport packets would reach their destination more
reliably. The possible disadvantages of using ICMP and RSVP are also reliably. The possible disadvantages of using ICMP and RSVP are also
expected to be similar: middleboxes in the network may not be able expected to be similar: middleboxes in the network may not be able
to forward the Quick-Start Request messages, and the IP tunnels to forward the Quick-Start Request messages, and the IP tunnels
might cause problems for processing the Quick-Start Requests. might cause problems for processing the Quick-Start Requests.
A.2. Alternate Encoding Functions B.2. Alternate Encoding Functions
In this section we look at alternate encoding functions for the Rate In this section we look at alternate encoding functions for the Rate
Request field in the Quick-Start Request. The main requirements for Request field in the Quick-Start Request. The main requirements for
this function is that it should have a sufficiently wide range for this function is that it should have a sufficiently wide range for
the requested rate. There is no need for overly-fine-grained the requested rate. There is no need for overly-fine-grained
precision in the requested rate. Similarly, while it would be precision in the requested rate. Similarly, while it would be
attractive for the encoding function to be easily computable, it is attractive for the encoding function to be easily computable, it is
also possible for end-nodes and routers to simply store the table also possible for end-nodes and routers to simply store the table
giving the mapping between the value N in the Rate Request field, giving the mapping between the value N in the Rate Request field,
and the actual rate request f(N). In this section we consider and the actual rate request f(N). In this section we consider
skipping to change at page 67, line 6 skipping to change at page 67, line 36
unnecessarily large request range. unnecessarily large request range.
For a four-bit Rate Request field, the upper limit on the rate For a four-bit Rate Request field, the upper limit on the rate
request is 1.3 Gbps. It seems to us that an upper limit of 1.3 Gbps request is 1.3 Gbps. It seems to us that an upper limit of 1.3 Gbps
would be fine for the Quick-Start rate request, and that connections would be fine for the Quick-Start rate request, and that connections
wishing to start up with a higher initial sending rate should be wishing to start up with a higher initial sending rate should be
encouraged to use other mechanisms, such as the explicit reservation encouraged to use other mechanisms, such as the explicit reservation
of bandwidth. If an upper limit of 1.3 Gbps was not acceptable, of bandwidth. If an upper limit of 1.3 Gbps was not acceptable,
then five or six bits could be used for the Rate Request field. then five or six bits could be used for the Rate Request field.
The lower limit of 80 Kbps could be useful for flows with round-trip
times of a second or more. For a flow with a round-trip time of one
second, as is typical in some wireless networks, the TCP initial
window of 4380 bytes allowed by RFC 3390 (given appropriate packet
sizes) would translate to an initial sending rate of 35 Kbps. Thus,
for TCP flows, a rate request of 80 Kbps could be useful for some
flows with large round-trip times.
The lower limit of 80 Kbps could also be useful for some non-TCP
flows that send small packets, with at most one small packet every
10 ms. A rate request of 80 Kbps would translate to a rate of a
hundred 100-byte packets per second (including packet headers).
While some small-packet flows with large round-trip times might find
a smaller rate request of 40 Kbps to be useful, our assumption is
that a lower limit of 80 Kbps on the rate request will be generally
sufficient. Again, if the lower limit of 80 kbps was not
acceptable, then extra bits could be used for the Rate Request
field.
If the granularity of factors of two was too coarse, then the If the granularity of factors of two was too coarse, then the
encoding function could use a base less than two. An alternate form encoding function could use a base less than two. An alternate form
for the encoding function would be to use a hybrid of linear and for the encoding function would be to use a hybrid of linear and
exponential functions. exponential functions.
A mantissa and exponent representation: A mantissa and exponent representation:
Section 4.4 of [B05] suggests a mantissa and exponent representation Section 4.4 of [B05] suggests a mantissa and exponent representation
for the Quick-Start encoding function. With e and f as the binary for the Quick-Start encoding function. With e and f as the binary
numbers in the exponent and mantissa fields, and with 0 <= f < 1, numbers in the exponent and mantissa fields, and with 0 <= f < 1,
this would represent the rate (1+f)*2^e. [B05] suggests a mantissa this would represent the rate (1+f)*2^e. [B05] suggests a mantissa
skipping to change at page 67, line 28 skipping to change at page 68, line 29
encoding that is less coarse than the powers-of-two encoding used in encoding that is less coarse than the powers-of-two encoding used in
this document. this document.
Constraints of the transport protocol: Constraints of the transport protocol:
We note that the Rate Request is also constrained by the abilities We note that the Rate Request is also constrained by the abilities
of the transport protocol. For example, for TCP with Window of the transport protocol. For example, for TCP with Window
Scaling, the maximum window is at most 2**30 bytes. For a TCP Scaling, the maximum window is at most 2**30 bytes. For a TCP
connection with a long, 1 second round-trip time, this would give a connection with a long, 1 second round-trip time, this would give a
maximum sending rate of 1.07 Gbps. maximum sending rate of 1.07 Gbps.
A.3. The Quick-Start Request: Packets or Bytes? B.3. The Quick-Start Request: Packets or Bytes?
One of the design questions is whether the Rate Request field should One of the design questions is whether the Rate Request field should
be in bytes per second or in packets per second. We discuss this be in bytes per second or in packets per second. We discuss this
separately from the perspective of the transport, and from the separately from the perspective of the transport, and from the
perspective of the router. perspective of the router.
For TCP, the results from the Quick-Start Request are translated For TCP, the results from the Quick-Start Request are translated
into a congestion window in bytes, using the measured round-trip into a congestion window in bytes, using the measured round-trip
time and the MSS. This window applies only to the bytes of data time and the MSS. This window applies only to the bytes of data
payload, and does not include the bytes in the TCP or IP packet payload, and does not include the bytes in the TCP or IP packet
skipping to change at page 68, line 45 skipping to change at page 69, line 46
are discussed in more detail in RFC 3390 [RFC3390]. are discussed in more detail in RFC 3390 [RFC3390].
For a Quick-Start Request in bytes per second, the transport senders For a Quick-Start Request in bytes per second, the transport senders
would have the additional complication of estimating the bandwidth would have the additional complication of estimating the bandwidth
usage added by the packet headers. usage added by the packet headers.
We have chosen a Rate Request field in bytes per second rather than We have chosen a Rate Request field in bytes per second rather than
in packets per second because it seems somewhat more robust, in packets per second because it seems somewhat more robust,
particularly to routers. particularly to routers.
A.4. Quick-Start Semantics: Total Rate or Additional Rate? B.4. Quick-Start Semantics: Total Rate or Additional Rate?
For a Quick-Start Request sent in the middle of a connection, there For a Quick-Start Request sent in the middle of a connection, there
are two possible semantics for the Rate Request field, as follows: are two possible semantics for the Rate Request field, as follows:
(1) Total Rate: The requested Rate Request is the requested total (1) Total Rate: The requested Rate Request is the requested total
rate for the connection, including the current rate; or rate for the connection, including the current rate; or
(2) Additional Rate: The requested Rate Request is the requested (2) Additional Rate: The requested Rate Request is the requested
increase in the total rate for that connection, over and above the increase in the total rate for that connection, over and above the
current sending rate. current sending rate.
skipping to change at page 69, line 42 skipping to change at page 70, line 44
The Additional Rate semantics also lends itself to gaming by the The Additional Rate semantics also lends itself to gaming by the
connection, with senders sending frequent Quick-Start Requests in connection, with senders sending frequent Quick-Start Requests in
the hope of gaining a higher rate. If the router is granting the the hope of gaining a higher rate. If the router is granting the
same maximum rate for all rate requests, then there is little same maximum rate for all rate requests, then there is little
benefit to a connection of sending a rate request over and over benefit to a connection of sending a rate request over and over
again. However, if the router is granting an *additional* rate with again. However, if the router is granting an *additional* rate with
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 D 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.
A.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.5 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
skipping to change at page 70, line 37 skipping to change at page 71, line 42
at the router, and we cannot recommend it at this time. at the router, and we cannot recommend it at this time.
Another drawback of approaches that don't revert back to slow-start Another drawback of approaches that don't revert back to slow-start
when a Quick-Start packet in the initial window is dropped is that when a Quick-Start packet in the initial window is dropped is that
such approaches could give the TCP receiver a greater incentive to such approaches could give the TCP receiver a greater incentive to
lie about the Quick-Start request. If the sender reverts to slow- lie about the Quick-Start request. If the sender reverts to slow-
start when a Quick-Start packet in the initial window is dropped, start when a Quick-Start packet in the initial window is dropped,
this diminishes the benefit a receiver would get from a Quick-Start this diminishes the benefit a receiver would get from a Quick-Start
request that resulted in a dropped or ECN-marked packet. request that resulted in a dropped or ECN-marked packet.
A.6. Why Not Include More Functionality? B.6. Why Not Include More Functionality?
This proposal for Quick-Start is a rather coarse-grained mechanism This proposal for Quick-Start is a rather coarse-grained mechanism
that would allow a connection to use a higher sending rate along that would allow a connection to use a higher sending rate along
underutilized paths, but that does not attempt to provide a next- underutilized paths, but that does not attempt to provide a next-
generation transport protocol or congestion control mechanism, and generation transport protocol or congestion control mechanism, and
does not attempt the goal of providing very high throughput with does not attempt the goal of providing very high throughput with
very low delay. As Section 13.4 discusses, there are a number of very low delay. As Section A.4 discusses, there are a number of
proposals such as XCP, MaxNet, and AntiECN for more fine-grained proposals such as XCP, MaxNet, and AntiECN for more fine-grained
per-packet feedback from routers than the current congestion control per-packet feedback from routers than the current congestion control
mechanisms, that do attempt these more ambitious goals. mechanisms, that do attempt these more ambitious goals.
Compared to proposals such as XCP and AntiECN, Quick-Start offers Compared to proposals such as XCP and AntiECN, Quick-Start offers
much less control. Quick-Start does not attempt to provide a new much less control. Quick-Start does not attempt to provide a new
congestion control mechanism, but simply to get permission from congestion control mechanism, but simply to get permission from
routers for a higher sending rate at start-up, or after an idle routers for a higher sending rate at start-up, or after an idle
period. Quick-Start can be thought of as an "anti-congestion- period. Quick-Start can be thought of as an "anti-congestion-
control" mechanism, that is only of any use when all of the routers control" mechanism, that is only of any use when all of the routers
skipping to change at page 73, line 43 skipping to change at page 74, 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.
A.7. Alternate Implementations for a QuickStart Nonce B.7. Alternate Implementations for a QuickStart Nonce
A.7.1. An Alternate Proposal for the QuickStart Nonce B.7.1. An Alternate Proposal for the QuickStart 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 74, line 26 skipping to change at page 75, 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.
A.7.2. The Earlier Request-Approved QuickStart Nonce B.7.2. The Earlier Request-Approved QuickStart 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 QuickStart 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 QuickStart 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
skipping to change at page 75, line 14 skipping to change at page 76, line 19
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
value for the QS TTL, Quick-Start-capable routers can't tell if the value for the QS TTL, Quick-Start-capable routers can't tell if the
Quick-Start Request is invalid because of non-Quick-Start-capable Quick-Start Request is invalid because of non-Quick-Start-capable
routers upstream. This is the cost of using a design that makes it routers upstream. This is the cost of using a design that makes it
difficult for the receiver to cheat about the value of the QS TTL. difficult for the receiver to cheat about the value of the QS TTL.
B. 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 [KHF05] for a more detailed description of DCCP, and of the
congestion control mechanisms. congestion control mechanisms.
skipping to change at page 76, line 45 skipping to change at page 78, line 5
been requested. been requested.
(3) When does the sender decide there has been no feedback from the (3) When does the sender decide there has been no feedback from the
receiver? receiver?
As in the case of the initial sending rate, it would seem prudent to As in the case of the initial sending rate, it would seem prudent to
reduce the sending rate if no feedback is received from the receiver reduce the sending rate if no feedback is received from the receiver
in at least two round-trip times. It seems likely that in this in at least two round-trip times. It seems likely that in this
case, the sending rate should be reduced to the sending rate that case, the sending rate should be reduced to the sending rate that
would have been used if no Quick-Start request had been approved. would have been used if no Quick-Start request had been approved.
C. Possible Router Algorithm D. Possible Router Algorithm
This specification does not tightly define the algorithm a router This specification does not tightly define the algorithm a router
uses when deciding whether to approve a Quick-Start Rate Request or uses when deciding whether to approve a Quick-Start Rate Request or
whether and how to reduce a Rate Request. A range of algorithms is whether and how to reduce a Rate Request. A range of algorithms is
likely useful in this space and we consider the algorithm a likely useful in this space and we consider the algorithm a
particular router uses to be a local policy decision. In addition, particular router uses to be a local policy decision. In addition,
we believe that additional experimentation with router algorithms is we believe that additional experimentation with router algorithms is
necessary to have a solid understanding of the dynamics various necessary to have a solid understanding of the dynamics various
algorithms impose. However, we provide one particular algorithm in algorithms impose. However, we provide one particular algorithm in
this appendix as an example and as a framework for thinking about this appendix as an example and as a framework for thinking about
skipping to change at page 78, line 29 skipping to change at page 79, line 37
Also note that given that Rate Requests are fairly coarse, the Also note that given that Rate Requests are fairly coarse, the
approved rate should be rounded down when it does not fall exactly approved rate should be rounded down when it does not fall exactly
on one of the rates allowed by the encoding scheme. on one of the rates allowed by the encoding scheme.
Routers that wish to keep close track of the allocated Quick-Start Routers that wish to keep close track of the allocated Quick-Start
bandwidth could use Approved Rate reports to learn when rate bandwidth could use Approved Rate reports to learn when rate
requests had been decremented downstream in the network, and also to requests had been decremented downstream in the network, and also to
learn when a sender begins to use the approved Quick-Start request. learn when a sender begins to use the approved Quick-Start request.
D. Possible Additional Uses for the Quick-Start Option E. Possible Additional Uses for the Quick-Start Option
The Quick-Start Option contains a four-bit Function field in the The Quick-Start Option contains a four-bit Function field in the
third byte, enabling additional uses to be defined for the Quick- third byte, enabling additional uses to be defined for the Quick-
Start Option. In this section we discuss some of the possible Start Option. In this section we discuss some of the possible
additional uses that have been discussed for Quick-Start. The additional uses that have been discussed for Quick-Start. The
Function field makes it easy to add new functions for the Quick- Function field makes it easy to add new functions for the Quick-
Start Option. Start Option.
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
skipping to change at page 79, line 42 skipping to change at page 81, 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.
E. Feedback from Bob Briscoe F. Feedback from Bob Briscoe
[B05] is a review of an earlier version of the Quick-Start proposal [B05] is a review of an earlier version of the Quick-Start proposal
that discusses a number of potential problems with Quick-Start, and that discusses a number of potential problems with Quick-Start, and
argues for an alternate approach for policing congestion in networks argues for an alternate approach for policing congestion in networks
using re-feedback [BJCG+05,BJS05]. However, [B05] didn't oppose the using re-feedback [BJCG+05,BJS05]. However, [B05] didn't oppose the
move to Quick-Start to experimental status as long as its move to Quick-Start to experimental status as long as its
applicability is made clear. applicability is made clear.
E.1. Potential Deployment Scenarios F.1. Potential Deployment Scenarios
[B05] argues that because the sender's trustworthiness is not [B05] argues that because the sender's trustworthiness is not
necessarily verified, Quick-Start, if it is remain stateless, should necessarily verified, Quick-Start, if it is remain stateless, should
be confined to environments where every source is trusted. Section be confined to environments where every source is trusted. Section
3.2 of [B05] argues that either (1) Quick-Start should be 3.2 of [B05] argues that either (1) Quick-Start should be
recommended for deployment only in trusted environments, or (2) recommended for deployment only in trusted environments, or (2)
Quick-Start could be recommended for deployment also in untrusted Quick-Start could be recommended for deployment also in untrusted
environments, with flow state required at some or all routers. environments, with flow state required at some or all routers.
Since [B05], we have added the Report of Approved Rate as a required Since [B05], we have added the Report of Approved Rate as a required
skipping to change at page 80, line 32 skipping to change at page 81, line 41
clearly not recommending Quick-Start for widespread deployment in clearly not recommending Quick-Start for widespread deployment in
the global Internet, we also don't feel the need to explicitly the global Internet, we also don't feel the need to explicitly
restrict its deployment to environments where every source is restrict its deployment to environments where every source is
trusted, or to explicitly require per-flow state at Quick-Start trusted, or to explicitly require per-flow state at Quick-Start
routers. We assume that Quick-Start will only be enabled at routers routers. We assume that Quick-Start will only be enabled at routers
if the system administrators feel either that they have sufficient if the system administrators feel either that they have sufficient
trust in senders, sufficient policing mechanisms for checking for trust in senders, sufficient policing mechanisms for checking for
misbehaving nodes, or sufficient oversite to disable Quick-Start if misbehaving nodes, or sufficient oversite to disable Quick-Start if
it is determined to be causisng problems.. it is determined to be causisng problems..
E.2. Misbehaving Senders and Receivers F.2. Misbehaving Senders and Receivers
Some of the criticisms of Quick-Start in [B05] are criticisms for Some of the criticisms of Quick-Start in [B05] are criticisms for
mechanisms that allocate rates to senders, but this is not what mechanisms that allocate rates to senders, but this is not what
Quick-Start does. Quick-Start requests apply to individual Quick-Start does. Quick-Start requests apply to individual
connections, not to unique addresses or unique tuples of addresses. connections, not to unique addresses or unique tuples of addresses.
Further, the approval by routers of Quick-Start requests does not Further, the approval by routers of Quick-Start requests does not
result in an allocation of bandwidth for the sender making that result in an allocation of bandwidth for the sender making that
request; the approval by routers does not result in any allocation request; the approval by routers does not result in any allocation
of bandwidth at all. The state used by routers from past Quick- 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 Start approvals is used only to guide the router in its approval or
skipping to change at page 81, line 38 skipping to change at page 83, line 5
compared to non-Quick-Start data packets. Thus, a sender's claim compared to non-Quick-Start data packets. Thus, a sender's claim
that its data results from a previous Quick-Start request should that its data results from a previous Quick-Start request should
make no difference in how those data packets are treated at routers. 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 The approval of a Quick-Start request is not a promise by the router
that the subsequent data packets will receive differential treatment that the subsequent data packets will receive differential treatment
at the router; it is only a statement from the router that the at the router; it is only a statement from the router that the
router believes that the Quick-Start data packets will not change router believes that the Quick-Start data packets will not change
the current under-utilized state of the router. We have clarified the current under-utilized state of the router. We have clarified
this in Section 3.3 of this document. this in Section 3.3 of this document.
E.3. Fairness F.3. Fairness
In its abstract, [B05] says the following: "Because traffic variance In its abstract, [B05] says the following: "Because traffic variance
will always blur the boundary, we argue that under-utilisation will always blur the boundary, we argue that under-utilisation
should be treated as the extreme of a spectrum where fairness is should be treated as the extreme of a spectrum where fairness is
always an issue to some extent." always an issue to some extent."
The specification for Quick-Start now says in section 2 the The specification for Quick-Start now says in section 2 the
following: "A router should only approve a Quick-Start request if following: "A router should only approve a Quick-Start request if
the output link is underutilized, and if the router judges that the the output link is underutilized, and if the router judges that the
output link will continue to be underutilized if the request is output link will continue to be underutilized if the request is
skipping to change at page 82, line 4 skipping to change at page 83, line 17
In its abstract, [B05] says the following: "Because traffic variance In its abstract, [B05] says the following: "Because traffic variance
will always blur the boundary, we argue that under-utilisation will always blur the boundary, we argue that under-utilisation
should be treated as the extreme of a spectrum where fairness is should be treated as the extreme of a spectrum where fairness is
always an issue to some extent." always an issue to some extent."
The specification for Quick-Start now says in section 2 the The specification for Quick-Start now says in section 2 the
following: "A router should only approve a Quick-Start request if following: "A router should only approve a Quick-Start request if
the output link is underutilized, and if the router judges that the the output link is underutilized, and if the router judges that the
output link will continue to be underutilized if the request is output link will continue to be underutilized if the request is
approved." approved."
We changed the quote "for a mechanism for requesting an initial We changed the quote "for a mechanism for requesting an initial
sending rate in an underutilized environment, the fairness issues of sending rate in an underutilized environment, the fairness issues of
a general congestion control mechanism go away" to the following: a general congestion control mechanism go away" to the following:
"because Quick-Start is a mechanism for requesting an initial "because Quick-Start is a mechanism for requesting an initial
sending rate in an underutilized environment, its fairness issues sending rate in an underutilized environment, its fairness issues
are less severe than those of a general congestion control are less severe than those of a general congestion control
mechanism" in section A.6 However, we did not add the sentence mechanism" in section B.6 However, we did not add the sentence
recommended in section 3.4 of [B05], that "Quick-Start is targeted recommended in section 3.4 of [B05], that "Quick-Start is targeted
at an experimental environment where the more intractable issues can at an experimental environment where the more intractable issues can
be set aside". In particular, we don't agree that Quick-Start needs 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. to be targeted only for environments where fairness is not an issue.
E.4. Models of Under-Utilization F.4. Models of Under-Utilization
[B05] states that "One of the under-utilisation assumptions I had in [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 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, 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 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 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 that this `one big flow at a time" model was *never* the implicit or
explicit model underlying the Quick-Start design. (We would also explicit model underlying the Quick-Start design. (We would also
note that every version of this document since the first version note that every version of this document since the first version
back in 2002 has discussed router responses when the router back in 2002 has discussed router responses when the router
experiences a flood of Quick-Start requests.) experiences a flood of Quick-Start requests.)
[B05] also says the following: "By reverse engineering this [B05] also says the following: "By reverse engineering this
algorithm, it was possible to guess that there was an assumption algorithm, it was possible to guess that there was an assumption
that host capacity was smaller than the network's, so meeting a 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 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 next request." Again, we would like to clarify that there has been
no such assumption underlying the Quick-Start design. no such assumption underlying the Quick-Start design.
E.5. Router Algorithms as Local Policy F.5. Router Algorithms as Local Policy
[B05] recommends that either this document should set constraints on [B05] recommends that either this document should set constraints on
possible router algorithms, or say that experiments are needed "in possible router algorithms, or say that experiments are needed "in
order to establish constraints required on router algorithms for order to establish constraints required on router algorithms for
interworking, robustness, fairness etc." While it is possible that interworking, robustness, fairness etc." While it is possible that
experiments will lead to an understanding of constraints that are experiments will lead to an understanding of constraints that are
needed on router algorithms, we think it is more likely that there needed on router algorithms, we think it is more likely that there
will not be a need for explicit constraints on router algorithms for will not be a need for explicit constraints on router algorithms for
accepting or rejecting Quick-Start requests. accepting or rejecting Quick-Start requests.
Our approach is that, while the Quick-Start IETF documentation Our approach is that, while the Quick-Start IETF documentation
standardizes the semantics of Quick-Start and the format of the standardizes the semantics of Quick-Start and the format of the
Quick-Start IP Option and the Quick-Start Response TCP Option, the Quick-Start IP Option and the Quick-Start Response TCP Option, the
IETF documentation should not and does not standardize the IETF documentation should not and does not standardize the
algorithms used at routers for approving or denying Quick-Start algorithms used at routers for approving or denying Quick-Start
request. Appendix D in this document has presented one possible request. Appendix E in this document has presented one possible
router algorithm for approving or denying Quick-Start requests, but router algorithm for approving or denying Quick-Start requests, but
further discussion of the range of possibilities in router further discussion of the range of possibilities in router
algorithms is available elsewhere [SAF06]. As an example, the algorithms is available elsewhere [SAF06]. As an example, the
fairness criteria that routers might apply in granting or denying fairness criteria that routers might apply in granting or denying
Quick-Start requests are discussed in [SAF06], but are not discussed Quick-Start requests are discussed in [SAF06], but are not discussed
in the same detail in this document. This document leaves routers in the same detail in this document. This document leaves routers
free to apply any criteria they choose in accepting or denying free to apply any criteria they choose in accepting or denying
Quick-Start requests, modulo the requirements given in Section 3.3 Quick-Start requests, modulo the requirements given in Section 3.3
above. above.
This approach of the Quick-Start router algorithm as a matter of This approach of the Quick-Start router algorithm as a matter of
local policy is consistent with the approach in RFC 3168 on local policy is consistent with the approach in RFC 3168 on
standardizing Explicit Congestion Notification (ECN). RFC 3168 standardizing Explicit Congestion Notification (ECN). RFC 3168
standardized the semantics of the ECN field, but did not standardize standardized the semantics of the ECN field, but did not standardize
a router's Active Queue Management mechanisms for deciding when to a router's Active Queue Management mechanisms for deciding when to
set the Congestion Experienced codepoint in packets. set the Congestion Experienced codepoint in packets.
E.6. An Alternate Proposal F.6. An Alternate Proposal
[B05] proposes an alternate to Quick-Start where endpoints allocate [B05] proposes an alternate to Quick-Start where endpoints allocate
rates to themselves. [B05] argues that adding rate allocation to rates to themselves. [B05] argues that adding rate allocation to
interior routers is not the fundamentally correct direction. interior routers is not the fundamentally correct direction.
[B05] argues for an approach that associates senders with their [B05] argues for an approach that associates senders with their
ingress attachment point, with routers reporting their impairment ingress attachment point, with routers reporting their impairment
status back to the sender [BJCG+05,BJS05]. The source declares the status back to the sender [BJCG+05,BJS05]. The source declares the
impairment that it believes it will accumulate along the path, and impairment that it believes it will accumulate along the path, and
routers effectively subtract the local impairment status. If the routers effectively subtract the local impairment status. If the
skipping to change at page 90, line 7 skipping to change at page 92, line 7
Pasi Sarolahti Pasi Sarolahti
Nokia Research Center Nokia Research Center
P.O. Box 407 P.O. Box 407
FI-00045 NOKIA GROUP FI-00045 NOKIA GROUP
Finland Finland
Phone: +358 50 4876607 Phone: +358 50 4876607
Email: pasi.sarolahti@iki.fi Email: pasi.sarolahti@iki.fi
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The Internet Society 2006. This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 70 change blocks. 
167 lines changed or deleted 203 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/