draft-ietf-tsvwg-quickstart-00.txt   draft-ietf-tsvwg-quickstart-01.txt 
Internet Engineering Task Force A. Jain Internet Engineering Task Force A. Jain
INTERNET-DRAFT F5 Networks INTERNET-DRAFT F5 Networks
draft-ietf-tsvwg-quickstart-00.txt S. Floyd draft-ietf-tsvwg-quickstart-01.txt S. Floyd
Expires: November 2005 M. Allman Expires: April 2006 M. Allman
ICIR ICIR
P. Sarolahti P. Sarolahti
Nokia Research Center Nokia Research Center
31 May 2005 13 October 2005
Quick-Start for TCP and IP Quick-Start for TCP and IP
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she becomes aware will be disclosed, in accordance with
Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
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 November 2005. This Internet-Draft will expire on April 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. 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. While Quick-Start is designed to be used by a range data transfer (e.g., after an idle period). While Quick-Start is
of transport protocols, in this document we describe its use with designed to be used by a range of transport protocols, in this
TCP. By using Quick-Start, a TCP host, say, host A, would indicate document we describe its use with TCP. By using Quick-Start, a TCP
its desired sending rate in bytes per second, using a Quick Start host, say, host A, would indicate its desired sending rate in bytes
Request option in the IP header of a TCP packet. Each router along per second, using a Quick Start Request option in the IP header of a
the path could, in turn, either approve the requested rate, reduce TCP packet. Each router along the path could, in turn, either
the requested rate, or indicate that the Quick-Start request is not approve the requested rate, reduce the requested rate, or indicate
approved. If the Quick-Start request is not approved, then the that the Quick-Start request is not approved. If the Quick-Start
sender would use the default congestion control mechanisms. The request is not approved, then the sender would use the default
Quick-Start mechanism can determine if there are routers along the congestion control mechanisms. The Quick-Start mechanism can
path that do not understand the Quick-Start Request option, or have determine if there are routers along the path that do not understand
not agreed to the Quick-Start rate request. TCP host B communicates the Quick-Start Request option, or have not agreed to the Quick-
the final rate request to TCP host A in a transport-level Quick- Start rate request. TCP host B communicates the final rate request
Start Response in an answering TCP packet. Quick-Start is designed to TCP host A in a transport-level Quick-Start Response in an
to allow connections to use higher sending rates when there is answering TCP packet. Quick-Start is designed to allow connections
significant unused bandwidth along the path, and all of the routers to use higher sending rates when there is significant unused
along the path support the Quick-Start Request. bandwidth along the path, and all of the routers along the path
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-00:
* Added a 30-bit QS Nonce. Based on feedback from Guohan Lu
and Gorry Fairhurst (and deleted the text about a possible
four-bit QS nonce).
* Added a new section "Quick-Start and IPsec AH", based on feedback
from Joe Touch and David Black.
* Revised "Quick-Start in IP Tunnels" Section, based on feedback
from Joe Touch and David Black.
* Added a section about "Possible Uses for the Reserved Fields".
* Changes from feedback from Gorry Fairhurst:
- Section 4.4, revised the explanation for reducing the
congestion window when the first ACK for a Quick-Start
packet is received.
- Section 6.4, deleted the last sentence.
- Minor editing changes.
- Revised Section 4.6.2 to say that sender SHOULD send one packet
with an initial RTO of three seconds.
- Revised Section 4.6.3 to say that the TCP sender SHOULD use an
initial RTO setting of three seconds.
- Added text to Section 6.2 on Multiple Paths, discussing
multi-path routing.
- Clarified about GPRS round-trip times.
- Clarified about PMTUD and the first window of data.
- A small reorganization, rearranging sections.
* Changes from feedback from Martin Duke:
- Revised text about the size of QS requests.
- Added some text to Section 4.1, about when to send QS requests.
Changes from draft-amit-quick-start-04.txt: Changes from draft-amit-quick-start-04.txt:
* A significant amount of general editing. * A significant amount of general editing.
* Because the Rate Request field only uses four bits, specified * Because the Rate Request field only uses four bits, specified
that the other four bits are reserved, and talked about a that the other four bits are reserved, and talked about a
possible use for them. This is discussed in a new section on possible use for them. This is discussed in a new section on
"A Rate-Reduced Nonce?" "A Rate-Reduced Nonce?"
* Specified that a Quick-Start-capable router denying a request * Specified that a Quick-Start-capable router denying a request
SHOULD delete the Quick-Start option, and if this is not SHOULD delete the Quick-Start option, and if this is not
possible, SHOULD zero the QS TTL and the Rate Request fields. possible, SHOULD zero the QS TTL and the Rate Request fields.
* Made the following change: If the Quick-Start Response is lost * Made the following change: If the Quick-Start Response is lost
skipping to change at page 4, line 24 skipping to change at page 5, line 4
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. . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 9
2. Assumptions and General Principles. . . . . . . . . . . . . . 8 2. Assumptions and General Principles. . . . . . . . . . . . . . 10
2.1. Overview of Quick-Start. . . . . . . . . . . . . . . . . 9 2.1. Overview of Quick-Start. . . . . . . . . . . . . . . . . 11
3. The Quick-Start Request in IP . . . . . . . . . . . . . . . . 12 3. The Quick-Start Request in IP . . . . . . . . . . . . . . . . 14
3.1. The Quick-Start Request Option for IPv4. . . . . . . . . 12 3.1. The Quick-Start Request Option for IPv4. . . . . . . . . 14
3.2. The Quick-Start Request Option for IPv6. . . . . . . . . 14 3.2. The Quick-Start Request Option for IPv6. . . . . . . . . 16
3.3. Processing the Quick-Start Request at 3.3. Processing the Quick-Start Request at
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4. Deciding the Permitted Rate Request at a 3.4. The QS Nonce . . . . . . . . . . . . . . . . . . . . . . 18
Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.5. Quick-Start in IP Tunnels. . . . . . . . . . . . . . . . 17
3.6. A Rate-Reduced Nonce?. . . . . . . . . . . . . . . . . . 19
4. The Quick-Start Mechanisms in TCP . . . . . . . . . . . . . . 20 4. The Quick-Start Mechanisms in TCP . . . . . . . . . . . . . . 20
4.1. When to Use Quick-Start. . . . . . . . . . . . . . . . . 21 4.1. When to Use Quick-Start. . . . . . . . . . . . . . . . . 21
4.2. The Quick-Start Response Option in the TCP 4.2. The Quick-Start Response Option in the TCP
header. . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 header. . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3. TCP: Sending the Quick-Start Response. . . . . . . . . . 23 4.3. TCP: Sending the Quick-Start Response. . . . . . . . . . 24
4.4. TCP: Receiving and Using the Quick-Start 4.4. TCP: Receiving and Using the Quick-Start
Response Packet . . . . . . . . . . . . . . . . . . . . . . . 24 Response Packet . . . . . . . . . . . . . . . . . . . . . . . 24
4.5. TCP: Responding to a Loss of a Quick-Start 4.5. TCP: Responding to a Loss of a Quick-Start
Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.6. TCP: A Quick-Start Request for a Larger Ini- 4.6. TCP: A Quick-Start Request for a Larger Ini-
tial Window . . . . . . . . . . . . . . . . . . . . . . . . . 25 tial Window . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.6.1. Determining the Rate to Request . . . . . . . . . . 25 4.6.1. Interactions with Path MTU Discovery. . . . . . . . 27
4.6.2. Interactions with Path MTU Discovery. . . . . . . . 26 4.6.2. Quick-Start Request Packets that are
4.6.3. Quick-Start Request Packets that are
Discarded by Middleboxes . . . . . . . . . . . . . . . . . 27 Discarded by Middleboxes . . . . . . . . . . . . . . . . . 27
4.7. TCP: A Quick-Start Request in the Middle of 4.7. TCP: A Quick-Start Request in the Middle of
Connection. . . . . . . . . . . . . . . . . . . . . . . . . . 28 Connection. . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.8. An Example Quick-Start Scenario with TCP . . . . . . . . 29 4.8. An Example Quick-Start Scenario with TCP . . . . . . . . 29
5. The Quick-Start Mechanism in other Transport Pro- 5. Quick-Start and IPsec AH. . . . . . . . . . . . . . . . . . . 30
tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6. Quick-Start in IP Tunnels . . . . . . . . . . . . . . . . . . 31
6. Evaluation of Quick-Start . . . . . . . . . . . . . . . . . . 30 6.1. Simple Tunnels That Are Compatible with
6.1. Benefits of Quick-Start. . . . . . . . . . . . . . . . . 30 Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2. Costs of Quick-Start . . . . . . . . . . . . . . . . . . 31 6.1.1. Simple Tunnels that are Aware of Quick-
6.3. Protection against Misbehaving Nodes . . . . . . . . . . 33 Start. . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.3.1. Receivers Lying about Whether the 6.2. Simple Tunnels That Are Not Compatible with
Request was Approved . . . . . . . . . . . . . . . . . . . 33 Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.3.2. Receivers Lying about the Approved 6.3. Tunnels That Support Quick-Start . . . . . . . . . . . . 35
Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7. The Quick-Start Mechanism in other Transport Pro-
6.3.3. Collusion between Misbehaving Routers . . . . . . . 35 tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.3.4. Misbehaving Middleboxes and the IP 8. Using Quick-Start . . . . . . . . . . . . . . . . . . . . . . 37
TTL. . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 8.1. Determining the Rate to Request. . . . . . . . . . . . . 37
6.4. Quick-Start with QoS-enabled Traffic . . . . . . . . . . 36 8.2. Deciding the Permitted Rate Request at a
6.5. Limitations of Quick-Start . . . . . . . . . . . . . . . 36 Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.6. Attacks on Quick-Start . . . . . . . . . . . . . . . . . 37 9. Evaluation of Quick-Start . . . . . . . . . . . . . . . . . . 38
6.7. Simulations with Quick-Start . . . . . . . . . . . . . . 37 9.1. Benefits of Quick-Start. . . . . . . . . . . . . . . . . 39
7. Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 38 9.2. Costs of Quick-Start . . . . . . . . . . . . . . . . . . 39
7.1. Fast Start-ups without Explicit Information 9.3. Quick-Start with QoS-enabled Traffic . . . . . . . . . . 41
from Routers. . . . . . . . . . . . . . . . . . . . . . . . . 38 9.4. Protection against Misbehaving Nodes . . . . . . . . . . 41
7.2. Optimistic Sending without Explicit Informa- 9.4.1. Receivers Lying about Whether the
tion from Routers . . . . . . . . . . . . . . . . . . . . . . 39 Request was Approved . . . . . . . . . . . . . . . . . . . 41
7.3. Fast Start-ups with other Information from 9.4.2. Receivers Lying about the Approved
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.4. Fast Start-ups with more Fine-Grained Feed- 9.4.3. Collusion between Misbehaving Routers . . . . . . . 43
back from Routers . . . . . . . . . . . . . . . . . . . . . . 41 9.4.4. Misbehaving Middleboxes and the IP
8. Implementation and Deployment Issues. . . . . . . . . . . . . 41 TTL. . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
8.1. Implementation Issues for Sending Quick- 9.5. Attacks on Quick-Start . . . . . . . . . . . . . . . . . 45
Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 42 9.6. Simulations with Quick-Start . . . . . . . . . . . . . . 45
8.2. Implementation Issues for Processing Quick- 10. Implementation and Deployment Issues . . . . . . . . . . . . 46
Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 42 10.1. Implementation Issues for Sending Quick-
8.3. Possible Deployment Scenarios. . . . . . . . . . . . . . 43 Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 46
8.4. Would QuickStart packets take the slow path 10.2. Implementation Issues for Processing Quick-
in routers? . . . . . . . . . . . . . . . . . . . . . . . . . 44 Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 47
8.5. A Comparison with the Deployment Problems of 10.3. Possible Deployment Scenarios . . . . . . . . . . . . . 47
ECN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 10.4. Would QuickStart packets take the slow path
9. Security Considerations . . . . . . . . . . . . . . . . . . . 44 in routers? . . . . . . . . . . . . . . . . . . . . . . . . . 48
10. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . 45 10.5. A Comparison with the Deployment Problems
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 of ECN. . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
A. Design Decisions. . . . . . . . . . . . . . . . . . . . . . . 45 11. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 49
11.1. Fast Start-ups without Explicit Information
from Routers. . . . . . . . . . . . . . . . . . . . . . . . . 49
11.2. Optimistic Sending without Explicit Infor-
mation from Routers . . . . . . . . . . . . . . . . . . . . . 50
11.3. Fast Start-ups with other Information from
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
11.4. Fast Start-ups with more Fine-Grained Feed-
back from Routers . . . . . . . . . . . . . . . . . . . . . . 52
12. Security Considerations. . . . . . . . . . . . . . . . . . . 52
13. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . 53
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54
A. Design Decisions. . . . . . . . . . . . . . . . . . . . . . . 54
A.1. Alternate Mechanisms for the Quick-Start A.1. Alternate Mechanisms for the Quick-Start
Request: ICMP and RSVP. . . . . . . . . . . . . . . . . . . . 45 Request: ICMP and RSVP. . . . . . . . . . . . . . . . . . . . 54
A.1.1. ICMP. . . . . . . . . . . . . . . . . . . . . . . . 46 A.1.1. ICMP. . . . . . . . . . . . . . . . . . . . . . . . 54
A.1.2. RSVP. . . . . . . . . . . . . . . . . . . . . . . . 47 A.1.2. RSVP. . . . . . . . . . . . . . . . . . . . . . . . 56
A.2. Alternate Encoding Functions . . . . . . . . . . . . . . 48 A.2. Alternate Encoding Functions . . . . . . . . . . . . . . 57
A.3. The Quick-Start Request: Packets or Bytes? . . . . . . . 49 A.3. The Quick-Start Request: Packets or Bytes? . . . . . . . 58
A.4. Quick-Start Semantics: Total Rate or Addi- A.4. Quick-Start Semantics: Total Rate or Addi-
tional Rate?. . . . . . . . . . . . . . . . . . . . . . . . . 50 tional Rate?. . . . . . . . . . . . . . . . . . . . . . . . . 59
A.5. Alternate Responses to the Loss of a Quick- A.5. Alternate Responses to the Loss of a Quick-
Start Packet. . . . . . . . . . . . . . . . . . . . . . . . . 51 Start Packet. . . . . . . . . . . . . . . . . . . . . . . . . 60
A.6. Why Not Include More Functionality?. . . . . . . . . . . 52 A.6. Why Not Include More Functionality?. . . . . . . . . . . 61
A.7. The Earlier QuickStart Nonce . . . . . . . . . . . . . . 55 A.7. The Earlier QuickStart Nonce . . . . . . . . . . . . . . 64
B. Quick-Start with DCCP . . . . . . . . . . . . . . . . . . . . 56 B. Quick-Start with DCCP . . . . . . . . . . . . . . . . . . . . 65
C. Possible Router Algorithm . . . . . . . . . . . . . . . . . . 58 C. Possible Router Algorithm . . . . . . . . . . . . . . . . . . 67
Normative References . . . . . . . . . . . . . . . . . . . . . . 60 D. Possible Uses for the Reserved Fields . . . . . . . . . . . . 68
Informative References . . . . . . . . . . . . . . . . . . . . . 60 Normative References . . . . . . . . . . . . . . . . . . . . . . 70
IANA Considerations. . . . . . . . . . . . . . . . . . . . . . . 63 Informative References . . . . . . . . . . . . . . . . . . . . . 70
IP Option. . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 E. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74
TCP Option . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 E.1. IP Option. . . . . . . . . . . . . . . . . . . . . . . . 74
AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 64 E.2. TCP Option . . . . . . . . . . . . . . . . . . . . . . . 75
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 64 AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 75
Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 65 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 75
Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 76
1. Introduction 1. Introduction
Each TCP connection begins with a question: "What is the appropriate Each TCP connection begins with a question: "What is the appropriate
sending rate for the current network path?" The question is not sending rate for the current network path?" The question is not
answered explicitly for TCP, but each TCP connection determines the answered explicitly for TCP, but each TCP connection determines the
sending rate by probing the network path and altering the congestion sending rate by probing the network path and altering the congestion
window (cwnd) based on perceived congestion. Each connection starts window (cwnd) based on perceived congestion. Each connection starts
with a pre-configured initial congestion window (ICW). Currently, with a pre-configured initial congestion window (ICW). Currently,
TCP allows an initial window of between one and four MSS-sized TCP allows an initial window of between one and four MSS-sized
skipping to change at page 8, line 32 skipping to change at page 10, line 32
Assumptions: Assumptions:
* The data transfer in the two directions of a connection traverses * The data transfer in the two directions of a connection traverses
different queues, and possibly even different routers. Thus, any different queues, and possibly even different routers. Thus, any
mechanism for determining the allowed sending rate would have to be mechanism for determining the allowed sending rate would have to be
used independently for each direction. used independently for each direction.
* 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. shows this assumption should be generally valid, although [RFC3819]
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.
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
skipping to change at page 9, line 12 skipping to change at page 11, line 12
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.
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.
Open 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 6 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, This does not preclude using Quick-Start in Intranets. Further,
[MAF04] also shows that over time the blocking of packets [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. Appendix A.1 on "Alternate Mechanisms for the Quick-
Start Request" discusses the possibility of using RSVP or ICMP Start Request" discusses the possibility of using RSVP or ICMP
instead of IP Options for carrying Quick-Start Requests to routers. instead of IP Options for carrying Quick-Start Requests to routers.
* A second practical consideration is that packets could be dropped * A second practical consideration is that packets could be dropped
at non-IP queues along the path. at non-IP queues along the path.
This is discussed in more detail in Section 6.2. * Apart from the This is discussed in more detail in Section 9.2 .
merits and shortcomings of the Quick-Start mechanism, is there
likely to be a compelling need to add explicit congestion-related * Apart from the merits and shortcomings of the Quick-Start
feedback from routers over and above the one-bit feedback from ECN? mechanism, is there likely to be a compelling need to add explicit
congestion-related feedback from routers over and above the one-bit
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
skipping to change at page 12, line 42 skipping to change at page 15, line 6
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 Request in IP
3.1. The Quick-Start Request Option for IPv4 3.1. The Quick-Start Request 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
| Option | Length=4 | QS TTL |Resv. |Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option | Length=8 | QS TTL | Resv. | Rate |
| | | | |Request| | | | | |Request|
+--------------+--------------+--------------+--------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QS Nonce | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. The Quick-Start Request Option for IPv4. Figure 3. The Quick-Start Request Option for IPv4.
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 four bytes. length of eight bytes.
The third byte contains the Quick-Start TTL (QS TTL) field. The The third byte contains the Quick-Start TTL (QS TTL) field. The
sender MUST set the QS TTL field to a random value. Routers that sender MUST set the QS TTL field to a random value. Routers that
approve the Quick-Start Request decrement the QS TTL (mod 256). The approve the Quick-Start Request decrement the QS TTL (mod 256). The
QS TTL is used by the sender to detect if all of the routers along QS TTL is used by the sender to detect if all of the routers along
the path understood and approved the Quick-Start option. the path understood and approved the Quick-Start option.
The transport sender MUST calculate and store the TTL Diff, the The transport sender MUST calculate and store the TTL Diff, the
difference between the IP TTL value and the QS TTL value in the difference between the IP TTL value and the QS TTL value in the
Quick-Start request packet, as follows: 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 The fourth byte includes a four-bit Reserved field, and a four-bit
Rate Request field. The sender initializes the Rate Request to the Rate Request field. The second four bytes contain a 30-bit QS Nonce
desired sending rate, including an estimate of the transport and IP and a two-bit Reserved field. The sender SHOULD set the reserved
header overhead. fields to zero, and routers SHOULD ignore the reserved fields. The
sender SHOULD set the 30-bit QS Nonce to a random value.
The encoding function for the Rate Request sets the request rate to The sender initializes the Rate Request to the desired sending rate,
K*2^N bps, for N the value in the Rate Request field, and for K set including an estimate of the transport and IP header overhead. The
to 40,000. For N=0, the rate request would be set to zero, encoding function for the Rate Request sets the request rate to
regardless of the encoding function. This is illustrated in Table 1 K*2^N bps (bits per second), for N the value in the Rate Request
below. For the four-bit Rate Request field, the request range is field, and for K set to 40,000. For N=0, the rate request would be
from 80 Kbps to 1.3 Gbps. Alternate encodings that were considered set to zero, regardless of the encoding function. This is
for the Rate Request are given in Appendix A.2. 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
that were considered for the Rate Request are given in Appendix A.2.
N Rate Request (in Kbps) N Rate Request (in Kbps)
--- ------------------- --- -------------------
0 0 0 0
1 80 1 80
2 160 2 160
3 320 3 320
4 640 4 640
5 1,280 5 1,280
6 2,560 6 2,560
7 5,120 7 5,120
8 10,240 8 10,240
9 20,480 9 20,480
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 the Rate Request field to the 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.
We note that unlike a Quick-Start Request sent at the beginning of a We note that unlike a Quick-Start Request sent at the beginning of a
connection, when a Quick-Start Request is sent in the middle of a connection, when a Quick-Start Request is sent in the middle of a
connection, the connection could already have an established connection, the connection could already have an established
congestion window or sending rate. The Rate Request is the congestion window or sending rate. The Rate Request is the
requested total rate for the connection, including the current rate requested total rate for the connection, including the current rate
of the connection; the Rate Request is *not* a request for an of the connection; the Rate Request is *not* a request for an
skipping to change at page 15, line 4 skipping to change at page 17, line 4
In IPv4, a change in IP options at routers requires recalculating In IPv4, a change in IP options at routers requires recalculating
the IP header checksum. the IP header checksum.
3.2. The Quick-Start Request Option for IPv6 3.2. The Quick-Start Request Option for IPv6
The Quick-Start Request Option for IPv6 is placed in the Hop-by-Hop The Quick-Start Request Option for IPv6 is placed in the Hop-by-Hop
Options extension header that is processed at every network node Options extension header that is processed at every network node
along the communication path [RFC 2460]. The option format following along the communication path [RFC 2460]. The option format following
the generic Hop-by-Hop Options header is similar to the IPv4 format the generic Hop-by-Hop Options header is similar 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 2. type and length fields in the option format and be set to 6 bytes.
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
| Option | Length=2 | QS TTL |Resv. |Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option | Length=6 | QS TTL | Resv. | Rate |
| | | | |Request| | | | | |Request|
+--------------+--------------+--------------+--------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QS Nonce | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. The Quick-Start Request Option for IPv6. Figure 4. The Quick-Start Request Option for IPv6.
The transport receiver compares the Quick-Start TTL with the IPv6 The transport receiver compares the Quick-Start TTL with the IPv6
Hop Limit field in order to calculate the TTL Diff. (The Hop Limit Hop Limit field in order to calculate the TTL Diff. (The Hop Limit
in IPv6 is the equivalent of the TTL in IPv4.) That is, TTL Diff in IPv6 is the equivalent of the TTL in IPv4.) That is, TTL Diff
MUST be calculated and stored as follows: 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 Request IPv6
Option does not require checksum re-calculation, because the IPv6 Option does not require checksum re-calculation, because the IPv6
header does not have a checksum field, and modifying the Quick-Start header does not have a checksum field, and modifying the Quick-Start
Request in the IPv6 Hop-by-Hop options header does not affect the Request in the IPv6 Hop-by-Hop options header does not affect the
IPv6 pseudo-header checksum used in upper-layer checksum IPv6 pseudo-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. This requirement would contents throughout the IP flow lifetime. However, the Quick-Start
have to be modified to implement Quick-Start on an IPv6
implementation that uses flow labels, because the Quick-Start
Request option would be included in only a small fraction of the Request option would be included in only a small fraction of the
packets during a flow lifetime. packets during a flow lifetime. Thus, Quick-Start SHOULD NOT be
used in an IPv6 connection that uses flow labels unless the
experimental specification of flow labels in Appendix A of RFC 2460
is changed. We note that RFC 2460 states that the use of the flow
label field in IPv6 "is, at the time of writing, still experimental
and subject to change as the requirements for flow support in the
Internet become clearer" [RFC2460].
3.3. Processing the Quick-Start Request at Routers 3.3. Processing the Quick-Start Request at Routers
Each participating router can either terminate or approve the Quick- Each participating router can either terminate or approve the Quick-
Start Request. The router terminates the Quick-Start Request if the Start Request. The router terminates the Quick-Start Request if the
router is not underutilized, and therefore has decided not to grant router is not underutilized, and therefore has decided not to grant
the Quick-Start Request. 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 and the Rate Request fields. This may be SHOULD zero the QS TTL, QS Nonce, and Rate Request fields. This may
more efficient for routers to implement than deleting the Quick- be more efficient for routers to implement than deleting the Quick-
Start option. A router that doesn't understand the Quick-Start Start option. A router that doesn't understand the Quick-Start
option will of course simply forward the packet with the Quick-Start option will simply forward the packet with the Quick-Start Request
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 decrements the QS TTL by one. * The router MUST decrement the QS TTL by one.
* If the router is only willing to approve an 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. Request in the Quick-Start Request. If the router decreases the
Rate Request, the router MUST also modify the QS Nonce, as described
in Section 3.4.
* In IPv4, the router MUST update the IP header checksum. * In IPv4, the router MUST update the IP header checksum.
A non-participating router forwards the Quick-Start Request A non-participating router forwards the Quick-Start Request
unchanged, without decrementing the QS TTL. Of course, the non- unchanged, without decrementing the QS TTL. The non-participating
participating router still decrements the TTL field in the IP router still decrements the TTL field in the IP header, as is
header, as is required for all routers [RFC1812]. As a result, the required for all routers [RFC1812]. As a result, the sender will be
sender will be able to detect that the Quick-Start Request had not able to detect that the Quick-Start Request had not been understood
been understood or approved by all of the routers along the path. or approved by all of the routers along the path.
A router that modifies or deletes the Quick-Start Request in the
IPv4 header also MUST update the IPv4 Header checksum. For IPv6, no
checksum updates are needed.
3.4. Deciding the Permitted Rate Request at a Router
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
could ask the following questions:
* Has the router's output link been underutilized for some time
(e.g., several seconds).
* Would the output link remain underutilized if the arrival rate was
to increase by the aggregate rate requests that the router has
approved over the last fraction of a second?
In order to answer this question, the router must have some
knowledge of the available bandwidth on the output link and of the
Quick-Start bandwidth that could arrive due to recently-approved
Quick-Start Requests. In this way, if an underutilized router
experiences a flood of Quick-Start requests, the router can begin to
deny Quick-Start requests while the output link is still
underutilized.
A simple way for the router to keep track of the potential bandwidth
from recently-approved requests is to maintain two counters, one for
the total aggregate Rate Requests that have been approved in the
current time interval [T1, T2], for the current time between T1 and
T2, and one for the total aggregate Rate Requests approved over a
previous time interval [T0, T1]. However, this document doesn't
specify router algorithms for approving Quick-Start requests, or
make requirements for the appropriate time intervals for remembering
the aggregate approved Quick-Start bandwidth. A possible router
algorithm is given in Appendix C, and more discussion of these
issues is available in [SAF05].)
* If the router's output link has been underutilized and the
aggregate Quick Start Request Rate options granted is low enough to
prevent a near-term bandwidth shortage, then the router could
approve the Quick-Start Request.
Section 8.2 discusses some of the implementation issues in
processing Quick-Start requests at routers. [SAF05] discusses the
range of possible Quick-Start algorithms at the router for deciding
whether to approve a Quick-Start request. In order to explore the
limits of the possible functionality at routers, [SAF05] also
discusses Extreme Quick-Start mechanisms at routers, where the
router would keep per-flow state concerning approved Quick-Start
requests.
3.5. Quick-Start in IP Tunnels
In this section we consider the effect of IP tunnels on Quick-Start.
In the discussion, we use TTL Diff, defined earlier as the
difference between the IP TTL and the Quick-Start TTL, mod 256.
Recall that the sender considers the Quick-Start request approved if
the value of TTL Diff for the packet entering the network is the
same as the value of TTL Diff for the packet exiting the network.
There are two legitimate ways for handling the Quick-Start Request
with IP tunnels:
(1) The tunnel ingress node does not support Quick-Start, or does 3.4. The QS Nonce
not approve the Quick-Start request. The node could strip the Quick-
Start Request option from the IP header before encapsulation.
Alternately, the ingress node can decrement the IP TTL before
encapsulation, while leaving the Quick-Start TTL unchanged, thereby
changing TTL Diff. This is the assumed behavior of current IP
tunnels that are not aware of Quick-Start.
For a tunnel ingress node that does not support Quick-Start, The QS Nonce gives the Quick-Start sender some protection against
problems with a Quick-Start Request could still occur if a tunnel receivers lying about the value of the received Rate Request. This
discards the outer header at egress and does not decrement the inner is particularly important if the receiver knows the original value
IP TTL at the ingress. In this case, if both the inner IP TTL and of the Rate Request (e.g., when the sender always requests the same
the Quick-Start TTL are decremented after decapsulation at a Quick- value, and the receiver has a long history of communication with
Start-aware egress, or if neither is decremented at the egress, then that sender.) Without the QS Nonce, there is nothing to prevent the
TTL Diff would be the same after egress as it was before ingress, so receiver from reporting back to the sender a Rate Request of K, when
that it would wrongly appear that all the routers in the tunnel had the received Rate Request was in fact less than K. This version of
approved the Quick-Start request. Fortunately, we are not aware of the nonce is based on a proposal from Guohan Lu [L05]. Initial
tunnel technologies that operate this way; to the best of our versions of this document contained an eight-bit QS Nonce, and
knowledge, all tunnels decrement the IP TTL either at the ingress subsequent versions discussed the possibility of a four-bit QS
before encapsulation, or at the egress router after decapsulation, Nonce.
thus changing TTL Diff.
Even the extreme case when the tunnel ingress is at the TCP sender Table 2 gives the format for the 30-bit QS Nonce.
and the tunnel egress is at the TCP receiver, our assumption is that
the IP TTL will be decremented either at the tunnel ingress or at
the tunnel egress, changing TTL Diff and preventing the end-nodes
from wrongly inferring that the Quick-Start Request was approved by
all of the routers along the path. If there are tunnels where the
IP TTL in not decremented, perhaps for PPP over SSH, then additional
attention will have to be paid to the robustness of Quick-Start in
these environments.
A Quick-Start-aware egress must also make sure that the Quick-Start Bits Purpose
Request is not approved if for some reason the inner header includes --------- ------------------
the Quick-Start Request option, the outer header does not, and the Bits 0-1: Rate 15 -> Rate 14
Quick-Start TTL and IP TTL have been decremented in a fashion that Bits 2-3: Rate 14 -> Rate 13
makes it appear as if the request has been approved. If the Quick- Bits 4-5: Rate 13 -> Rate 12
Start Request doesn't appear in the outer header, then the egress Bits 6-7: Rate 12 -> Rate 11
node should remove the Quick-Start Request option from the inner Bits 8-9: Rate 11 -> Rate 10
header after decapsulation. Alternately, the egress node could Bits 10-11: Rate 10 -> Rate 9
decrement the Rate Request in the Quick-Start Request option to Bits 12-13: Rate 9 -> Rate 8
zero. Bits 14-15: Rate 8 -> Rate 7
Bits 16-17: Rate 7 -> Rate 6
Bits 18-19: Rate 6 -> Rate 5
Bits 20-21: Rate 5 -> Rate 4
Bits 22-23: Rate 4 -> Rate 3
Bits 24-25: Rate 3 -> Rate 2
Bits 26-27: Rate 2 -> Rate 1
Bits 28-29: Rate 1 -> Rate 0
(2) The tunnel ingress node may choose to support Quick-Start, and Table 2: The QS Nonce.
locally approve the Quick-Start Request. In this case the IP TTL
and Quick-Start option MUST be copied from the inner IP header to
the outer header at the tunnel ingress. Upon decapsulation, the IP
TTL and the Quick-Start option in the outer IP header MUST be copied
back to the inner header. If the ingress router decrements the IP
TTL in the inner header before encapsulation, or in the outer header
after encapsulation, then if the ingress router wishes to approve
the Quick-Start request, it MUST decrement the Quick-Start TTL at
the same time, so as not to change TTL Diff. Similarly, if the
egress router wishes to approve the Quick-Start request, then when
it decrements the IP TTL in the outer header before decapsulation,
or in the inner header after decapsulation, it MUST decrement the
Quick-Start TTL at the same time.
A tunnel ingress node can support a Quick-Start request without The transport sender MUST initialize the QS Nonce to a random value.
explicitly verifying that the tunnel egress also supports Quick- If the router reduces the Rate Request from rate K to rate K-1, then
Start. All that the ingress node has to do is to decrement the IP the router MUST set the field in the QS Nonce for "Rate K -> Rate
TTL, but not the Quick-Start TTL, in the inner header after K-1" to a new random value. Similarly, if the router reduces the
encapsulation. In this case, if the egress node simply discards the Rate Request by N steps, the router MUST set the 2N bits in the
outer header at the egress point, TTL Diff will be different after relevant fields in the QS Nonce to a new random value. The receiver
the tunnel egress than it was at the tunnel ingress, and the Quick- MUST report the QS Nonce back to the sender.
Start will not be considered by the end-nodes as having been
approved in the network. Thus, the tunnel ingress node on its own
can provide protection against egress nodes that might discard the
outer header at the egress point.
3.6. A Rate-Reduced Nonce? If the Rate Request was not decremented in the network, then the QS
Nonce should have its original value. Similarly, if the Rate
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
Nonce should have their original value.
One possibility for the Reserved Field, for further investigation, With the QS Nonce, the receiver has a 1/4 chance of cheating about
is to use the four bits for a four-bit Rate-Reduced Nonce. The goal each step change in the rate request. Thus, if the rate request was
of the Rate-Reduced Nonce would be to give the Quick-Start sender reduced by two steps in the network, the receiver has a 1/16 chance
some protection against receivers lying about the value of the of successfully reporting that the original request was approved, as
received Rate Request. The Rate-Reduced Nonce would be initialized this requires reporting the original value for the QS nonce.
by the sender to a random value. When a router approves the Quick- Similarly, if the rate request is reduced many steps in the network,
Start request but reduces the Rate Request field, the router resets and the receiver receives a QS Option with a rate request of K, the
the Rate-Reduced Nonce to a new random value. When a Quick-Start- receiver has a 1/16 chance of guessing the original values for the
capable router denies the Quick-Start request, the router either fields in the QS nonce for "Rate K+2 -> Rate K+1" and "Rate K+1 ->
deletes the Quick-Start Option, or zeroes the Rate-Reduced Nonce Rate K". Thus, the receiver has a 1/16 chance in successfully lying
when zeroing the Rate Request and the QS TTL. The receiver reports and saying that the received rate request was K+2 instead of K.
the value of the Rate-Reduced Nonce back to the sender.
The Rate-Reduced Nonce would be of use in cases where the receiver We note that the protection offered by the QS Nonce is the same
knows the original Rate Request R sent by the sender (e.g., because whether one router makes all of the decrements in the rate request,
the sender always uses the same Rate Request), but the Rate Request or whether they are made at different routers along the path.
has been decremented by routers along the path. What prevents the
receiver from reporting back to the sender a Rate Request of R, when
the received Rate Request was in fact less than R? If the Rate
Request was not decremented in the network, then the Rate-Reduced
Nonce should have its original value. If the Rate Request *was*
decremented in the network, then the probability that the Rate-
Reduced Nonce still has its original value is 1/16. Similarly, if
the Rate Request was decremented in the network, the chance that the
receiver can guess the original value of the Rate-Reduced Nonce is
1/16.
Thus, if the receiver reports back to the sender the original values The requirements for randomization for the sender and routers in
for the Rate Request and the Rate-Reduced Nonce, and the correct setting `random' values in the QS Nonce are not stringent - almost
value for the TTL Diff, then it is likely that the Quick-Start any form of pseudo-random numbers would do. The requirement from
Request was in fact approved at its original value by the routers the sender is that the original value for the QS Nonce is not easily
along the path, in particular by all of the Quick-Start-capable guessable by the receiver. Thus, if two bits of the QS Nonce are
routers. The Rate-Reduced Nonce would make it more difficult for changed by a router along the path, the receiver should not be able
the receiver to report that the Rate Request was received at its to guess those two bits from the other 28 bits in the QS Nonce.
original value, when in fact the received Rate Request was less than
its original value.
We note, however, that the Rate-Reduced Nonce doesn't provide A requirement of the routers is that the receiver can not be able to
protection against receivers reporting that the Rate Request was tell, from the QS Nonce itself, which numbers in the QS Nonce were
decremented by only one step, when it fact it was decremented by generated by the sender, and which were generated by routers along
many steps in the network. This, if the receiver knows the original the path. This makes it harder for the receiver to infer the value
Rate Request from the sender, and the received rate request is of the original rate request, making it one step harder for the
considerably less than the original request, then the receiver could receiver to cheat.
report a received rate request just one step smaller than the
original request, and the Rate-Reduced Nonce wouldn't provide any
protection against this.
Section 6.3 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 Request option in the IP
header of the TCP packet, called the Quick-Start request packet. header of the TCP packet, called the Quick-Start request packet.
(We will be somewhat loose in our use of "packet" vs. "segment" in (We will be somewhat loose in our use of "packet" vs. "segment" in
this section.) When used for initial start-up, the Quick-Start this section.) The Quick-Start Request also includes random values
request packet can be either the SYN or SYN/ACK packet, as described for the QS TTL and the QS Nonce. When used for initial start-up,
above. The requested rate includes an estimate for the transport the Quick-Start request packet can be either the SYN or SYN/ACK
and IP header overhead. The TCP receiver, say host B, returns the packet, as described above. The requested rate includes an estimate
Quick-Start Response option in the TCP header in the responding for the transport and IP header overhead. The TCP receiver, say
SYN/ACK packet or ACK packet, called the Quick-Start response host B, returns the Quick-Start Response option in the TCP header in
packet, informing host A of the results of their request. the responding SYN/ACK packet or ACK packet, called the Quick-Start
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, then host A MUST assume that its Quick-Start request failed. Diff or the QS Nonce, then host A MUST assume that its Quick-Start
In this case, host A uses TCP's default congestion control request failed. In this case, host A uses TCP's default congestion
procedure. For initial start-up, host A uses the default initial control procedure. For initial start-up, host A uses the default
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 packets are defined as
packets sent as the result of a successful Quick-Start request, up packets sent as the result of a successful Quick-Start request, up
to the time when the first Quick-Start packet is acknowledged. In to the time when the first Quick-Start packet is acknowledged. In
order to use Quick-Start, the TCP host MUST use rate-based pacing to order to use Quick-Start, the TCP host MUST use rate-based pacing 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
skipping to change at page 21, line 38 skipping to change at page 21, line 43
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 connection initiation when the transport has no idea of (1) At or soon after connection initiation, when the transport
the capacity of the network, as discussed above. (A transport has no idea of the capacity of the network, as discussed above.
that uses TCP Control Block sharing, the Congestion Manager, or (A transport that uses TCP Control Block sharing, the Congestion
the like may not need Quick-Start to determine an appropriate Manager, or the like may not need Quick-Start to determine an
rate.) appropriate rate.)
(2) After an idle period when the transport no longer has a (2) After an idle period when the transport no longer has a
validated estimate of the available bandwidth for this flow. validated estimate of the available bandwidth for this flow.
(An example could be a persistent-HTTP connection when a new (An example could be a persistent-HTTP connection when a new
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 for
the appropriate rate at which to send. (Alternatively, the appropriate rate at which to send. (Alternatively,
skipping to change at page 22, line 27 skipping to change at page 22, line 32
(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 assess the available capacity on the network path. 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 Rate Request.
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
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
circumstances, the sender MUST NOT make a QS request if it has made
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
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
| Kind | Length=4 | Rate | TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Request | Diff | | Kind | Length=8 | Resv. | Rate | TTL Diff |
+----------+----------+----------+----------+ | | | |Request| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QS Nonce | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. The Quick-Start Response option in the TCP header. Figure 6. 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 the The third byte of the Quick-Start Response option contains a four-
allowed Rate Request, formatted as in the Quick-Start Request bit Reserved field, and the four-bit allowed Rate Request, formatted
option. as in the Quick-Start Request 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
and a two-bit Reserved field.
We note that the Quick-Start Response Option for TCP contains eight
bytes, and the length of the TCP option field is generally at most
40 bytes. Other TCP options that might be used include Time Stamp
(ten bytes), Window Scale (three bytes), Maximum Segment Size (four
bytes), Selective Acknowledgments Data (at least ten bytes), and
Selective Acknowledgments Permitted (two bytes).
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 Request option, or to a lower value if
the TCP receiver is only willing to allow a lower Rate Request. The the TCP receiver is only willing to allow a lower Rate Request. The
TTL Diff in the Quick-Start Response is set to the difference TTL Diff in the Quick-Start Response is set to the difference
between the IP TTL value and the QS TTL value as given in equation between the IP TTL value and the QS TTL value as given in equation
(1) or (2) (depending on whether IPv4 or IPv6 is used). (1) or (2) (depending on whether IPv4 or IPv6 is used). The QS
Nonce in the Response is set to the received value of the QS Nonce
in the Quick-Start Request 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. If this check is not successful, then the the Quick-Start Request. In addition, if the received Rate Request
Quick-Start request failed, and the TCP host MUST use the default is K, then the the rightmost 2K bits of the QS Nonce must match
TCP congestion window that it would have used without Quick-Start. those bits in the QS Nonce sent in the Quick-Start Request. If
these checks are not successful, then the Quick-Start request
failed, and the TCP host MUST use the default TCP congestion window
that it would have used without Quick-Start.
If the checks of the TTL Diff and the Rate Request are successful, If the checks of the TTL Diff and the Rate Request are successful,
then the TCP host sets its Quick-Start congestion window (in terms then the TCP host sets its Quick-Start congestion window (in terms
of MSS-sized segments), QS-cwnd, as follows: of MSS-sized segments), QS-cwnd, as follows:
QS-cwnd = (R * T) / (MSS + H) (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).
Derivation: the sender is allowed to transmit at R bytes per second Derivation: the sender is allowed to transmit at R bytes per second
including packet headers, but only R*MSS/(MSS+H) bytes per second, including packet headers, but only R*MSS/(MSS+H) bytes per second,
or equivalently R*T*MSS/(MSS+H) bytes per round-trip time, of or equivalently R*T*MSS/(MSS+H) bytes per round-trip time, of
application data. application data.
The TCP host SHOULD set its congestion window cwnd to QS-cwnd only The TCP host SHOULD set its congestion window cwnd to QS-cwnd only
if QS-cwnd is greater than cwnd; otherwise QS-cwnd is ignored. If if QS-cwnd is greater than cwnd; otherwise QS-cwnd is ignored. When
QS-cwnd is used, the TCP host sets a flag that it is in Quick-Start Quick-Start is used at the beginning of a connection, before any
mode, and while in Quick-Start mode the TCP sender MUST use rate- packet marks or losses have been reported, the TCP host MAY use the
based pacing to pace out Quick-Start packets at the specified Rate reported Rate Request to set the slow-start threshold to a desired
Request. Quick-Start mode ends when the TCP host receives an ACK value, e.g., to some small multiple of the congestion window. (The
for one of the Quick-Start packets. initial value of ssthresh is allowed to be arbitrarily high, and
some TCP implementations use the size of the advertised window for
ssthresh [RFC2581].)
If QS-cwnd is used, the TCP host sets a flag that it is in Quick-
Start mode, and while in Quick-Start mode the TCP sender MUST use
rate-based pacing to pace out Quick-Start packets at the specified
Rate Request. If, during Quick-Start mode, the TCP sender receives
ACKs for packets sent before this Quick-Start mode was entered,
these ACKs are processed as usual, following the default congestion
control mechanisms. Quick-Start mode ends when the TCP host
receives an ACK for one of the Quick-Start packets.
If the congestion window has not been fully used when the first ack If the congestion window has not been fully used when the first ack
arrives ending the Quick-Start mode, then the congestion window is arrives ending the Quick-Start mode, then the congestion window is
decreased to the amount that has actually been used so far. This decreased to the amount that has actually been used so far. This is
addresses the problem of an overly-large congestion window from an necessary because when the Quick-Start Response is received, the TCP
overly-large measurement of the round-trip time. sender's round-trip-time estimate might be longer than for
succeeding round-trip times, e.g., because of delays at routers
processing the IP QuickStart option, or because of delays at the
receiver in responding to the Quick-Start Request packet. In this
case, an overly-large round-trip-time estimate could have caused the
TCP sender to translate the approved Quick-Start sending rate in
bytes per second into a congestion window that is larger than
needed, with the TCP sender receiving an ACK for the first Quick-
Start packet before the entire congestion window has been used.
Thus, when the TCP sender receives the first ACK for a Quick-Start
packet, the sender reduces its congestion window to the amount that
has actually been used.
If the Quick-Start mode ends with all Quick-Start packets being As an example, a TCP sender with an approved Quick-Start request of
successfully acknowledged, the TCP sender returns to using the R KBps, B-byte packets including headers, and an RTT estimate of T
default congestion control mechanisms. After all the packets are seconds, would translate the Rate Request of R KBps to a congestion
acknowledged from a Quick-Start request for an initial window, for window of R*T/B packets. The TCP sender would send the Quick-Start
example, the TCP sender remains in slow-start, if permitted by packets rate-paced at R KBps. However, if the actual current round-
ssthresh, continuing to increase its congestion window rather trip time was T/2 seconds instead of T seconds, then the sender
aggressively from one round-trip time to the next. To add would begin to receive acknowledgements for Quick-Start packets
robustness, the TCP sender MUST use Limited Slow-Start [RFC3742] after T/2 seconds. Following the paragraph above, the TCP sender
along with Quick-Start. With Limited Slow-Start, the TCP sender would then reduce its congestion window from R*T/B to R*T/(B*2)
limits the number of packets by which the congestion window is packets, the actual number of packets that were needed to fill the
increased for one window of data during slow-start. pipe at a sending rate of R KBps.
After Quick-Start mode is exited and the congestion window adjusted
if necessary, the TCP sender returns to using the default congestion
control mechanisms, processing further incoming ACK packets as
specified by those congestion control mechanisms. For example, if
the TCP sender was in slow-start prior to the Quick-Start request,
and no packets were lost or marked since that time, then the sender
continues in slow-start after exiting Quick-Start mode, as allowed
by ssthresh.
To add robustness, the TCP sender MUST use Limited Slow-Start
[RFC3742] along with Quick-Start. With Limited Slow-Start, the TCP
sender limits the number of packets by which the congestion window
is increased for one window of data during slow-start.
4.5. TCP: Responding to a Loss of a Quick-Start Packet 4.5. TCP: Responding to a Loss of a Quick-Start Packet
For TCP, we have defined a ``Quick-Start packet'' as one of the For TCP, we have defined a ``Quick-Start packet'' as one of the
packets sent in the window immediately following a successful Quick- packets sent in the window immediately following a successful Quick-
Start request. After detecting the loss of a Quick-Start packet, Start request. After detecting the loss of a Quick-Start packet,
TCP MUST revert to the default congestion control procedures that TCP MUST revert to the default congestion control procedures that
would have been used if the Quick-Start request had not been would have been used if the Quick-Start request had not been
approved. For example, if Quick-Start is used for setting the approved. For example, if Quick-Start is used for setting the
initial window, and a packet from the initial window is lost, then initial window, and a packet from the initial window is lost, then
the TCP sender MUST then slow-start with the default initial window the TCP sender MUST then slow-start with the default initial window
that would have been used if Quick-Start had not been used. In that would have been used if Quick-Start had not been used. In
addition to reverting to the default congestion control mechanisms, addition to reverting to the default congestion control mechanisms,
the sender must take into account that the Quick-Start congestion the sender MUST take into account that the Quick-Start congestion
window was too large. Thus, the sender should decrease ssthresh to window was too large. Thus, the sender SHOULD decrease ssthresh to
at most half the number of Quick-Start packets that were at most half the number of Quick-Start packets that were
successfully transmitted. Section A.5 discusses possible successfully transmitted. Section A.5 discusses possible
alternatives in responding to the loss of a Quick-Start packet. alternatives in responding to the loss of a Quick-Start packet.
We note that ECN [RFC3168] can be used with Quick-Start. As is We note that ECN [RFC3168] MAY be used with Quick-Start. As is
always the case with ECN, the sender's congestion control response always the case with ECN, the sender's congestion control response
to an ECN-marked Quick-Start packet is the same as the response to a to an ECN-marked Quick-Start packet is the same as the response to a
dropped Quick-Start packet, thus reverting to slow start in the case dropped Quick-Start packet, thus reverting to slow start in the case
of Quick-Start packets marked as experiencing congestion. of Quick-Start packets marked as experiencing congestion.
4.6. TCP: A Quick-Start Request for a Larger Initial Window 4.6. TCP: A Quick-Start Request for a Larger Initial Window
Some of the issues of using Quick-Start are related to the specific Some of the issues of using Quick-Start are related to the specific
scenario in which Quick-Start is used. This section discusses the scenario in which Quick-Start is used. This section discusses the
following issues that arise when Quick-Start is used by TCP to following issues that arise when Quick-Start is used by TCP to
request a larger initial window: (1) determining the rate to request a larger initial window: (1) interactions with Path MTU
request; (2) interactions with Path MTU Discovery; and (3) Quick- Discovery (PMTUD); and (2) Quick-Start request packets that are
Start request packets that are discarded by middleboxes. discarded by middleboxes.
4.6.1. Determining the Rate to Request
As discussed in [SAF05], the data sender does not necessarily have
information about the size of the data transfer at connection
initiation; for example, in request-response protocols such as HTTP,
the server doesn't know the size or name of the requested object
during connection initiation. [SAF05] explores some of the
performance implications of overly-large Quick-Start requests, and
discusses heuristics that end-nodes could use to size their requests
appropriately. For example, the sender might have information about
the bandwidth of the last-mile hop, the size of the local socket
buffer, or of the TCP receive window, and could use this information
in determining the rate to request. Web servers that mostly have
small objects to transfer might decide not to use Quick-Start at
all, since Quick-Start would be of little benefit to them.
In the absence of other information, there could be a configured
value for the Quick-Start Rate Request. Quick-Start will be more
effective if Quick-Start requests are not larger than necessary;
every Quick-Start request that is approved but not used (or not
fully used) takes away from the bandwidth pool available for
granting successive Quick-Start requests. Therefore, it is
recommended that the request for the initial sending rate be
somewhat conservative, in order to improve the chances for more
Quick-Start requests to be approved.
4.6.2. Interactions with Path MTU Discovery 4.6.1. Interactions with Path MTU Discovery
A second issue when Quick-Start is used to request a large initial One issue when Quick-Start is used to request a large initial window
window concerns the interactions between the large initial window concerns the interactions between the large initial window and Path
and Path MTU Discovery. Some of the issues are discussed in RFC MTU Discovery. Some of the issues are discussed in RFC 3390:
3390:
"When larger initial windows are implemented along with Path MTU "When larger initial windows are implemented along with Path MTU
Discovery [RFC1191], alternatives are to set the "Don't Discovery [RFC1191], alternatives are to set the "Don't
Fragment" (DF) bit in all segments in the initial window, or to Fragment" (DF) bit in all segments in the initial window, or to
set the "Don't Fragment" (DF) bit in one of the segments. It is set the "Don't Fragment" (DF) bit in one of the segments. It is
an open question as to which of these two alternatives is best." an open question as to which of these two alternatives is best."
Unfortunately, the sender doesn't necessarily know the Path MTU when If the sender knows the Path MTU when the initial window is sent
it sends packets in the initial window. The sender should be (e.g., from a PMTUD cache or from some other IETF-approved method),
conservative in the packet size used. Sending a large number of then the sender should use that MTU for segments in the initial
overly-large packets with the DF bit set is not desirable, but window. Unfortunately, the sender doesn't necessarily know the Path
sending a large number of packets that are fragmented in the network MTU when it sends packets in the initial window. In this case, the
can be equally undesirable. sender should be conservative in the packet size used. Sending a
large number of overly-large packets with the DF bit set is not
desirable, but sending a large number of packets that are fragmented
in the network can be equally undesirable.
One possibility would be for the sender to send one large packet in The sender SHOULD send one large packet in the initial window with
the initial window with the DF bit set, and to send the remaining the DF bit set, and send the remaining packets in the initial window
packets in the initial window with a smaller MTU of 576 bytes (or with a smaller MTU of 576 bytes (or 1280 bytes with IPv6).
1280 bytes with IPv6).
A second possibility would be for the sender to delay sending the A second possibility would be for the sender to delay sending the
Quick-Start Request for one round-trip time, sending the Quick-Start Quick-Start Request for one round-trip time, sending the Quick-Start
Request with the first window of data while also doing Path MTU Request with the first window of data while also doing Path MTU
Discovery. Discovery.
In the future, it might be possible for the TCP SYN packet to do a 4.6.2. Quick-Start Request Packets that are Discarded by Middleboxes
probe about the Path MTU. For example, [W03] has proposed an IP
Option that queries routers for their MTU before starting a Path MTU
Discovery process.
4.6.3. Quick-Start Request Packets that are Discarded by Middleboxes
It is always possible for a TCP SYN packet carrying a Quick-Start It is always possible for a TCP SYN packet carrying a Quick-Start
request to be dropped in the network due to congestion, or to be request to be dropped in the network due to congestion, or to be
blocked due to interactions with middleboxes. Measurement studies blocked due to interactions with middleboxes, where a middlebox is
defined as any intermediary box performing functions apart from
normal, standard functions of an IP router on the data path between
a source host and destination host [RFC3234]. Measurement studies
of interactions between transport protocols and middleboxes [MAF04] of interactions between transport protocols and middleboxes [MAF04]
show that for 70% of the web servers investigated, no connection is show that for 70% of the web servers investigated, no connection is
established if the TCP SYN packet contains an unknown IP option (and established if the TCP SYN packet contains an unknown IP option (and
for 43% of the web servers, no connection is established if the TCP for 43% of the web servers, no connection is established if the TCP
SYN packet contains an IP TimeStamp Option). In both cases, this is SYN packet contains an IP TimeStamp Option). In both cases, this is
presumably due to middleboxes along that path. presumably due to middleboxes along that path.
If the TCP sender doesn't receive a response to the SYN or SYN/ACK If the TCP sender doesn't receive a response to the SYN or SYN/ACK
packet containing the Quick-Start Request, then the TCP sender packet containing the Quick-Start Request, then the TCP sender
SHOULD resend the SYN or SYN/ACK packet without the Quick-Start SHOULD resend the SYN or SYN/ACK packet without the Quick-Start
Request. Similarly, if the TCP sender receives a TCP reset in Request. Similarly, if the TCP sender receives a TCP reset in
response to the SYN or SYN/ACK packet containing the Quick-Start response to the SYN or SYN/ACK packet containing the Quick-Start
Request, then the TCP sender SHOULD resend the SYN or SYN/ACK packet Request, then the TCP sender SHOULD resend the SYN or SYN/ACK packet
without the Quick-Start Request [RFC3360]. without the Quick-Start Request [RFC3360].
While RFC 1122 and 2988 recommend that the sender should set the RFC 1122 and 2988 recommend that the sender should set the initial
initial RTO to three seconds, 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, we RECOMMEND an RTO of one second, so that the sender Start request, the TCP sender SHOULD use an initial RTO of three
can retransmit the SYN packet reasonably promptly if the original seconds.
TCP SYN packet is dropped by a middlebox in the network.
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/ACKs) was transmitted. In this way, an
acknowledgement for the retransmitted SYN or SYN/ACK packet can be acknowledgement for the retransmitted SYN or SYN/ACK packet can be
matched with the SYN or SYN/ACK being acknowledged, and the 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
skipping to change at page 29, line 10 skipping to change at page 29, line 48
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 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 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 example, for TCP, the Quick-Start Request could be carried by a data
packet, or by a pure acknowledgement packet. 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: request Quick-Start for setting their initial windows. This is
similar to Figures 1 and 2 in Section 2.1, except that it
illustrates a TCP connection with both TCP hosts sending Quick-Start
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.
* Routers along the forward path modify the Quick-Start Request as * Routers along the forward path modify the Quick-Start Request as
appropriate. appropriate.
* Host B receives the Quick-Start Request in the SYN packet, and * Host B receives the Quick-Start Request in the SYN packet, and
calculates the TTL Diff. If Host B approves the Quick-Start calculates the TTL Diff. If Host B approves the Quick-Start
Request, then Host B sends a Quick-Start Response in the TCP header Request, then Host B sends a Quick-Start Response in the TCP header
of the SYN/ACK packet. Host B also sends a Quick-Start Request in of the SYN/ACK packet. Host B also sends a Quick-Start Request in
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 and Rate Request for validity. If they are and checks the TTL Diff, Rate Request, and QS Nonce for validity.
valid, then Host A sets its initial congestion window appropriately, If they are valid, then Host A sets its initial congestion window
and sets up rate-based pacing to be used with the initial window. appropriately, and sets up rate-based pacing to be used with the
If the Quick-Start Response is not valid, then Host A uses TCP's initial window. If the Quick-Start Response is not valid, then Host
default initial window. A uses TCP's default initial window.
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 and Rate Request for validity. If the Quick- checks the TTL Diff, Rate Request, and QS Nonce for validity. If
Start Response is valid, then Host B sets its initial congestion the Quick-Start Response is valid, then Host B sets its initial
window appropriately, and sets up rate-based pacing to be used with congestion window appropriately, and sets up rate-based pacing to be
its initial window. If the Quick-Start Response is not valid, then used with its initial window. If the Quick-Start Response is not
Host B uses TCP's default initial window. valid, then Host B uses TCP's default initial window.
5. The Quick-Start Mechanism in other Transport Protocols 5. Quick-Start and IPsec AH
This section shows that Quick-Start is compatible with IPsec AH
(Authentication Header). AH uses an Integrity Check Value (ICV) in
the IPsec Authentication Header to verify both message
authentication and integrity [RFC2402,2402bis]. Changes to 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
tunnels, regardless of what IPsec headers or processing are used in
conjunction with the tunnel.
Because the contents of the Quick-Start Request option can change
along the path, it is important that these changes not affect the
IPsec Authentication Header Integrity Check Value (AH ICV). For
IPv4, RFC 2402 requires that unrecognized IPv4 options be zeroed for
AH ICV computation purposes, so Quick-Start IP Option data changing
en route does not cause problems with existing IPsec AH
implementations for IPv4. If the Quick-Start Request option is
recognized, it MUST be treated as a mutable IPv4 option, and hence
be completely zeroed for AH ICV calculation purposes. IPv6 option
numbers explicitly indicate whether the option is mutable; the 3rd
highest order bit in the IANA-allocated option type has the value 1
to indicate that the Quick-Start Request option data can change en
route. RFC 2402 requires that the option data of any such option be
zeroed for AH ICV computation purposes. Therefore changes to the
Quick-Start option in the IP header do not affect the calculation of
the AH ICV.
6. Quick-Start in IP Tunnels
This section considers interactions between Quick-Start and IP
tunnels, including IPsec [RFC2401,2401bis] and IP in IP [RFC2003].
In the discussion, we use TTL Diff, defined earlier as the
difference between the IP TTL and the Quick-Start TTL, mod 256.
Recall that the sender considers the Quick-Start request approved
only if the value of TTL Diff for the packet entering the network is
the same as the value of TTL Diff for the packet exiting the
network.
Simple tunnels: IP tunnel modes are generally based on adding a new
"outer" IP header that encapsulates the original or "inner" IP
header and its associated packet. In many cases, the new "outer" IP
header may be added and removed at intermediate points along a
connection, enabling the network to establish a tunnel without
requiring endpoint participation. We denote tunnels that specify
that the outer header be discarded at tunnel egress as "simple
tunnels", and we denote tunnels where the egress saves and uses
information from the outer header before discarding it as "non-
simple tunnels". An example of a "non-simple tunnel" would be a
tunnel configured to support ECN, where the egress router might copy
the ECN codepoint in the outer header to the inner header before
discarding the outer header [RFC3168].
__ Tunnels Compatible with Quick-Start
/
Simple Tunnels __/
\
\__ Tunnels Not Compatible with Quick-Start
(False Positives!)
__ Tunnels Supporting Quick-Start
/
/
Non-Simple Tunnels __/_____ Tunnels Compatible with Quick-Start,
\ but Not Supporting Quick-Start
\
\__ Tunnels Not Compatible with Quick-Start?
Figure 5: Categories of Tunnels.
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-
Start Request over such a tunnel allows false positives, where the
TCP sender incorrectly believes that the Quick-Start Request was
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
tunnel `is compatible with Quick-Start'.
If the IP TTL of the inner header is decremented during forwarding
before tunnel encapsulation takes place, then the simple tunnel is
compatible with Quick-Start, with Quick-Start requests being
rejected. Section 6.1 describes in more detail the ways that a
simple tunnel can be compatible with Quick-Start.
There are some simple tunnels that are not compatible with with
Quick-Start, allowing `false positives' where the TCP sender
incorrectly believes that the Quick-Start Request was approved by
all routers along the path. This is discussed in Section 6.2 below.
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
the extent to which such tunnels are modified over time. The
evaluation of the problem of false positives from tunnels that are
not compatible with Quick-Start will affect the progression of
Quick-Start from Experimental to Proposed Standard, and will affect
the degree of deployment of Quick-Start while in Experimental mode.
Tunnels that support Quick-Start: We say that an IP tunnel `supports
Quick-Start' if it allows routers along the tunnel path to process
the Quick-Start Request and give feedback, resulting in the
appropriate possible acceptance of the Quick-Start request. Some
tunnels that are compatible with Quick-Start support Quick-Start,
while others do not. We note that a simple tunnel is not able to
support Quick-Start.
From a security point of view, the use of Quick-Start in the outer
header of an IP tunnel might raise security concerns because an
adversary could tamper with the Quick-Start information that
propagates beyond the tunnel endpoint, or because the Quick-Start
Option exposes information to network scanners. Our approach is to
make supporting Quick-Start an option for IP tunnels. That is, in
environments or tunneling protocols where the risks of using Quick-
Start are judged to outweigh its benefits, the tunnel can simply
delete the Quick-Start option or zero the Quick-Start rate request
and QS TTL fields before encapsulation. The result is that there
are two viable options for IP tunnels to be compatible with Quick-
Start. The first option is the simple tunnel described above and in
Section 6.1, where the tunnel is compatible with Quick-Start but
does not support Quick-Start, where all Quick-Start requests along
the path will be rejected. The second approach is a Quick-Start-
capable mode, described in Section 6.3, where the tunnel actively
supports Quick-Start.
6.1. Simple Tunnels That Are Compatible with Quick-Start
This section describes the ways that a simple tunnel can be
compatible with Quick-Start but not support Quick-Start, resulting
in the rejection of all Quick-Start requests that traverse the
tunnel.
If the tunnel ingress for the simple tunnel is at a router, the IP
TTL of the inner header is generally decremented during forwarding
before tunnel encapsulation takes place. In this case TTL Diff will
be changed, correctly causing the Quick-Start request to be
rejected. For a simple tunnel it is preferable if the Quick-Start
Request is not copied to the outer header, saving the routers within
the tunnel from unnecessarily processing the Quick-Start request.
However, the Quick-Start request will be rejected correctly in this
case whether or not the Quick-Start Request is copied to the outer
header.
6.1.1. Simple Tunnels that are Aware of Quick-Start
If a tunnel ingress is aware of Quick-Start, but does not want to
support Quick-Start, then the tunnel ingress MUST either zero the
Quick-Start rate request, QS TTL, and QS Nonce fields or remove the
Quick-Start option from the inner header before encapsulation.
Section 6.3 describes the procedures for a tunnel that does want to
support Quick-Start.
Deleting the Quick-Start option or zeroing the Quick-Start rate
request *after decapsulation* also serves to prevent the propagation
of Quick-Start information, and is compatible with Quick-Start. If
the outer header does not contain a Quick-Start Request, a Quick-
Start-aware tunnel egress MUST reject the inner Quick-Start Request
by resetting the Rate Request field in the inner header, or by
deleting the Quick-Start Request option.
If the tunnel ingress is at a sending host or router where the IP
TTL is not decremented prior to encapsulation, and neither tunnel
endpoint is aware of Quick-Start, then this allows false positives,
described in the section below.
6.2. Simple Tunnels That Are Not Compatible with Quick-Start
Sometimes a tunnel implementation that does not support Quick-Start
is independent of the TCP sender or a router implementation that
supports Quick-Start. In these cases it is possible that a Quick-
Start Request gets erroneously approved without the routers in the
tunnel having individually approved the request, causing a false
positive.
If a tunnel ingress is a separate component from the TCP sender or
IP forwarding, it is possible that a packet with a Quick-Start
option is encapsulated without the IP TTL being decremented first,
or with both IP TTL and QS TTL being decremented before the tunnel
encapsulation takes place. If the tunnel ingress does not know about
Quick-Start, a valid Quick-Start Request with unchanged TTL Diff
traverses in the inner header, while the outer header most likely
does not carry a Quick-Start Request. If the tunnel egress also
does not support Quick-Start, it remains possible that the Quick-
Start Request would be falsely approved, because the packet is
decapsulated using the Quick-Start request from the inner header,
and the value of TTL Diff echoed to the sender remains unchanged.
For example, such a scenario can occur with a Bump-In-The-Stack
(BITS), an IPSec encryption implementation where the data encryption
occurs between the network drivers and the TCP/IP protocol stack
[RFC2401].
As one example, if a remote access VPN client uses a BITS structure,
then Quick-Start obstacles between the client and the VPN gateway
won't be seen. This is a particular problem because the path
between the client and the VPN gateway is likely to contain the most
congested part of the path. Because most VPN clients are reported
to use BITS [H05], we will explore this in more detail.
A Bump-In-The-Wire (BITW) is an IPSec encryption implementation
where the encryption occurs on an outboard processor, offloading the
encryption processing overhead from the host or router [RFC2401].
The BITW device is usually IP addressable, which means that the IP
TTL is decremented before the packet is passed to the BITW. If the
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
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
the BITW, and a false positive could occur.
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],
and tunnels using the Layer Two Tunneling Protocol [RFC2661].
Section 6.2 discusses the related issue of non-IP queues, such as
layer-two Ethernet or ATM networks, as another instance of possible
bottlenecks that do not participate in the Quick-Start feedback.
6.3. Tunnels That Support Quick-Start
This section discusses tunnels configured to support Quick-Start.
If the tunnel ingress node chooses to locally approve the Quick-
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
and the Quick-Start option from the inner IP header to the outer
header. During encapsulation, the tunnel ingress MUST zero the
Quick-Start rate request field in the inner header to ensure that
the Quick-Start request will be rejected if the tunnel egress does
not support Quick-Start.
If the tunnel ingress node does not choose to locally approve the
Quick-Start request, then it MUST either delete the Quick-Start
option from the inner header before encapsulation, or zero the QS
TTL and the Rate Request fields before encapsulation.
Upon decapsulation, if the outer header contains a 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.
IPsec uses the IKE (Internet Key Exchange) Protocol for security
associations. We do not consider the interactions between Quick-
Start and IPsec with IKEv1 [RFC2409] in this document. When the RFC
for IKEv2 [IKEv2] is published, we will specify a modification of
IPsec to allow the support of Quick-Start to be negotiated; this
modification will specify the negotiation between tunnel endpoints
to allow or forbid support for Quick-Start within the tunnel. This
was done for ECN for IPsec tunnels, with IKEv1 [RFC3168, Section
9.2]. This negotiation of Quick-Start capability in an IPsec tunnel
will be specified in a separate IPsec document. This document will
also include a discussion of the potential effects of an adversary's
modifications of the Quick-Start field (as in Sections 18 and 19 of
RFC 3168), and of the security considerations of exposing the Quick-
Start rate request to network scanners.
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:
* Quick-Start is only specified for unicast transport protocols with * Quick-Start is only specified for unicast transport protocols with
appropriate congestion control mechanisms. Note: Quick-Start is not appropriate congestion control mechanisms. Note: Quick-Start is not
a replacement for standard congestion control techniques, but meant a replacement for standard congestion control techniques, but meant
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 and the TTL Diff. 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 starts sending Quick-Start packets, rate-paced out
at the approved sending rate. 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
skipping to change at page 30, line 42 skipping to change at page 37, line 16
continues using the standard congestion control mechanisms of that continues using the standard congestion control mechanisms of that
protocol. protocol.
* If one of the Quick-Start packets is lost, then the sender reverts * If one of the Quick-Start packets is lost, then the sender reverts
to the standard congestion control method of that protocol that to the standard congestion control method of that protocol that
would have been used if the Quick-Start request had not been would have been used if the Quick-Start request had not been
approved. In addition, the sender takes into account the approved. In addition, the sender takes into account the
information that the Quick-Start congestion window was too large information that the Quick-Start congestion window was too large
(e.g., by decreasing ssthresh in TCP). (e.g., by decreasing ssthresh in TCP).
6. Evaluation of Quick-Start 8. Using Quick-Start
6.1. Benefits of Quick-Start 8.1. Determining the Rate to Request
As discussed in [SAF05], the data sender does not necessarily have
information about the size of the data transfer at connection
initiation; for example, in request-response protocols such as HTTP,
the server doesn't know the size or name of the requested object
during connection initiation. [SAF05] explores some of the
performance implications of overly-large Quick-Start requests, and
discusses heuristics that end-nodes could use to size their requests
appropriately. For example, the sender might have information about
the bandwidth of the last-mile hop, the size of the local socket
buffer, or of the TCP receive window, and could use this information
in determining the rate to request. Web servers that mostly have
small objects to transfer might decide not to use Quick-Start at
all, since Quick-Start would be of little benefit to them.
Quick-Start will be more effective if Quick-Start requests are not
larger than necessary; every Quick-Start request that is approved
but not used (or not fully used) takes away from the bandwidth pool
available for granting successive Quick-Start requests. Following
Section 4.1, the sender SHOULD NOT request a sending rate larger
than it is able to use over the round-trip time of the connection
(or over 100 ms, if the round-trip time is not known), except as
required to round up the desired sending rate to the next-highest
allowable request.
8.2. Deciding the Permitted Rate Request at a Router
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
could ask the following questions:
* Has the router's output link been underutilized for some time
(e.g., several seconds).
* Would the output link remain underutilized if the arrival rate was
to increase by the aggregate rate requests that the router has
approved over the last fraction of a second?
In order to answer this question, the router must have some
knowledge of the available bandwidth on the output link and of the
Quick-Start bandwidth that could arrive due to recently-approved
Quick-Start Requests. In this way, if an underutilized router
experiences a flood of Quick-Start requests, the router can begin to
deny Quick-Start requests while the output link is still
underutilized.
A simple way for the router to keep track of the potential bandwidth
from recently-approved requests is to maintain two counters, one for
the total aggregate Rate Requests that have been approved in the
current time interval [T1, T2], for the current time between T1 and
T2, and one for the total aggregate Rate Requests approved over a
previous time interval [T0, T1]. However, this document doesn't
specify router algorithms for approving Quick-Start requests, or
make requirements for the appropriate time intervals for remembering
the aggregate approved Quick-Start bandwidth. A possible router
algorithm is given in Appendix C, and more discussion of these
issues is available in [SAF05].)
* If the router's output link has been underutilized and the
aggregate Quick Start Request Rate options granted is low enough to
prevent a near-term bandwidth shortage, then the router could
approve the Quick-Start Request.
Section 10.2 discusses some of the implementation issues in
processing Quick-Start requests at routers. [SAF05] discusses the
range of possible Quick-Start algorithms at the router for deciding
whether to approve a Quick-Start request. In order to explore the
limits of the possible functionality at routers, [SAF05] also
discusses Extreme Quick-Start mechanisms at routers, where the
router would keep per-flow state concerning approved Quick-Start
requests.
9. Evaluation of Quick-Start
9.1. Benefits of Quick-Start
The main benefit of Quick-Start is the faster start-up for the The main benefit of Quick-Start is the faster start-up for the
transport connection itself. For a small TCP transfer of one to transport connection itself. For a small TCP transfer of one to
five packets, Quick-Start is probably of very little benefit; at five packets, Quick-Start is probably of very little benefit; at
best, it might shorten the connection lifetime from three to two best, it might shorten the connection lifetime from three to two
round-trip times (including the round-trip time for connection round-trip times (including the round-trip time for connection
establishment). Similarly, for a very large transfer, where the establishment). Similarly, for a very large transfer, where the
slow-start phase would have been only a small fraction of the slow-start phase would have been only a small fraction of the
connection lifetime, Quick-Start would be of limited benefit. connection lifetime, Quick-Start would be of limited benefit.
Quick-Start would not significantly shorten the connection lifetime, Quick-Start would not significantly shorten the connection lifetime,
but it might eliminate or at least shorten the start-up phase. but it might eliminate or at least shorten the start-up phase.
However, for moderate-sized connections in a well-provisioned However, for moderate-sized connections in a well-provisioned
environment, Quick-Start could possibly allow the entire transfer of environment, Quick-Start could possibly allow the entire transfer of
M packets to be completed in one round-trip time (after the initial M packets to be completed in one round-trip time (after the initial
round-trip time for the SYN exchange), instead of the log_2(M)-2 round-trip time for the SYN exchange), instead of the log_2(M)-2
round-trip times that it would normally take for the data transfer, round-trip times that it would normally take for the data transfer,
in an uncongested environments (assuming an initial window of four in an uncongested environments (assuming an initial window of four
packets). packets).
6.2. Costs of Quick-Start 9.2. Costs of Quick-Start
This section discusses the costs of Quick-Start for the connection This section discusses the costs of Quick-Start for the connection
and for the routers along the path. and for the routers along the path.
The cost of having a Quick-Start packet dropped: The cost of having a Quick-Start packet dropped:
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
skipping to change at page 32, line 22 skipping to change at page 40, line 28
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 Request option. In addition, for the underutilized links where
Quick-Start Requests could actually be approved, or in typical Quick-Start Requests could actually be approved, or in typical
environments where most of the packets belong to large flows, the environments where most of the packets belong to large flows, the
burden of the Quick-Start Option on routers would be considerably burden of the Quick-Start Option on routers would be considerably
reduced. Nevertheless, it is still conceivable, in the worst case, reduced. Nevertheless, it is still conceivable, in the worst case,
that many packets would carry Quick-Start requests; this could slow that many packets would carry Quick-Start requests; this could slow
down the processing of Quick-Start packets in routers considerably. down the processing of Quick-Start packets in routers considerably.
As discussed in Section 6.6, routers can easily protect against this As discussed in Section 9.5, routers can easily protect against this
by enforcing a limit on the rate at which Quick-Start requests will by enforcing a limit on the rate at which Quick-Start requests will
be considered. be considered.
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. This is, however, similar to what would
happen if the connection's path was changed in the middle of the happen, for a connection with sufficient data, if the connection's
connection, when the connection had already established the allowed path was changed in the middle of the connection, when the
initial rate. connection had already established the allowed initial rate.
A router that uses multipath routing for packets within a single
connection MUST NOT approve a Quick-Start request. Quick-Start
would not perform robustly in an environment with multipath routing,
where different packets in a connection routinely follow different
paths. In such an environment, the Quick-Start request and some
fraction of the packets in the connection might take an
underutilized path, while the rest of the packets take an alternate,
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.
6.3. Protection against Misbehaving Nodes 9.3. Quick-Start with QoS-enabled Traffic
The discussion in this document has largely been of Quick-Start with
default, best-effort traffic. However, Quick-Start could also be
used by traffic using some form of differentiated services, and
routers could take the traffic class into account when deciding
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
specification of Quick-Start.
9.4. Protection against Misbehaving Nodes
In this section we discuss the protection against receivers or In this section we discuss the protection against receivers or
colluding middleboxes lying about the Quick-Start Request. First, colluding middleboxes lying about the Quick-Start Request. First,
we note that it is not necessarily in the receiver's interest to lie we note that it is not necessarily in the receiver's interest to lie
about the Quick-Start Request. If the sender sends at too-high of about the Quick-Start Request. If the sender sends at too-high of
an initial rate, and has a packet dropped, this does not necessarily an initial rate, and has a packet dropped, this does not necessarily
improve the performance of the connection, relative to the case when improve the performance of the connection, relative to the case when
the Quick-Start Request was not approved. the Quick-Start Request was not approved.
6.3.1. Receivers Lying about Whether the Request was Approved 9.4.1. 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. If a router that understands the falsely reporting the TTL Diff and QS Nonce. If a router that
Quick-Start Request denies the request by deleting the request or by understands the Quick-Start Request denies the request by deleting
zeroing the QS TTL, then the receiver can ``lie" about whether the the request or by zeroing the QS TTL and QS Nonce, then the receiver
request was approved only by successfully guessing the value of the can ``lie" about whether the request was approved only by
TTL Diff to report. The chance of the receiver successfully successfully guessing the value of the TTL Diff and QS Nonce to
guessing the correct value for the TTL Diff is 1/256. report. The chance of the receiver successfully guessing 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
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 field, the the receiver could lie about whether the Quick-Start TTL and QS Nonce fields, the the receiver could lie about whether
Requests were approved by modifying the QS TTL in successive the Quick-Start Requests were approved by modifying the QS TTL in
requests received from the same host. In particular, if the sender successive requests received from the same host. In particular, if
does not act on a Quick-Start Request, then the receiver could the sender does not act on a Quick-Start Request, then the receiver
decrement the QS TTL by one in the next request received from that could decrement the QS TTL by one in the next request received from
host before calculating the TTL Diff, and decrement the QS TTL by that host before calculating the TTL Diff, and decrement the QS TTL
two in the following received request, until the sender acts on one by two in the following received request, until the sender acts on
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 a TTL field to deny a request. As a result, the QS TTL is zeroing the QS TTL and QS Nonce to deny a request. As a result, the
not a fail-safe mechanism for preventing lying by receivers in the QS TTL is not a fail-safe mechanism for preventing lying by
case of non-Quick-Start-capable routers. receivers in the case of non-Quick-Start-capable routers.
6.3.2. Receivers Lying about the Approved Rate 9.4.2. Receivers Lying about the Approved Rate
A second form of misbehavior would be for the receiver to lie to the A second form of misbehavior would be for the receiver to lie to the
sender about the Rate Request for an approved Quick-Start Request, sender about the Rate Request for an approved Quick-Start Request,
by increasing the value of the Rate Request field. However, the by increasing the value of the Rate Request field. However, the
receiver generally doesn't know the Rate Request in the original receiver doesn't necessarily know the Rate Request in the original
Quick-Start Request sent by the sender, and a higher Rate Request Quick-Start Request sent by the sender, and a higher Rate Request
reported by the receiver will only be considered valid by the sender reported by the receiver will only be considered valid by the sender
if it is no higher than the Rate Request originally requested by the if it is no higher than the Rate Request originally requested by the
sender. This limits the ability of the receiver to cheat. For sender. For example, if the sender sends a Quick-Start Request with
example, if the sender sends a Quick-Start Request with an Rate a Rate Request of X, and the receiver reports receiving a Quick-
Request of X, and the receiver reports receiving a Quick-Start Start Request with a Rate Request of Y > X, then the sender knows
Request with an Rate Request of Y > X, then the sender knows that that either some router along the path malfunctioned (increasing the
either some router along the path malfunctioned (increasing the Rate Rate Request inappropriately), or the receiver is lying about the
Request inappropriately), or the receiver is lying about the Rate Rate Request in the received packet.
Request in the received packet.
However, if the sender sends a Quick-Start Request with an Rate If the sender sends a Quick-Start Request with a Rate Request of Z,
Request of Z, the receiver receives the Quick-Start Request with an the receiver receives the Quick-Start Request with an approved Rate
approved Rate Request of X, and reports an Rate Request of Y, for X Request of X, and reports a Rate Request of Y, for X < Y <= Z, then
< Y <= Z, then the receiver succeeds in lying to the sender about the receiver only succeeds in lying to the sender about the approved
the approved rate. rate if the receiver successfully reports the rightmost 2Y bits in
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
Rate Request, and this would make it easier for the receiver to lie Rate Request, and this would make it easier for the receiver to lie
about the value of the Rate Request field. Similarly, if the about the value of the Rate Request field. Similarly, if the
receiver often communicates with a particular sender, and the sender receiver often communicates with a particular sender, and the sender
always uses the same Rate Request for that receiver, then the always uses the same Rate Request for that receiver, then the
receiver might over time be able to infer the original Rate Request receiver might over time be able to infer the original Rate Request
used by the sender. used by the sender.
There are several possible forms of protection against receivers There are several possible additional forms of protection against
lying about the value of the Rate Request. One form of protection receivers lying about the value of the Rate Request. One possible
would be the Rate-Reduced Nonce discussed earlier, where the additional protection would be for a router that decreases a Rate
receiver would have to report the original value of the nonce if the
receiver reported that the original rate request was approved.
A second possible protection would be for a router decreasing a Rate
Request in a Quick-Start Request to report the decrease directly to Request in a Quick-Start Request to report the decrease directly to
the sender. However, this could lead to many reports back to the the sender. However, this could lead to many reports back to the
sender for a single request, and could also be used in address- sender for a single request, and could also be used in address-
spoofing attacks. spoofing attacks.
A third 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.
6.3.3. Collusion between Misbehaving Routers 9.4.3. 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 for the request packet the egress router out-of-band of the TTL Diff and QS Nonce for the
at the ingress. This would enable the egress router to modify the request packet at the ingress. This would enable the egress router
QS TTL so that it appeared that all of the routers along the path to modify the QS TTL and QS Nonce so that it appeared that all of
had approved the request. There does not appear to be any the routers along the path had approved the request. There does not
protection against a colluding ingress and egress router. Even if appear to be any protection against a colluding ingress and egress
an intermediate router had deleted the Quick-Start Request Option router. Even if an intermediate router had deleted the Quick-Start
from the packet, the ingress router could have sent the Quick-Start Request Option from the packet, the ingress router could have sent
Request Option to the egress router out-of-band, with the egress the Quick-Start Request Option to the egress router out-of-band,
router inserting the Quick-Start Request Option, with a modified QS with the egress router inserting the Quick-Start Request Option,
TTL field, back in the packet. with a modified QS TTL 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 36, line 16 skipping to change at page 44, line 44
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).
6.3.4. Misbehaving Middleboxes and the IP TTL 9.4.4. Misbehaving Middleboxes and the IP TTL
A separate possibility is that of traffic normalizers [HKP01] or A separate possibility 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).
6.4. Quick-Start with QoS-enabled Traffic 9.5. Attacks on Quick-Start
The discussion in this document has largely been of Quick-Start with
default, best-effort traffic. However, Quick-Start could also be
used by traffic using some form of differentiated services, and
routers could take the traffic class into account when deciding
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
specification of Quick-Start. However, we note that routers should
be discouraged from granting Quick-Start requests for higher-
priority traffic when this is likely to result in significant packet
loss for lower-priority traffic.
6.5. Limitations of Quick-Start
The Quick-Start proposal, taken together with HighSpeed TCP [F03],
could go a significant way towards extending the range of
performance for best-effort traffic in the Internet. However, there
are many things that the Quick-Start proposal would not accomplish.
Quick-Start is not a congestion control mechanism, and would not
help in making more precise use of the available bandwidth, that is,
of achieving the goal of high throughput with low delay and low
packet loss rates. Quick-Start would not give routers more control
over the decrease rates of active connections. One of the open
questions addressed 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.
6.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 37, line 46 skipping to change at page 45, line 42
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.
6.7. Simulations with Quick-Start 9.6. Simulations with Quick-Start
Quick-Start was added to the NS simulator [SH02] by Srikanth Quick-Start was added to the NS simulator [SH02] by Srikanth
Sundarrajan, and additional functionality was added by Pasi Sundarrajan, and additional functionality was added by Pasi
Sarolahti. The validation test is at `test-all-quickstart' in the Sarolahti. The validation test is at `test-all-quickstart' in the
`tcl/test' directory in NS. The initial simulation studies from `tcl/test' directory in NS. The initial simulation studies from
[SH02] show a significant performance improvement using Quick-Start [SH02] show a significant performance improvement using Quick-Start
for moderate-sized flows (between 4KB and 128KB) in under-utilized for moderate-sized flows (between 4KB and 128KB) in under-utilized
environments. These studies are of file transfers, with the environments. These studies are of file transfers, with the
improvement measured as the relative increase in the overall improvement measured as the relative increase in the overall
throughput for the file transfer. The study shows that potential throughput for the file transfer. The study shows that potential
improvement from Quick-Start is proportional to the delay-bandwidth improvement from Quick-Start is proportional to the delay-bandwidth
product of the path. product of the path.
The Quick-Start simulations in [SAF05] explore the following: the The Quick-Start simulations in [SAF05] explore the following: the
potential benefit of Quick-Start for the connection; the relative potential benefit of Quick-Start for the connection; the relative
benefits of different router-based algorithms for approving Quick- benefits of different router-based algorithms for approving Quick-
Start requests; and the effectiveness of Quick-Start as a function Start requests; and the effectiveness of Quick-Start as a function
of the senders' algorithms for choosing the size of the rate of the senders' algorithms for choosing the size of the rate
request. request.
7. Related Work 10. Implementation and Deployment Issues
Any evaluation of Quick-Start must include a discussion of the This section discusses some of the implementation issues with Quick-
relative benefits of approaches that use no explicit information Start. This section also discusses some of the key deployment
from routers, and of approaches that use more fine-grained feedback issues, such as the chicken-and-egg deployment problems of
from routers as part of a larger congestion control mechanism. We mechanisms that have to be deployed in both routers and end nodes in
discuss three classes of proposals (no explicit feedback from order to work, and the problems posed by the wide deployment of
routers; explicit feedback about the initial rate; and more fine- middleboxes today that block the use of known or unknown IP Options.
grained feedback from routers) in the sections below.
7.1. Fast Start-ups without Explicit Information from Routers 10.1. Implementation Issues for Sending Quick-Start Requests
Section 4.6 discusses some of the issues with deciding the initial
sending rate to request. Quick-Start raises additional issues about
the communication between the transport protocol and the
application, and about the use of the past history with Quick-Start
in the end node.
One possibility is that a protocol implementation could provide an
API for applications to indicate when they want to request Quick-
Start, and what rate they would like to request. In the
conventional socket API this could be a socket option that is set
before a connection is established. Some applications, such those
that use TCP for bulk transfers, do not have interest in the
transmission rate, but they might know the amount of data that can
be sent immediately. Based on this, the sender implementation could
decide whether Quick-Start would be useful, and what rate should be
requested. Datagram-based real-time streaming applications, on the
other hand, may have a specific preference on the transmission rate
and they could indicate the required rate explicitly to the
transport protocol to be used in the Quick-Start Request.
We note that when Quick-Start is used, the TCP sender is required to
implement an additional timer for the paced transmission of Quick-
Start packets.
10.2. Implementation Issues for Processing Quick-Start Requests
A router or other network host must be able to determine the
approximate bandwidth of its outbound network interfaces in order to
process incoming Quick-Start rate requests, including those that
originate from the host itself. One possibility would be for hosts
to rely on configuration information to determine link bandwidths;
this has the drawback of not being robust to errors in
configuration. Another possibility would be for network device
drivers to infer the bandwidth for the interface and to communicate
this to the IP layer.
Particular issues will arise for wireless links with variable
bandwidth, where decisions will have to be made about how frequently
the network host gets updates of the changing bandwidth. It seems
appropriate that Quick-Start Requests would be handled particularly
conservatively for links with variable bandwidth, to avoid cases
where Quick-Start Requests are approved, the link bandwidth is
reduced, and the data packets that are send end up being dropped.
10.3. Possible Deployment Scenarios
Because of possible problems discussed above concerning using Quick-
Start over some network paths, the most realistic initial deployment
of Quick-Start would likely to take place in Intranets and other
controlled environments. Quick-Start is most useful on high
bandwidth-delay paths that are significantly underutilized. The
primary initial users of Quick-Start would likely be in
organizations that provide network services to their users and also
have control over a large portion of the network path.
Below are a few examples of networking environments where Quick-
Start would potentially be useful. These are the environments that
might consider an initial deployment of Quick-Start in the routers
and end-nodes, where the incentives for routers to deploy Quick-
Start might be the most clear.
* Centrally-administrated organizational Intranets often have large
network capacity and the networks are underutilized for most of the
time. Such Intranets might also include high-bandwidth and high-
delay paths to remote sites. In such an environment, Quick-Start
would be of benefit to users, and there would be a clear incentive
for the deployment of Quick-Start in routers. For example, Quick-
Start could be quite useful in high-bandwidth networks used for
scientific computing.
* Quick-Start could also be useful in high-delay environments of
Cellular Wide-Area Wireless Networks such as the GPRS [BW97] and
their enhancements and next generations. For example, GPRS EDGE
(Enhanced Data for GSM Evolution) is expected to provide wireless
bandwidth of up to 384 Kbps (roughly 32 1500-byte packets per
second) while the GPRS round-trip times range typically from few
hundred milliseconds to over a second excluding any possible
queueing delays in the network [GPAR02]. In addition, these networks
sometimes have variable additional delays due to resource allocation
that could be avoided by keeping the connection path constantly
utilized, starting from initial slow-start. Thus, Quick-Start could
be of significant benefit to users in these environments.
* Geostationary Orbit (GEO) satellite links have one-way propagation
delays on the order of 250 ms while the bandwidth can be measured in
megabits per second [RFC2488]. Because of the considerable
bandwidth-delay product on the link, TCP's slow-start is a major
performance limitation in the beginning of the connection. A large
initial congestion window would be useful to users of such satellite
links.
10.4. Would QuickStart packets take the slow path in routers?
How much delay would the slow path add to the processing time for
this packet? Similarly, if QuickStart packets took the slow path,
how much stress would it add to routers for there to be many more
packets on the slow path, because of the number of packets using
QuickStart? These are both questions to be explored while
experimenting with Quick-Start in the Internet.
10.5. A Comparison with the Deployment Problems of ECN
Given the glacially slow rate of deployment of ECN in the Internet
to date [MAF05], it is disconcerting to note that some of the
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
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
the routers along the end-to-end path. Second, unlike ECN, which
uses an allocated field in the IP header, Quick-Start requires the
extra complications of an IP Option.
However, in spite of these issues, there is some hope for the
deployment of Quick-Start, at least in protected corners of the
Internet, because the potential benefits of Quick-Start to the user
are considerably more dramatic than those of ECN. Rather than
simply replacing the occasional dropped packet by an ECN-marked
packet, Quick-Start is capable of dramatically increasing the
throughput of connections in underutilized environments.
11. Related Work
The Quick-Start proposal, taken together with HighSpeed TCP [F03] or
other transport protocols for high-bandwidth transfers,, could go a
significant way towards extending the range of performance for best-
effort traffic in the Internet. However, there are many things that
the Quick-Start proposal would not accomplish. Quick-Start is not a
congestion control mechanism, and would not help in making more
precise use of the available bandwidth, that is, of achieving the
goal of high throughput with low delay and low packet loss rates.
Quick-Start would not give routers more control over the decrease
rates of active connections. % One of the open questions addressed
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
of the relative benefits of approaches that use no explicit
information from routers, and of approaches that use more fine-
grained feedback from routers as part of a larger congestion control
mechanism. We discuss three classes of proposals (no explicit
feedback from routers; explicit feedback about the initial rate; and
more fine-grained feedback from routers) in the sections below.
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
than the current slow-start. While it seems clear that approaches than the current slow-start. While it seems clear that approaches
*without* explicit feedback from the routers will be strictly less *without* explicit feedback from the routers will be strictly less
skipping to change at page 39, line 42 skipping to change at page 50, line 48
allowed sending rate for an individual flow. As an example, if the allowed sending rate for an individual flow. As an example, if the
TCP sender sends four packets back-to-back in the initial window, TCP sender sends four packets back-to-back in the initial window,
and the TCP receiver reports that the data packets were received and the TCP receiver reports that the data packets were received
with roughly the same spacing as they were transmitted, does this with roughly the same spacing as they were transmitted, does this
mean that the flow can infer an underutilized path? And how fast mean that the flow can infer an underutilized path? And how fast
can the flow send in the next round-trip time? Do the results can the flow send in the next round-trip time? Do the results
depend on the level of statistical multiplexing at the congested depend on the level of statistical multiplexing at the congested
link, and on the number of flows attempting a faster start-up at the link, and on the number of flows attempting a faster start-up at the
same time? same time?
7.2. Optimistic Sending without Explicit Information from Routers 11.2. Optimistic Sending without Explicit Information from Routers
Another possibility that has been suggested [S02] is for the sender Another possibility that has been suggested [S02] is for the sender
to start with a large initial window without explicit permission to start with a large initial window without explicit permission
from the routers and without bandwidth estimation techniques, and from the routers and without bandwidth estimation techniques, and
for the first packet of the initial window to contain information for the first packet of the initial window to contain information
such as the size or sending rate of the initial window. The such as the size or sending rate of the initial window. The
proposal would be that congested routers would use this information proposal would be that congested routers would use this information
in the first data packet to drop or delay many or all of the packets in the first data packet to drop or delay many or all of the packets
from that initial window. In this way a flow's optimistically-large from that initial window. In this way a flow's optimistically-large
initial window would not force the router to drop packets from initial window would not force the router to drop packets from
skipping to change at page 40, line 34 skipping to change at page 51, line 39
(3) Distributed Denial of Service attacks: (3) Distributed Denial of Service attacks:
A third key question would be the potential role of optimistic A third key question would be the potential role of optimistic
senders in amplifying the damage done by a Distributed Denial of senders in amplifying the damage done by a Distributed Denial of
Service (DDoS) attack. Service (DDoS) attack.
(4) Performance hits if a packet is dropped: (4) Performance hits if a packet is dropped:
A fourth issue would be to quantify the performance hit to the A fourth issue would be to quantify the performance hit to the
connection when a packet is dropped from one of the initial windows. connection when a packet is dropped from one of the initial windows.
7.3. Fast Start-ups with other Information from Routers 11.3. Fast Start-ups with other Information from Routers
There have been several proposals somewhat similar to Quick-Start, There have been several proposals somewhat similar to Quick-Start,
where the transport protocol collects explicit information from the where the transport protocol collects explicit information from the
routers along the path. routers along the path.
An IP Option about the free buffer size: An IP Option about the free buffer size:
In related work, [P00] investigates the use of a slightly different In related work, [P00] investigates the use of a slightly different
IP option for TCP connections to discover the available bandwidth IP option for TCP connections to discover the available bandwidth
along the path. In that proposal, the IP option would query the along the path. In that proposal, the IP option would query the
routers along the path about the smallest available free buffer routers along the path about the smallest available free buffer
skipping to change at page 41, line 15 skipping to change at page 52, line 20
along the path from the sender to the receiver [W00]. For example, along the path from the sender to the receiver [W00]. For example,
a single PTP packet could be used to determine the bottleneck a single PTP packet could be used to determine the bottleneck
bandwidth along a path. bandwidth along a path.
ETEN: ETEN:
Additional proposals for end nodes to collect explicit information Additional proposals for end nodes to collect explicit information
from routers include Explicit Transport Error Notification (ETEN), from routers include Explicit Transport Error Notification (ETEN),
which includes a cumulative mechanism to notify endpoints of which includes a cumulative mechanism to notify endpoints of
aggregate congestion statistics along the path [KAPS02]. aggregate congestion statistics along the path [KAPS02].
7.4. Fast Start-ups with more Fine-Grained Feedback from Routers 11.4. Fast Start-ups with more Fine-Grained Feedback from Routers
Proposals for more fine-grained congestion-related feedback from Proposals for more fine-grained congestion-related feedback from
routers include XCP [KHR02], MaxNet [MaxNet], and AntiECN marking routers include XCP [KHR02], MaxNet [MaxNet], and AntiECN marking
[K03]. Section A.6 discusses in more detail the relationship [K03]. Section A.6 discusses in more detail the relationship
between Quick-Start and proposals for more fine-grained per-packet between Quick-Start and proposals for more fine-grained per-packet
feedback from routers. feedback from routers.
XCP: XCP:
Proposals such as XCP for new congestion control mechanisms based on Proposals such as XCP for new congestion control mechanisms based on
more feedback from routers are more powerful than Quick-Start, but more feedback from routers are more powerful than Quick-Start, but
skipping to change at page 41, line 41 skipping to change at page 52, line 46
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.
8. Implementation and Deployment Issues 12. Security Considerations
This section discusses some of the implementation issues with Quick-
Start. This section also discusses some of the key deployment
issues, such as the chicken-and-egg deployment problems of
mechanisms that have to be deployed in both routers and end nodes in
order to work, and the problems posed by the wide deployment of
middleboxes today that block the use of known or unknown IP Options.
8.1. Implementation Issues for Sending Quick-Start Requests
Section 4.6 discusses some of the issues with deciding the initial
sending rate to request. Quick-Start raises additional issues about
the communication between the transport protocol and the
application, and about the use of the past history with Quick-Start
in the end node.
One possibility is that a protocol implementation could provide an
API for applications to indicate when they want to request Quick-
Start, and what rate they would like to request. In the
conventional socket API this could be a socket option that is set
before a connection is established. Some applications, such those
that use TCP for bulk transfers, do not have interest in the
transmission rate, but they might know the amount of data that can
be sent immediately. Based on this, the sender implementation could
decide whether Quick-Start would be useful, and what rate should be
requested. Datagram-based real-time streaming applications, on the
other hand, may have a specific preference on the transmission rate
and they could indicate the required rate explicitly to the
transport protocol to be used in the Quick-Start Request.
We note that when Quick-Start is used, the TCP sender is required to
implement an additional timer for the paced transmission of Quick-
Start packets.
8.2. Implementation Issues for Processing Quick-Start Requests
A router or other network host must be able to determine the
approximate bandwidth of its outbound network interfaces in order to
process incoming Quick-Start rate requests, including those that
originate from the host itself. One possibility would be for hosts
to rely on configuration information to determine link bandwidths;
this has the drawback of not being robust to errors in
configuration. Another possibility would be for network device
drivers to infer the bandwidth for the interface and to communicate
this to the IP layer.
Particular issues will arise for wireless links with variable
bandwidth, where decisions will have to be made about how frequently
the network host gets updates of the changing bandwidth. It seems
appropriate that Quick-Start Requests would be handled particularly
conservatively for links with variable bandwidth, to avoid cases
where Quick-Start Requests are approved, the link bandwidth is
reduced, and the data packets that are send end up being dropped.
8.3. Possible Deployment Scenarios
Because of possible problems discussed above concerning using Quick-
Start over some network paths, the most realistic initial deployment
of Quick-Start would likely to take place in Intranets and other
controlled environments. Quick-Start is most useful on high
bandwidth-delay paths that are significantly underutilized. The
primary initial users of Quick-Start would likely be in
organizations that provide network services to their users and also
have control over a large portion of the network path.
Below are a few examples of networking environments where Quick-
Start would potentially be useful. These are the environments that
might consider an initial deployment of Quick-Start in the routers
and end-nodes, where the incentives for routers to deploy Quick-
Start might be the most clear.
* Centrally-administrated organizational Intranets often have large
network capacity and the networks are underutilized for most of the
time. Such Intranets might also include high-bandwidth and high-
delay paths to remote sites. In such an environment, Quick-Start
would be of benefit to users, and there would be a clear incentive
for the deployment of Quick-Start in routers. For example, Quick-
Start could be quite useful in high-bandwidth networks used for
scientific computing.
* Quick-Start could also be useful in high-delay environments of
Cellular Wide-Area Wireless Networks such as the GPRS [BW97] and
their enhancements and next generations. For example, GPRS EDGE
(Enhanced Data for GSM Evolution) is expected to provide wireless
bandwidth of up to 384 Kbps (roughly 32 1500-byte packets per
second) while the GPRS round-trip times are typically up to one
second excluding any possible queueing delays in the network
[GPAR02]. In addition, these networks sometimes have variable
additional delays due to resource allocation that could be avoided
by keeping the connection path constantly utilized, starting from
initial slow-start. Thus, Quick-Start could be of significant
benefit to users in these environments.
* Geostationary Orbit (GEO) satellite links have one-way propagation
delays on the order of 250 ms while the bandwidth can be measured in
megabits per second [RFC2488]. Because of the considerable
bandwidth-delay product on the link, TCP's slow-start is a major
performance limitation in the beginning of the connection. A large
initial congestion window would be useful to users of such satellite
links.
8.4. Would QuickStart packets take the slow path in routers?
How much delay would the slow path add to the processing time for
this packet? Similarly, if QuickStart packets took the slow path,
how much stress would it add to routers for there to be many more
packets on the slow path, because of the number of packets using
QuickStart? These are both questions to be explored while
experimenting with Quick-Start in the Internet.
8.5. A Comparison with the Deployment Problems of ECN
Given the glacially slow rate of deployment of ECN in the Internet
to date [MAF05], it is disconcerting to note that some of the
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
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
the routers along the end-to-end path. Second, unlike ECN, which
uses an allocated field in the IP header, Quick-Start requires the
extra complications of an IP Option.
However, in spite of these issues, there is some hope for the
deployment of Quick-Start, at least in protected corners of the
Internet, because the potential benefits of Quick-Start to the user
are considerably more dramatic than those of ECN. Rather than
simply replacing the occasional dropped packet by an ECN-marked
packet, Quick-Start is capable of dramatically increasing the
throughput of connections in underutilized environments.
9. Security Considerations
Sections 6.3 and 6.6 discuss the security considerations related to Sections 9.4 and 9.5 discuss the security considerations related to
Quick-Start. Section 6.3 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 of receivers lying about whether the request was approved or
about the approved rate; of routers in collusion to misuse Quick- about the approved rate; of routers in collusion to misuse Quick-
Start; and of potential problems with traffic normalizers that Start; and of potential problems with traffic normalizers that
rewrite IP TTLs in packet headers. All of these problems could rewrite IP TTLs in packet headers. All of these problems could
result in the sender using an Rate Request that was inappropriately result in the sender using a Rate Request that was inappropriately
large, or thinking that a request was approved when it was in fact large, or thinking that a request was approved when it was in fact
denied by at least one router along the path. This inappropriate denied by at least one router along the path. This inappropriate
use of Quick-Start would result in congestion and an unacceptable use of Quick-Start would result in congestion and an unacceptable
level of packet drops along the path, Such congestion could also be level of packet drops along the path, Such congestion could also be
part of a Denial of Service attack. part of a Denial of Service attack.
Section 6.6 discusses a potential attack on the routers' processing Section 9.5 discusses a potential attack on the routers' processing
and state load from an attack of Quick-Start Requests. Section 6.6 and state load from an attack of Quick-Start Requests. Section 9.5
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.3 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.
10. Conclusions As discussed in Section 5, for IPv4 IPsec Authentication Header
Integrity Check Value (AH ICV) calculation, the Quick-Start Request
option MUST be treated as a mutable IPv4 option, and hence
completely zeroed for AH ICV calculation purposes; this is also the
treatment required by RFC 2402 for unrecognized IPv4 options. The
IPv6 Quick-Start Request option's IANA-allocated option type
indicates that it is a mutable option, hence, according to RFC 2402,
its option data MUST be zeroed for AH ICV computation purposes. See
RFC 2402 for further explanation.
We are presenting the Quick-Start mechanism as a proposal for a Section 6.2 discusses possible problems of Quick-Start used by
simple, understandable, and incrementally-deployable mechanism that connections carried over simple tunnels that are not compatible with
would be sufficient to allow connections to start up with large Quick-Start. In this case it is possible that a Quick-Start
initial rates, or large initial congestion windows, in Request is erroneously considered approved by the sender without the
overprovisioned, high-bandwidth environments. We expect there will routers in the tunnel having individually approved the request,
be an increasing number of overprovisioned, high-bandwidth causing a false positive.
environments where the Quick-Start mechanism, or another mechanism
of similar power, could be of significant benefit to a wide range of
traffic. We are presenting the Quick-Start mechanism as a request
for the community to provide feedback and experimentation on issues
relating to Quick-Start.
11. Acknowledgements 13. Conclusions
We are presenting the Quick-Start mechanism as a simple,
understandable, and incrementally-deployable mechanism that would be
sufficient to allow some connections to start up with large initial
rates, or large initial congestion windows, in overprovisioned,
high-bandwidth environments. We expect there will be an increasing
number of overprovisioned, high-bandwidth environments where the
Quick-Start mechanism, or another mechanism of similar power, could
be of significant benefit to a wide range of traffic. We are
presenting the Quick-Start mechanism as a request for the community
to provide feedback and experimentation on issues relating to Quick-
Start.
14. Acknowledgements
The authors wish to thank Mark Handley for discussions of these The authors wish to thank Mark Handley for discussions of these
issues. The authors also thank the End-to-End Research Group, the issues. The authors also thank the End-to-End Research Group, the
Transport Services Working Group, and members of IPAM's program on Transport Services Working Group, and members of IPAM's program on
Large Scale Communication Networks for both positive and negative Large Scale Communication Networks for both positive and negative
feedback on this proposal. We thank Srikanth Sundarrajan for the feedback on this proposal. We thank Srikanth Sundarrajan for the
initial implementation of Quick-Start in the NS simulator, and for initial implementation of Quick-Start in the NS simulator, and for
the initial simulation study. We also thank Mohammed Ashraf, John the initial simulation study. Many thanks to David Black and Joe
Border, Tom Dunigan, John Heidemann, Paul Hyder, Dina Katabi, and Touch for extensive feedback on QuickStart and IP tunnels. We also
Vern Paxson for feedback. This draft builds upon the concepts thank Mohammed Ashraf, John Border, Martin Duke, Tom Dunigan, Gorry
described in [RFC3390], [AHO98], [RFC2415], and [RFC3168]. Fairhurst, John Heidemann, Paul Hyder, Dina Katabi and Vern Paxson,
for feedback. This draft builds upon the concepts described in
[RFC3390], [AHO98], [RFC2415], and [RFC3168]. Some of the text on
Quick-Start in tunnels was borrowed directly from RFC 3168.
This is a modification of a draft originally by Amit Jain for This is a modification of a draft originally by Amit Jain for
Initial Window Discovery. Initial Window Discovery.
A. Design Decisions A. Design Decisions
A.1. Alternate Mechanisms for the Quick-Start Request: ICMP and RSVP A.1. Alternate Mechanisms for the Quick-Start Request: ICMP and RSVP
This document has proposed using an IP Option for the Quick-Start This document has proposed using an IP Option for the Quick-Start
Request from the sender to the receiver, and using transport Request from the sender to the receiver, and using transport
skipping to change at page 50, line 34 skipping to change at page 59, line 19
is not set [RFC1191]. A Rate Request in bytes per second is is not set [RFC1191]. A Rate Request in bytes per second is
reasonably robust to fragmentation. Clearly a Rate Request in reasonably robust to fragmentation. Clearly a Rate Request in
packets per second is less robust in the presence of fragmentation. packets per second is less robust in the presence of fragmentation.
Interactions between larger initial windows and Path MTU Discovery Interactions between larger initial windows and Path MTU Discovery
are discussed in more detail in RFC 3390 [RFC3390]. are discussed in more detail in RFC 3390 [RFC3390].
For a Quick-Start Request in bytes per second, the transport senders For a Quick-Start Request in bytes per second, the transport senders
would have the additional complication of estimating the bandwidth would have the additional complication of estimating the bandwidth
usage added by the packet headers. usage added by the packet headers.
We have chosen an Rate Request field in bytes per second rather than We have chosen a Rate Request field in bytes per second rather than
in packets per second because it seems somewhat more robust, in packets per second because it seems somewhat more robust,
particularly to routers. particularly to routers.
A.4. Quick-Start Semantics: Total Rate or Additional Rate? A.4. Quick-Start Semantics: Total Rate or Additional Rate?
For a Quick-Start Request sent in the middle of a connection, there For a Quick-Start Request sent in the middle of a connection, there
are two possible semantics for the Rate Request field, as follows: are two possible semantics for the Rate Request field, as follows:
(1) Total Rate: The requested Rate Request is the requested total (1) Total Rate: The requested Rate Request is the requested total
rate for the connection, including the current rate; or rate for the connection, including the current rate; or
skipping to change at page 52, line 38 skipping to change at page 61, line 22
request than was actually approved if the result is going to be a request than was actually approved if the result is going to be a
Quick-Start packet dropped in the network. However, if the receiver Quick-Start packet dropped in the network. However, if the receiver
benefits from a larger Quick-Start window even when the larger benefits from a larger Quick-Start window even when the larger
window results in Quick-Start packets dropped in the network, then window results in Quick-Start packets dropped in the network, then
the receiver has a greater incentive to lie about the received rate the receiver has a greater incentive to lie about the received rate
request, in an effort to get the sender to use a larger initial request, in an effort to get the sender to use a larger initial
sending rate. sending rate.
A.6. Why Not Include More Functionality? A.6. Why Not Include More Functionality?
As Section 6.5 discussed, this proposal for Quick-Start is a rather This proposal for Quick-Start is a rather coarse-grained mechanism
coarse-grained mechanism that would allow connections to use higher that would allow connections to use higher sending rates along
sending rates along underutilized paths, but that does not attempt underutilized paths, but that does not attempt to provide a next-
to provide a next-generation transport protocol, and does not generation transport protocol, and does not attempt the goal of
attempt the goal of providing very high throughput with very low providing very high throughput with very low delay. As Section 11.4
delay. As Section 7.4 discusses, there are a number of proposals discusses, there are a number of proposals such as XCP, MaxNet, and
such as XCP, MaxNet, and AntiECN for more fine-grained per-packet AntiECN for more fine-grained per-packet feedback from routers that
feedback from routers that the current congestion control the current congestion control mechanisms, that do attempt these
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
skipping to change at page 55, line 20 skipping to change at page 64, line 20
+------------------+----------------------+----------------------+ +------------------+----------------------+----------------------+
Relationship to | In addition. | Replacement. Relationship to | In addition. | Replacement.
congestion ctrl: | | congestion ctrl: | |
+------------------+----------------------+----------------------+ +------------------+----------------------+----------------------+
Frequency: | Start-up, or after | Every packet. Frequency: | Start-up, or after | Every packet.
| an idle period. | | an idle period. |
+------------------+----------------------+----------------------+ +------------------+----------------------+----------------------+
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 2: 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,
skipping to change at page 55, line 50 skipping to change at page 64, line 50
hacks but mechanisms that lead the overall architecture in the hacks but mechanisms that lead the overall architecture in the
fundamentally correct direction. fundamentally correct direction.
A.7. The Earlier QuickStart Nonce A.7. The Earlier 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
TCP receiver to the TCP sender in the Quick-Start Response. A transport receiver to the transport sender in the Quick-Start
router could deny the Quick-Start request by failing to decrement Response. A router could deny the Quick-Start request by failing to
the QS TTL field, by zeroing the QS Nonce field, or by deleting the decrement the QS TTL field, by zeroing the QS Nonce field, or by
Quick-Start Request from the packet header. The QS Nonce was deleting the Quick-Start Request from the packet header. The QS
included to provide some protection against broken downstream Nonce was included to provide some protection against broken
routers, or against misbehaving TCP receivers that might be inclined downstream routers, or against misbehaving TCP receivers that might
to lie about whether the Rate Request was approved. This protection be inclined to lie about whether the Rate Request was approved.
is now provided by the use of a random initial value for the QS TTL This protection is now provided by the QS Nonce, by the use of a
field, and by Quick-Start-capable routers hopefully either deleting random initial value for the QS TTL field, and by Quick-Start-
the Quick-Start Option or zeroing the QS TTL field when they deny a capable routers hopefully either deleting the Quick-Start Option or
request. zeroing the QS TTL and QS Nonce fields when they deny a request.
With the old Request-Approved QuickStart Nonce, along with the QS With the old Request-Approved QuickStart Nonce, along with the QS
TTL field set to the same value as the TTL field in the IP header, TTL field set to the same value as the TTL field in the IP header,
the Quick-Start Request mechanism would have been self-terminating; the Quick-Start Request mechanism would have been self-terminating;
the Quick-Start Request would terminate at the first participating the Quick-Start Request would terminate at the first participating
router after a non-participating router had been encountered on the router after a non-participating router had been encountered on the
path. This minimizes unnecessary overhead incurred by routers path. This minimizes unnecessary overhead incurred by routers
because of option processing for the Quick-Start Request. In the because of option processing for the Quick-Start Request. In the
current specification, this "self-terminating" property is provided current specification, this "self-terminating" property is provided
by Quick-Start-capable routers hopefully either deleting the Quick- by Quick-Start-capable routers hopefully either deleting the Quick-
Start Option or zeroing the Rate Request field when they deny a Start Option or zeroing the Rate Request field when they deny a
request. Because the current specification uses a random initial request. Because the current specification uses a random initial
value for the QS TTL, Quick-Start-capable routers can't tell if the value for the QS TTL, Quick-Start-capable routers can't tell if the
Quick-Start Request is invalid because of non-Quick-Start-capable Quick-Start Request is invalid because of non-Quick-Start-capable
routers upstream. This is the cost of using a single field for the routers upstream. This is the cost of using a design that makes it
QS TTL, instead of two fields, one for the QS TTL and another for a difficult for the receiver to cheat about the value of the QS TTL.
QS-Approved Nonce.
The Quick-Start Nonce has been resurrected in the current proposal
for a Rate-Reduced Nonce given in Section 3.6. This proposal would
provide specific protection against receivers lying about whether
the rate request was decremented by routers along the path. In this
proposal, the Rate-Reduced Nonce would be reset to a new random
value by routers that approve the request but decrement the value of
the Rate Request. Thus, if the original value for the Rate-Reduced
Nonce is reported back by the receiver to the sender, then it is
likely that the Rate Request was not decremented or denied by Quick-
Start-capable routers along the path.
B. Quick-Start with DCCP B. Quick-Start with DCCP
DCCP is a new transport protocol for congestion-controlled, DCCP is a new transport protocol for congestion-controlled,
unreliable datagrams, intended for applications such as streaming unreliable datagrams, intended for applications such as streaming
media, Internet telephony, and on-line games. In DCCP, the media, Internet telephony, and on-line games. In DCCP, the
application has a choice of congestion control mechanisms, with the application has a choice of congestion control mechanisms, with the
currently-specified Congestion Control Identifiers (CCIDs) being currently-specified Congestion Control Identifiers (CCIDs) being
CCID 2 for TCP-like congestion control, and CCID 3 for TFRC, an CCID 2 for TCP-like congestion control, and CCID 3 for TFRC, an
equation-based form of congestion control. We refer the reader to equation-based form of congestion control. We refer the reader to
skipping to change at page 59, line 24 skipping to change at page 68, line 12
Second, we define the "target" algorithm for processing incoming Second, we define the "target" algorithm for processing incoming
Quick-Start Rate Requests (also from [SAF05]). The algorithm relies Quick-Start Rate Requests (also from [SAF05]). The algorithm relies
on knowing the bandwidth of the outgoing link (which in many cases on knowing the bandwidth of the outgoing link (which in many cases
can be easily configured), the utilization of the outgoing link can be easily configured), the utilization of the outgoing link
(from an estimation technique such as given above) and an estimate (from an estimation technique such as given above) and an estimate
of the potential bandwidth from recent Quick-Start approvals. of the potential bandwidth from recent Quick-Start approvals.
Tracking the potential bandwidth from recent Quick-Start approvals Tracking the potential bandwidth from recent Quick-Start approvals
is another case where local policy dictates how it should be done. is another case where local policy dictates how it should be done.
The simpliest method, outlined in Section 3.4, is for the router to The simpliest method, outlined in Section 8.2, is for the router to
keep track of the aggregate Quick-Start rate requests approved in keep track of the aggregate Quick-Start rate requests approved in
the most recent two or more time intervals, including the current the most recent two or more time intervals, including the current
time interval, and to use the sum of the aggregate rate requests time interval, and to use the sum of the aggregate rate requests
over these time intervals as the estimate of the approved Rate over these time intervals as the estimate of the approved Rate
Requests. The experiments in [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
skipping to change at page 60, line 10 skipping to change at page 68, line 46
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 gross 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
The Quick-Start Request Option contains a four-bit Reserved field in
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
Approved Rate bit set would not be requesting Quick-Start bandwidth,
but would be reporting the approved rate for Quick-Start bandwidth
that was approved one round-trip time earlier. This could be used
by routers to track which Quick-Start requests were actually
approved and in use, along with the approved rate.
Report of Current Sending Rate: A Quick-Start Request with the
`Report of Current Sending Rate' bit set would be using the Rate
Request field to report the current estimated sending rate for that
connection. This could accompany a second Quick-Start Request in
the same packet containing a standard 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
Sending Rate' would indicate that the connection is not idle or just
starting up, but is attemmpting to use Quick-Start to increase its
current sending rate. This bit would not change the semantics of
the Rate Request field.
RTT Estimate: A field for the RTT Estimate would contain one or more
bits giving the sender's rough estimate of the round-trip time, if
known. E.g., the sender could estimate whether the RTT was greater
or less than 200 ms.
Informational Request: An Informational Request bit would indicate
that a request is purely informational, for the sender to find out
if a rate request would be approved, and what size rate request
would be approved, when the Informational Request is sent. For
example, an Informational Request could be followed one round-trip
time later by a standard Quick-Start Request. A router approving an
Informational Request would not consider this as an approval for
Quick-Start bandwidth to be used, and would not be under any
obligation to approve a similar standard Quick-Start Request one
round-trip time later.
Use Format X for the Rate Request Field: A Quick-Start bit for `Use
Format X for the Rate Request Field' would indicate that an
alternate format was being used for the Rate Request field.
Do Not Decrement: A Do Not Decrement bit could be set in a Quick-
Start request if the sender would rather have the request denied
than to have the rate request decremented in the network. This
could be used if the sender was only interested in using Quick-Start
if the original rate request was approved.
If any of these functions were standardized for Quick-Start, the
standardization would also have to address the issue of backwards
compatibility with older Quick-Start routers or end-nodes that do
not understand the newly-added function.
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
(IPv6) Specification. RFC 2460, December 1998. (IPv6) Specification. RFC 2460, December 1998.
skipping to change at page 60, line 42 skipping to change at page 70, line 42
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.
[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,
October 1996.
[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),
RFC 2409, November 1998.
[RFC2246] T. Dierks and C. Allen, The TLS Protocol, RFC 2246.
[RFC2309] B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, [RFC2309] B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering,
D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L. D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L.
Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang, Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang,
Recommendations on Queue Management and Congestion Avoidance in the Recommendations on Queue Management and Congestion Avoidance in the
Internet, RFC 2309, April 1998. Internet, RFC 2309, April 1998.
[RFC2401] S. Kent and R. Atkinson. Security Architecture for the [RFC2401] S. Kent and R. Atkinson. Security Architecture for the
Internet Protocol. RFC 2401, November 1998. Internet Protocol. RFC 2401, November 1998.
[2401bis] S. Kent and K. Seo, Security Architecture for the Internet
Protocol, internet-draft draft-ietf-ipsec-rfc2401bis-06.txt, work-
in-progress, March 2005.
[RFC2402] S. Kent and R. Atkinson. IP Authentication Header. RFC
2402, November 1998.
[2402bis] S. Kent, IP Authentication Header, internet-draft draft-
ietf-ipsec-rfc2402bis-11.txt work-in-progress, March 2005.
[RFC2415] K. Poduri and K. Nichols. Simulation Studies of Increased [RFC2415] K. Poduri and K. Nichols. Simulation Studies of Increased
Initial TCP Window Size. RFC 2415. September 1998. Initial TCP Window Size. RFC 2415. September 1998.
[RFC2416] T. Shepard and C. Partridge. When TCP Starts Up With Four [RFC2416] T. Shepard and C. Partridge. When TCP Starts Up With Four
Packets Into Only Three Buffers. RFC 2416. September 1998. Packets Into Only Three Buffers. RFC 2416. September 1998.
[RFC2463] A. Conta and S. Deering. Internet Control Message Protocol [RFC2463] A. Conta and S. Deering. Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification.
RFC 2463, December 1998. RFC 2463, December 1998.
[RFC2488] M. Allman, D. Glover, and L. Sanchez. Enhancing TCP Over [RFC2488] M. Allman, D. Glover, and L. Sanchez. Enhancing TCP Over
Satellite Channels using Standard Mechanisms. RFC 2488. January Satellite Channels using Standard Mechanisms. RFC 2488. January
1999. 1999.
[RFC2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, and
B. Palter, Layer Two Tunneling Protocol "L2TP", RFC 2661, August
1999.
[RFC2960] R. Stewart, et. al. Stream Control Transmission Protocol. [RFC2960] R. Stewart, et. al. Stream Control Transmission Protocol.
RFC 2960, October 2000. RFC 2960, October 2000.
[RFC3124] H. Balakrishnan and S. Seshan. The Congestion Manager. RFC [RFC3124] H. Balakrishnan and S. Seshan. The Congestion Manager. RFC
3124. June 2001. 3124. June 2001.
[RFC3234] B. Carpenter and S. Brim, Middleboxes: Taxonomy and
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.
[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
Designers", July 2004.
[RFC3948] A. Huttunen, B. Swander, V. Volpe, L. DiBurro, and M.
Stenberg, UDP Encapsulation of IPsec ESP Packets, RFC 3948, January
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.
[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 [F03] Floyd, S., HighSpeed TCP for Large Congestion Windows, RFC
3649, December 2003. 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
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 [KHR02] Dina Katabi, Mark Handley, and Charles Rohrs, Internet
Congestion Control for Future High Bandwidth-Delay Product Congestion Control for Future High Bandwidth-Delay Product
Environments. ACM Sigcomm 2002, August 2002. URL Environments. ACM Sigcomm 2002, August 2002. URL
"http://ana.lcs.mit.edu/dina/XCP/". "http://ana.lcs.mit.edu/dina/XCP/".
skipping to change at page 62, line 42 skipping to change at page 73, line 31
[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/".
[L05] Guohan Lu, Nonce in TCP Quick Start, draft, September 2005.
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. To appear in
Computer Communications Review, April 2004. Computer Communications Review, April 2004.
[MaxNet] MaxNet Home Page, URL [MaxNet] MaxNet Home Page, URL
skipping to change at page 63, line 43 skipping to change at page 74, line 36
"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.
IANA Considerations E. IANA Considerations
Quick-Start requires an IP Option and a TCP Option. Quick-Start requires an IP Option and a TCP Option.
IP Option E.1. IP Option
Quick-Start requires an IP Option Number to be allocated. The IP Quick-Start requires that both an IPv4 and an IPv6 Option Number be
Option would have a copied flag of 0, a class field of 00, and the allocated. The IPv4 Option would have a copied flag of 0, a class
assigned five-bit option number. The name of the option would be field of 00, and the assigned five-bit option number. The IPv6
"QSR - Quick-Start Request", with this document as the reference Option would have the first three bits of "001" [RFC 2460, Section
document. 4.2], with the first two bits indicating that the IPv6 node skip
over this option and continue processing the header if it doesn't
recognize the option type, and the third bit indicating that the
Option Data may change en-route.
TCP Option In both cases the name of the option would be "QSR - Quick-Start
Request", with this document as the reference document.
E.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 Amit Jain
F5 Networks F5 Networks
Email : a.jain@f5.com Email : a.jain@f5.com
 End of changes. 139 change blocks. 
747 lines changed or deleted 1192 lines changed or added

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