draft-ietf-tsvwg-quickstart-01.txt   draft-ietf-tsvwg-quickstart-02.txt 
Internet Engineering Task Force A. Jain Internet Engineering Task Force S. Floyd
INTERNET-DRAFT F5 Networks INTERNET-DRAFT M. Allman
draft-ietf-tsvwg-quickstart-01.txt S. Floyd draft-ietf-tsvwg-quickstart-02.txt ICIR
Expires: April 2006 M. Allman Expires: September 2006 A. Jain
ICIR F5 Networks
P. Sarolahti P. Sarolahti
Nokia Research Center Nokia Research Center
13 October 2005 5 March 2006
Quick-Start for TCP and IP Quick-Start for TCP and IP
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 2006. This Internet-Draft will expire on September 2006.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
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 describe its use with TCP. By using Quick-Start, a TCP document we describe its use with TCP. By using Quick-Start, a TCP
host, say, host A, would indicate its desired sending rate in bytes host, say, host A, would indicate its desired sending rate in bytes
per second, using a Quick Start Request option in the IP header of a per second, using a Quick Start option in the IP header of a TCP
TCP packet. Each router along the path could, in turn, either packet. Each router along the path could, in turn, either approve
approve the requested rate, reduce the requested rate, or indicate the requested rate, reduce the requested rate, or indicate that the
that the Quick-Start request is not approved. If the Quick-Start Quick-Start request is not approved. If the Quick-Start request is
request is not approved, then the sender would use the default not approved, then the sender would use the default congestion
congestion control mechanisms. The Quick-Start mechanism can control mechanisms. The Quick-Start mechanism can determine if
determine if there are routers along the path that do not understand there are routers along the path that do not understand the Quick-
the Quick-Start Request option, or have not agreed to the Quick- Start option, or have not agreed to the Quick-Start rate request.
Start rate request. TCP host B communicates the final rate request TCP host B communicates the final rate request to TCP host A in a
to TCP host A in a transport-level Quick-Start Response in an transport-level Quick-Start Response in an answering TCP packet.
answering TCP packet. Quick-Start is designed to allow connections Quick-Start is designed to allow connections to use higher sending
to use higher sending rates when there is significant unused rates when there is significant unused bandwidth along the path, and
bandwidth along the path, and all of the routers along the path all of the routers along the path support the Quick-Start Request.
support the Quick-Start Request.
TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION:
Changes from draft-ietf-tsvwg-quickstart-01:
* Added a citation to SPAND: Speeding Up Short Data Transfers.
* Added a sentence in Section 8.1 on "Implementation Issues for
Processing Quick-Start Requests" about multi-access links.
* Mentioned the IP Router Alert option, RFC 2113, in Appendix
A.1.1.
* Added a discussion of lower-than-best-effort service.
* Added a few sentences about the requirements for
randomness in the nonce.
* Changed the name of the option from the Quick-Start Request
Option to the Quick-Start Option.
* Changed the semantics of the Reserved field to the Function
field, adding that a Quick-Start option is only interpreted
as a request if this field is zero.
* Changed the "Reporting Approved Rate" option from a
"Possible Use" in Appendix D to a required use in Section 3.1,
to allow routers and receivers some protection against
misbehaving senders.
* Changes from feedback from Bob Briscoe:
- Added Appendix E with a response to Sections 1-3 of
Bob Briscoe's document.
- Added a clarification that the approval of a
Quick-Start request at a router does not affect
the treatment of the subsequent arriving
Quick-Start data packets.
- Added the one-way hash function as an alternate
implementation for the QS Nonce.
- Clarified the phrase "incrementally deployable", adding
the following:
"We note that while Quick-Start is incrementally deployable
in this sense, a Quick-Start request can not be approved
for a particular connection unless both end-nodes and all
of the routers along the path have been configured to
support Quick-Start."
- Clarified semantics about additional rate.
- Said that when denying a rate request, the router
may in the future use the QS Nonce field to report
an error code.
- Add Bob's suggestion from Section 4.4 as an alternate
possible rate encoding.
- Made changes suggested in Section 5.1.3 of Bob's paper,
including saying that the router should decrement the QS TTL
by the same amount that it decrements the IP TTL (on the
off chance that it decrements the IP TTL by more than one).
- Fixed nits.
Changes from draft-ietf-tsvwg-quickstart-00: Changes from draft-ietf-tsvwg-quickstart-00:
* Added a 30-bit QS Nonce. Based on feedback from Guohan Lu * Added a 30-bit QS Nonce. Based on feedback from Guohan Lu
and Gorry Fairhurst (and deleted the text about a possible and Gorry Fairhurst (and deleted the text about a possible
four-bit QS nonce). four-bit QS nonce).
* Added a new section "Quick-Start and IPsec AH", based on feedback * Added a new section "Quick-Start and IPsec AH", based on feedback
from Joe Touch and David Black. from Joe Touch and David Black.
* Revised "Quick-Start in IP Tunnels" Section, based on feedback * Revised "Quick-Start in IP Tunnels" Section, based on feedback
from Joe Touch and David Black. from Joe Touch and David Black.
* Added a section about "Possible Uses for the Reserved Fields". * Added a section about "Possible Uses for the Reserved Fields".
* Changes from feedback from Gorry Fairhurst: * Changes from feedback from Gorry Fairhurst:
skipping to change at page 5, line 4 skipping to change at page 5, line 51
Changes from draft-amit-quick-start-01.txt: Changes from draft-amit-quick-start-01.txt:
* Added a discussion in the related work section about the * Added a discussion in the related work section about the
possibility of optimistically sending a large initial window, possibility of optimistically sending a large initial window,
without explicit permission of routers. without explicit permission of routers.
* Added a discussion in the related work section about the * Added a discussion in the related work section about the
tradeoffs of XCP vs. Quick-Start. tradeoffs of XCP vs. Quick-Start.
* Added a section on "The Quick-Start Request: Packets or Bytes?" * Added a section on "The Quick-Start Request: Packets or Bytes?"
Changes from draft-amit-quick-start-00.txt: Changes from draft-amit-quick-start-00.txt:
* The addition of a citation to [KHR02]. * The addition of a citation to [KHR02].
* The addition of a Related Work section. * The addition of a Related Work section.
* Deleted the QS Nonce, in favor of a random initial value for the * Deleted the QS Nonce, in favor of a random initial value for the
QS TTL. QS TTL.
Table of Contents Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 10
2. Assumptions and General Principles. . . . . . . . . . . . . . 10 2. Assumptions and General Principles. . . . . . . . . . . . . . 11
2.1. Overview of Quick-Start. . . . . . . . . . . . . . . . . 11 2.1. Overview of Quick-Start. . . . . . . . . . . . . . . . . 13
3. The Quick-Start Request in IP . . . . . . . . . . . . . . . . 14 3. The Quick-Start Option in IP. . . . . . . . . . . . . . . . . 15
3.1. The Quick-Start Request Option for IPv4. . . . . . . . . 14 3.1. The Quick-Start Option for IPv4. . . . . . . . . . . . . 15
3.2. The Quick-Start Request Option for IPv6. . . . . . . . . 16 3.2. The Quick-Start Option for IPv6. . . . . . . . . . . . . 18
3.3. Processing the Quick-Start Request at 3.3. Processing the Quick-Start Request at
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4. The QS Nonce . . . . . . . . . . . . . . . . . . . . . . 18 3.3.1. Processing the Report of Approved
4. The Quick-Start Mechanisms in TCP . . . . . . . . . . . . . . 20 Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1. When to Use Quick-Start. . . . . . . . . . . . . . . . . 21 3.4. The QS Nonce . . . . . . . . . . . . . . . . . . . . . . 21
4. The Quick-Start Mechanisms in TCP . . . . . . . . . . . . . . 23
4.1. When to Use Quick-Start. . . . . . . . . . . . . . . . . 24
4.2. The Quick-Start Response Option in the TCP 4.2. The Quick-Start Response Option in the TCP
header. . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 header. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3. TCP: Sending the Quick-Start Response. . . . . . . . . . 24 4.3. TCP: Sending the Quick-Start Response. . . . . . . . . . 27
4.4. TCP: Receiving and Using the Quick-Start 4.4. TCP: Receiving and Using the Quick-Start
Response Packet . . . . . . . . . . . . . . . . . . . . . . . 24 Response Packet . . . . . . . . . . . . . . . . . . . . . . . 27
4.5. TCP: Responding to a Loss of a Quick-Start 4.5. TCP: Responding to a Loss of a Quick-Start
Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.6. TCP: A Quick-Start Request for a Larger Ini- 4.6. TCP: A Quick-Start Request for a Larger Ini-
tial Window . . . . . . . . . . . . . . . . . . . . . . . . . 27 tial Window . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.6.1. Interactions with Path MTU Discovery. . . . . . . . 27 4.6.1. Interactions with Path MTU Discovery. . . . . . . . 30
4.6.2. Quick-Start Request Packets that are 4.6.2. Quick-Start Request Packets that are
Discarded by Middleboxes . . . . . . . . . . . . . . . . . 27 Discarded by Middleboxes . . . . . . . . . . . . . . . . . 31
4.7. TCP: A Quick-Start Request in the Middle of 4.7. TCP: A Quick-Start Request in the Middle of
Connection. . . . . . . . . . . . . . . . . . . . . . . . . . 29 a Connection. . . . . . . . . . . . . . . . . . . . . . . . . 32
4.8. An Example Quick-Start Scenario with TCP . . . . . . . . 29 4.8. An Example Quick-Start Scenario with TCP . . . . . . . . 33
5. Quick-Start and IPsec AH. . . . . . . . . . . . . . . . . . . 30 5. Quick-Start and IPsec AH. . . . . . . . . . . . . . . . . . . 34
6. Quick-Start in IP Tunnels . . . . . . . . . . . . . . . . . . 31 6. Quick-Start in IP Tunnels . . . . . . . . . . . . . . . . . . 34
6.1. Simple Tunnels That Are Compatible with 6.1. Simple Tunnels That Are Compatible with
Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 33 Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.1.1. Simple Tunnels that are Aware of Quick- 6.1.1. Simple Tunnels that are Aware of Quick-
Start. . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Start. . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2. Simple Tunnels That Are Not Compatible with 6.2. Simple Tunnels That Are Not Compatible with
Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 34 Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.3. Tunnels That Support Quick-Start . . . . . . . . . . . . 35 6.3. Tunnels That Support Quick-Start . . . . . . . . . . . . 38
7. The Quick-Start Mechanism in other Transport Pro- 7. The Quick-Start Mechanism in other Transport Pro-
tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8. Using Quick-Start . . . . . . . . . . . . . . . . . . . . . . 37 8. Using Quick-Start . . . . . . . . . . . . . . . . . . . . . . 40
8.1. Determining the Rate to Request. . . . . . . . . . . . . 37 8.1. Determining the Rate to Request. . . . . . . . . . . . . 40
8.2. Deciding the Permitted Rate Request at a 8.2. Deciding the Permitted Rate Request at a
Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
9. Evaluation of Quick-Start . . . . . . . . . . . . . . . . . . 38 9. Evaluation of Quick-Start . . . . . . . . . . . . . . . . . . 42
9.1. Benefits of Quick-Start. . . . . . . . . . . . . . . . . 39 9.1. Benefits of Quick-Start. . . . . . . . . . . . . . . . . 42
9.2. Costs of Quick-Start . . . . . . . . . . . . . . . . . . 39 9.2. Costs of Quick-Start . . . . . . . . . . . . . . . . . . 42
9.3. Quick-Start with QoS-enabled Traffic . . . . . . . . . . 41 9.3. Quick-Start with QoS-enabled Traffic . . . . . . . . . . 44
9.4. Protection against Misbehaving Nodes . . . . . . . . . . 41 9.4. Protection against Misbehaving Nodes . . . . . . . . . . 44
9.4.1. Receivers Lying about Whether the 9.4.1. Misbehaving Senders . . . . . . . . . . . . . . . . 44
Request was Approved . . . . . . . . . . . . . . . . . . . 41 9.4.2. Receivers Lying about Whether the
9.4.2. Receivers Lying about the Approved Request was Approved . . . . . . . . . . . . . . . . . . . 45
Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 9.4.3. Receivers Lying about the Approved
9.4.3. Collusion between Misbehaving Routers . . . . . . . 43 Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.4.4. Misbehaving Middleboxes and the IP 9.4.4. Collusion between Misbehaving Routers . . . . . . . 47
TTL. . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 9.5. Misbehaving Middleboxes and the IP TTL . . . . . . . . . 49
9.5. Attacks on Quick-Start . . . . . . . . . . . . . . . . . 45 9.6. Attacks on Quick-Start . . . . . . . . . . . . . . . . . 49
9.6. Simulations with Quick-Start . . . . . . . . . . . . . . 45 9.7. Simulations with Quick-Start . . . . . . . . . . . . . . 50
10. Implementation and Deployment Issues . . . . . . . . . . . . 46 10. Implementation and Deployment Issues . . . . . . . . . . . . 50
10.1. Implementation Issues for Sending Quick- 10.1. Implementation Issues for Sending Quick-
Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 46 Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 50
10.2. Implementation Issues for Processing Quick- 10.2. Implementation Issues for Processing Quick-
Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 47 Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 51
10.3. Possible Deployment Scenarios . . . . . . . . . . . . . 47 10.3. Possible Deployment Scenarios . . . . . . . . . . . . . 51
10.4. Would QuickStart packets take the slow path 10.4. Would QuickStart packets take the slow path
in routers? . . . . . . . . . . . . . . . . . . . . . . . . . 48 in routers? . . . . . . . . . . . . . . . . . . . . . . . . . 52
10.5. A Comparison with the Deployment Problems 10.5. A Comparison with the Deployment Problems
of ECN. . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 of ECN. . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
11. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 49 11. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 53
11.1. Fast Start-ups without Explicit Information 11.1. Fast Start-ups without Explicit Information
from Routers. . . . . . . . . . . . . . . . . . . . . . . . . 49 from Routers. . . . . . . . . . . . . . . . . . . . . . . . . 53
11.2. Optimistic Sending without Explicit Infor- 11.2. Optimistic Sending without Explicit Infor-
mation from Routers . . . . . . . . . . . . . . . . . . . . . 50 mation from Routers . . . . . . . . . . . . . . . . . . . . . 55
11.3. Fast Start-ups with other Information from 11.3. Fast Start-ups with other Information from
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
11.4. Fast Start-ups with more Fine-Grained Feed- 11.4. Fast Start-ups with more Fine-Grained Feed-
back from Routers . . . . . . . . . . . . . . . . . . . . . . 52 back from Routers . . . . . . . . . . . . . . . . . . . . . . 56
12. Security Considerations. . . . . . . . . . . . . . . . . . . 52 11.5. Fast Start-ups with Lower-Than-Best-Effort
13. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . 53 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 12. Security Considerations. . . . . . . . . . . . . . . . . . . 58
A. Design Decisions. . . . . . . . . . . . . . . . . . . . . . . 54 13. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . 58
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 59
A. Design Decisions. . . . . . . . . . . . . . . . . . . . . . . 59
A.1. Alternate Mechanisms for the Quick-Start A.1. Alternate Mechanisms for the Quick-Start
Request: ICMP and RSVP. . . . . . . . . . . . . . . . . . . . 54 Request: ICMP and RSVP. . . . . . . . . . . . . . . . . . . . 59
A.1.1. ICMP. . . . . . . . . . . . . . . . . . . . . . . . 54 A.1.1. ICMP. . . . . . . . . . . . . . . . . . . . . . . . 59
A.1.2. RSVP. . . . . . . . . . . . . . . . . . . . . . . . 56 A.1.2. RSVP. . . . . . . . . . . . . . . . . . . . . . . . 61
A.2. Alternate Encoding Functions . . . . . . . . . . . . . . 57 A.2. Alternate Encoding Functions . . . . . . . . . . . . . . 62
A.3. The Quick-Start Request: Packets or Bytes? . . . . . . . 58 A.3. The Quick-Start Request: Packets or Bytes? . . . . . . . 63
A.4. Quick-Start Semantics: Total Rate or Addi- A.4. Quick-Start Semantics: Total Rate or Addi-
tional Rate?. . . . . . . . . . . . . . . . . . . . . . . . . 59 tional Rate?. . . . . . . . . . . . . . . . . . . . . . . . . 64
A.5. Alternate Responses to the Loss of a Quick- A.5. Alternate Responses to the Loss of a Quick-
Start Packet. . . . . . . . . . . . . . . . . . . . . . . . . 60 Start Packet. . . . . . . . . . . . . . . . . . . . . . . . . 65
A.6. Why Not Include More Functionality?. . . . . . . . . . . 61 A.6. Why Not Include More Functionality?. . . . . . . . . . . 66
A.7. The Earlier QuickStart Nonce . . . . . . . . . . . . . . 64 A.7. Alternate Implementations for a QuickStart
B. Quick-Start with DCCP . . . . . . . . . . . . . . . . . . . . 65 Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
C. Possible Router Algorithm . . . . . . . . . . . . . . . . . . 67 A.7.1. An Alternate Proposal for the Quick-
D. Possible Uses for the Reserved Fields . . . . . . . . . . . . 68 Start Nonce. . . . . . . . . . . . . . . . . . . . . . . . 69
Normative References . . . . . . . . . . . . . . . . . . . . . . 70 A.7.2. The Earlier Request-Approved QuickStart
Informative References . . . . . . . . . . . . . . . . . . . . . 70 Nonce. . . . . . . . . . . . . . . . . . . . . . . . . . . 70
E. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74 B. Quick-Start with DCCP . . . . . . . . . . . . . . . . . . . . 71
E.1. IP Option. . . . . . . . . . . . . . . . . . . . . . . . 74 C. Possible Router Algorithm . . . . . . . . . . . . . . . . . . 73
E.2. TCP Option . . . . . . . . . . . . . . . . . . . . . . . 75 D. Possible Additional Uses for the Quick-Start
AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 75 Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 75 E. Feedback from Bob Briscoe . . . . . . . . . . . . . . . . . . 75
Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 76 E.1. Potential Deployment Scenarios . . . . . . . . . . . . . 76
E.2. Misbehaving Senders and Receivers. . . . . . . . . . . . 76
E.3. Fairness . . . . . . . . . . . . . . . . . . . . . . . . 77
E.4. Models of Under-Utilization. . . . . . . . . . . . . . . 78
E.5. Router Algorithms as Local Policy. . . . . . . . . . . . 78
E.6. An Alternate Proposal. . . . . . . . . . . . . . . . . . 79
Normative References . . . . . . . . . . . . . . . . . . . . . . 79
Informative References . . . . . . . . . . . . . . . . . . . . . 80
F. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 85
F.1. IP Option. . . . . . . . . . . . . . . . . . . . . . . . 85
F.2. TCP Option . . . . . . . . . . . . . . . . . . . . . . . 85
AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 85
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 87
Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 87
1. Introduction 1. Introduction
Each TCP 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 for TCP, but each TCP connection determines the answered explicitly, but each TCP connection determines the sending
sending rate by probing the network path and altering the congestion rate by probing the network path and altering the congestion window
window (cwnd) based on perceived congestion. Each 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
segments [RFC2581,RFC3390]. The TCP connection then probes the segments [RFC2581,RFC3390]. The TCP connection then probes the
network for available bandwidth using the slow-start procedure network for available bandwidth using the slow-start procedure
[Jac88,RFC2581], doubling cwnd during each congestion-free round- [Jac88,RFC2581], doubling cwnd during each congestion-free round-
trip time (RTT). trip time (RTT).
The slow-start algorithm can be time-consuming --- especially over The slow-start algorithm can be time-consuming --- especially over
networks with large bandwidth or long delays. It may take a number networks with large bandwidth or long delays. It may take a number
of RTTs in slow-start before the TCP connection begins to fully use of RTTs in slow-start before the TCP connection begins to fully use
skipping to change at page 10, line 10 skipping to change at page 11, line 10
be shared with a new connection to the same host. However, neither be shared with a new connection to the same host. However, neither
of these approaches addresses the case of a connection to a new of these approaches addresses the case of a connection to a new
destination, with no existing or recent connection (and therefore destination, with no existing or recent connection (and therefore
congestion control state) to that destination. congestion control state) to that destination.
Quick-Start would not be the first mechanism for explicit Quick-Start would not be the first mechanism for explicit
communication from routers to transport protocols about sending communication from routers to transport protocols about sending
rates. Explicit Congestion Notification (ECN) gives explicit rates. Explicit Congestion Notification (ECN) gives explicit
congestion control feedback from routers to transport protocols, congestion control feedback from routers to transport protocols,
based on the router detecting congestion before buffer overflow based on the router detecting congestion before buffer overflow
[RFC3168]. In contrast, routers would not use Quick-Start to get [RFC3168]. In contrast, routers would not use Quick-Start to give
congestion information, but instead would use Quick-Start as an congestion information, but instead would use Quick-Start as an
optional mechanism to give permission to transport protocols to use optional mechanism to give permission to transport protocols to use
higher sending rates, based on the ability of all the routers along higher sending rates, based on the ability of all the routers along
the path to determine if their respective output links are the path to determine if their respective output links are
significantly underutilized. significantly underutilized.
2. Assumptions and General Principles 2. Assumptions and General Principles
This section describes the assumptions and general principles behind This section describes the assumptions and general principles behind
the design of the Quick-Start mechanism. the design of the Quick-Start mechanism.
skipping to change at page 10, line 38 skipping to change at page 11, line 38
* The path between the two endpoints is relatively stable, such that * The path between the two endpoints is relatively stable, such that
the path used by the Quick-Start request is generally the same path the path used by the Quick-Start request is generally the same path
used by the Quick-Start packets one round-trip time later. [ZPS00] used by the Quick-Start packets one round-trip time later. [ZPS00]
shows this assumption should be generally valid, although [RFC3819] shows this assumption should be generally valid, although [RFC3819]
discusses a range of Bandwidth on Demand subnets. discusses a range of Bandwidth on Demand subnets.
* Any new mechanism must be incrementally deployable, and might not * Any new mechanism must be incrementally deployable, and might not
be supported by all of the routers and/or end-hosts. Thus, any new be supported by all of the routers and/or end-hosts. Thus, any new
mechanism must be able to accommodate non-supporting routers or end- mechanism must be able to accommodate non-supporting routers or end-
hosts without disturbing the current Internet semantics. hosts without disturbing the current Internet semantics. We note
that while Quick-Start is incrementally deployable in this sense, a
Quick-Start request can not be approved for a particular connection
unless both end-nodes and all of the routers along the path have
been configured to support Quick-Start.
General Principles: General Principles:
* Our underlying premise is that explicit feedback from all of the * Our underlying premise is that explicit feedback from all of the
routers along the path would be required, in the current routers along the path would be required, in the current
architecture, for best-effort connections to use initial windows architecture, for best-effort connections to use initial windows
significantly larger than those allowed by [RFC3390], in the absence significantly larger than those allowed by [RFC3390], in the absence
of other information about the path. of other information about the path.
* A router should only approve a request for a higher sending rate * A router should only approve a request for a higher sending rate
if the output link is underutilized. Any other approach will result if the output link is underutilized. Any other approach will result
in either per-flow state at the router, or the possibility of a in either per-flow state at the router, or the possibility of a
(possibly transient) queue at the router. (possibly transient) queue at the router.
* No per-flow state should be required at the router. Note that * No per-flow state should be required at the router. Note that
while per-flow state is not required we also do not preclude a while per-flow state is not required, we also do not preclude a
router from storing per-flow state for making Quick-Start decisions. router from storing per-flow state for making Quick-Start decisions
or for checking for misbehaving nodes.
There are also a number of questions regarding the Quick-Start There are also a number of questions regarding the Quick-Start
mechanism that are discussed later in this document. mechanism that are discussed later in this document.
Questions: Questions:
* Would the benefits of the Quick-Start mechanism be worth the added * Would the benefits of the Quick-Start mechanism be worth the added
complexity? complexity?
The benefits and drawbacks of Quick-Start are discussed in more The benefits and drawbacks of Quick-Start are discussed in more
detail in Section 9 on "Evaluation of Quick-Start". detail in Section 9 on "Evaluation of Quick-Start".
* One practical consideration is that packets with known and unknown * One practical consideration is that packets with known and unknown
IP options are often dropped in the current Internet [MAF04]. IP options are often dropped in the current Internet [MAF04].
This does not preclude using Quick-Start in Intranets. Further, We note that this does not preclude using Quick-Start in Intranets.
[MAF04] also shows that over time the blocking of packets Further, [MAF04] also shows that over time the blocking of packets
negotiating ECN has become less common, and therefore an incremental negotiating ECN has become less common, and therefore an incremental
deployment story for Quick-Start based on IP Options is not out of deployment story for Quick-Start based on IP Options is not out of
the question. Appendix A.1 on "Alternate Mechanisms for the Quick- the question for the Internet. Appendix A.1 on "Alternate
Start Request" discusses the possibility of using RSVP or ICMP Mechanisms for the Quick-Start Request" discusses the possibility of
instead of IP Options for carrying Quick-Start Requests to routers. using RSVP or ICMP instead of IP Options for carrying Quick-Start
Requests to routers.
* A second practical consideration is that packets could be dropped
at non-IP queues along the path.
This is discussed in more detail in Section 9.2 . * A second practical consideration is that Quick-Start data packets
could be dropped at non-IP queues along the path, if the non-IP
queue is a point of congestion. This is discussed in more detail in
Section 9.2.
* Apart from the merits and shortcomings of the Quick-Start * Apart from the merits and shortcomings of the Quick-Start
mechanism, is there likely to be a compelling need to add explicit mechanism, is there likely to be a compelling need to add explicit
congestion-related feedback from routers over and above the one-bit congestion-related feedback from routers over and above the one-bit
feedback from ECN? feedback from ECN?
If the answer to the question above is yes, should we be considering If the answer to the question above is yes, should we be considering
ways to incorporate Quick-Start in mechanisms that, while more ways to incorporate Quick-Start in mechanisms that, while more
complex, are also sufficiently more powerful than Quick-Start, or complex, are also sufficiently more powerful than Quick-Start, or
should Quick-Start be considered as orthogonal to such mechanisms? should Quick-Start be considered as orthogonal to such mechanisms?
This is discussed further in Appendix A.6 on "Why Not Include More This is discussed further in Appendix A.6 on "Why Not Include More
Functionality". Functionality".
2.1. Overview of Quick-Start 2.1. Overview of Quick-Start
In this section we give an overview of the use of Quick-Start with In this section we give an overview of the use of Quick-Start with
TCP, to request a higher congestion window. The description in this TCP to request a higher congestion window. The description in this
section is non-normative; the normative description of Quick-Start section is non-normative; the normative description of Quick-Start
with IP and TCP follows in Sections 3 and 4. Quick-Start can be used with IP and TCP follows in Sections 3 and 4. Quick-Start could be
in the middle of a connection, e.g., after an idle or underutilized used in the middle of a connection, e.g., after an idle or
period, as well as for the initial sending rate; these uses of underutilized period, as well as for the initial sending rate; these
Quick-Start are discussed later in the document. uses of Quick-Start are discussed later in the document.
Quick-Start requires end-points and routers to work together, with Quick-Start requires end-points and routers to work together, with
end-points requesting a higher sending rate in the Quick-Start end-points requesting a higher sending rate in the Quick-Start (QS)
Request (QSR) option in IP, and routers along the path approving, option in IP, and routers along the path approving, modifying,
modifying, discarding or ignoring (and therefore disallowing) the discarding or ignoring (and therefore disallowing) the Quick-Start
Quick-Start Request. The receiver uses reliable, transport-level Request. The receiver uses reliable, transport-level mechanisms to
mechanisms to inform the sender of the status of the Quick-Start inform the sender of the status of the Quick-Start Request. In
Request. In addition, Quick-Start assumes a unicast, congestion- addition, Quick-Start assumes a unicast, congestion-controlled
controlled transport protocol; we do not consider the use of Quick- transport protocol; we do not consider the use of Quick-Start for
Start for multicast traffic. multicast traffic.
The Quick-Start Request Option includes a request for a sending rate When sent as a request, the Quick-Start Option includes a request
in bytes per second, and a Quick-Start TTL (QS TTL) to be for a sending rate in bytes per second, and a Quick-Start TTL (QS
decremented by every router along the path that understands the TTL) to be decremented by every router along the path that
option and approves the request. The Quick-Start TTL is initialized understands the option and approves the request. The Quick-Start
by the sender to a random value. The transport receiver returns the TTL is initialized by the sender to a random value. The transport
rate and information about the TTL to the sender using transport- receiver returns the rate and information about the TTL to the
level mechanisms. In particular, the receiver computes the sender using transport-level mechanisms. In particular, the
difference between the Quick-Start TTL and the IP TTL (the TTL in receiver computes the difference between the Quick-Start TTL and the
the IP header) of the Quick-Start request packet, and returns this IP TTL (the TTL in the IP header) of the Quick-Start request packet,
in the Quick-Start response. The sender uses this information to and returns this in the Quick-Start response. The sender uses this
determine if all of the routers along the path decremented the information to determine if all of the routers along the path
Quick-Start TTL, approving the Quick-Start Request. decremented the Quick-Start TTL, approving the Quick-Start Request.
If the request is approved by all of the routers along the path, If the request is approved by all of the routers along the path,
then the TCP sender combines this allowed rate with the measurement then the TCP sender combines this allowed rate with the measurement
of the round-trip time, and ends up with an allowed TCP congestion of the round-trip time, and ends up with an allowed TCP congestion
window. This window is sent rate-paced over the next round-trip window. This window is sent rate-paced over the next round-trip
time, or until an ACK packet is received. time, or until an ACK packet is received.
Figure 1 shows a successful use of Quick-Start, with both routers Figure 1 shows a successful use of Quick-Start, with both routers
along the path approving the Quick-Start Request. In this example, along the path approving the Quick-Start Request. In this example,
Quick-Start is used by TCP to establish the initial congestion Quick-Start is used by TCP to establish the initial congestion
skipping to change at page 13, line 33 skipping to change at page 14, line 33
| <IP TTL: 61> | <IP TTL: 61>
| <QS TTL: 89> | <QS TTL: 89>
| <TTL Diff: 28> | <TTL Diff: 28>
| Return Quick-Start | Return Quick-Start
| info to sender in | info to sender in
| <-- TCP ACK packet. | <-- TCP ACK packet.
| |
| <TTL Diff: 28> | <TTL Diff: 28>
| Quick-Start approved, | Quick-Start approved,
| translate to cwnd. | translate to cwnd.
| Report Approved Rate.
V Send cwnd paced over one RTT. --> V Send cwnd paced over one RTT. -->
Figure 1: A successful Quick-Start Request. Figure 1: A successful Quick-Start Request.
Figure 2 shows an unsuccessful use of Quick-Start, with one of the Figure 2 shows an unsuccessful use of Quick-Start, with one of the
routers along the path not approving the Quick-Start Request. If routers along the path not approving the Quick-Start Request. If
the Quick-Start Request is not approved, then the sender uses the the Quick-Start Request is not approved, then the sender uses the
default congestion control mechanisms for that transport protocol, default congestion control mechanisms for that transport protocol,
including the default initial congestion window, response to idle including the default initial congestion window, response to idle
periods, etc. periods, etc.
skipping to change at page 14, line 31 skipping to change at page 15, line 31
| |
| <IP TTL: 61> | <IP TTL: 61>
| <QS TTL: 90> | <QS TTL: 90>
| <TTL Diff: 29> | <TTL Diff: 29>
| Return Quick-Start | Return Quick-Start
| info to sender in | info to sender in
| <-- TCP ACK packet. | <-- TCP ACK packet.
| |
| <TTL Diff: 29> | <TTL Diff: 29>
| Quick-Start not approved. | Quick-Start not approved.
| Report Approved Rate.
V Use default initial cwnd. --> V Use default initial cwnd. -->
Figure 2: An unsuccessful Quick-Start Request. Figure 2: An unsuccessful Quick-Start Request.
3. The Quick-Start Request in IP 3. The Quick-Start Option in IP
3.1. The Quick-Start Request 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 | QS TTL | Resv. | Rate | | Option | Length=8 | Func. | Rate | QS TTL |
| | | | |Request| | | | 0000 |Request| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QS Nonce | | | QS Nonce | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. The Quick-Start Request Option for IPv4. Figure 3. The Quick-Start Option for IPv4.
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
length of eight bytes. length of eight bytes.
The third byte contains the Quick-Start TTL (QS TTL) field. The The third byte includes a four-bit Function field. If the Function
sender MUST set the QS TTL field to a random value. Routers that field is set to "0000", then the Quick-Start Option is a Rate
approve the Quick-Start Request decrement the QS TTL (mod 256). The Request. In this case, the second half of the third byte is a four-
QS TTL is used by the sender to detect if all of the routers along bit Rate Request field.
the path understood and approved the Quick-Start option.
The transport sender MUST calculate and store the TTL Diff, the For a Rate Request, the fourth byte contains the Quick-Start TTL (QS
difference between the IP TTL value and the QS TTL value in the TTL) field. The sender MUST set the QS TTL field to a random value.
Quick-Start request packet, as follows: Routers that approve the Quick-Start Request decrement the QS TTL
(mod 256) by the same amount that they decrement the IP TTL. The QS
TTL is used by the sender to detect if all of the routers along the
path understood and approved the Quick-Start option.
For a Rate Request, the transport sender MUST calculate and store
the TTL Diff, the difference between the IP TTL value and the QS TTL
value in the Quick-Start request packet, as follows:
TTL Diff = ( IP TTL - QS TTL ) mod 256 (1) TTL Diff = ( IP TTL - QS TTL ) mod 256 (1)
The fourth byte includes a four-bit Reserved field, and a four-bit For a Rate Request, the second four bytes contain a 30-bit QS Nonce
Rate Request field. The second four bytes contain a 30-bit QS Nonce
and a two-bit Reserved field. The sender SHOULD set the reserved and a two-bit Reserved field. The sender SHOULD set the reserved
fields to zero, and routers SHOULD ignore the reserved fields. The field to zero, and routers SHOULD ignore the reserved field. The
sender SHOULD set the 30-bit QS Nonce to a random value. 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
skipping to change at page 16, line 27 skipping to change at page 17, line 31
10 40,960 10 40,960
11 81,920 11 81,920
12 163,840 12 163,840
13 327,680 13 327,680
14 655,360 14 655,360
15 1,310,720 15 1,310,720
Table 1: Mapping from Rate Request field to rate request in Kbps. Table 1: Mapping from Rate Request field to rate request in Kbps.
Routers can approve the Quick-Start Request for a lower rate by Routers can approve the Quick-Start Request for a lower rate by
decreasing the Rate Request in the Quick-Start Request. decreasing the Rate Request in the Quick-Start Request. Section 4.2
discusses the Quick-Start Response from the TCP receiver to the TCP
sender, and Section 4.4 discusses the TCP sender's mechanism for
determining if a Quick-Start Request has been approved.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option | Length=8 | Func. | Rate | Not Used |
| | | 1000 | Report| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Not Used |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. The Quick-Start Option for IPv4.
Report of Approved Rate.
If the Function field in the third byte of the Quick-Start Option is
set to "1000", then the Quick-Start Option is a Report of Approved
Rate. In this case the second four bits in the third byte are the
Rate Report field, formatted exactly as in the Rate Request field in
a Rate Request. For a Report of Approved Rate, the last five bytes
of the Quick-Start Option are not used.
After an approved Rate Request, the sender MUST report the Approved
Rate, using a Quick-Start Option configured as a Report of Approved
Rate with the Rate Report field set to the approved rate. The
packet containing the Report of Approved Rate MUST be either a
control packet sent before the first Quick-Start data packet, or a
Quick-Start Option in the first data packet itself. The Report of
Approved Rate does not have to be sent reliably; for example, if the
approved rate is reported in a separate control packet, the sender
does not necessarily know if the control packet has been dropped in
the network.
If the Rate Request is denied, the sender MUST sent a Report of
Approved Rate with the Rate Report field set to zero.
We note that unlike a Quick-Start Request sent at the beginning of a We note that unlike a Quick-Start Request sent at the beginning of a
connection, when a Quick-Start Request is sent in the middle of a connection, when a Quick-Start Request is sent in the middle of a
connection, the connection could already have an established connection, the connection could already have an established
congestion window or sending rate. The Rate Request is the congestion window or sending rate. The Rate Request is the
requested total rate for the connection, including the current rate requested total rate for the connection, including the current rate
of the connection; the Rate Request is *not* a request for an of the connection; the Rate Request is *not* a request for an
additional sending rate over and above the current sending rate. If additional sending rate over and above the current sending rate. If
the Rate Request is denied, or lowered to a value below the the Rate Request is denied, or lowered to a value below the
connection's current sending rate, then the sender ignores the connection's current sending rate, then the sender ignores the
request, and reverts to the default congestion control mechanisms of request, and reverts to the default congestion control mechanisms of
the transport protocol. the transport protocol.
In IPv4, a change in IP options at routers requires recalculating We note that in IPv4, a change in IP options at routers requires
the IP header checksum. recalculating the IP header checksum.
3.2. The Quick-Start Request Option for IPv6 3.2. The Quick-Start Option for IPv6
The Quick-Start Request Option for IPv6 is placed in the Hop-by-Hop The Quick-Start Option for IPv6 is placed in the Hop-by-Hop Options
Options extension header that is processed at every network node extension header that is processed at every network node along the
along the communication path [RFC 2460]. The option format following communication path [RFC 2460]. The option format following the
the generic Hop-by-Hop Options header is similar to the IPv4 format generic Hop-by-Hop Options header is identical to the IPv4 format,
with the exception that the Length field should exclude the common with the exception that the Length field should exclude the common
type and length fields in the option format and be set to 6 bytes. type and length fields in the option format and be set to 6 bytes
instead of 8 bytes.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option | Length=6 | QS TTL | Resv. | Rate |
| | | | |Request|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QS Nonce | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. The Quick-Start Request Option for IPv6.
The transport receiver compares the Quick-Start TTL with the IPv6 For a Quick-Start Request, the transport receiver compares the
Hop Limit field in order to calculate the TTL Diff. (The Hop Limit Quick-Start TTL with the IPv6 Hop Limit field in order to calculate
in IPv6 is the equivalent of the TTL in IPv4.) That is, TTL Diff the TTL Diff. (The Hop Limit in IPv6 is the equivalent of the TTL
MUST be calculated and stored as follows: in IPv4.) That is, TTL Diff MUST be calculated and stored as
follows:
TTL Diff = ( IPv6 Hop Limit - QS TTL ) mod 256 (2) TTL Diff = ( IPv6 Hop Limit - QS TTL ) mod 256 (2)
Unlike IPv4, modifying or deleting the Quick-Start Request IPv6 Unlike IPv4, modifying or deleting the Quick-Start IPv6 Option does
Option does not require checksum re-calculation, because the IPv6 not require checksum re-calculation, because the IPv6 header does
header does not have a checksum field, and modifying the Quick-Start not have a checksum field, and modifying the Quick-Start Request in
Request in the IPv6 Hop-by-Hop options header does not affect the the IPv6 Hop-by-Hop options header does not affect the IPv6 pseudo-
IPv6 pseudo-header checksum used in upper-layer checksum header checksum used in upper-layer checksum calculations.
calculations.
Note that [RFC2460] specifies that when a specific flow label has Note that [RFC2460] specifies that when a specific flow label has
been assigned to packets, the contents of the Hop-by-Hop options, been assigned to packets, the contents of the Hop-by-Hop options,
excluding the next header field, must originate with the same excluding the next header field, must originate with the same
contents throughout the IP flow lifetime. However, the Quick-Start contents throughout the IP flow lifetime. However, the Quick-Start
Request option would be included in only a small fraction of the option would be included in only a small fraction of the packets
packets during a flow lifetime. Thus, Quick-Start SHOULD NOT be during a flow lifetime. Thus, Quick-Start SHOULD NOT be used in an
used in an IPv6 connection that uses flow labels unless the IPv6 connection that uses flow labels unless the experimental
experimental specification of flow labels in Appendix A of RFC 2460 specification of flow labels in Appendix A of RFC 2460 is changed.
is changed. We note that RFC 2460 states that the use of the flow We note that RFC 2460 states that the use of the flow label field in
label field in IPv6 "is, at the time of writing, still experimental IPv6 "is, at the time of writing, still experimental and subject to
and subject to change as the requirements for flow support in the change as the requirements for flow support in the Internet become
Internet become clearer" [RFC2460]. clearer" [RFC2460].
3.3. Processing the Quick-Start Request at Routers 3.3. Processing the Quick-Start Request at Routers
Each participating router can either terminate or approve the Quick- The Quick-Start Request does not report the current sending rate of
Start Request. The router terminates the Quick-Start Request if the the connection sending the request; in the default case of a router
router is not underutilized, and therefore has decided not to grant that does not maintain per-flow state, a router makes the
the Quick-Start Request. conservative assumption that the flow's current sending rate is
zero. Each participating router can either terminate or approve the
Quick-Start Request. A router should only approve a Quick-Start
request if the output link is underutilized, and if the router
judges that the output link will continue to be underutilized if the
request is approved. Otherwise, the router terminates the Quick-
Start Request.
A router that wishes to terminate the Quick-Start Request SHOULD A router that wishes to terminate the Quick-Start Request SHOULD
delete the Quick-Start Request from the IP header. This saves delete the Quick-Start Request from the IP header. This saves
resources as downstream routers will have no option to process. If resources as downstream routers will have no option to process. If
a Quick-Start-capable router wishes to deny the request but doesn't a Quick-Start-capable router wishes to deny the request but doesn't
delete the Quick-Start Request from the IP header, then the router delete the Quick-Start Request from the IP header, then the router
SHOULD zero the QS TTL, QS Nonce, and Rate Request fields. This may SHOULD zero the QS TTL, QS Nonce, and Rate Request fields. Zeroing
be more efficient for routers to implement than deleting the Quick- the Rate Request field may be more efficient for routers to
Start option. A router that doesn't understand the Quick-Start implement than deleting the Quick-Start option. As suggested in
option will simply forward the packet with the Quick-Start Request [B05], future additions to Quick-Start could define error codes for
routers to insert into the QS Nonce field to report back to the
sender the reason that the Quick-Start request was denied, e.g.,
that the router is denying all Quick-Start requests at this time, or
that this router as a matter of policy does not grant Quick-Start
requests. A router that doesn't understand the Quick-Start option
will simply forward the packet with the Quick-Start Request
unchanged. unchanged.
If the participating router has decided to approve the Quick-Start If the participating router has decided to approve the Quick-Start
Request, it does the following: Request, it does the following:
* The router MUST decrement the QS TTL by one. * The router MUST decrement the QS TTL by one.
* If the router is only willing to approve a Rate Request less than * If the router is only willing to approve a Rate Request less than
that in the Quick-Start Request, then the router replaces the Rate that in the Quick-Start Request, then the router replaces the Rate
Request with a smaller value. The router MUST NOT increase the Rate Request with a smaller value. The router MUST NOT increase the Rate
Request in the Quick-Start Request. If the router decreases the Request in the Quick-Start Request. If the router decreases the
Rate Request, the router MUST also modify the QS Nonce, as described Rate Request, the router MUST also modify the QS Nonce, as described
in Section 3.4. in Section 3.4.
* In IPv4, the router MUST update the IP header checksum. * In IPv4, the router MUST update the IP header checksum.
If the router approves the Quick-Start request, this approval SHOULD
be taken into account in the router's decision to accept or reject
subsequent Quick-Start requests (e.g., in a variable that tracks the
recent aggregate of accepted Quick-Start bandwidth), but this
approval SHOULD NOT be used by the router to affect the treatment of
the data packets that arrive from this connection in the next few
round-trip times. That is, the approval by the router of a Quick-
Start request does not give differential treatment for Quick-Start
data packets at that router; it is only a statement from the router
that the router believes that the subsequent Quick-Start data
packets from this connection will not change the current under-
utilized state of the router.
A non-participating router forwards the Quick-Start Request A non-participating router forwards the Quick-Start Request
unchanged, without decrementing the QS TTL. The non-participating unchanged, without decrementing the QS TTL. The non-participating
router still decrements the TTL field in the IP header, as is router still decrements the TTL field in the IP header, as is
required for all routers [RFC1812]. As a result, the sender will be required for all routers [RFC1812]. As a result, the sender will be
able to detect that the Quick-Start Request had not been understood able to detect that the Quick-Start Request had not been understood
or approved by all of the routers along the path. or approved by all of the routers along the path.
3.3.1. Processing the Report of Approved Rate
If the Quick-Start Option has the Function field set to "1000", then
this is a Report of Approved Rate, rather than a Rate Request. The
router MAY ignore such an option, and in any case it MUST NOT modify
the contents of the option for a Report of Approved Rate. However,
the router MAY use the Approved Rate report to check that the sender
is not lying about the approved rate. If the reported Approved Rate
is higher than the rate that the router actually approved for this
connection in the previous round-trip time, then the router may
decide to deny future Quick-Start requests from this sender,
including, if desired, deleting Quick-Start requests from future
packets from this sender. Section 9.4.1 discusses misbehaving
senders in more detail. From the Report of Approved Rate, the
router can also learn if some of the downstream routers have
approved the Quick-Start request for a smaller rate, and adjust its
bandwidth allocations accordingly. From a Report of Approved Rate
with a Rate Report of zero, the router can learn if downstream
routers denied the earlier Quick-Start request.
3.4. The QS Nonce 3.4. The QS Nonce
The QS Nonce gives the Quick-Start sender some protection against The QS Nonce gives the Quick-Start sender some protection against
receivers lying about the value of the received Rate Request. This receivers lying about the value of the received Rate Request. This
is particularly important if the receiver knows the original value is particularly important if the receiver knows the original value
of the Rate Request (e.g., when the sender always requests the same of the Rate Request (e.g., when the sender always requests the same
value, and the receiver has a long history of communication with value, and the receiver has a long history of communication with
that sender.) Without the QS Nonce, there is nothing to prevent the that sender). Without the QS Nonce, there is nothing to prevent the
receiver from reporting back to the sender a Rate Request of K, when receiver from reporting back to the sender a Rate Request of K, when
the received Rate Request was in fact less than K. This version of the received Rate Request was in fact less than K. This version of
the nonce is based on a proposal from Guohan Lu [L05]. Initial the nonce is based on a proposal from Guohan Lu [L05]. Initial
versions of this document contained an eight-bit QS Nonce, and versions of this document contained an eight-bit QS Nonce, and
subsequent versions discussed the possibility of a four-bit QS subsequent versions discussed the possibility of a four-bit QS
Nonce. Nonce.
Table 2 gives the format for the 30-bit QS Nonce. Table 2 gives the format for the 30-bit QS Nonce.
Bits Purpose Bits Purpose
skipping to change at page 19, line 31 skipping to change at page 22, line 28
Bits 22-23: Rate 4 -> Rate 3 Bits 22-23: Rate 4 -> Rate 3
Bits 24-25: Rate 3 -> Rate 2 Bits 24-25: Rate 3 -> Rate 2
Bits 26-27: Rate 2 -> Rate 1 Bits 26-27: Rate 2 -> Rate 1
Bits 28-29: Rate 1 -> Rate 0 Bits 28-29: Rate 1 -> Rate 0
Table 2: The QS Nonce. Table 2: The QS Nonce.
The transport sender MUST initialize the QS Nonce to a random value. The transport sender MUST initialize the QS Nonce to a random value.
If the router reduces the Rate Request from rate K to rate K-1, then If the router reduces the Rate Request from rate K to rate K-1, then
the router MUST set the field in the QS Nonce for "Rate K -> Rate the router MUST set the field in the QS Nonce for "Rate K -> Rate
K-1" to a new random value. Similarly, if the router reduces the K-1" to a new random value, using the requirements for "randomness"
in the previous paragraph. Similarly, if the router reduces the
Rate Request by N steps, the router MUST set the 2N bits in the Rate Request by N steps, the router MUST set the 2N bits in the
relevant fields in the QS Nonce to a new random value. The receiver relevant fields in the QS Nonce to a new random value. The receiver
MUST report the QS Nonce back to the sender. MUST report the QS Nonce back to the sender.
If the Rate Request was not decremented in the network, then the QS If the Rate Request was not decremented in the network, then the QS
Nonce should have its original value. Similarly, if the Rate Nonce should have its original value. Similarly, if the Rate
Request was decremented by N steps in the network, and the receiver Request was decremented by N steps in the network, and the receiver
reports back a Rate Request of K, then the last 2K bits of the QS reports back a Rate Request of K, then the last 2K bits of the QS
Nonce should have their original value. Nonce should have their original value.
skipping to change at page 20, line 14 skipping to change at page 23, line 11
fields in the QS nonce for "Rate K+2 -> Rate K+1" and "Rate K+1 -> fields in the QS nonce for "Rate K+2 -> Rate K+1" and "Rate K+1 ->
Rate K". Thus, the receiver has a 1/16 chance in successfully lying Rate K". Thus, the receiver has a 1/16 chance in successfully lying
and saying that the received rate request was K+2 instead of K. and saying that the received rate request was K+2 instead of K.
We note that the protection offered by the QS Nonce is the same We note that the protection offered by the QS Nonce is the same
whether one router makes all of the decrements in the rate request, whether one router makes all of the decrements in the rate request,
or whether they are made at different routers along the path. or whether they are made at different routers along the path.
The requirements for randomization for the sender and routers in The requirements for randomization for the sender and routers in
setting `random' values in the QS Nonce are not stringent - almost setting `random' values in the QS Nonce are not stringent - almost
any form of pseudo-random numbers would do. The requirement from any form of pseudo-random numbers would do. The requirement is that
the sender is that the original value for the QS Nonce is not easily the original value for the QS Nonce is not easily guessable by the
guessable by the receiver. Thus, if two bits of the QS Nonce are receiver, and in particular, the nonce MUST NOT be easily determined
changed by a router along the path, the receiver should not be able from inspection of the rest of the packet or from previous packets.
to guess those two bits from the other 28 bits in the QS Nonce. In particular, the nonce MUST NOT be based only on a combination of
specific packet header fields. Thus, if two bits of the QS Nonce
are changed by a router along the path, the receiver should not be
able to guess those two bits from the other 28 bits in the QS Nonce.
A requirement of the routers is that the receiver can not be able to An additional requirement is that the receiver can not be able to
tell, from the QS Nonce itself, which numbers in the QS Nonce were tell, from the QS Nonce itself, which numbers in the QS Nonce were
generated by the sender, and which were generated by routers along generated by the sender, and which were generated by routers along
the path. This makes it harder for the receiver to infer the value the path. This makes it harder for the receiver to infer the value
of the original rate request, making it one step harder for the of the original rate request, making it one step harder for the
receiver to cheat. receiver to cheat.
Section 9.4 also considers issues of receiver cheating in more Section 9.4 also considers issues of receiver cheating in more
detail. detail.
4. The Quick-Start Mechanisms in TCP 4. The Quick-Start Mechanisms in TCP
This section describes how the Quick-Start mechanism would be used This section describes how the Quick-Start mechanism would be used
in TCP. We first sketch the procedure and then tightly define it in in TCP. We first sketch the procedure and then tightly define it in
the subsequent subsections. the subsequent subsections.
If a TCP sender, say host A, would like to use Quick-Start, the TCP If a TCP sender, say host A, would like to use Quick-Start, the TCP
sender puts the requested sending rate in bytes per second, sender puts the requested sending rate in bytes per second,
appropriately formatted, in the Quick-Start Request option in the IP appropriately formatted, in the Quick-Start option in the IP header
header of the TCP packet, called the Quick-Start request packet. of the TCP packet, called the Quick-Start request packet. (We will
(We will be somewhat loose in our use of "packet" vs. "segment" in be somewhat loose in our use of "packet" vs. "segment" in this
this section.) The Quick-Start Request also includes random values section.) The Quick-Start Request also includes random values for
for the QS TTL and the QS Nonce. When used for initial start-up, the QS TTL and the QS Nonce. When used for initial start-up, the
the Quick-Start request packet can be either the SYN or SYN/ACK Quick-Start request packet can be either the SYN or SYN/ACK packet,
packet, as described above. The requested rate includes an estimate as described above. The requested rate includes an estimate for the
for the transport and IP header overhead. The TCP receiver, say transport and IP header overhead. The TCP receiver, say host B,
host B, returns the Quick-Start Response option in the TCP header in returns the Quick-Start Response option in the TCP header in the
the responding SYN/ACK packet or ACK packet, called the Quick-Start responding SYN/ACK packet or ACK packet, called the Quick-Start
response packet, informing host A of the results of their request. response packet, informing host A of the results of their request.
If the acknowledging packet does not contain a Quick-Start Response, If the acknowledging packet does not contain a Quick-Start Response,
or contains a Quick-Start Response with the wrong value for the TTL or contains a Quick-Start Response with the wrong value for the TTL
Diff or the QS Nonce, then host A MUST assume that its Quick-Start Diff or the QS Nonce, then host A MUST assume that its Quick-Start
request failed. In this case, host A uses TCP's default congestion request failed. In this case, host A sends a Report of Approved
Rate with a Rate Report of zero, and uses TCP's default congestion
control procedure. For initial start-up, host A uses the default control procedure. For initial start-up, host A uses the default
initial congestion window. initial congestion window.
If the returning packet contains a valid Quick-Start Response, then If the returning packet contains a valid Quick-Start Response, then
host A uses the information in the response, along with its host A uses the information in the response, along with its
measurement of the round-trip time, to determine the Quick-Start measurement of the round-trip time, to determine the Quick-Start
congestion window (QS-cwnd). Quick-Start packets are defined as congestion window (QS-cwnd). Quick-Start data packets are defined
packets sent as the result of a successful Quick-Start request, up as data packets sent as the result of a successful Quick-Start
to the time when the first Quick-Start packet is acknowledged. In request, up to the time when the first Quick-Start packet is
order to use Quick-Start, the TCP host MUST use rate-based pacing to acknowledged. The sender sends a Report of Approved Rate. In order
to use Quick-Start, the TCP host MUST use rate-based pacing to
transmit Quick-Start packets at the rate indicated in the Quick- transmit Quick-Start packets at the rate indicated in the Quick-
Start Response, at the level of granularity possible by the sending Start Response, at the level of granularity possible by the sending
host. We note that the limitations of interrupt timing on computers host. We note that the limitations of interrupt timing on computers
can limit the ability of the TCP host in rate-pacing the outgoing can limit the ability of the TCP host in rate-pacing the outgoing
packets. packets.
The two TCP end-hosts can independently decide whether to request The two TCP end-hosts can independently decide whether to request
Quick-Start. For example, host A could sent a Quick-Start Request Quick-Start. For example, host A could sent a Quick-Start Request
in the SYN packet, and host B could also send a Quick-Start Request in the SYN packet, and host B could also send a Quick-Start Request
in the SYN/ACK packet. in the SYN/ACK packet.
4.1. When to Use Quick-Start 4.1. When to Use Quick-Start
In addition to the use of Quick-Start when a connection is In addition to the use of Quick-Start when a connection is
established, there are several additional points in a connection established, there are several additional points in a connection
when a transport protocol may want to issue a Rate Request. We when a transport protocol may want to issue a Rate Request. We
first re-iterate the notion that Quick-Start is a coarse-grained first re-iterate the notion that Quick-Start is a coarse-grained
mechanism. That is, Quick-Start's Rate Requests are not meant to be mechanism. That is, Quick-Start's Rate Requests are not meant to be
used for fine-grained control of the transport's sending rate. used for fine-grained control of the transport's sending rate.
Rather, the transport MAY issue a Rate Request when no information Rather, the transport MAY issue a Rate Request when no information
about the appropriate sending rate is available, and the default about the appropriate sending rate is available and the default
congestion control mechanisms might be significantly underestimating congestion control mechanisms might be significantly underestimating
the appropriate sending rate. the appropriate sending rate.
The following are potential points where Quick-Start may be useful: The following are potential points where Quick-Start may be useful:
(1) At or soon after connection initiation, when the transport (1) At or soon after connection initiation, when the transport
has no idea of the capacity of the network, as discussed above. has no idea of the capacity of the network, as discussed above.
(A transport that uses TCP Control Block sharing, the Congestion (A transport that uses TCP Control Block sharing, the Congestion
Manager, or the like may not need Quick-Start to determine an Manager, or the like may not need Quick-Start to determine an
appropriate rate.) appropriate rate.)
skipping to change at page 22, line 17 skipping to change at page 25, line 17
HTTP request is received after an idle period.) HTTP request is received after an idle period.)
(3) After a host has received explicit indications that one of (3) After a host has received explicit indications that one of
the endpoints has moved its point of network attachment. This the endpoints has moved its point of network attachment. This
can happen due to some underlying mobility mechanism like Mobile can happen due to some underlying mobility mechanism like Mobile
IP [RFC3344,RFC3775]. Some transports, such as SCTP [RFC2960], IP [RFC3344,RFC3775]. Some transports, such as SCTP [RFC2960],
may associate with multiple IP addresses and can switch may associate with multiple IP addresses and can switch
addresses (and, therefore network paths) in mid-connection. If addresses (and, therefore network paths) in mid-connection. If
the transport has concrete knowledge of a changing network path the transport has concrete knowledge of a changing network path
then the current sending rate may not be appropriate and the then the current sending rate may not be appropriate and the
transport sender may use Quick-Start to probe the network for transport sender may use Quick-Start to probe the network to see
the appropriate rate at which to send. (Alternatively, if it can send at a higher rate. (Alternatively, traditional
traditional slow-start should be used in this case when Quick- slow-start should be used in this case when Quick-Start is not
Start is not available.) available.)
(4) After an application-limited period when the sender has been (4) After an application-limited period when the sender has been
using only a small amount of its appropriate share of the using only a small amount of its appropriate share of the
network capacity, and has no valid estimate for its fair share. network capacity, and has no valid estimate for its fair share.
In this case, Quick-Start may be an appropriate mechanism to In this case, Quick-Start may be an appropriate mechanism to
assess the available capacity on the network path. For determine if the sender can send at a higher rate. For
instance, consider an application that steadily exchanges low- instance, consider an application that steadily exchanges low-
rate control messages and suddenly needs to transmit a large rate control messages and suddenly needs to transmit a large
amount of data. amount of data.
Of the above, this document recommends that a TCP sender MAY attempt Of the above, this document recommends that a TCP sender MAY attempt
to use Quick-Start in cases (1) and (2). It is NOT RECOMMENDED that to use Quick-Start in cases (1) and (2). It is NOT RECOMMENDED that
a TCP sender use Quick-Start for case (3) at the current time. Case a TCP sender use Quick-Start for case (3) at the current time. Case
(3) requires external notifications not presently defined for TCP or (3) requires external notifications not presently defined for TCP or
other transport protocols. Finally, a TCP SHOULD NOT use Quick- other transport protocols. Finally, a TCP SHOULD NOT use Quick-
Start for case (4) at the current time. Case (4) requires further Start for case (4) at the current time. Case (4) requires further
thought and investigation with regard to how the transport protocol thought and investigation with regard to how the transport protocol
could determine it was in a situation that would warrant could determine it was in a situation that would warrant
transmitting a Quick-Start Rate Request. transmitting a Quick-Start Request.
As a general guideline, a TCP sender SHOULD NOT send a Quick-Start As a general guideline, a TCP sender SHOULD NOT send a Quick-Start
request until it has confirmed that is ready to transmit enough data request until it has confirmed that is ready to transmit enough data
to use the requested rate over the round-trip time of the connection to use the requested rate over the round-trip time of the connection
(or over 100 ms, if the round-trip time is not known). In any (or over 100 ms, if the round-trip time is not known). In any
circumstances, the sender MUST NOT make a QS request if it has made circumstances, the sender MUST NOT make a QS request if it has made
a QS request within the most recent round-trip time. a QS request within the most recent round-trip time.
Section 4.6 discusses some of the issues of using Quick-Start at Section 4.6 discusses some of the issues of using Quick-Start at
connection initiation, and Section 4.7 discusses issues that arise connection initiation, and Section 4.7 discusses issues that arise
when Quick-Start is used to request a larger sending rate after an when Quick-Start is used to request a larger sending rate after an
idle period. idle period.
4.2. The Quick-Start Response Option in the TCP header 4.2. The Quick-Start Response Option in the TCP header
In order to approve the use of Quick-Start, the TCP receiver
responds to the receipt of a Quick-Start Request with a Quick-Start
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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. 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 four bytes. option length in bytes. The length field MUST be set to four bytes.
The third byte of the Quick-Start Response option contains a four- The third byte of the Quick-Start Response option contains a four-
bit Reserved field, and the four-bit allowed Rate Request, formatted bit Reserved field, and the four-bit allowed Rate Request, formatted
as in the Quick-Start Request option. as in the Quick-Start option.
The fourth byte of the TCP option contains the TTL Diff. The TTL The fourth byte of the TCP option contains the TTL Diff. The TTL
Diff contains the difference between the IP TTL and QS TTL fields in Diff contains the difference between the IP TTL and QS TTL fields in
the received Quick-Start request packet, as calculated in equations the received Quick-Start request packet, as calculated in equations
(1) or (2) (depending on whether IPv4 or IPv6 is used). (1) or (2) (depending on whether IPv4 or IPv6 is used).
The last four bytes of the TCP option contain the 30-bit QS Nonce The last four bytes of the TCP option contain the 30-bit QS Nonce
and a two-bit Reserved field. and a two-bit Reserved field.
We note that the Quick-Start Response Option for TCP contains eight We note that the Quick-Start Response Option for TCP contains eight
skipping to change at page 24, line 15 skipping to change at page 27, line 17
4.3. TCP: Sending the Quick-Start Response 4.3. TCP: Sending the Quick-Start Response
An end host, say host B, that receives an IP packet containing a An end host, say host B, that receives an IP packet containing a
Quick-Start Request passes the Quick-Start Request, along with the Quick-Start Request passes the Quick-Start Request, along with the
value in the IP TTL field, to the receiving TCP layer. value in the IP TTL field, to the receiving TCP layer.
If the TCP host is willing to permit the Quick-Start Request, then a If the TCP host is willing to permit the Quick-Start Request, then a
Quick-Start Response option is included in the TCP header of the Quick-Start Response option is included in the TCP header of the
corresponding acknowledgement packet. The Rate Request in the corresponding acknowledgement packet. The Rate Request in the
Quick-Start Response option is set to the received value of the Rate Quick-Start Response option is set to the received value of the Rate
Request in the Quick-Start Request option, or to a lower value if Request in the Quick-Start option, or to a lower value if the TCP
the TCP receiver is only willing to allow a lower Rate Request. The receiver is only willing to allow a lower Rate Request. The TTL
TTL Diff in the Quick-Start Response is set to the difference Diff in the Quick-Start Response is set to the difference between
between the IP TTL value and the QS TTL value as given in equation the IP TTL value and the QS TTL value as given in equation (1) or
(1) or (2) (depending on whether IPv4 or IPv6 is used). The QS (2) (depending on whether IPv4 or IPv6 is used). The QS Nonce in
Nonce in the Response is set to the received value of the QS Nonce the Response is set to the received value of the QS Nonce in the
in the Quick-Start Request option. Quick-Start option.
The Quick-Start Response will NOT be resent if it is lost in the The Quick-Start Response will NOT be resent if it is lost in the
network. Packet loss is an indication of congestion on the return network. Packet loss is an indication of congestion on the return
path, in which case it is better not to approve the Quick-Start path, in which case it is better not to approve the Quick-Start
Request. Request.
4.4. TCP: Receiving and Using the Quick-Start Response Packet 4.4. TCP: Receiving and Using the Quick-Start Response Packet
A TCP host, say TCP host A, that sent a Quick-Start Request and A TCP host, say TCP host A, that sent a Quick-Start Request and
receives a Quick-Start Response in an acknowledgement first checks receives a Quick-Start Response in an acknowledgement first checks
that the Quick-Start Response is valid. The Quick-Start Response is that the Quick-Start Response is valid. The Quick-Start Response is
valid if it contains the correct value for the TTL Diff, and an valid if it contains the correct value for the TTL Diff, and an
equal or lesser value for the Rate Request than that transmitted in equal or lesser value for the Rate Request than that transmitted in
the Quick-Start Request. In addition, if the received Rate Request the Quick-Start Request. In addition, if the received Rate Request
is K, then the the rightmost 2K bits of the QS Nonce must match is K, then the the rightmost 2K bits of the QS Nonce must match
those bits in the QS Nonce sent in the Quick-Start Request. If those bits in the QS Nonce sent in the Quick-Start Request. If
these checks are not successful, then the Quick-Start request these checks are not successful, then the Quick-Start request
failed, and the TCP host MUST use the default TCP congestion window failed, and the TCP host MUST use the default TCP congestion window
that it would have used without Quick-Start. that it would have used without Quick-Start. If the rightmost 2K
bits of the QS Nonce do not match those bits in the QS Nonce sent in
the Quick-Start Request, for a received Rate Request of K, then the
TCP host MUST NOT send additional Quick-Start requests during the
life of the connection. Whether the Quick-Start request was
successful or not, the TCP host MUST send a Report of Approved Rate.
If the checks of the TTL Diff and the Rate Request are successful, If the checks of the TTL Diff and the Rate Request are successful,
then the TCP host sets its Quick-Start congestion window (in terms then the TCP host sets its Quick-Start congestion window (in terms
of MSS-sized segments), QS-cwnd, as follows: of MSS-sized segments), QS-cwnd, as follows:
QS-cwnd = (R * T) / (MSS + H) (3) QS-cwnd = (R * T) / (MSS + H) (3)
where R the Rate Request in bytes per second, T the measured round- where R the Rate Request in bytes per second, T the measured round-
trip time in seconds, and H the estimated TCP/IP header size in trip time in seconds, and H the estimated TCP/IP header size in
bytes (e.g., 40 bytes). bytes (e.g., 40 bytes).
skipping to change at page 28, line 32 skipping to change at page 31, line 38
RFC 1122 and 2988 recommend that the sender should set the initial RFC 1122 and 2988 recommend that the sender should set the initial
RTO to three seconds, though many TCP implementations set the RTO to three seconds, though many TCP implementations set the
initial RTO to one second. For a TCP SYN packet sent with a Quick- initial RTO to one second. For a TCP SYN packet sent with a Quick-
Start request, the TCP sender SHOULD use an initial RTO of three Start request, the TCP sender SHOULD use an initial RTO of three
seconds. seconds.
In the case of a retransmission, in addition to resending the SYN or In the case of a retransmission, in addition to resending the SYN or
SYN/ACK packet without the Quick-Start Request, the TCP sender SYN/ACK packet without the Quick-Start Request, the TCP sender
SHOULD use an RTO of three seconds and a different Initial Sequence SHOULD use an RTO of three seconds and a different Initial Sequence
Number. Using this scheme the TCP sender MUST keep track of when Number. Using this scheme the TCP sender MUST keep track of when
each of the SYN (or SYN/ACKs) was transmitted. In this way, an each of the SYN (or SYN/ACK) packets was transmitted. In this way,
acknowledgement for the retransmitted SYN or SYN/ACK packet can be an acknowledgement for the retransmitted SYN or SYN/ACK packet can
matched with the SYN or SYN/ACK being acknowledged, and the be matched with the SYN or SYN/ACK being acknowledged, and the
transmission time of the SYN (or SYN/ACK) being acknowledged can be transmission time of the SYN (or SYN/ACK) being acknowledged can be
used for an RTT measurement to seed the RTO. If only the used for an RTT measurement to seed the RTO. If only the
retransmitted SYN or SYN/ACK is acknowledged, the TCP sender can retransmitted SYN or SYN/ACK is acknowledged, the TCP sender can
reasonably assume that the earlier SYN or SYN/ACK with the Quick- reasonably assume that the earlier SYN or SYN/ACK with the Quick-
Start option was dropped by the network because of the option and Start option was dropped by the network because of the option and
not because of congestion. In this case, the TCP sender can refrain not because of congestion. In this case, the TCP sender can refrain
from performing TCP's standard congestion control state changes. from performing TCP's standard congestion control state changes.
We note that if the TCP SYN packet is using the IP Quick-Start We note that if the TCP SYN packet is using the IP Quick-Start
Option for a Quick-Start request, and it is also using bits in the Option for a Quick-Start request, and it is also using bits in the
skipping to change at page 29, line 11 skipping to change at page 32, line 16
information in the TCP header negotiating ECN. In this case, the information in the TCP header negotiating ECN. In this case, the
sender could resend the dropped packet without either the Quick- sender could resend the dropped packet without either the Quick-
Start or the ECN requests. Alternately, the sender could resend the Start or the ECN requests. Alternately, the sender could resend the
dropped packet with only the ECN request in the TCP header, dropped packet with only the ECN request in the TCP header,
resending the TCP SYN packet without either the Quick-Start or the resending the TCP SYN packet without either the Quick-Start or the
ECN requests if the second TCP SYN packet is dropped. The second ECN requests if the second TCP SYN packet is dropped. The second
choice seems reasonable, given that a TCP SYN packet today is more choice seems reasonable, given that a TCP SYN packet today is more
likely to be blocked due to IP Options than due to an ECN request in likely to be blocked due to IP Options than due to an ECN request in
the TCP header [MAF04]. the TCP header [MAF04].
4.7. TCP: A Quick-Start Request in the Middle of Connection It is always possible that some middlebox that doesn't drop TCP SYN
packets containing Quick-Start options will still drop or delay TCP
data packets containing Quick-Start options as Approved Rate
reports. This would be one reason for a TCP sender to report the
Approved Rate in a separate control packet, rather than in a data
packet.
4.7. TCP: A Quick-Start Request in the Middle of a Connection
This section discusses the following issues that arise when Quick- This section discusses the following issues that arise when Quick-
Start is used by TCP to request a larger window in the middle of Start is used by TCP to request a larger window in the middle of
connection, for example after an idle period: (1) determining the connection, for example after an idle period: (1) determining the
rate to request; and (2) the response if Quick-Start packets are rate to request; and (2) the response if Quick-Start packets are
dropped; dropped;
(1) Determining the rate to request: (1) Determining the rate to request:
In the middle of connection, an easy rule of thumb would be for the In the middle of connection, an easy rule of thumb would be for the
TCP sender to determine the largest congestion window that the TCP TCP sender to determine the largest congestion window that the TCP
skipping to change at page 29, line 34 skipping to change at page 32, line 46
Start request. If the request is granted, then the sender Start request. If the request is granted, then the sender
essentially restarts with its old congestion window from before it essentially restarts with its old congestion window from before it
was reduced, for example during an idle period. was reduced, for example during an idle period.
In the case of an idle period, the sender SHOULD NOT use Quick-Start In the case of an idle period, the sender SHOULD NOT use Quick-Start
if the idle period has been less than an RTO, and the congestion if the idle period has been less than an RTO, and the congestion
window has not decayed down to less than half of its value at the window has not decayed down to less than half of its value at the
start of the idle period. Such a use of Quick-Start requires start of the idle period. Such a use of Quick-Start requires
further investigation. further investigation.
A Quick-Start Request sent in the middle of a TCP connection could
be carried either in a data packet or in a pure acknowledgement
packet.
(2) Response if Quick-Start packets are dropped: (2) Response if Quick-Start packets are dropped:
If Quick-Start packets are dropped in the middle of connection, then If Quick-Start packets are dropped in the middle of connection, then
the sender MUST revert to half of the Quick-Start window, or to the the sender MUST revert to half of the Quick-Start window, or to the
congestion window that the sender would have used if the Quick-Start congestion window that the sender would have used if the Quick-Start
request had not been approved, whichever is smaller. request had not been approved, whichever is smaller.
We note that a packet in the middle of a connection carrying a
Quick-Start Request might or might not carry a data payload. For
example, for TCP, the Quick-Start Request could be carried by a data
packet, or by a pure acknowledgement packet.
4.8. An Example Quick-Start Scenario with TCP 4.8. An Example Quick-Start Scenario with TCP
The following is an example scenario in the case when both hosts The following is an example scenario in the case when both hosts
request Quick-Start for setting their initial windows. This is request Quick-Start for setting their initial windows. This is
similar to Figures 1 and 2 in Section 2.1, except that it similar to Figures 1 and 2 in Section 2.1, except that it
illustrates a TCP connection with both TCP hosts sending Quick-Start illustrates a TCP connection with both TCP hosts sending Quick-Start
Requests. Requests.
* The TCP SYN packet from Host A contains a Quick-Start Request in * The TCP SYN packet from Host A contains a Quick-Start Request in
the IP header. the IP header.
skipping to change at page 30, line 27 skipping to change at page 33, line 38
the IP header of the SYN/ACK packet. the IP header of the SYN/ACK packet.
* Routers along the reverse path modify the Quick-Start Request as * Routers along the reverse path modify the Quick-Start Request as
appropriate. appropriate.
* Host A receives the Quick-Start Response in the SYN/ACK packet, * Host A receives the Quick-Start Response in the SYN/ACK packet,
and checks the TTL Diff, Rate Request, and QS Nonce for validity. and checks the TTL Diff, Rate Request, and QS Nonce for validity.
If they are valid, then Host A sets its initial congestion window If they are valid, then Host A sets its initial congestion window
appropriately, and sets up rate-based pacing to be used with the appropriately, and sets up rate-based pacing to be used with the
initial window. If the Quick-Start Response is not valid, then Host initial window. If the Quick-Start Response is not valid, then Host
A uses TCP's default initial window. A uses TCP's default initial window. In either case, Host A sends a
Report of Approved Rate.
Host A also calculates the TTL Diff for the Quick-Start Request in Host A also calculates the TTL Diff for the Quick-Start Request in
the incoming SYN/ACK packet, and sends a Quick-Start Response in the the incoming SYN/ACK packet, and sends a Quick-Start Response in the
TCP header of the ACK packet. TCP header of the ACK packet.
* Host B receives the Quick-Start Response in an ACK packet, and * Host B receives the Quick-Start Response in an ACK packet, and
checks the TTL Diff, Rate Request, and QS Nonce for validity. If checks the TTL Diff, Rate Request, and QS Nonce for validity. If
the Quick-Start Response is valid, then Host B sets its initial the Quick-Start Response is valid, then Host B sets its initial
congestion window appropriately, and sets up rate-based pacing to be congestion window appropriately, and sets up rate-based pacing to be
used with its initial window. If the Quick-Start Response is not used with its initial window. If the Quick-Start Response is not
valid, then Host B uses TCP's default initial window. valid, then Host B uses TCP's default initial window. In either
case, Host B sends a Report of Approved Rate.
5. Quick-Start and IPsec AH 5. Quick-Start and IPsec AH
This section shows that Quick-Start is compatible with IPsec AH This section shows that Quick-Start is compatible with IPsec AH
(Authentication Header). AH uses an Integrity Check Value (ICV) in (Authentication Header). AH uses an Integrity Check Value (ICV) in
the IPsec Authentication Header to verify both message the IPsec Authentication Header to verify both message
authentication and integrity [RFC2402,2402bis]. Changes to the authentication and integrity [RFC2402,2402bis]. Changes to the
Quick-Start option in the IP header do not affect this AH ICV. The Quick-Start option in the IP header do not affect this AH ICV. The
tunnel considerations in Section 3.6 below apply to all IPsec tunnel considerations in Section 6 below apply to all IPsec tunnels,
tunnels, regardless of what IPsec headers or processing are used in regardless of what IPsec headers or processing are used in
conjunction with the tunnel. conjunction with the tunnel.
Because the contents of the Quick-Start Request option can change Because the contents of the Quick-Start option can change along the
along the path, it is important that these changes not affect the path, it is important that these changes not affect the IPsec
IPsec Authentication Header Integrity Check Value (AH ICV). For Authentication Header Integrity Check Value (AH ICV). For IPv4, RFC
IPv4, RFC 2402 requires that unrecognized IPv4 options be zeroed for 2402 requires that unrecognized IPv4 options be zeroed for AH ICV
AH ICV computation purposes, so Quick-Start IP Option data changing computation purposes, so Quick-Start IP Option data changing en
en route does not cause problems with existing IPsec AH route does not cause problems with existing IPsec AH implementations
implementations for IPv4. If the Quick-Start Request option is for IPv4. If the Quick-Start option is recognized, it MUST be
recognized, it MUST be treated as a mutable IPv4 option, and hence treated as a mutable IPv4 option, and hence be completely zeroed for
be completely zeroed for AH ICV calculation purposes. IPv6 option AH ICV calculation purposes. IPv6 option numbers explicitly
numbers explicitly indicate whether the option is mutable; the 3rd indicate whether the option is mutable; the 3rd highest order bit in
highest order bit in the IANA-allocated option type has the value 1 the IANA-allocated option type has the value 1 to indicate that the
to indicate that the Quick-Start Request option data can change en Quick-Start option data can change en route. RFC 2402 requires that
route. RFC 2402 requires that the option data of any such option be the option data of any such option be zeroed for AH ICV computation
zeroed for AH ICV computation purposes. Therefore changes to the purposes. Therefore changes to the Quick-Start option in the IP
Quick-Start option in the IP header do not affect the calculation of header do not affect the calculation of the AH ICV.
the AH ICV.
6. Quick-Start in IP Tunnels 6. Quick-Start in IP Tunnels
This section considers interactions between Quick-Start and IP This section considers interactions between Quick-Start and IP
tunnels, including IPsec [RFC2401,2401bis] and IP in IP [RFC2003]. tunnels, including IPsec [RFC2401,2401bis] and IP in IP [RFC2003].
In the discussion, we use TTL Diff, defined earlier as the In the discussion, we use TTL Diff, defined earlier as the
difference between the IP TTL and the Quick-Start TTL, mod 256. difference between the IP TTL and the Quick-Start TTL, mod 256.
Recall that the sender considers the Quick-Start request approved Recall that the sender considers the Quick-Start request approved
only if the value of TTL Diff for the packet entering the network is only if the value of TTL Diff for the packet entering the network is
skipping to change at page 32, line 20 skipping to change at page 35, line 25
(False Positives!) (False Positives!)
__ Tunnels Supporting Quick-Start __ Tunnels Supporting Quick-Start
/ /
/ /
Non-Simple Tunnels __/_____ Tunnels Compatible with Quick-Start, Non-Simple Tunnels __/_____ Tunnels Compatible with Quick-Start,
\ but Not Supporting Quick-Start \ but Not Supporting Quick-Start
\ \
\__ Tunnels Not Compatible with Quick-Start? \__ Tunnels Not Compatible with Quick-Start?
Figure 5: Categories of Tunnels. Figure 6: Categories of Tunnels.
Tunnels that are compatible with Quick-Start: We say that an IP Tunnels that are compatible with Quick-Start: We say that an IP
tunnel `is not compatible with Quick-Start' if the use of a Quick- tunnel `is not compatible with Quick-Start' if the use of a Quick-
Start Request over such a tunnel allows false positives, where the Start Request over such a tunnel allows false positives, where the
TCP sender incorrectly believes that the Quick-Start Request was TCP sender incorrectly believes that the Quick-Start Request was
approved by all routers along the path. If the use of Quick-Start approved by all routers along the path. If the use of Quick-Start
over the tunnel does not cause false positives, we say that the IP over the tunnel does not cause false positives, we say that the IP
tunnel `is compatible with Quick-Start'. tunnel `is compatible with Quick-Start'.
If the IP TTL of the inner header is decremented during forwarding If the IP TTL of the inner header is decremented during forwarding
before tunnel encapsulation takes place, then the simple tunnel is before tunnel encapsulation takes place, then the simple tunnel is
compatible with Quick-Start, with Quick-Start requests being compatible with Quick-Start, with Quick-Start requests being
rejected. Section 6.1 describes in more detail the ways that a rejected. Section 6.1 describes in more detail the ways that a
simple tunnel can be compatible with Quick-Start. simple tunnel can be compatible with Quick-Start.
There are some simple tunnels that are not compatible with with There are some simple tunnels that are not compatible with Quick-
Quick-Start, allowing `false positives' where the TCP sender Start, allowing `false positives' where the TCP sender incorrectly
incorrectly believes that the Quick-Start Request was approved by believes that the Quick-Start Request was approved by all routers
all routers along the path. This is discussed in Section 6.2 below. along the path. This is discussed in Section 6.2 below.
One of our tasks in the future will be to investigate the occurrence One of our tasks in the future will be to investigate the occurrence
of tunnels that are not compatible with Quick-Start, and to track of tunnels that are not compatible with Quick-Start, and to track
the extent to which such tunnels are modified over time. The the extent to which such tunnels are modified over time. The
evaluation of the problem of false positives from tunnels that are evaluation of the problem of false positives from tunnels that are
not compatible with Quick-Start will affect the progression of not compatible with Quick-Start will affect the progression of
Quick-Start from Experimental to Proposed Standard, and will affect Quick-Start from Experimental to Proposed Standard, and will affect
the degree of deployment of Quick-Start while in Experimental mode. the degree of deployment of Quick-Start while in Experimental mode.
Tunnels that support Quick-Start: We say that an IP tunnel `supports Tunnels that support Quick-Start: We say that an IP tunnel `supports
skipping to change at page 34, line 14 skipping to change at page 37, line 20
Quick-Start rate request, QS TTL, and QS Nonce fields or remove the Quick-Start rate request, QS TTL, and QS Nonce fields or remove the
Quick-Start option from the inner header before encapsulation. Quick-Start option from the inner header before encapsulation.
Section 6.3 describes the procedures for a tunnel that does want to Section 6.3 describes the procedures for a tunnel that does want to
support Quick-Start. support Quick-Start.
Deleting the Quick-Start option or zeroing the Quick-Start rate Deleting the Quick-Start option or zeroing the Quick-Start rate
request *after decapsulation* also serves to prevent the propagation request *after decapsulation* also serves to prevent the propagation
of Quick-Start information, and is compatible with Quick-Start. If of Quick-Start information, and is compatible with Quick-Start. If
the outer header does not contain a Quick-Start Request, a Quick- the outer header does not contain a Quick-Start Request, a Quick-
Start-aware tunnel egress MUST reject the inner Quick-Start Request Start-aware tunnel egress MUST reject the inner Quick-Start Request
by resetting the Rate Request field in the inner header, or by by zeroing the Rate Request field in the inner header, or by
deleting the Quick-Start Request option. deleting the Quick-Start option.
If the tunnel ingress is at a sending host or router where the IP If the tunnel ingress is at a sending host or router where the IP
TTL is not decremented prior to encapsulation, and neither tunnel TTL is not decremented prior to encapsulation, and neither tunnel
endpoint is aware of Quick-Start, then this allows false positives, endpoint is aware of Quick-Start, then this allows false positives,
described in the section below. described in the section below.
6.2. Simple Tunnels That Are Not Compatible with Quick-Start 6.2. Simple Tunnels That Are Not Compatible with Quick-Start
Sometimes a tunnel implementation that does not support Quick-Start Sometimes a tunnel implementation that does not support Quick-Start
is independent of the TCP sender or a router implementation that is independent of the TCP sender or a router implementation that
skipping to change at page 35, line 24 skipping to change at page 38, line 32
QS TTL is not decremented, then the value of TTL Diff is changed, QS TTL is not decremented, then the value of TTL Diff is changed,
and the Quick-Start request will be denied. However, if the BITW and the Quick-Start request will be denied. However, if the BITW
supports a host and does not have its own IP address, then the IP supports a host and does not have its own IP address, then the IP
TTL is not decremented before the packet is passed from the host to TTL is not decremented before the packet is passed from the host to
the BITW, and a false positive could occur. the BITW, and a false positive could occur.
Other tunnels that need to be looked at are IP tunnels over non- Other tunnels that need to be looked at are IP tunnels over non-
network protocols, such as IP over TCP and IP over UDP [RFC3948], network protocols, such as IP over TCP and IP over UDP [RFC3948],
and tunnels using the Layer Two Tunneling Protocol [RFC2661]. and tunnels using the Layer Two Tunneling Protocol [RFC2661].
Section 6.2 discusses the related issue of non-IP queues, such as Section 9.2 discusses the related issue of non-IP queues, such as
layer-two Ethernet or ATM networks, as another instance of possible layer-two Ethernet or ATM networks, as another instance of possible
bottlenecks that do not participate in the Quick-Start feedback. bottlenecks that do not participate in the Quick-Start feedback.
6.3. Tunnels That Support Quick-Start 6.3. Tunnels That Support Quick-Start
This section discusses tunnels configured to support Quick-Start. This section discusses tunnels configured to support Quick-Start.
If the tunnel ingress node chooses to locally approve the Quick- If the tunnel ingress node chooses to locally approve the Quick-
Start request, then the ingress node MUST decrement the Quick-Start Start request, then the ingress node MUST decrement the Quick-Start
TTL at the same time it decrements the IP TTL, and MUST copy IP TTL TTL at the same time it decrements the IP TTL, and MUST copy IP TTL
skipping to change at page 36, line 5 skipping to change at page 39, line 12
Quick-Start request, then it MUST either delete the Quick-Start Quick-Start request, then it MUST either delete the Quick-Start
option from the inner header before encapsulation, or zero the QS option from the inner header before encapsulation, or zero the QS
TTL and the Rate Request fields before encapsulation. TTL and the Rate Request fields before encapsulation.
Upon decapsulation, if the outer header contains a Quick-Start Upon decapsulation, if the outer header contains a Quick-Start
option, the tunnel egress MUST copy the IP TTL and the Quick-Start option, the tunnel egress MUST copy the IP TTL and the Quick-Start
option from the outer IP header to the inner header. option from the outer IP header to the inner header.
IPsec uses the IKE (Internet Key Exchange) Protocol for security IPsec uses the IKE (Internet Key Exchange) Protocol for security
associations. We do not consider the interactions between Quick- associations. We do not consider the interactions between Quick-
Start and IPsec with IKEv1 [RFC2409] in this document. When the RFC Start and IPsec with IKEv1 [RFC2409] in this document. Now that the
for IKEv2 [IKEv2] is published, we will specify a modification of RFC for IKEv2 [RFC4306] is published, we plan to specify a
IPsec to allow the support of Quick-Start to be negotiated; this modification of IPsec to allow the support of Quick-Start to be
modification will specify the negotiation between tunnel endpoints negotiated; this modification will specify the negotiation between
to allow or forbid support for Quick-Start within the tunnel. This tunnel endpoints to allow or forbid support for Quick-Start within
was done for ECN for IPsec tunnels, with IKEv1 [RFC3168, Section the tunnel. This was done for ECN for IPsec tunnels, with IKEv1
9.2]. This negotiation of Quick-Start capability in an IPsec tunnel [RFC3168, Section 9.2]. This negotiation of Quick-Start capability
will be specified in a separate IPsec document. This document will in an IPsec tunnel will be specified in a separate IPsec document.
also include a discussion of the potential effects of an adversary's This document will also include a discussion of the potential
modifications of the Quick-Start field (as in Sections 18 and 19 of effects of an adversary's modifications of the Quick-Start field (as
RFC 3168), and of the security considerations of exposing the Quick- in Sections 18 and 19 of RFC 3168), and of the security
Start rate request to network scanners. considerations of exposing the Quick-Start rate request to network
scanners.
7. The Quick-Start Mechanism in other Transport Protocols 7. The Quick-Start Mechanism in other Transport Protocols
The section earlier specified the use of Quick-Start in TCP. In The section earlier specified the use of Quick-Start in TCP. In
this section, we generalize this to give guidelines for the use of this section, we generalize this to give guidelines for the use of
Quick-Start with other transport protocols. We also discuss briefly Quick-Start with other transport protocols. We also discuss briefly
how Quick-Start could be specified for other transport protocols. how Quick-Start could be specified for other transport protocols.
The general guidelines for Quick-Start in transport protocols are as The general guidelines for Quick-Start in transport protocols are as
follows: follows:
skipping to change at page 36, line 41 skipping to change at page 39, line 49
to augment their operation. to augment their operation.
* A transport-level mechanism is needed for the Quick-Start response * A transport-level mechanism is needed for the Quick-Start response
from the receiver to the sender. This response contains the Rate from the receiver to the sender. This response contains the Rate
Request, TTL Diff, and QS Nonce. Request, TTL Diff, and QS Nonce.
* The sender checks the validity of the Quick-Start response. * The sender checks the validity of the Quick-Start response.
* The sender has an estimate of the round-trip time, and translates * The sender has an estimate of the round-trip time, and translates
the Quick-Start response into an allowed window or allowed sending the Quick-Start response into an allowed window or allowed sending
rate. The sender starts sending Quick-Start packets, rate-paced out rate. The sender sends a Report of Approved Rate. The sender
at the approved sending rate. starts sending Quick-Start packets, rate-paced out at the approved
sending rate.
* After the sender receives the first acknowledgement packet for a * After the sender receives the first acknowledgement packet for a
Quick-Start packet, no more Quick-Start packets are sent. The Quick-Start packet, no more Quick-Start packets are sent. The
sender adjusts its current congestion window or sending rate to be sender adjusts its current congestion window or sending rate to be
consistent with the actual amount of data that was transmitted in consistent with the actual amount of data that was transmitted in
that round-trip time. that round-trip time.
* When the last Quick-Start packet is acknowledged, the sender * When the last Quick-Start packet is acknowledged, the sender
continues using the standard congestion control mechanisms of that continues using the standard congestion control mechanisms of that
protocol. protocol.
skipping to change at page 37, line 47 skipping to change at page 41, line 9
available for granting successive Quick-Start requests. Following available for granting successive Quick-Start requests. Following
Section 4.1, the sender SHOULD NOT request a sending rate larger Section 4.1, the sender SHOULD NOT request a sending rate larger
than it is able to use over the round-trip time of the connection than it is able to use over the round-trip time of the connection
(or over 100 ms, if the round-trip time is not known), except as (or over 100 ms, if the round-trip time is not known), except as
required to round up the desired sending rate to the next-highest required to round up the desired sending rate to the next-highest
allowable request. allowable request.
8.2. Deciding the Permitted Rate Request at a Router 8.2. Deciding the Permitted Rate Request at a Router
In this section we briefly outline how a router might decide whether In this section we briefly outline how a router might decide whether
or not to approve a Quick-Start Request. As an example, the router or not to approve a Quick-Start Request. The router should ask the
could ask the following questions: following questions:
* Has the router's output link been underutilized for some time * Has the router's output link been underutilized for some time
(e.g., several seconds). (e.g., several seconds).
* Would the output link remain underutilized if the arrival rate was * Would the output link remain underutilized if the arrival rate was
to increase by the aggregate rate requests that the router has to increase by the aggregate rate requests that the router has
approved over the last fraction of a second? approved over the last fraction of a second?
In order to answer this question, the router must have some In order to answer the last question, the router must have some
knowledge of the available bandwidth on the output link and of the knowledge of the available bandwidth on the output link and of the
Quick-Start bandwidth that could arrive due to recently-approved Quick-Start bandwidth that could arrive due to recently-approved
Quick-Start Requests. In this way, if an underutilized router Quick-Start Requests. In this way, if an underutilized router
experiences a flood of Quick-Start requests, the router can begin to experiences a flood of Quick-Start requests, the router can begin to
deny Quick-Start requests while the output link is still deny Quick-Start requests while the output link is still
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], for the current time between T1 and current time interval [T1, T2], and one for the total aggregate Rate
T2, and one for the total aggregate Rate Requests approved over a Requests approved over a previous time interval [T0, T1]. However,
previous time interval [T0, T1]. However, this document doesn't this document doesn't specify router algorithms for approving Quick-
specify router algorithms for approving Quick-Start requests, or Start requests, or make requirements for the appropriate time
make requirements for the appropriate time intervals for remembering intervals for remembering the aggregate approved Quick-Start
the aggregate approved Quick-Start bandwidth. A possible router bandwidth. A possible router algorithm is given in Appendix D, and
algorithm is given in Appendix C, and more discussion of these more discussion of these issues is available in [SAF05].)
issues is available in [SAF05].)
* If the router's output link has been underutilized and the * If the router's output link has been underutilized and the
aggregate Quick Start Request Rate options granted is low enough to aggregate of the Quick Start Request Rate options granted is low
prevent a near-term bandwidth shortage, then the router could enough to prevent a near-term bandwidth shortage, then the router
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. [SAF05] discusses the processing Quick-Start requests at routers. [SAF05] discusses the
range of possible Quick-Start algorithms at the router for deciding range of possible Quick-Start algorithms at the router for deciding
whether to approve a Quick-Start request. In order to explore the whether to approve a Quick-Start request. In order to explore the
limits of the possible functionality at routers, [SAF05] also limits of the possible functionality at routers, [SAF05] also
discusses Extreme Quick-Start mechanisms at routers, where the discusses Extreme Quick-Start mechanisms at routers, where the
router would keep per-flow state concerning approved Quick-Start router would keep per-flow state concerning approved Quick-Start
requests. requests.
skipping to change at page 39, line 41 skipping to change at page 42, line 43
For the sender the biggest risk in using Quick-Start lies in the For the sender the biggest risk in using Quick-Start lies in the
possibility of suffering from congestion-related losses of the possibility of suffering from congestion-related losses of the
Quick-Start packets. This should be an unlikely situation because Quick-Start packets. This should be an unlikely situation because
routers are expected to approve Quick-Start Requests only when they routers are expected to approve Quick-Start Requests only when they
are significantly underutilized. However, a transient increase in are significantly underutilized. However, a transient increase in
cross-traffic in one of the routers, a sudden decrease in available cross-traffic in one of the routers, a sudden decrease in available
bandwidth on one of the links, or congestion at a non-IP queue could bandwidth on one of the links, or congestion at a non-IP queue could
result in packet losses even when the Quick-Start Request was result in packet losses even when the Quick-Start Request was
approved by all of the routers along the path. If a Quick-Start approved by all of the routers along the path. If a Quick-Start
packet is dropped, then the sender reverts to the congestion control packet is dropped, then the sender reverts to the congestion control
mechanisms it would have used if the Quick-Start request has not mechanisms it would have used if the Quick-Start request had not
been approved, so the performance cost to the connection of having a been approved, so the performance cost to the connection of having a
Quick-Start packet dropped is small, compared to the performance Quick-Start packet dropped is small, compared to the performance
without Quick-Start. (On the other hand, the performance difference without Quick-Start. (On the other hand, the performance difference
between Quick-Start with a Quick-Start packet dropped and Quick- between Quick-Start with a Quick-Start packet dropped and Quick-
Start with no Quick-Start packet dropped can be considerable.) Start with no Quick-Start packet dropped can be considerable.)
Added complexity at routers: Added complexity at routers:
The main cost of Quick-Start at routers concerns the costs of added The main cost of Quick-Start at routers concerns the costs of added
complexity. The added complexity at the end-points is moderate, and complexity. The added complexity at the end-points is moderate, and
might easily be outweighed by the benefit of Quick-Start to the end might easily be outweighed by the benefit of Quick-Start to the end
hosts. The added complexity at the routers is also somewhat hosts. The added complexity at the routers is also somewhat
moderate; it involves estimating the unused bandwidth on the output moderate; it involves estimating the unused bandwidth on the output
link over the last several seconds, processing the Quick-Start link over the last several seconds, processing the Quick-Start
request, and keeping a counter of the aggregate Quick-Start rate request, and keeping a counter of the aggregate Quick-Start rate
approved over the last fraction of a second. However, this added approved over the last fraction of a second. However, this added
complexity at routers adds to the development cycle, and could complexity at routers adds to the development cycle, and could
prevent the addition of other competing functionality to routers. prevent the addition of other competing functionality to routers.
skipping to change at page 40, line 21 skipping to change at page 43, line 25
Thus, careful thought would have to be given to the addition of Thus, careful thought would have to be given to the addition of
Quick-Start to IP. Quick-Start to IP.
The slow path in routers: The slow path in routers:
Another drawback of Quick-Start is that packets containing the Another drawback of Quick-Start is that packets containing the
Quick-Start Request message might not take the fast path in routers, Quick-Start Request message might not take the fast path in routers,
particularly in the beginning of Quick-Start's deployment in the particularly in the beginning of Quick-Start's deployment in the
Internet. This would mean some extra delay for the end hosts, and Internet. This would mean some extra delay for the end hosts, and
extra processing burden for the routers. However, as discussed in extra processing burden for the routers. However, as discussed in
Sections 4.1 and 4.6, not all packets would carry the Quick-Start Sections 4.1 and 4.6, not all packets would carry the Quick-Start
Request option. In addition, for the underutilized links where option. In addition, for the underutilized links where Quick-Start
Quick-Start Requests could actually be approved, or in typical Requests could actually be approved, or in typical environments
environments where most of the packets belong to large flows, the where most of the packets belong to large flows, the burden of the
burden of the Quick-Start Option on routers would be considerably Quick-Start Option on routers would be considerably reduced.
reduced. Nevertheless, it is still conceivable, in the worst case, Nevertheless, it is still conceivable, in the worst case, that many
that many packets would carry Quick-Start requests; this could slow packets would carry Quick-Start requests; this could slow down the
down the processing of Quick-Start packets in routers considerably. processing of Quick-Start packets in routers considerably. As
As discussed in Section 9.5, routers can easily protect against this discussed in Section 9.6, routers can easily protect against this by
by enforcing a limit on the rate at which Quick-Start requests will enforcing a limit on the rate at which Quick-Start requests will be
be considered. considered. [RW03] and [RW04] contain measurements of the impact of
IP Option Processing on packet round-trip times.
Multiple paths: Multiple paths:
One limitation of Quick-Start is that it presumes that the data One limitation of Quick-Start is that it presumes that the data
packets of a connection will follow the same path as the Quick-Start packets of a connection will follow the same path as the Quick-Start
request packet. If this is not the case, then the connection could request packet. If this is not the case, then the connection could
be sending the Quick-Start packets, at the approved rate, along a be sending the Quick-Start packets, at the approved rate, along a
path that was already congested, or that became congested as a path that was already congested, or that became congested as a
result of this connection. This is, however, similar to what would result of this connection. Thus, Quick-Start could give poor
happen, for a connection with sufficient data, if the connection's performance when there is a routing change immediately after the
path was changed in the middle of the connection, when the Quick-Start request is approved, and the Quick-Start data packets
connection had already established the allowed initial rate. follow a different path from that of the original Quick-Start
Request. This is, however, similar to what would happen, for a
connection with sufficient data, if the connection's path was
changed in the middle of the connection, when the connection had
already established the allowed initial rate.
A router that uses multipath routing for packets within a single A router that uses multipath routing for packets within a single
connection MUST NOT approve a Quick-Start request. Quick-Start connection MUST NOT approve a Quick-Start request. Quick-Start
would not perform robustly in an environment with multipath routing, would not perform robustly in an environment with multipath routing,
where different packets in a connection routinely follow different where different packets in a connection routinely follow different
paths. In such an environment, the Quick-Start request and some paths. In such an environment, the Quick-Start request and some
fraction of the packets in the connection might take an fraction of the packets in the connection might take an
underutilized path, while the rest of the packets take an alternate, underutilized path, while the rest of the packets take an alternate,
congested path. congested path.
As discussed in Section 6.2, Quick-Start could also give poor
performance when there is a routing change immediately after the
Quick-Start request is approved, and the Quick-Start data packets
follow a different path from that of the original Quick-Start
Request. However, as noted in Section 6.2, this is similar to what
can happen without Quick-Start when a connection path is changed
after the connection had already established a certain sending rate
on the original path.
Non-IP queues: Non-IP queues:
A problem of any mechanism for feedback from routers at the IP level A problem of any mechanism for feedback from routers at the IP level
is that there can be queues and bottlenecks in the end-to-end path is that there can be queues and bottlenecks in the end-to-end path
that are not in IP-level routers. As an example, these include that are not in IP-level routers. As an example, these include
queues in layer-two Ethernet or ATM networks. One possibility would queues in layer-two Ethernet or ATM networks. One possibility would
be that an IP-level router adjacent to such a non-IP queue or be that an IP-level router adjacent to such a non-IP queue or
bottleneck would be configured to reject Quick-Start requests if bottleneck would be configured to reject Quick-Start requests if
that was appropriate. One would hope that in general, IP networks that was appropriate. One would hope that in general, IP networks
are configured so that non-IP queues between IP routers do not end are configured so that non-IP queues between IP routers do not end
up being the congested bottlenecks. up being the congested bottlenecks.
skipping to change at page 41, line 37 skipping to change at page 44, line 35
The discussion in this document has largely been of Quick-Start with The discussion in this document has largely been of Quick-Start with
default, best-effort traffic. However, Quick-Start could also be default, best-effort traffic. However, Quick-Start could also be
used by traffic using some form of differentiated services, and used by traffic using some form of differentiated services, and
routers could take the traffic class into account when deciding routers could take the traffic class into account when deciding
whether or not to grant the Quick-Start request. We don't address whether or not to grant the Quick-Start request. We don't address
this context further in this paper, since it is orthogonal to the this context further in this paper, since it is orthogonal to the
specification of Quick-Start. specification of Quick-Start.
9.4. Protection against Misbehaving Nodes 9.4. Protection against Misbehaving Nodes
In this section we discuss the protection against receivers or In this section we discuss the protection against senders,
colluding middleboxes lying about the Quick-Start Request. First, receivers, or colluding middleboxes lying about the Quick-Start
we note that it is not necessarily in the receiver's interest to lie Request. First, we note that it is not necessarily in the sender's
about the Quick-Start Request. If the sender sends at too-high of or receiver's interest to lie about the Quick-Start Request. If the
an initial rate, and has a packet dropped, this does not necessarily sender sends at too-high of an initial rate, and has a packet
improve the performance of the connection, relative to the case when dropped, this does not necessarily improve the performance of the
the Quick-Start Request was not approved. connection, relative to the case when the Quick-Start Request was
not approved.
9.4.1. Receivers Lying about Whether the Request was Approved 9.4.1. Misbehaving Senders
A transport sender could try to transmit data at a higher rate than
that approved in the Quick-Start Request, or transmit at a high rate
even without using Quick-Start at all. The network could use a
traffic policer to protect against such misbehaving senders, for
example by dropping packets that exceed the allowed transmission
rate. The required Report of Approved Rate allows traffic policers
to check that the Report of Approved Rate does not exceed the Rate
Request actually approved at that point in the network in the
previous Quick-Start Request from that connection. The required
Approved Rate report also allows traffic policers to check that the
sender's sending rate does not exceed the rate in the Report of
Approved Rate.
If a router or receiver receives an Approved Rate report that is
larger than the Rate Request in the Quick-Start request approved for
that sender for that connection in the previous round-trip time,
then the router or receiver could deny future Quick-Start requests
from that sender, e.g., by deleting the Quick-Start Request from
future packets from that sender. We note that routers are not
required to use Approved Rate reports to check if senders are
cheating; this is at the discretion of the router. If a router sees
a Report of Approved Rate, and did not see an earlier Quick-Start
request, then either the sender could be cheating, or the
connection's path could have changed since the Quick-Start request
was sent. In either case, the router could decide to deny future
Quick-Start requests from this sender. In particular, it is
reasonable for the router to deny a Quick-Start request if either
the sender is cheating, or if the connection path suffers from path
changes or multi-pathing.
If a router approved a Quick-Start Request, but does not see a
subsequent Approved Rate report, then there are several
possibilities: (1) the sender did not send a Report of Approved
Rate; (2) the Approved Rate report was dropped in the network; or
(3) the Approved Rate report took a different path from the Quick-
Start Request. In any of these three cases, the router would be
justified in denying future Quick-Start Requests from this sender.
In any of the above mentioned cases (i.e., an Approved Rate report
that is larger than the Rate Request in the earlier Quick-Start
request; no Approved Rate report because of packet drops, path
changes, or the sender's failure to send one), a traffic policer may
assume that Quick-Start is not being used appropriately, or is being
used in an inappropriate environment, and take some corresponding
action.
9.4.2. Receivers Lying about Whether the Request was Approved
One form of misbehavior would be for the receiver to lie to the One form of misbehavior would be for the receiver to lie to the
sender about whether the Quick-Start Request was approved, by sender about whether the Quick-Start Request was approved, by
falsely reporting the TTL Diff and QS Nonce. If a router that falsely reporting the TTL Diff and QS Nonce. If a router that
understands the Quick-Start Request denies the request by deleting understands the Quick-Start Request denies the request by deleting
the request or by zeroing the QS TTL and QS Nonce, then the receiver the request or by zeroing the QS TTL and QS Nonce, then the receiver
can ``lie" about whether the request was approved only by can ``lie" about whether the request was approved only by
successfully guessing the value of the TTL Diff and QS Nonce to successfully guessing the value of the TTL Diff and QS Nonce to
report. The chance of the receiver successfully guessing the report. The chance of the receiver successfully guessing the
correct value for the TTL Diff is 1/256, and the chance of the correct value for the TTL Diff is 1/256, and the chance of the
receiver successfully guessing the QS nonce for a reported rate receiver successfully guessing the QS nonce for a reported rate
request of K is 1/(2K). request of K is 1/(2K).
However, if the Quick-Start request is denied only by a non-Quick- However, if the Quick-Start request is denied only by a non-Quick-
Start-capable router, or by a router that is unable to zero the QS Start-capable router, or by a router that is unable to zero the QS
TTL and QS Nonce fields, the the receiver could lie about whether TTL and QS Nonce fields, then the receiver could lie about whether
the Quick-Start Requests were approved by modifying the QS TTL in the Quick-Start Requests were approved by modifying the QS TTL in
successive requests received from the same host. In particular, if successive requests received from the same host. In particular, if
the sender does not act on a Quick-Start Request, then the receiver the sender does not act on a Quick-Start Request, then the receiver
could decrement the QS TTL by one in the next request received from could decrement the QS TTL by one in the next request received from
that host before calculating the TTL Diff, and decrement the QS TTL that host before calculating the TTL Diff, and decrement the QS TTL
by two in the following received request, until the sender acts on by two in the following received request, until the sender acts on
one of the Quick-Start Requests. one of the Quick-Start Requests.
Unfortunately, if a router doesn't understand Quick-Start, then it Unfortunately, if a router doesn't understand Quick-Start, then it
is not possible for that router to take an active step such as is not possible for that router to take an active step such as
zeroing the QS TTL and QS Nonce to deny a request. As a result, the zeroing the QS TTL and QS Nonce to deny a request. As a result, the
QS TTL is not a fail-safe mechanism for preventing lying by QS TTL is not a fail-safe mechanism for preventing lying by
receivers in the case of non-Quick-Start-capable routers. receivers in the case of non-Quick-Start-capable routers.
9.4.2. Receivers Lying about the Approved Rate As we noted above, it is not necessarily in the receiver's interests
to lie about whether the rate request was approved, particularly
since such lying could result in Quick-Start data packets dropped in
the network due to congestion.
A second form of misbehavior would be for the receiver to lie to the 9.4.3. Receivers Lying about the Approved Rate
sender about the Rate Request for an approved Quick-Start Request,
by increasing the value of the Rate Request field. However, the A second form of receiver misbehavior would be for the receiver to
receiver doesn't necessarily know the Rate Request in the original lie to the sender about the Rate Request for an approved Quick-Start
Quick-Start Request sent by the sender, and a higher Rate Request Request, by increasing the value of the Rate Request field.
reported by the receiver will only be considered valid by the sender However, the receiver doesn't necessarily know the Rate Request in
if it is no higher than the Rate Request originally requested by the the original Quick-Start Request sent by the sender, and a higher
sender. For example, if the sender sends a Quick-Start Request with Rate Request reported by the receiver will only be considered valid
a Rate Request of X, and the receiver reports receiving a Quick- by the sender if it is no higher than the Rate Request originally
Start Request with a Rate Request of Y > X, then the sender knows requested by the sender. For example, if the sender sends a Quick-
that either some router along the path malfunctioned (increasing the Start Request with a Rate Request of X, and the receiver reports
Rate Request inappropriately), or the receiver is lying about the receiving a Quick-Start Request with a Rate Request of Y > X, then
Rate Request in the received packet. the sender knows that either some router along the path
malfunctioned (increasing the Rate Request inappropriately), or the
receiver is lying about the Rate Request in the received packet.
If the sender sends a Quick-Start Request with a Rate Request of Z, If the sender sends a Quick-Start Request with a Rate Request of Z,
the receiver receives the Quick-Start Request with an approved Rate the receiver receives the Quick-Start Request with an approved Rate
Request of X, and reports a Rate Request of Y, for X < Y <= Z, then Request of X, and reports a Rate Request of Y, for X < Y <= Z, then
the receiver only succeeds in lying to the sender about the approved the receiver only succeeds in lying to the sender about the approved
rate if the receiver successfully reports the rightmost 2Y bits in rate if the receiver successfully reports the rightmost 2Y bits in
the QS nonce. the QS nonce.
If senders often use a configured default value for the Rate If senders often use a configured default value for the Rate
Request, then receivers would often be able to guess the original Request, then receivers would often be able to guess the original
skipping to change at page 43, line 31 skipping to change at page 47, line 37
spoofing attacks. spoofing attacks.
A second limited form of protection would be for senders to use some A second limited form of protection would be for senders to use some
degree of randomization in the requested Rate Request, so that it is degree of randomization in the requested Rate Request, so that it is
difficult for receivers to guess the original value for the Rate difficult for receivers to guess the original value for the Rate
Request. However, this is difficult because there is a fairly Request. However, this is difficult because there is a fairly
coarse granularity in the set of rate requests available to the coarse granularity in the set of rate requests available to the
sender, and randomizing the initial request only offers limited sender, and randomizing the initial request only offers limited
protection in any case. protection in any case.
9.4.3. Collusion between Misbehaving Routers Again, as we noted above, it is not necessarily in the receiver's
interests to lie about the value of the approved rate request,
particularly since such lying could result in Quick-Start data
packets dropped in the network due to congestion.
9.4.4. Collusion between Misbehaving Routers
In addition to protecting against misbehaving receivers, it is In addition to protecting against misbehaving receivers, it is
necessary also to protect against misbehaving routers. Consider necessary also to protect against misbehaving routers. Consider
collusion between an ingress router and an egress router belonging collusion between an ingress router and an egress router belonging
to the same Intranet. The ingress router could decrement the Rate to the same Intranet. The ingress router could decrement the Rate
Request at the ingress, with the egress router increasing it again Request at the ingress, with the egress router increasing it again
at the egress. The routers between the ingress and egress that at the egress. The routers between the ingress and egress that
approved the decremented rate request might not have been willing to approved the decremented rate request might not have been willing to
approve the larger, original request. approve the larger, original request.
Another form of collusion would be for the ingress router to inform Another form of collusion would be for the ingress router to inform
the egress router out-of-band of the TTL Diff and QS Nonce for the the egress router out-of-band of the TTL Diff and QS Nonce for the
request packet at the ingress. This would enable the egress router request packet at the ingress. This would enable the egress router
to modify the QS TTL and QS Nonce so that it appeared that all of to modify the QS TTL and QS Nonce so that it appeared that all of
the routers along the path had approved the request. There does not the routers along the path had approved the request. There does not
appear to be any protection against a colluding ingress and egress appear to be any protection against a colluding ingress and egress
router. Even if an intermediate router had deleted the Quick-Start router. Even if an intermediate router had deleted the Quick-Start
Request Option from the packet, the ingress router could have sent Option from the packet, the ingress router could have sent the
the Quick-Start Request Option to the egress router out-of-band, Quick-Start Option to the egress router out-of-band, with the egress
with the egress router inserting the Quick-Start Request Option, router inserting the Quick-Start Option, with a modified QS TTL
with a modified QS TTL field, back in the packet. field, back in the packet.
However, unlike ECN, there is somewhat less incentive for However, unlike ECN, there is somewhat less incentive for
cooperating ingress and egress routers to collude to falsely modify cooperating ingress and egress routers to collude to falsely modify
the Quick-Start Request so that it appears to have been approved by the Quick-Start Request so that it appears to have been approved by
all of the routers along the path. With ECN, a colluding ingress all of the routers along the path. With ECN, a colluding ingress
router could falsely mark a packet as ECN-capable, with the router could falsely mark a packet as ECN-capable, with the
colluding egress router returning the ECN field in the IP header to colluding egress router returning the ECN field in the IP header to
its original non-ECN-capable codepoint, and congested routers along its original non-ECN-capable codepoint, and congested routers along
the path could have been fooled into not dropping that packet. This the path could have been fooled into not dropping that packet. This
collusion would give an unfair competitive advantage to the traffic collusion would give an unfair competitive advantage to the traffic
skipping to change at page 44, line 32 skipping to change at page 48, line 42
does not have enough available bandwidth to approve the Quick-Start does not have enough available bandwidth to approve the Quick-Start
request, then the Quick-Start packets sent as a result of the request, then the Quick-Start packets sent as a result of the
falsely-approved request could be dropped in the network, to the falsely-approved request could be dropped in the network, to the
resulting disadvantage of the connection. Thus, while the ingress resulting disadvantage of the connection. Thus, while the ingress
and egress routers could collude to prevent intermediate routers and egress routers could collude to prevent intermediate routers
from denying a Quick-Start request, it would not necessarily be to from denying a Quick-Start request, it would not necessarily be to
the connection's advantage for this to happen. In addition, the the connection's advantage for this to happen. In addition, the
router between the ingress and egress nodes that denied the request router between the ingress and egress nodes that denied the request
could be monitoring connection performance, actively penalizing could be monitoring connection performance, actively penalizing
nodes that seem to be using Quick-Start after a Quick-Start request nodes that seem to be using Quick-Start after a Quick-Start request
was denied. was denied, or that are reporting an Approved Rate higher than that
actually approved by that router.
If the congested router was ECN-capable, and the colluding ingress If the congested router was ECN-capable, and the colluding ingress
and egress routers were lying about ECN-capability as well as about and egress routers were lying about ECN-capability as well as about
Quick-Start, then the result could be that the Quick-Start request Quick-Start, then the result could be that the Quick-Start request
falsely appears to the sender to have been approved, and the Quick- falsely appears to the sender to have been approved, and the Quick-
Start packets falsely appear to the congested router to be ECN- Start packets falsely appear to the congested router to be ECN-
capable. In this case, the colluding routers might succeed in capable. In this case, the colluding routers might succeed in
giving a competitive advantage to the traffic protected by their giving a competitive advantage to the traffic protected by their
collusion (if no intermediate router is monitoring to catch such collusion (if no intermediate router is monitoring to catch such
misbehavior). misbehavior).
9.4.4. Misbehaving Middleboxes and the IP TTL 9.5. Misbehaving Middleboxes and the IP TTL
A separate possibility is that of traffic normalizers [HKP01] or One possible difficulty is that of traffic normalizers [HKP01] or
other middleboxes along that path that re-write IP TTLs, in order to other middleboxes along that path that re-write IP TTLs, in order to
foil other kinds of attacks in the network. If such a traffic foil other kinds of attacks in the network. If such a traffic
normalizer re-wrote the IP TTL, but did not adjust the Quick-Start normalizer re-wrote the IP TTL, but did not adjust the Quick-Start
TTL by the same amount, then the sender's mechanism for determining TTL by the same amount, then the sender's mechanism for determining
if the request was approved by all routers along the path would no if the request was approved by all routers along the path would no
longer be reliable. Re-writing the IP TTL could result in false longer be reliable. Re-writing the IP TTL could result in false
positives (with the sender incorrectly believing that the Quick- positives (with the sender incorrectly believing that the Quick-
Start request was approved) as well as false negatives (with the Start request was approved) as well as false negatives (with the
sender incorrectly believing that the Quick-Start request was sender incorrectly believing that the Quick-Start request was
denied). denied).
9.5. Attacks on Quick-Start 9.6. Attacks on Quick-Start
As discussed in [SAF05], Quick-Start is vulnerable to two kinds of As discussed in [SAF05], Quick-Start is vulnerable to two kinds of
Quick-Start attacks: (1) attacks to increase the routers' Quick-Start attacks: (1) attacks to increase the routers'
processing and state load; and (2) attacks with bogus Quick-Start processing and state load; and (2) attacks with bogus Quick-Start
requests to temporarily tie up available Quick-Start bandwidth, requests to temporarily tie up available Quick-Start bandwidth,
preventing routers from approving Quick-Start requests from other preventing routers from approving Quick-Start requests from other
connections. Routers can protect against the first kind of attack connections. Routers can protect against the first kind of attack
by applying a simple limit on the rate at which Quick-Start requests by applying a simple limit on the rate at which Quick-Start requests
will be considered by the router. will be considered by the router.
skipping to change at page 45, line 42 skipping to change at page 50, line 5
centralized control over the users in the system. We also note that centralized control over the users in the system. We also note that
this form of attack could potentially make Quick-Start unusable, but this form of attack could potentially make Quick-Start unusable, but
it would not do any further damage; in the worst case, the network it would not do any further damage; in the worst case, the network
would function as a network without Quick-Start. would function as a network without Quick-Start.
[SAF05] considers the potential of Extreme Quick-Start algorithms at [SAF05] considers the potential of Extreme Quick-Start algorithms at
routers, which keep per-flow state for Quick-Start connections, in routers, which keep per-flow state for Quick-Start connections, in
protecting the availability of Quick-Start bandwidth in the face of protecting the availability of Quick-Start bandwidth in the face of
frequent overly-larqe Quick-Start requests. frequent overly-larqe Quick-Start requests.
9.6. Simulations with Quick-Start 9.7. Simulations with Quick-Start
Quick-Start was added to the NS simulator [SH02] by Srikanth Quick-Start was added to the NS simulator [SH02] by Srikanth
Sundarrajan, and additional functionality was added by Pasi Sundarrajan, and additional functionality was added by Pasi
Sarolahti. The validation test is at `test-all-quickstart' in the Sarolahti. The validation test is at `test-all-quickstart' in the
`tcl/test' directory in NS. The initial simulation studies from `tcl/test' directory in NS. The initial simulation studies from
[SH02] show a significant performance improvement using Quick-Start [SH02] show a significant performance improvement using Quick-Start
for moderate-sized flows (between 4KB and 128KB) in under-utilized for moderate-sized flows (between 4KB and 128KB) in under-utilized
environments. These studies are of file transfers, with the environments. These studies are of file transfers, with the
improvement measured as the relative increase in the overall improvement measured as the relative increase in the overall
throughput for the file transfer. The study shows that potential throughput for the file transfer. The study shows that potential
skipping to change at page 46, line 49 skipping to change at page 51, line 11
that use TCP for bulk transfers, do not have interest in the that use TCP for bulk transfers, do not have interest in the
transmission rate, but they might know the amount of data that can transmission rate, but they might know the amount of data that can
be sent immediately. Based on this, the sender implementation could be sent immediately. Based on this, the sender implementation could
decide whether Quick-Start would be useful, and what rate should be decide whether Quick-Start would be useful, and what rate should be
requested. Datagram-based real-time streaming applications, on the requested. Datagram-based real-time streaming applications, on the
other hand, may have a specific preference on the transmission rate other hand, may have a specific preference on the transmission rate
and they could indicate the required rate explicitly to the and they could indicate the required rate explicitly to the
transport protocol to be used in the Quick-Start Request. transport protocol to be used in the Quick-Start Request.
We note that when Quick-Start is used, the TCP sender is required to We note that when Quick-Start is used, the TCP sender is required to
implement an additional timer for the paced transmission of Quick- save the QS Nonce and the TTL Diff when the Quick-Start request is
Start packets. sent, and to implement an additional timer for the paced
transmission of Quick-Start packets.
10.2. Implementation Issues for Processing Quick-Start Requests 10.2. Implementation Issues for Processing Quick-Start Requests
A router or other network host must be able to determine the A router or other network host must be able to determine the
approximate bandwidth of its outbound network interfaces in order to approximate bandwidth of its outbound network interfaces in order to
process incoming Quick-Start rate requests, including those that process incoming Quick-Start rate requests, including those that
originate from the host itself. One possibility would be for hosts originate from the host itself. One possibility would be for hosts
to rely on configuration information to determine link bandwidths; to rely on configuration information to determine link bandwidths;
this has the drawback of not being robust to errors in this has the drawback of not being robust to errors in
configuration. Another possibility would be for network device configuration. Another possibility would be for network device
drivers to infer the bandwidth for the interface and to communicate drivers to infer the bandwidth for the interface and to communicate
this to the IP layer. this to the IP layer.
Particular issues will arise for wireless links with variable Particular issues will arise for wireless links with variable
bandwidth, where decisions will have to be made about how frequently bandwidth, where decisions will have to be made about how frequently
the network host gets updates of the changing bandwidth. It seems the network host gets updates of the changing bandwidth. It seems
appropriate that Quick-Start Requests would be handled particularly appropriate that Quick-Start Requests would be handled particularly
conservatively for links with variable bandwidth, to avoid cases conservatively for links with variable bandwidth, to avoid cases
where Quick-Start Requests are approved, the link bandwidth is where Quick-Start Requests are approved, the link bandwidth is
reduced, and the data packets that are send end up being dropped. reduced, and the data packets that are sent end up being dropped.
Difficult issues also arise for paths with multi-access links (e.g.,
Ethernet). Routers with multi-access links should be particularly
conservative in granting Quick-Start requests.
10.3. Possible Deployment Scenarios 10.3. Possible Deployment Scenarios
Because of possible problems discussed above concerning using Quick- Because of possible problems discussed above concerning using Quick-
Start over some network paths, the most realistic initial deployment Start over some network paths, the most realistic initial deployment
of Quick-Start would likely to take place in Intranets and other of Quick-Start would most likely take place in Intranets and other
controlled environments. Quick-Start is most useful on high controlled environments. Quick-Start is most useful on high
bandwidth-delay paths that are significantly underutilized. The bandwidth-delay paths that are significantly underutilized. The
primary initial users of Quick-Start would likely be in primary initial users of Quick-Start would likely be in
organizations that provide network services to their users and also organizations that provide network services to their users and also
have control over a large portion of the network path. have control over a large portion of the network path.
Below are a few examples of networking environments where Quick- Below are a few examples of networking environments where Quick-
Start would potentially be useful. These are the environments that Start would potentially be useful. These are the environments that
might consider an initial deployment of Quick-Start in the routers might consider an initial deployment of Quick-Start in the routers
and end-nodes, where the incentives for routers to deploy Quick- and end-nodes, where the incentives for routers to deploy Quick-
Start might be the most clear. Start might be the most clear.
* Centrally-administrated organizational Intranets often have large * Centrally-administrated organizational Intranets: These intranets
network capacity and the networks are underutilized for most of the often have large network capacity, with networks that are
time. Such Intranets might also include high-bandwidth and high- underutilized for much of the time. Such Intranets might also
delay paths to remote sites. In such an environment, Quick-Start include high-bandwidth and high-delay paths to remote sites. In
would be of benefit to users, and there would be a clear incentive such an environment, Quick-Start would be of benefit to users, and
for the deployment of Quick-Start in routers. For example, Quick- there would be a clear incentive for the deployment of Quick-Start
Start could be quite useful in high-bandwidth networks used for in routers. For example, Quick-Start could be quite useful in high-
scientific computing. bandwidth networks used for scientific computing.
* Quick-Start could also be useful in high-delay environments of * GPRS: Quick-Start could also be useful in high-delay environments
Cellular Wide-Area Wireless Networks such as the GPRS [BW97] and of Cellular Wide-Area Wireless Networks such as the GPRS [BW97] and
their enhancements and next generations. For example, GPRS EDGE their enhancements and next generations. For example, GPRS EDGE
(Enhanced Data for GSM Evolution) is expected to provide wireless (Enhanced Data for GSM Evolution) is expected to provide wireless
bandwidth of up to 384 Kbps (roughly 32 1500-byte packets per bandwidth of up to 384 Kbps (roughly 32 1500-byte packets per
second) while the GPRS round-trip times range typically from few second) while the GPRS round-trip times range typically from few
hundred milliseconds to over a second excluding any possible hundred milliseconds to over a second excluding any possible
queueing delays in the network [GPAR02]. In addition, these networks queueing delays in the network [GPAR02]. In addition, these networks
sometimes have variable additional delays due to resource allocation sometimes have variable additional delays due to resource allocation
that could be avoided by keeping the connection path constantly that could be avoided by keeping the connection path constantly
utilized, starting from initial slow-start. Thus, Quick-Start could utilized, starting from initial slow-start. Thus, Quick-Start could
be of significant benefit to users in these environments. be of significant benefit to users in these environments.
* Geostationary Orbit (GEO) satellite links have one-way propagation * Paths over satellite links: Geostationary Orbit (GEO) satellite
delays on the order of 250 ms while the bandwidth can be measured in links have one-way propagation delays on the order of 250 ms while
megabits per second [RFC2488]. Because of the considerable the bandwidth can be measured in megabits per second [RFC2488].
bandwidth-delay product on the link, TCP's slow-start is a major Because of the considerable bandwidth-delay product on the link,
performance limitation in the beginning of the connection. A large TCP's slow-start is a major performance limitation in the beginning
initial congestion window would be useful to users of such satellite of the connection. A large initial congestion window would be
links. useful to users of such satellite links.
10.4. Would QuickStart packets take the slow path in routers? 10.4. Would QuickStart packets take the slow path in routers?
How much delay would the slow path add to the processing time for How much delay would the slow path add to the processing time for
this packet? Similarly, if QuickStart packets took the slow path, Quick-Start request packets? In addition, if QuickStart request
how much stress would it add to routers for there to be many more packets took the slow path, this could add stress to routers, though
packets on the slow path, because of the number of packets using routers could always rate-limit the number of QuickStart request
QuickStart? These are both questions to be explored while packets they are willing to consider.
experimenting with Quick-Start in the Internet.
10.5. A Comparison with the Deployment Problems of ECN 10.5. A Comparison with the Deployment Problems of ECN
Given the glacially slow rate of deployment of ECN in the Internet Given the glacially slow rate of deployment of ECN in the Internet
to date [MAF05], it is disconcerting to note that some of the to date [MAF05], it is disconcerting to note that some of the
deployment problems of Quick-Start are even greater than those of deployment problems of Quick-Start are even greater than those of
ECN. First, unlike ECN, which can be of benefit even if it is only ECN. First, unlike ECN, which can be of benefit even if it is only
deployed on one of the routers along the end-to-end path, a deployed on one of the routers along the end-to-end path, a
connection's use of Quick-Start requires its deployment on all of connection's use of Quick-Start requires its deployment on all of
the routers along the end-to-end path. Second, unlike ECN, which the routers along the end-to-end path. Second, unlike ECN, which
skipping to change at page 49, line 12 skipping to change at page 53, line 27
However, in spite of these issues, there is some hope for the However, in spite of these issues, there is some hope for the
deployment of Quick-Start, at least in protected corners of the deployment of Quick-Start, at least in protected corners of the
Internet, because the potential benefits of Quick-Start to the user Internet, because the potential benefits of Quick-Start to the user
are considerably more dramatic than those of ECN. Rather than are considerably more dramatic than those of ECN. Rather than
simply replacing the occasional dropped packet by an ECN-marked simply replacing the occasional dropped packet by an ECN-marked
packet, Quick-Start is capable of dramatically increasing the packet, Quick-Start is capable of dramatically increasing the
throughput of connections in underutilized environments. throughput of connections in underutilized environments.
11. Related Work 11. Related Work
The Quick-Start proposal, taken together with HighSpeed TCP [F03] or The Quick-Start proposal, taken together with HighSpeed TCP
other transport protocols for high-bandwidth transfers,, could go a [RFC3649] or other transport protocols for high-bandwidth transfers,
significant way towards extending the range of performance for best- could go a significant way towards extending the range of
effort traffic in the Internet. However, there are many things that performance for best-effort traffic in the Internet. However, there
the Quick-Start proposal would not accomplish. Quick-Start is not a are many things that the Quick-Start proposal would not accomplish.
congestion control mechanism, and would not help in making more Quick-Start is not a congestion control mechanism, and would not
precise use of the available bandwidth, that is, of achieving the help in making more precise use of the available bandwidth, that is,
goal of high throughput with low delay and low packet loss rates. of achieving the goal of high throughput with low delay and low
Quick-Start would not give routers more control over the decrease packet loss rates. Quick-Start would not give routers more control
rates of active connections. % One of the open questions addressed over the decrease rates of active connections.
later in this % document is whether the % limited capabilities of
Quick-Start are sufficient to warrant % standardization and
deployment, or whether more work is % needed first to explore the
space of potential mechanisms.
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 three classes of proposals (no explicit mechanism. We discuss several classes of proposals (no explicit
feedback from routers; explicit feedback about the initial rate; and feedback from routers; explicit feedback about the initial rate;
more fine-grained feedback from routers) in the sections below. more fine-grained feedback from routers; and proposals based on
lower-than-best-effort service) in the sections below.
11.1. Fast Start-ups without Explicit Information from Routers 11.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
skipping to change at page 50, line 24 skipping to change at page 54, line 34
some of the earlier work on inferring the available bandwidth from some of the earlier work on inferring the available bandwidth from
packet trains. packet trains.
Swift-Start: Swift-Start:
The Swift Start proposal from [PRAKS02] combines packet-pair and The Swift Start proposal from [PRAKS02] combines packet-pair and
packet-pacing techniques. An initial congestion window of four packet-pacing techniques. An initial congestion window of four
segments is used to estimate the available bandwidth along the path. segments is used to estimate the available bandwidth along the path.
This estimate is then used to dramatically increase the congestion This estimate is then used to dramatically increase the congestion
window during the second RTT of data transmission. window during the second RTT of data transmission.
SPAND:
In the TCP/SPAND proposal from [ZQK00] for speeding up short data
transfers, network performance information would be shared among
many co-located hosts to estimate each connection's fair share of
the network resources. Based on such estimation and the transfer
size, the TCP sender would determine the optimal initial congestion
window size. The design for TCP/SPAND uses a performance gateway
that monitors all traffic entering and leaving an organization's
network.
While continued research on the limits of the ability of TCP and While continued research on the limits of the ability of TCP and
other transport protocols to learn of available bandwidth without other transport protocols to learn of available bandwidth without
explicit feedback from the router seems useful, we note that there explicit feedback from the router seems useful, we note that there
are several fundamental advantages of explicit feedback from are several fundamental advantages of explicit feedback from
routers. routers.
(1) Explicit feedback is faster than implicit feedback: (1) Explicit feedback is faster than implicit feedback:
One advantage of explicit feedback from the routers is that it One advantage of explicit feedback from the routers is that it
allows the transport sender to reliably learn of available bandwidth allows the transport sender to reliably learn of available bandwidth
in one round-trip time. in one round-trip time.
skipping to change at page 52, line 46 skipping to change at page 57, line 20
congestion window when this packet is acknowledged. congestion window when this packet is acknowledged.
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.
11.5. Fast Start-ups with Lower-Than-Best-Effort Service
There have been proposals for routers to provide a Lower Effort
differentiated service that would be lower than best effort
[RFC3662]. Such a service could carry traffic for which delivery is
strictly optional, or could carry traffic that is important but that
has low priority in terms of time. Because it does not interfere
with best-effort traffic, Lower Effort services would be used by
transport protocols that start-up faster than slow-start. For
example, [SGF05] is a proposal for the transport sender to use low-
priority traffic for much of the initial traffic, with routers
configured to use strict priority queueing.
A separate but related issue is that of below-best-effort TCP,
variants of TCP that would not rely on Lower Effort services in the
network, but would approximate below-best-effort traffic by
detecting and responding to congestion sooner that standard TCP.
TCP Nice [V02] and TCP Low Priority (TCP-LP) [KK03] are two such
proposals for below-best-effort TCP, with the purpose of allowing
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
the default slow-start mechanisms of TCP.
We note that Quick-Start is quite different from either a Lower
Effort service or a below-best-effort variant of TCP. Unlike these
proposals, Quick-Start is intended to be useful for best-effort
traffic that wishes to receive at least as much bandwidth as
competing best-effort connections.
12. Security Considerations 12. Security Considerations
Sections 9.4 and 9.5 discuss the security considerations related to Sections 9.4 and 9.6 discuss the security considerations related to
Quick-Start. Section 9.4 discusses the potential abuse of Quick- Quick-Start. Section 9.4 discusses the potential abuse of Quick-
Start of receivers lying about whether the request was approved or Start by senders or receivers lying about whether the request was
about the approved rate; of routers in collusion to misuse Quick- approved or about the approved rate, and of routers in collusion to
Start; and of potential problems with traffic normalizers that misuse Quick-Start. Section 9.5 discusses potential problems with
rewrite IP TTLs in packet headers. All of these problems could traffic normalizers that rewrite IP TTLs in packet headers. All of
result in the sender using a Rate Request that was inappropriately these problems could result in the sender using a Rate Request that
large, or thinking that a request was approved when it was in fact was inappropriately large, or thinking that a request was approved
denied by at least one router along the path. This inappropriate when it was in fact denied by at least one router along the path.
use of Quick-Start would result in congestion and an unacceptable This inappropriate use of Quick-Start would result in congestion and
level of packet drops along the path, Such congestion could also be an unacceptable level of packet drops along the path, Such
part of a Denial of Service attack. congestion could also be part of a Denial of Service attack.
Section 9.5 discusses a potential attack on the routers' processing Section 9.6 discusses a potential attack on the routers' processing
and state load from an attack of Quick-Start Requests. Section 9.5 and state load from an attack of Quick-Start Requests. Section 9.6
also discusses a potential attack on the available Quick-Start also discusses a potential attack on the available Quick-Start
bandwidth by sending bogus Quick-Start requests for bandwidth that bandwidth by sending bogus Quick-Start requests for bandwidth that
will not in fact be used. will not in fact be used.
Section 4.6.2 discusses the potential problem of packets with Quick- Section 4.6.2 discusses the potential problem of packets with Quick-
Start Requests dropped by middleboxes along the path. Start Requests dropped by middleboxes along the path.
As discussed in Section 5, for IPv4 IPsec Authentication Header As discussed in Section 5, for IPv4 IPsec Authentication Header
Integrity Check Value (AH ICV) calculation, the Quick-Start Request Integrity Check Value (AH ICV) calculation, the Quick-Start option
option MUST be treated as a mutable IPv4 option, and hence MUST be treated as a mutable IPv4 option, and hence completely
completely zeroed for AH ICV calculation purposes; this is also the zeroed for AH ICV calculation purposes; this is also the treatment
treatment required by RFC 2402 for unrecognized IPv4 options. The required by RFC 2402 for unrecognized IPv4 options. The IPv6 Quick-
IPv6 Quick-Start Request option's IANA-allocated option type Start option's IANA-allocated option type indicates that it is a
indicates that it is a mutable option, hence, according to RFC 2402, mutable option, hence, according to RFC 2402, its option data MUST
its option data MUST be zeroed for AH ICV computation purposes. See be zeroed for AH ICV computation purposes. See RFC 2402 for further
RFC 2402 for further explanation. explanation.
Section 6.2 discusses possible problems of Quick-Start used by Section 6.2 discusses possible problems of Quick-Start used by
connections carried over simple tunnels that are not compatible with connections carried over simple tunnels that are not compatible with
Quick-Start. In this case it is possible that a Quick-Start Quick-Start. In this case it is possible that a Quick-Start
Request is erroneously considered approved by the sender without the Request is erroneously considered approved by the sender without the
routers in the tunnel having individually approved the request, routers in the tunnel having individually approved the request,
causing a false positive. causing a false positive.
13. Conclusions 13. Conclusions
skipping to change at page 54, line 18 skipping to change at page 59, line 22
14. Acknowledgements 14. Acknowledgements
The authors wish to thank Mark Handley for discussions of these The authors wish to thank Mark Handley for discussions of these
issues. The authors also thank the End-to-End Research Group, the issues. The authors also thank the End-to-End Research Group, the
Transport Services Working Group, and members of IPAM's program on Transport Services Working Group, and members of IPAM's program on
Large Scale Communication Networks for both positive and negative Large Scale Communication Networks for both positive and negative
feedback on this proposal. We thank Srikanth Sundarrajan for the feedback on this proposal. We thank Srikanth Sundarrajan for the
initial implementation of Quick-Start in the NS simulator, and for initial implementation of Quick-Start in the NS simulator, and for
the initial simulation study. Many thanks to David Black and Joe the initial simulation study. Many thanks to David Black and Joe
Touch for extensive feedback on QuickStart and IP tunnels. We also Touch for extensive feedback on QuickStart and IP tunnels. We also
thank Mohammed Ashraf, John Border, Martin Duke, Tom Dunigan, Gorry thank Mohammed Ashraf, John Border, Bob Briscoe, Martin Duke, Tom
Fairhurst, John Heidemann, Paul Hyder, Dina Katabi and Vern Paxson, Dunigan, Gorry Fairhurst, John Heidemann, Paul Hyder, Dina Katabi
for feedback. This draft builds upon the concepts described in and Vern Paxson for feedback. This draft builds upon the concepts
[RFC3390], [AHO98], [RFC2415], and [RFC3168]. Some of the text on described in [RFC3390], [AHO98], [RFC2415], and [RFC3168]. Some of
Quick-Start in tunnels was borrowed directly from RFC 3168. the text on Quick-Start in tunnels was borrowed directly from RFC
3168.
This is a modification of a draft originally by Amit Jain for This document is the development of a proposal originally by Amit
Initial Window Discovery. Jain for Initial Window Discovery.
A. Design Decisions A. Design Decisions
A.1. Alternate Mechanisms for the Quick-Start Request: ICMP and RSVP A.1. Alternate Mechanisms for the Quick-Start Request: ICMP and RSVP
This document has proposed using an IP Option for the Quick-Start This document has proposed using an IP Option for the Quick-Start
Request from the sender to the receiver, and using transport Request from the sender to the receiver, and using transport
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
skipping to change at page 54, line 47 skipping to change at page 60, line 8
A.1.1. ICMP A.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; for now, we have to pass by the routers on the path to the receiver, possibly
don't address the mechanisms that would be needed to accomplish this using the IP Router Alert option [RFC2113]. A router that approves
task. A router that approves the Quick-Start Request would take the the Quick-Start Request would take the same actions as in the case
same actions as in the case with the Quick-Start IP Option, and with the Quick-Start IP Option, and forward the packet to the next
forward the packet to the next router along the path. A router that router along the path. A router that does not approve the Quick-
does not approve the Quick-Start Request, even with a decreased Start Request, even with a decreased value for the Requested Rate,
value for the Requested Rate, would delete the ICMP Quick-Start would delete the ICMP Quick-Start Request, and send an ICMP Reply to
Request, and send an ICMP Reply to the sender that the request was the sender that the request was not approved. If the ICMP Reply was
not approved. If the ICMP Reply was dropped in the network, and did dropped in the network, and did not reach the receiver, the sender
not reach the receiver, the sender would still know that the request would still know that the request was not approved from the absence
was not approved from the absence of feedback from the receiver. If of feedback from the receiver. If the ICMP Quick-Start request was
the ICMP Quick-Start request was dropped in the network due to dropped in the network due to congestion, the sender would assume
congestion, the sender would assume that the request was not that the request was not approved. The ICMP message would need the
approved. If the ICMP Quick-Start Request reached the receiver, the source and destination port numbers for demultiplexing at the end
receiver would use transport-level mechanisms to send a response to nodes. If the ICMP Quick-Start Request reached the receiver, the
the sender, exactly as with the IP Option. receiver would use transport-level or application-level mechanisms
to send a response to the sender, exactly as with the IP Option.
One benefit of using ICMP would be that the delivery of the TCP SYN One benefit of using ICMP would be that the delivery of the TCP SYN
packet or other initial packet would not be delayed by IP option packet or other initial packet would not be delayed by IP option
processing at routers. A greater advantage is that if middleboxes processing at routers. A greater advantage is that if middleboxes
were blocking packets with Quick-Start Requests, using the Quick- were blocking packets with Quick-Start Requests, using the Quick-
Start Request in a separate ICMP packet would mean that the Start Request in a separate ICMP packet would mean that the
middlebox behavior would not affect the connection as a whole. (To middlebox behavior would not affect the connection as a whole. (To
get this robustness to middleboxes with TCP using an IP Quick-Start get this robustness to middleboxes with TCP using an IP Quick-Start
Option, one would have to have a TCP-level Quick-Start Request Option, one would have to have a TCP-level Quick-Start Request
packet that was sent concurrently but separately from the TCP SYN packet that could be sent concurrently but separately from the TCP
packet.) SYN packet.)
However, there are a number of disadvantages to using ICMP. Some However, there are a number of disadvantages to using ICMP. Some
firewalls and middleboxes may not forward the ICMP Quick-Start firewalls and middleboxes may not forward the ICMP Quick-Start
Request packets. (If an ICMP Reply packet from a router to the Request packets. (If an ICMP Reply packet from a router to the
sender is dropped in the network, the sender would still know that sender is dropped in the network, the sender would still know that
the request was not approved, as stated earlier, so this would not the request was not approved, as stated earlier, so this would not
be a problem.) In addition, it would be difficult, if not be as serious of a problem.) In addition, it would be difficult, if
impossible, for a router in the middle of an IP tunnel to deliver an not impossible, for a router in the middle of an IP tunnel to
ICMP Reply packet to the actual source, for example when the inner deliver an ICMP Reply packet to the actual source, for example when
IP header is encrypted as in IPsec tunnel mode [RFC2401]. Again, the inner IP header is encrypted as in IPsec tunnel mode [RFC2401].
however, the ICMP Reply packet would not be essential to the correct Again, however, the ICMP Reply packet would not be essential to the
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 A.1.2. RSVP
skipping to change at page 56, line 19 skipping to change at page 61, line 23
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
transmitted downstream from the sender to receiver in the RSVP Path transmitted downstream from the sender to receiver in the RSVP Path
messages, which is different from the conventional RSVP model where messages, which is different from the conventional RSVP model where
the reservations originate from the receiver. Furthermore, the the reservations originate from the receiver. Furthermore, the
Quick-Start Response would be sent using the transport-level Quick-Start Response would be sent using the transport-level or
mechanisms instead of using the RSVP Resv message. application-level mechanisms instead of using the RSVP Resv message.
If RSVP was used for carrying a Quick-Start Request, a new "Quick- If RSVP was used for carrying a Quick-Start Request, a new "Quick-
Start Request" class object would be included in the RSVP Path Start Request" class object would be included in the RSVP Path
message that is sent from the sender to receiver. The object would message that is sent from the sender to receiver. The object would
contain the rate request field in addition to the common length and contain the rate request field in addition to the common length and
type fields. The Send_TTL field in the RSVP common header could be type fields. The Send_TTL field in the RSVP common header could be
used as the equivalent of the QS TTL field. The Quick-Start capable used as the equivalent of the QS TTL field. The Quick-Start capable
routers along the path would inspect the Quick-Start Request object routers along the path would inspect the Quick-Start Request object
in the RSVP Path message, decrement Send_TTL and adjust the rate in the RSVP Path message, decrement Send_TTL and adjust the rate
request field if needed. If an RSVP router did not understand the request field if needed. If an RSVP router did not understand the
skipping to change at page 57, line 15 skipping to change at page 62, line 19
A.2. Alternate Encoding Functions A.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 both and the actual rate request f(N). In this section we consider
four-bit and eight-bit Rate Request fields. possible encoding methods for Rate Request fields of different
sizes, including four-bit, eight-bit, and larger Rate Request
fields.
Linear functions: Linear functions:
The Quick-Start Request contains an 8-bit field for the Rate One possible proposal would be for the Rate Request field to be
Request. One possible proposal would be for this field to be formatted in bits per second, scaled so that one unit equals M Kbps,
formatted in bits per second, scaled so that one unit equals 80 for some fixed value of M. Thus, for the value N in the Rate
Kbps. Thus, for the value N in the Rate Request field, the Request field, the requested rate would be M*N Kbps.
requested rate is 80,000*N bps. This gives a request range between
80 Kbps and 20.48 Mbps. For 1500-byte packets, this corresponds to
a request range between 6 and 1706 packets per second.
Powers of two: Powers of two:
If a granularity of factors of two is sufficient for the Rate If a granularity of factors of two is sufficient for the Rate
Request, then the encoding function with the most range would be for Request, then the encoding function with the most range would be for
the requested rate to be K*2^N, for N the value in the Rate Request the requested rate to be K*2^N, for N the value in the Rate Request
field, and for K some constant. For N=0, the rate request would be field, and for K some constant. For N=0, the rate request would be
set to zero, regardless of the encoding function. For example, for set to zero, regardless of the encoding function. For example, for
K=40,000, the request range would be from 80 Kbps to 40*2^256 Kbps. K=40,000 and an eight-bit Rate Request field, the request range
This clearly would be an unnecessarily large request range. would be from 80 Kbps to 40*2^255 Kbps. This clearly would be an
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 is possible 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 is not acceptable, then of bandwidth. If an upper limit of 1.3 Gbps was not acceptable,
five bits could be used for the Rate Request field. then five or six bits could be used for the Rate Request field.
If the granularity of factors of two is 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.
We note that the Rate Request also has to be constrained by the A mantissa and exponent representation:
abilities of the transport protocol. For example, for TCP with Section 4.4 of [B05] suggests a mantissa and exponent representation
Window Scaling, the maximum window is at most 2**30 bytes. For a for the Quick-Start encoding function. With e and f as the binary
TCP connection with a long, 1 second round-trip time, this would numbers in the exponent and mantissa fields, and with 0 <= f < 1,
give a maximum sending rate of 1.07 Gbps. this would represent the rate (1+f)*2^e. [B05] suggests a mantissa
field for f of 8, 16, or 24 bits, with an exponent field for e of 8
bits. This representation would allow larger rate requests, with an
encoding that is less coarse than the powers-of-two encoding used in
this document.
Constraints of the transport protocol:
We note that the Rate Request is also constrained by the abilities
of the transport protocol. For example, for TCP with Window
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
maximum sending rate of 1.07 Gbps.
A.3. The Quick-Start Request: Packets or Bytes? A.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 will discuss be in bytes per second or in packets per second. We discuss this
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
headers. Other transport protocols would conceivably use the Quick- headers. Other transport protocols would conceivably use the Quick-
Start Request directly in packets per second, or could translate the Start Request directly in packets per second, or could translate the
Quick-Start Request to a congestion window in packets. Quick-Start Request to a congestion window in packets.
skipping to change at page 60, line 19 skipping to change at page 65, line 37
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.
For either of these alternatives, there would not be room to report Appendix D discusses a Report of Current Sending Rate as one
the current sending rate in the Quick-Start Option using the current possible function in the Quick-Start Option. However, we have not
minimal format for the Quick-Start Request. Thus, either the Quick- standardized this possible use at this time.
Start Option would have to take more than four bytes to include a
report of the current sending rate, or the current sending rate
would not be reported to the routers.
A.5. Alternate Responses to the Loss of a Quick-Start Packet A.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
skipping to change at page 61, line 28 skipping to change at page 66, line 43
sending rate. sending rate.
A.6. Why Not Include More Functionality? A.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 connections to use higher sending rates along that would allow connections to use higher sending rates 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, and does not attempt the goal of generation transport protocol, and does not attempt the goal of
providing very high throughput with very low delay. As Section 11.4 providing very high throughput with very low delay. As Section 11.4
discusses, there are a number of proposals such as XCP, MaxNet, and discusses, there are a number of proposals such as XCP, MaxNet, and
AntiECN for more fine-grained per-packet feedback from routers that AntiECN for more fine-grained per-packet feedback from routers than
the current congestion control mechanisms, that do attempt these the current congestion control mechanisms, that do attempt these
more ambitious goals. 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
along the path are significantly under-utilized. Thus, Quick-Start along the path are significantly under-utilized. Thus, Quick-Start
is of no use towards a target of high link utilization, or fairness is of no use towards a target of high link utilization, or fairness
in a high-utilization scenario, or controlling queueing delay during in a high-utilization scenario, or controlling queueing delay during
high-utilization, or anything of the like. high-utilization, or anything of the like.
At the same time, Quick-Start would allow larger initial windows At the same time, Quick-Start would allow larger initial windows
than would proposals such as AntiECN, requires less input to routers than would proposals such as AntiECN, requires less input to routers
than XCP, and would require less frequent feedback from routers than than XCP (e.g., XCP's cwnd and rtt fields), and would require less
any new congestion control mechanism. Thus, Quick-Start is frequent feedback from routers than any new congestion control
significantly less powerful than proposals for new congestion mechanism. Thus, Quick-Start is significantly less powerful than
control mechanisms such as XCP and AntiECN, but as powerful or more proposals for new congestion control mechanisms such as XCP and
powerful in terms of the specific issue of allowing larger initial AntiECN, but as powerful or more powerful in terms of the specific
windows, and (we think) more amenable to incremental deployment in issue of allowing larger initial windows, and (we think) more
the current Internet. amenable to incremental deployment in the current Internet.
We do not discuss proposals such as XCP in detail, but simply note We do not discuss proposals such as XCP in detail, but simply note
that there are a number of open questions. One question concerns that there are a number of open questions. One question concerns
whether there is a pressing need for more sophisticated congestion whether there is a pressing need for more sophisticated congestion
control mechanisms such as XCP in the Internet. Quick-Start is control mechanisms such as XCP in the Internet. Quick-Start is
inherently a rather crude tool that does not deliver assurances inherently a rather crude tool that does not deliver assurances
about maintaining high link utilization and low queueing delay; about maintaining high link utilization and low queueing delay;
Quick-Start is designed for use in environments that are Quick-Start is designed for use in environments that are
significantly underutilized, and addresses the single question of significantly underutilized, and addresses the single question of
whether a higher sending rate is allowed. New congestion control whether a higher sending rate is allowed. New congestion control
skipping to change at page 63, line 21 skipping to change at page 68, line 37
acknowledged. However, the power of Quick-Start would be acknowledged. However, the power of Quick-Start would be
considerably limited if it was restricted to only two bits of considerably limited if it was restricted to only two bits of
feedback; it seems likely that determining the initial sending rate feedback; it seems likely that determining the initial sending rate
fundamentally requires more bits of feedback from routers than does fundamentally requires more bits of feedback from routers than does
the steady-state, per-packet feedback to increase or decrease the the steady-state, per-packet feedback to increase or decrease the
sending rate. sending rate.
On a more practical level, one difference between Quick-Start and On a more practical level, one difference between Quick-Start and
proposals for per-packet feedback is that there are fewer open proposals for per-packet feedback is that there are fewer open
issues with Quick-Start than there would be with a new congestion issues with Quick-Start than there would be with a new congestion
control mechanism. For example, for a mechanism for requesting a control mechanism. Because Quick-Start is a mechanism for
initial sending rate in an underutilized environment, the fairness requesting an initial sending rate in an underutilized environment,
issues of a general congestion control mechanism go away, and there its fairness issues are less severe than those of a general
is no need for the end nodes to tell the routers the round-trip time congestion control mechanism. With Quick-Start, there is no need
and congestion window, as is done in XCP; all that is needed is for for the end nodes to tell the routers the round-trip time and
the end nodes to report the requested sending rate. congestion window, as is done in XCP; all that is needed is for the
end nodes to report the requested sending rate.
Table 2 provides a summary of the differences between Quick-Start Table 3 provides a summary of the differences between Quick-Start
and proposals for per-packet congestion control feedback. and proposals for per-packet congestion control feedback.
Proposals for Proposals for
Quick-Start Per-Packet Feedback Quick-Start Per-Packet Feedback
+------------------+----------------------+----------------------+ +------------------+----------------------+----------------------+
Semantics: | Allowed sending rate | Change in rate/window, Semantics: | Allowed sending rate | Change in rate/window,
| per connection. | per-packet. | per connection. | per-packet.
+------------------+----------------------+----------------------+ +------------------+----------------------+----------------------+
Relationship to | In addition. | Replacement. Relationship to | In addition. | Replacement.
congestion ctrl: | | congestion ctrl: | |
skipping to change at page 64, line 27 skipping to change at page 69, line 27
Limitations: | Only useful on | General congestion Limitations: | Only useful on | General congestion
| underutilized paths.| control mechanism. | underutilized paths.| control mechanism.
+------------------+----------------------+----------------------+ +------------------+----------------------+----------------------+
Input to routers: | Rate request. |RTT, cwnd, request (XCP) Input to routers: | Rate request. |RTT, cwnd, request (XCP)
| | None (Anti-ECN). | | None (Anti-ECN).
+------------------+----------------------+----------------------+ +------------------+----------------------+----------------------+
Bits of feedback: | Four bits for | A few bits would Bits of feedback: | Four bits for | A few bits would
| rate request. | suffice? | rate request. | suffice?
+------------------+----------------------+----------------------+ +------------------+----------------------+----------------------+
Table 2: Differences between Quick-Start and Proposals for Table 3: Differences between Quick-Start and Proposals for
Fine-Grained Per-Packet Feedback. Fine-Grained Per-Packet Feedback.
A separate question concerns whether mechanisms such as Quick-Start, A separate question concerns whether mechanisms such as Quick-Start,
in combination with HighSpeed TCP and other changes in progress, in combination with HighSpeed TCP and other changes in progress,
would make a significant contribution towards meeting some of these would make a significant contribution towards meeting some of these
needs for new congestion control mechanisms. This could be viewed needs for new congestion control mechanisms. This could be viewed
as a positive step of meeting some of the current needs with a as a positive step towards meeting some of the more pressing current
simple and reasonably deployable mechanism, or alternately, as a needs with a simple and reasonably deployable mechanism, or
negative step of unnecessarily delaying more fundamental changes. alternately, as a negative step of unnecessarily delaying more
Without answering this question, we would note that our own approach fundamental changes. Without answering this question, we would note
tends to favor the incremental deployment of relatively simple that our own approach tends to favor the incremental deployment of
mechanisms, as long as the simple mechanisms are not short-term relatively simple mechanisms, as long as the simple mechanisms are
hacks but mechanisms that lead the overall architecture in the not short-term hacks but mechanisms that lead the overall
fundamentally correct direction. architecture in the fundamentally correct direction.
A.7. The Earlier QuickStart Nonce A.7. Alternate Implementations for a QuickStart Nonce
A.7.1. An Alternate Proposal for the QuickStart Nonce
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
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,
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.
Because the sender knows the original value for the nonce, and the
original rate request, the sender knows the total number of steps s
that the rate has been reduced. The sender then hashes the original
nonce s times, to check whether the result is the same as the nonce
returned by the receiver.
This alternate proposal for the nonce would be considerably more
powerful than the QS nonce described in Section 3.4, but it would
also require more CPU cycles from the routers when they reduce a
Quick-Start request, and from the sender in verifying the nonce
returned by the receiver. As reported in [B05], routers could
protect themselves from processor exhaustion attacks by limiting the
rate at which they will approve reductions of Quick-Start requests.
Both the Function field and the Reserved field in the 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
it was ever desired.
A.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 66, line 21 skipping to change at page 72, line 4
have used if the Quick-Start request had not been approved. have used if the Quick-Start request had not been approved.
(2) When does the sender decide there has been no feedback from the (2) When does the sender decide there has been no feedback from the
receiver: receiver:
Unlike TCP, CCID 3 does not use acknowledgements for every packet, Unlike TCP, CCID 3 does not use acknowledgements for every packet,
or for every other packet. In contrast, the CCID 3 receiver sends or for every other packet. In contrast, the CCID 3 receiver sends
feedback to the sender roughly once per round-trip time. In CCID 3, feedback to the sender roughly once per round-trip time. In CCID 3,
the allowed sending rate is halved if no feedback is received from the allowed sending rate is halved if no feedback is received from
the receiver in at least four round-trip times (when the sender is the receiver in at least four round-trip times (when the sender is
sending at least one packet every two round-trip times). When a sending at least one packet every two round-trip times). When a
Quick-Start request is used, it would seem prudent to use a smaller Quick-Start request is used, it would seem necessary to use a
time interval, e.g., to reduce the sending rate if no feedback is smaller time interval, e.g., to reduce the sending rate if no
received from the receiver in at least two round-trip times. feedback is received from the receiver in at least two round-trip
times.
The question also arises of how the sending rate should be reduced The question also arises of how the sending rate should be reduced
after a period of no feedback from the receiver. As with TCP, the after a period of no feedback from the receiver. As with TCP, the
default CCID 3 response of halving the sending rate is not default CCID 3 response of halving the sending rate is not
necessarily sufficient; an alternative is to reduce the sending rate necessarily a sufficient response to the absence of feedback; an
to the sending rate that would have been used if no Quick-Start alternative is to reduce the sending rate to the sending rate that
request had been approved. That is, if a CCID 3 sender uses a would have been used if no Quick-Start request had been approved.
Quick-Start request, special rules might be required to handle the That is, if a CCID 3 sender uses a Quick-Start request, special
sender's response to a period of no feedback from the receiver rules might be required to handle the sender's response to a period
regarding the Quick-Start packets. of no feedback from the receiver regarding the Quick-Start packets.
Similarly, in considering the use of Quick-Start with CCID 3 for Similarly, in considering the use of Quick-Start with CCID 3 for
requesting a higher sending rate after an idle period, the following requesting a higher sending rate after an idle period, the following
questions arise: (1) what rate does the sender request; (2) what is questions arise: (1) what rate does the sender request; (2) what is
the response to a loss; and (3) when does the sender determine that the response to a packet loss; and (3) when does the sender
there has been no feedback from the receiver, and the sending rate determine that there has been no feedback from the receiver, and the
must be reduced? sending rate must be reduced?
(1) What rate does the sender request: (1) What rate does the sender request:
As in TCP, there is a straightforward answer to the rate request As in TCP, there is a straightforward answer to the rate request
that the CCID 3 sender should use in requesting a higher sending that the CCID 3 sender should use in requesting a higher sending
rate after an idle period. The sender knows the current loss event rate after an idle period. The sender knows the current loss event
rate, either from its own calculations or from feedback from the rate, either from its own calculations or from feedback from the
receiver, and can determine the sending rate allowed by that loss receiver, and can determine the sending rate allowed by that loss
event rate. This is the upper bound on the sending rate that should event rate. This is the upper bound on the sending rate that should
be requested by the CCID 3 sender. A Quick-Start request is useful be requested by the CCID 3 sender. A Quick-Start request is useful
with CCID 3 when the sender is coming out of an idle or with CCID 3 when the sender is coming out of an idle or
underutilized period, because in standard operation CCID 3 does not underutilized period, because in standard operation CCID 3 does not
allow the sender to send more that twice as fast as the receiver has allow the sender to send more than twice as fast as the receiver has
reported received in the most recent feedback message. reported received in the most recent feedback message.
(2) What is the response to loss: (2) What is the response to loss:
The response to the loss of Quick-Start packets should be to return The response to the loss of Quick-Start packets should be to return
to the sending rate that would have been used if Quick-Start had not to the sending rate that would have been used if Quick-Start had not
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
skipping to change at page 68, line 26 skipping to change at page 74, line 10
over these time intervals as the estimate of the approved Rate over these time intervals as the estimate of the approved Rate
Requests. The experiments in [SAF05] keep track of the aggregate Requests. The experiments in [SAF05] keep track of the aggregate
approved Rate Requests over the most recent two time intervals, for approved Rate Requests over the most recent two time intervals, for
intervals of 150~msec. intervals of 150~msec.
The target algorithm also depends on a threshold (qs_thresh) that is The target algorithm also depends on a threshold (qs_thresh) that is
the fraction of the outgoing link bandwidth that represents the the fraction of the outgoing link bandwidth that represents the
router's notion of "significantly underutilized". If the router's notion of "significantly underutilized". If the
utilization, augmented by the potential bandwidth from recent Quick- utilization, augmented by the potential bandwidth from recent Quick-
Start approvals, is above this threshold then no Quick-Start Rate Start approvals, is above this threshold then no Quick-Start Rate
Requests will be approved. If the utilization is less than the Requests will be approved. If the utilization, again augmented by
threshold then Rate Requests will be approved. The Rate Requests the potential bandwidth from recent Quick-Start approvals, is less
will be reduced such that the bandwidth allocated would not drive than the threshold then Rate Requests can be approved. The Rate
the utilization to more than the given threshold. The algorithm is: Requests will be reduced such that the bandwidth allocated would not
drive the utilization to more than the given threshold. The
algorithm is:
util_bw = bandwidth * utilization; util_bw = bandwidth * utilization;
util_bw = util_bw + recent_qs_approvals; util_bw = util_bw + recent_qs_approvals;
if (util_bw < (qs_thresh * bandwidth)) if (util_bw < (qs_thresh * bandwidth))
{ {
approved = (qs_thresh * bandwidth) - util_bw; approved = (qs_thresh * bandwidth) - util_bw;
if (rate_request < approved) if (rate_request < approved)
approved = rate_request; approved = rate_request;
approved = round_down (approved); approved = round_down (approved);
recent_qs_approvals += approved; recent_qs_approvals += approved;
} }
Also note that given that Rate Requests are fairly gross 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.
D. Possible Uses for the Reserved Fields Routers that wish to keep close track of the allocated Quick-Start
bandwidth could use Approved Rate reports to learn when rate
requests had been decremented downstream in the network, and also to
learn when a sender begins to use the approved Quick-Start request.
The Quick-Start Request Option contains a four-bit Reserved field in D. Possible Additional Uses for the Quick-Start Option
the first four bytes, and a two-bit Reserved field in the last four
bytes. In this section we discuss some of the possible uses that
have been discussed for these Reserved bits.
Reporting Approved Rate: A Quick-Start Request with the Reporting The Quick-Start Option contains a four-bit Function field in the
Approved Rate bit set would not be requesting Quick-Start bandwidth, third byte, enabling additional uses to be defined for the Quick-
but would be reporting the approved rate for Quick-Start bandwidth Start Option. In this section we discuss some of the possible
that was approved one round-trip time earlier. This could be used additional uses that have been discussed for Quick-Start. The
by routers to track which Quick-Start requests were actually Function field makes it easy to add new functions for the Quick-
approved and in use, along with the approved rate. 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' bit set would be using the Rate `Report of Current Sending Rate' codepoint set in the Function field
Request field to report the current estimated sending rate for that would be using the Rate Request field to report the current
connection. This could accompany a second Quick-Start Request in estimated sending rate for that connection. This could accompany a
the same packet containing a standard rate request, for a connection second Quick-Start Request in the same packet containing a standard
that is using Quick-Start to increase its current sending rate. rate request, for a connection that is using Quick-Start to increase
its current sending rate.
Request to Increase Sending Rate: A bit for `Request to Increase Request to Increase Sending Rate: A codepoint for `Request to
Sending Rate' would indicate that the connection is not idle or just Increase Sending Rate' in the Function field would indicate that the
starting up, but is attemmpting to use Quick-Start to increase its connection is not idle or just starting up, but is attemmpting to
current sending rate. This bit would not change the semantics of use Quick-Start to increase its current sending rate. This
the Rate Request field. codepoint would not change the semantics of the Rate Request field.
RTT Estimate: A field for the RTT Estimate would contain one or more RTT Estimate: If a codepoint for `RTT Estimate' was used, a field
bits giving the sender's rough estimate of the round-trip time, if for the RTT Estimate would contain one or more bits giving the
known. E.g., the sender could estimate whether the RTT was greater sender's rough estimate of the round-trip time, if known. E.g., the
or less than 200 ms. sender could estimate whether the RTT was greater or less than 200
ms. Alternately, if the sender had an estimate of the RTT when it
sends the Rate Request, the two-bit Reserved field at the end of the
Quick-Start Option could be used for a coarse-grained encoding of
the RTT.
Informational Request: An Informational Request bit would indicate Informational Request: An Informational Request codepoint in the
that a request is purely informational, for the sender to find out Function field would indicate that a request is purely
if a rate request would be approved, and what size rate request informational, for the sender to find out if a rate request would be
would be approved, when the Informational Request is sent. For approved, and what size rate request would be approved, when the
example, an Informational Request could be followed one round-trip Informational Request is sent. For example, an Informational
time later by a standard Quick-Start Request. A router approving an Request could be followed one round-trip time later by a standard
Informational Request would not consider this as an approval for Quick-Start Request. A router approving an Informational Request
Quick-Start bandwidth to be used, and would not be under any would not consider this as an approval for Quick-Start bandwidth to
obligation to approve a similar standard Quick-Start Request one be used, and would not be under any obligation to approve a similar
round-trip time later. standard Quick-Start Request one round-trip time later.
Use Format X for the Rate Request Field: A Quick-Start bit for `Use Use Format X for the Rate Request Field: A Quick-Start codepoint for
Format X for the Rate Request Field' would indicate that an `Use Format X for the Rate Request Field' would indicate that an
alternate format was being used for the Rate Request field. alternate format was being used for the Rate Request field.
Do Not Decrement: A Do Not Decrement bit could be set in a Quick- Do Not Decrement: A Do Not Decrement codepoint could be used for a
Start request if the sender would rather have the request denied Quick-Start request where the sender would rather have the request
than to have the rate request decremented in the network. This denied than to have the rate request decremented in the network.
could be used if the sender was only interested in using Quick-Start This could be used if the sender was only interested in using Quick-
if the original rate request was approved. Start if the original rate request was approved.
If any of these functions were standardized for Quick-Start, the E. Feedback from Bob Briscoe
standardization would also have to address the issue of backwards
compatibility with older Quick-Start routers or end-nodes that do [B05] in a review of an earlier version of the Quick-Start proposal
not understand the newly-added function. discussed a number of potential problems with Quick-Start, and
argued for an alternate approach for policing congestion in networks
using re-feedback [BJCG+05,BJS05]. However, [B05] didn't oppose the
move to Quick-Start to experimental status as long as its
applicability is made clear.
E.1. Potential Deployment Scenarios
[B05] argues that because the sender's trustworthiness is not
necessarily verified, Quick-Start, if it is remain stateless, should
be confined to environments where every source is trusted. Section
3.2 of [B05] argues that either (1) Quick-Start should be
recommended for deployment only in trusted environments, or (2)
Quick-Start could be recommended for deployment also in untrusted
environments, with flow state required at some or all routers.
Since [B05], we have added the Report of Approved Rate as a required
part of Quick-Start, and discussed ways that this could be used by
routers or by traffic policers, if desired, to check on the use of
Quick-Start by senders. We also note that senders can send at an
initial high rate even in the absence of Quick-Start, in the current
network; that is, in our view, Quick-Start does not change the
dangers to the network from malicious senders. Thus, while we are
clearly not recommending Quick-Start for widespread deployment in
the global Internet, we also don't feel the need to explicitly
restrict its deployment to environments where every source is
trusted, or to explicitly require per-flow state at Quick-Start
routers. We assume that Quick-Start will only be enabled at routers
if the system administrators feel either that they have sufficient
trust in senders, sufficient policing mechanisms for checking for
misbehaving nodes, or sufficient oversite to disable Quick-Start if
it is determined to be causisng problems..
E.2. Misbehaving Senders and Receivers
Some of the criticisms of Quick-Start in [B05] are criticisms for
mechanisms that allocate rates to senders, but this is not what
Quick-Start does. Quick-Start requests apply to individual
connections, not to unique addresses or unique tuples of addresses.
Further, the approval by routers of Quick-Start requests does not
result in an allocation of bandwidth for the sender making that
request; the approval by routers does not result in any allocation
of bandwidth at all. The state used by routers from past Quick-
Start approvals is used only to guide the router in its approval or
rejection of future Quick-Start requests. We have added text to
this document to make this quite explicit.
[B05] discusses the dangers of sender spoofing and identity
splitting. Identify splitting would not be a problem with Quick-
Start, because Quick-Start requests apply to individual connections,
not to unique addresses or unique tuples of addresses. Because
Quick-Start does not allocate rates to senders, sender-spoofing is
also not a critical issue (except as it would make it more difficult
for those Quick-Start routers that maintain per-flow state to
identify senders that send Quick-Start requests that are not in fact
used, due either to malicious requests or due to requests denied
downstream).
In Section 3.3, [B05] says that "the lack of a secure binding
between a request and subsequent traffic means that any other node
could send a burst of traffic and claim it requests it, with no-one
being able to prove it didn't." In the current Internet, any node
can send a burst of traffic any time it would like, even without
Quick-Start. However, in the absense of Quick-Start, sending at a
high rate is not always in the sender's interest, as the packets
that are send might have a high probability of being dropped in the
network, particularly in the absense of Quick-Start. The addition
of the Report of Approved Rate to Quick-Start gives traffic policers
the ability to check on some of the potential abuses of Quick-Start,
if they so desire.
In Section 3.8, [B05] states that "not only do Quick-Start senders
have to be trusted, but also other senders who could claim their
data had been authorised by a Quick-Start response when it hadn't
(Section 3.3)." In response, we would again clarify that with Quick-
Start, the Quick-Start request makes no difference in how the
subsequent Quick-Start data packets are treated at the router,
compared to non-Quick-Start data packets. Thus, a sender's claim
that its data results from a previous Quick-Start request should
make no difference in how those data packets are treated at routers.
The approval of a Quick-Start request is not a promise by the router
that the subsequent data packets will receive differential treatment
at the router; it is only a statement from the router that the
router believes that the Quick-Start data packets will not change
the current under-utilized state of the router. We have clarified
this in Section 3.3 of this document.
E.3. Fairness
In its abstract, [B05] says the following: "Because traffic variance
will always blur the boundary, we argue that under-utilisation
should be treated as the extreme of a spectrum where fairness is
always an issue to some extent."
The specification for Quick-Start now says the following: "A router
should only approve a Quick-Start request if the output link is
underutilized, and if the router judges that the output link will
continue to be underutilized if the request is approved."
We changed the quote "for a mechanism for requesting an initial
sending rate in an underutilized environment, the fairness issues of
a general congestion control mechanism go away" to the following:
"because Quick-Start is a mechanism for requesting an initial
sending rate in an underutilized environment, its fairness issues
are less severe than those of a general congestion control
mechanism."
However, we did not add the sentence recommended in Ssection 3.4 of
[B05], that "Quick-Start is targeted at an experimental environment
where the more intractable issues can be set aside". In particular,
we don't agree that Quick-Start needs to be targeted only for
environments where fairness is not an issue.
E.4. Models of Under-Utilization
[B05] states that "One of the under-utilisation assumptions I had in
my head while reading the paper was that any one host is generally
able to over-fill available capacity, but that, given a high rate,
the flow would end quickly." We are sorry that this is the model
that the author inferred from the draft, but we can give assurances
that this `one big flow at a time" model was *never* the implicit or
explicit model underlying the Quick-Start design. (We would also
note that every version of this document since the first version
back in 2002 has discussed router responses when the router
experiences a flood of Quick-Start requests.)
[B05] also says the following: "By reverse engineering this
algorithm, it was possible to guess that there was an assumption
that host capacity was smaller than the network's, so meeting a
request in full would still leave a lot of spare capacity for the
next request." Again, we would like to clarify that there has been
no such assumption underlying the Quick-Start design.
E.5. Router Algorithms as Local Policy
[B05] recommends that either this document should set constraints on
possible router algorithms, or say that experiments are needed "in
order to establish constraints required on router algorithms for
interworking, robustness, fairness etc." While it is possible that
experiments will lead to an understanding of constraints that are
needed on router algorithms, we think it is more likely that there
will not be a need for explicit constraints on router algorithms for
accepting or rejecting Quick-Start requests.
Our approach is that, while the Quick-Start IETF documentation
standardizes the semantics of Quick-Start and the format of the
Quick-Start IP Option and the Quick-Start Response TCP Option, the
IETF documentation should not and does not standardize the
algorithms used at routers for approving or denying Quick-Start
request. Appendix D in this document has presented one possible
router algorithm for approving or denying Quick-Start requests, but
further discussion of the range of possibilities in router
algorithms is available elsewhere [SAF05]. As an example, the
fairness criteria that routers might apply in granting or denying
Quick-Start requests are discussed in [SAF05], but are not discussed
in the same detail in this document. This document leaves routers
free to apply any criteria they choose in accepting or denying
Quick-Start requests, modulo the requirements given in Section 3.3
above.
This approach of the Quick-Start router algorithm as a matter of
local policy is consistent with the approach in RFC 3168 on
standardizing Explicit Congestion Notification (ECN). RFC 3168
standardized the semantics of the ECN field, but did not standardize
a router's Active Queue Management mechanisms for deciding when to
set the Congestion Experienced codepoint in packets.
E.6. An Alternate Proposal
[B05] proposes an alternate to Quick-Start where endpoints allocate
rates to themselves. [B05] argues that adding rate allocation to
interior routers is not the fundamenally correct direction.
[B05] argues for an approach that associates senders with their
ingress attachment point, with routers reporting their impairment
status back to the sender [BJCG+05, BJS05]. The source declares the
impairment that it believes it will accumulate along the path, and
routers effectively subtract the local impairment status. If the
sender is reporting correctly, and the impairment has not changed
significantly from one round-trip time to the next, the reported
impairment at the egress router should be close to zero.
Normative References Normative References
[RFC793] J. Postel, Transmission Control Protocol, RFC 793, [RFC793] J. Postel, Transmission Control Protocol, RFC 793,
September 1981. September 1981.
[RFC1191] Mogul, J. and S. Deering, Path MTU Discovery, RFC 1191, [RFC1191] Mogul, J. and S. Deering, Path MTU Discovery, RFC 1191,
November 1990. November 1990.
[RFC2460] S. Deering and R. Hinden. Internet Protocol, Version 6 [RFC2460] S. Deering and R. Hinden. Internet Protocol, Version 6
skipping to change at page 70, line 39 skipping to change at page 80, line 23
Initial Window. RFC 3390, October 2002. Initial Window. RFC 3390, October 2002.
[RFC3742] Floyd, S., Limited Slow-Start for TCP with Large [RFC3742] Floyd, S., Limited Slow-Start for TCP with Large
Congestion Windows, RFC 3742, Experimental, March 2004. Congestion Windows, RFC 3742, Experimental, March 2004.
Informative References Informative References
[RFC792] J. Postel. Internet Control Message Protocol. RFC 792, [RFC792] J. Postel. Internet Control Message Protocol. RFC 792,
September 1981. September 1981.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1812] F. Baker (ed.). Requirements for IP Version 4 Routers. RFC [RFC1812] F. Baker (ed.). Requirements for IP Version 4 Routers. RFC
1812, June 1995. 1812, June 1995.
[RFC2003] Perkins, C., IP Encapsulation within IP, RFC 2003, [RFC2003] Perkins, C., IP Encapsulation within IP, RFC 2003,
October 1996. October 1996.
[RFC2113] D. Katz. P Router Alert Option. RFC 2113, February 1997.
[RFC2140] J. Touch. TCP Control Block Interdependence. RFC 2140. [RFC2140] J. Touch. TCP Control Block Interdependence. RFC 2140.
April 1997. April 1997.
[RFC2205] R. Braden, et al. Resource ReSerVation Protocol (RSVP) -- [RFC2205] R. Braden, et al. Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification. RFC 2205, September 1997. Version 1 Functional Specification. RFC 2205, September 1997.
[RFC2409] D. Harkins and D. Carrel, The Internet Key Exchange (IKE), [RFC2409] D. Harkins and D. Carrel, The Internet Key Exchange (IKE),
RFC 2409, November 1998. RFC 2409, November 1998.
[RFC2246] T. Dierks and C. Allen, The TLS Protocol, RFC 2246. [RFC2246] T. Dierks and C. Allen, The TLS Protocol, RFC 2246.
skipping to change at page 72, line 14 skipping to change at page 81, line 49
[RFC3234] B. Carpenter and S. Brim, Middleboxes: Taxonomy and [RFC3234] B. Carpenter and S. Brim, Middleboxes: Taxonomy and
Issues, RFC 3234, February 2002. Issues, RFC 3234, February 2002.
[RFC3344] C. Perkins (ed.). IP Mobility Support for IPv4. RFC 3344, [RFC3344] C. Perkins (ed.). IP Mobility Support for IPv4. RFC 3344,
August 2002. August 2002.
[RFC3360] S. Floyd. Inappropriate TCP Resets Considered Harmful. [RFC3360] S. Floyd. Inappropriate TCP Resets Considered Harmful.
RFC 3360, August 2002. RFC 3360, August 2002.
[RFC3649] Floyd, S., HighSpeed TCP for Large Congestion Windows, RFC
3649, December 2003.
[RFC3662] R. Bless, K. Nichols, and K. Wehrle. A Lower Effort Per-
Domain Behavior (PDB) for Differentiated Services. RFC 3662,
December 2003.
[RFC3775] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in [RFC3775] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in
IPv6. RFC 3775, June 2004. IPv6. RFC 3775, June 2004.
[RFC3819] P. Karn et al., "Advice for Internet Subnetwork [RFC3819] P. Karn et al., "Advice for Internet Subnetwork
Designers", July 2004. Designers", July 2004.
[RFC3948] A. Huttunen, B. Swander, V. Volpe, L. DiBurro, and M. [RFC3948] A. Huttunen, B. Swander, V. Volpe, L. DiBurro, and M.
Stenberg, UDP Encapsulation of IPsec ESP Packets, RFC 3948, January Stenberg, UDP Encapsulation of IPsec ESP Packets, RFC 3948, January
2005. 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[AHO98] M. Allman, C. Hayes and S. Ostermann. An evaluation of TCP [AHO98] M. Allman, C. Hayes and S. Ostermann. An evaluation of TCP
with Larger Initial Windows. ACM Computer Communication Review, July with Larger Initial Windows. ACM Computer Communication Review, July
1998. 1998.
[B05] B. Briscoe, Review: Quick-Start for TCP and IP, internet-draft
draft-briscoe-tsvwg-quickstart-rvw-00, work-in-progress, URL
"http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html", November 2005.
[BJCG+05] Briscoe, B., Jacquet, A., Di Cairano-Gilfedder, C.,
Salvatori, A., Soppera, A., and M. Koyabe, "Policing Congestion
Response in an Internetwork Using Re-Feedback", SIGCOMM, August
2005.
[BJS05] Briscoe, B., Jacquet, A., and A. Salvatori, "Re-ECN: Adding
Accountability for Causing Congestion to TCP/IP", internet-draft
draft-briscoe-tsvwg-re-ecn-tcp-00.txt, work-in-progress, October
2005.
[BW97] G. Brasche and B. Walke. Concepts, Services and Protocols of [BW97] G. Brasche and B. Walke. Concepts, Services and Protocols of
the new GSM Phase 2+ General Packet Radio Service. IEEE the new GSM Phase 2+ General Packet Radio Service. IEEE
Communications Magazine, pages 94--104, August 1997. Communications Magazine, pages 94--104, August 1997.
[FF99] Floyd, S., and Fall, K., Promoting the Use of End-to-End [FF99] Floyd, S., and Fall, K., Promoting the Use of End-to-End
Congestion Control in the Internet, IEEE/ACM Transactions on Congestion Control in the Internet, IEEE/ACM Transactions on
Networking, August 1999. Networking, August 1999.
[F03] Floyd, S., HighSpeed TCP for Large Congestion Windows, RFC
3649, December 2003.
[GPAR02] A. Gurtov, M. Passoja, O. Aalto, and M. Raitola. Multi- [GPAR02] A. Gurtov, M. Passoja, O. Aalto, and M. Raitola. Multi-
Layer Protocol Tracing in a GPRS Network. In Proceedings of the IEEE Layer Protocol Tracing in a GPRS Network. In Proceedings of the IEEE
Vehicular Technology Conference (Fall VTC2002), Vancouver, Canada, Vehicular Technology Conference (Fall VTC2002), Vancouver, Canada,
September 2002. September 2002.
[H05] P. Hoffman, email, October 2005. Citation for acknowledgement [H05] P. Hoffman, email, October 2005. Citation for acknowledgement
purposes only. purposes only.
[HKP01] M. Handley, C. Kreibich and V. Paxson, Network Intrusion [HKP01] M. Handley, C. Kreibich and V. Paxson, Network Intrusion
Detection: Evasion, Traffic Normalization, and End-to-End Protocol Detection: Evasion, Traffic Normalization, and End-to-End Protocol
Semantics, Proc. USENIX Security Symposium 2001. Semantics, Proc. USENIX Security Symposium 2001.
[IKEv2] Kaufman, C., (ed.), "Internet Key Exchange (IKEv2)
Protocol", draft-ietf-ipsec-ikev2-17.txt, Internet draft (work in
progress), September 2004.
[Jac88] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM [Jac88] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM
[JD02] Manish Jain, Constantinos Dovrolis, End-to-End Available [JD02] Manish Jain, Constantinos Dovrolis, End-to-End Available
Bandwidth: Measurement Methodology, Dynamics, and Relation with TCP Bandwidth: Measurement Methodology, Dynamics, and Relation with TCP
Throughput, SIGCOMM 2002. Throughput, SIGCOMM 2002.
[KHR02] Dina Katabi, Mark Handley, and Charles Rohrs, Internet
Congestion Control for Future High Bandwidth-Delay Product
Environments. ACM Sigcomm 2002, August 2002. URL
"http://ana.lcs.mit.edu/dina/XCP/".
[KHF05] E. Kohler, M. Handley, and S. Floyd, Datagram Congestion
Control Protocol (DCCP), internet draft draft-ietf-dccp-spec-11.txt,
work in progress, March 2005.
[K03] S. Kunniyur, "AntiECN Marking: A Marking Scheme for High [K03] S. Kunniyur, "AntiECN Marking: A Marking Scheme for High
Bandwidth Delay Connections", Proceedings, IEEE ICC '03, May 2003. Bandwidth Delay Connections", Proceedings, IEEE ICC '03, May 2003.
URL "http://www.seas.upenn.edu/~kunniyur/". URL "http://www.seas.upenn.edu/~kunniyur/".
[KAPS02] Rajesh Krishnan, Mark Allman, Craig Partridge, James P.G. [KAPS02] Rajesh Krishnan, Mark Allman, Craig Partridge, James P.G.
Sterbenz. Explicit Transport Error Notification (ETEN) for Error- Sterbenz. Explicit Transport Error Notification (ETEN) for Error-
Prone Wireless and Satellite Networks. Technical Report No. 8333, Prone Wireless and Satellite Networks. Technical Report No. 8333,
BBN Technologies, March 2002. URL BBN Technologies, March 2002. URL
"http://www.icir.org/mallman/papers/". "http://www.icir.org/mallman/papers/".
[KHR02] Dina Katabi, Mark Handley, and Charles Rohrs, Internet
Congestion Control for Future High Bandwidth-Delay Product
Environments. ACM Sigcomm 2002, August 2002. URL
"http://ana.lcs.mit.edu/dina/XCP/".
[KHF05] E. Kohler, M. Handley, and S. Floyd, Datagram Congestion
Control Protocol (DCCP), internet draft draft-ietf-dccp-spec-11.txt,
work in progress, March 2005.
[KK03] A. Kuzmanovic and E. W. Knightly. TCP-LP: A Distributed
Algorithm for Low Priority Data Transfer. INFOCOM 2003, April 2003.
[L05] Guohan Lu, Nonce in TCP Quick Start, draft, September 2005. [L05] Guohan Lu, Nonce in TCP Quick Start, draft, September 2005.
URL "http://www.net-glyph.org/~lgh/nonce-usage.pdf". URL "http://www.net-glyph.org/~lgh/nonce-usage.pdf".
[MAF04] Alberto Medina, Mark Allman, and Sally Floyd, Measuring [MAF04] Alberto Medina, Mark Allman, and Sally Floyd, Measuring
Interactions Between Transport Protocols and Middleboxes, Internet Interactions Between Transport Protocols and Middleboxes, Internet
Measurement Conference 2004, August 2004. URL Measurement Conference 2004, August 2004. URL
"http://www.icir.org/tbit/". "http://www.icir.org/tbit/".
[MAF05] Alberto Medina, Mark Allman, and Sally Floyd. Measuring the [MAF05] Alberto Medina, Mark Allman, and Sally Floyd. Measuring the
Evolution of Transport Protocols in the Internet. To appear in Evolution of Transport Protocols in the Internet. Computer
Computer Communications Review, April 2004. Communications Review, April 2004.
[MaxNet] MaxNet Home Page, URL [MaxNet] MaxNet Home Page, URL
"http://netlab.caltech.edu/~bartek/maxnet.htm". "http://netlab.caltech.edu/~bartek/maxnet.htm".
[PK98] Venkata N. Padmanabhan and Randy H. Katz, TCP Fast Start: A [PK98] Venkata N. Padmanabhan and Randy H. Katz, TCP Fast Start: A
Technique For Speeding Up Web Transfers, IEEE GLOBECOM '98, November Technique For Speeding Up Web Transfers, IEEE GLOBECOM '98, November
1998. 1998.
[P00] Joon-Sang Park, Bandwidth Discovery of a TCP Connection, [P00] Joon-Sang Park, Bandwidth Discovery of a TCP Connection,
report to John Jeidemann, 2000, private communication. Citation for report to John Jeidemann, 2000, private communication. Citation for
acknowledgement purposes only. acknowledgement purposes only.
[PRAKS02] Craig Partridge, Dennis Rockwell, Mark Allman, Rajesh [PRAKS02] Craig Partridge, Dennis Rockwell, Mark Allman, Rajesh
Krishnan, James P.G. Sterbenz. A Swifter Start for TCP. Technical Krishnan, James P.G. Sterbenz. A Swifter Start for TCP. Technical
Report No. 8339, BBN Technologies, March 2002. URL Report No. 8339, BBN Technologies, March 2002. URL
"http://www.icir.org/mallman/papers/". "http://www.icir.org/mallman/papers/".
[RW03] Mattia Rossi and Michael Welzl, On the Impact of IP Option
Processing, Preprint-Reihe des Fachbereichs Mathematik - Informatik,
No. 15, October 2003.
[RW04] Mattia Rossi and Michael Welzl, On the Impact of IP Option
Processing - Part 2, Preprint-Reihe des Fachbereichs Mathematik -
Informatik, No. 26, July 2004.
[S02] Ion Stoica, private communication, 2002. Citation for [S02] Ion Stoica, private communication, 2002. Citation for
acknowledgement purposes only. acknowledgement purposes only.
[SAF05] Pasi Sarolahti, Mark Allman, and Sally Floyd. Evaluating [SAF05] Pasi Sarolahti, Mark Allman, and Sally Floyd. Evaluating
Quick-Start for TCP. Under submission, May 2005. URL Quick-Start for TCP. May 2005. URL
"http://www.icir.org/floyd/quickstart.html". "http://www.icir.org/floyd/quickstart.html".
[SGF05] Singh, M., Guha, S., and P. Francis, "Utilizing spare
network bandwidth to improve TCP performance", ACM SIGCOMM 2005 Work
in Progress session , August 2005,
https://www.guha.cc/saikat/pub/sigcomm05-lowtcp.pdf.
[SHA1] "Secure Hash Standard", FIPS, U.S. Department of Commerce,
Washington, D.C. publication 180-1, April 1995.
[SH02] Srikanth Sundarrajan and John Heidemann. Study of TCP Quick [SH02] Srikanth Sundarrajan and John Heidemann. Study of TCP Quick
Start with NS-2. Class Project, December 2002. Not publically Start with NS-2. Class Project, December 2002. Not publically
available; citation for acknowledgement purposes only. available; citation for acknowledgement purposes only.
[V02] A. Venkataramani, R. Kokku, and M. Dahlin. TCP Nice: A
Mechanism for Background Transfers. OSDI 2002.
[W00] Michael Welzl: PTP: Better Feedback for Adaptive Distributed [W00] Michael Welzl: PTP: Better Feedback for Adaptive Distributed
Multimedia Applications on the Internet, IPCCC 2000 (19th IEEE Multimedia Applications on the Internet, IPCCC 2000 (19th IEEE
International Performance, Computing, And Communications International Performance, Computing, And Communications
Conference), Phoenix, Arizona, USA, 20-22 February 2000. URL Conference), Phoenix, Arizona, USA, 20-22 February 2000. URL
"http://informatik.uibk.ac.at/users/c70370/research/publications/". "http://informatik.uibk.ac.at/users/c70370/research/publications/".
[W03] Michael Welzl, PMTU-Options: Path MTU Discovery Using Options, [W03] Michael Welzl, PMTU-Options: Path MTU Discovery Using Options,
expired internet-draft draft-welzl-pmtud-options-01.txt, work-in- expired internet-draft draft-welzl-pmtud-options-01.txt, work-in-
progress. February 2003. progress. February 2003.
[ZPS00] Y. Zhang, V. Paxson, and S. Shenker, The Stationarity of [ZPS00] Y. Zhang, V. Paxson, and S. Shenker, The Stationarity of
Internet Path Properties: Routing, Loss, and Throughput, ACIRI Internet Path Properties: Routing, Loss, and Throughput, ACIRI
Technical Report, May 2000. Technical Report, May 2000.
E. IANA Considerations [ZQK00] Y. Zhang, L. Qiu, and S. Keshav, Speeding Up Short Data
Transfers: Theory, Architectural Support, and Simulation Results,
NOSSDAV 2000, June 2000.
F. IANA Considerations
Quick-Start requires an IP Option and a TCP Option. Quick-Start requires an IP Option and a TCP Option.
E.1. IP Option F.1. IP Option
Quick-Start requires that both an IPv4 and an IPv6 Option Number be Quick-Start requires that both an IPv4 and an IPv6 Option Number be
allocated. The IPv4 Option would have a copied flag of 0, a class allocated. The IPv4 Option would have a copied flag of 0, a class
field of 00, and the assigned five-bit option number. The IPv6 field of 00, and the assigned five-bit option number. The IPv6
Option would have the first three bits of "001" [RFC 2460, Section Option would have the first three bits of "001" [RFC 2460, Section
4.2], with the first two bits indicating that the IPv6 node skip 4.2], with the first two bits indicating that the IPv6 node skip
over this option and continue processing the header if it doesn't over this option and continue processing the header if it doesn't
recognize the option type, and the third bit indicating that the recognize the option type, and the third bit indicating that the
Option Data may change en-route. Option Data may change en-route.
In both cases the name of the option would be "QSR - Quick-Start In both cases the name of the option would be "QS - Quick-Start",
Request", with this document as the reference document. with this document as the reference document.
E.2. TCP Option F.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.
AUTHORS' ADDRESSES AUTHORS' ADDRESSES
Amit Jain
F5 Networks
Email : a.jain@f5.com
Sally Floyd Sally Floyd
Phone: +1 (510) 666-2989 Phone: +1 (510) 666-2989
ICIR (ICSI Center for Internet Research) ICIR (ICSI Center for Internet Research)
Email: floyd@icir.org Email: floyd@icir.org
URL: http://www.icir.org/floyd/ URL: http://www.icir.org/floyd/
Mark Allman Mark Allman
ICSI Center for Internet Research ICSI Center for Internet Research
1947 Center Street, Suite 600 1947 Center Street, Suite 600
Berkeley, CA 94704-1198 Berkeley, CA 94704-1198
Phone: (440) 243-7361 Phone: (440) 243-7361
Email: mallman@icir.org Email: mallman@icir.org
URL: http://www.icir.org/mallman/ URL: http://www.icir.org/mallman/
Amit Jain
F5 Networks
Email : a.jain@f5.com
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 2005. 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. 191 change blocks. 
613 lines changed or deleted 1153 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/