wdiff draft-ietf-tsvwg-quickstart-01.txt draft-ietf-tsvwg-quickstart-02.txt

Internet Engineering Task Force A. Jain
INTERNET-DRAFT F5 Networks
draft-ietf-tsvwg-quickstart-01.txt S. Floyd
Expires: April 2006
INTERNET-DRAFT M. Allman
draft-ietf-tsvwg-quickstart-02.txt ICIR
Expires: September 2006 A. Jain
F5 Networks
P. Sarolahti
Nokia Research Center
13 October 2005
5 March 2006

Quick-Start for TCP and IP

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on April September 2006.

Abstract

This document specifies an optional Quick-Start mechanism for
transport protocols, in cooperation with routers, to determine an
allowed sending rate at the start and at times in the middle of a
data transfer (e.g., after an idle period). While Quick-Start is
designed to be used by a range of transport protocols, in this
document we describe its use with TCP. By using Quick-Start, a TCP
host, say, host A, would indicate its desired sending rate in bytes
per second, using a Quick Start Request option in the IP header of a TCP
packet. Each router along the path could, in turn, either approve
the requested rate, reduce the requested rate, or indicate that the
Quick-Start request is not approved. If the Quick-Start request is
not approved, then the sender would use the default congestion
control mechanisms. The Quick-Start mechanism can determine if
there are routers along the path that do not understand the Quick-Start Request Quick-
Start option, or have not agreed to the Quick-
Start Quick-Start rate request.
TCP host B communicates the final rate request to TCP host A in a
transport-level Quick-Start Response in an answering TCP packet.
Quick-Start is designed to allow connections to use higher sending
rates when there is significant unused 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:

Changes from draft-ietf-tsvwg-quickstart-00: draft-ietf-tsvwg-quickstart-01:
* 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). citation to SPAND: Speeding Up Short Data Transfers.
* Added a new section "Quick-Start and IPsec AH", based sentence in Section 8.1 on feedback
from Joe Touch and David Black. "Implementation Issues for
Processing Quick-Start Requests" about multi-access links.
* Revised "Quick-Start in Mentioned the IP Tunnels" Section, based on feedback
from Joe Touch and David Black. Router Alert option, RFC 2113, in Appendix
A.1.1.
* Added a section discussion of lower-than-best-effort service.
* Added a few sentences about "Possible Uses the requirements for
randomness in the Reserved Fields". nonce.
* Changes from feedback Changed the name of the option from Gorry Fairhurst:
- Section 4.4, revised the explanation for reducing Quick-Start Request
Option to the
congestion window when Quick-Start Option.
* Changed the first ACK for semantics of the Reserved field to the Function
field, adding that a Quick-Start
packet option is received.
- Section 6.4, deleted only interpreted
as a request if this field is zero.
* Changed the last sentence.
- Minor editing changes.
- Revised "Reporting Approved Rate" option from a
"Possible Use" in Appendix D to a required use in Section 4.6.2 3.1,
to say that sender SHOULD send one packet allow routers and receivers some protection against
misbehaving senders.
* Changes from feedback from Bob Briscoe:
- Added Appendix E with an initial RTO a response to Sections 1-3 of three seconds.
Bob Briscoe's document.
- Revised Section 4.6.3 to say Added a clarification that the TCP sender SHOULD use an
initial RTO setting approval of three seconds. a
Quick-Start request at a router does not affect
the treatment of the subsequent arriving
Quick-Start data packets.
- Added text to Section 6.2 on Multiple Paths, discussing
multi-path routing.
- Clarified about GPRS round-trip times. the one-way hash function as an alternate
implementation for the QS Nonce.
- Clarified about PMTUD and the first window phrase "incrementally deployable", adding
the following:
"We note that while Quick-Start is incrementally deployable
in this sense, a Quick-Start request can not be approved
for a particular connection unless both end-nodes and all
of data.
- A small reorganization, rearranging sections.
* Changes from feedback from Martin Duke: the routers along the path have been configured to
support Quick-Start."
- Revised text Clarified semantics about additional rate.
- Said that when denying a rate request, the router
may in the future use the size of QS requests.
- Added some text Nonce field to report
an error code.
- Add Bob's suggestion from Section 4.1, about when to send 4.4 as an alternate
possible rate encoding.
- Made changes suggested in Section 5.1.3 of Bob's paper,
including saying that the router should decrement the QS requests.

Changes from draft-amit-quick-start-04.txt:
* A significant TTL
by the same amount of general editing.
* Because that it decrements the Rate Request field only uses four bits, specified IP TTL (on the
off chance that it decrements the other four bits are reserved, IP TTL by more than one).
- Fixed nits.

Changes from draft-ietf-tsvwg-quickstart-00:
* Added a 30-bit QS Nonce. Based on feedback from Guohan Lu
and talked Gorry Fairhurst (and deleted the text about a possible use for them. This is discussed in
four-bit QS nonce).
* Added a new section "Quick-Start and IPsec AH", based on
"A Rate-Reduced Nonce?"
* Specified that a 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:
* A significant amount of general editing.
* Because the Rate Request field only uses four bits, specified
that the other four bits are reserved, and talked about a
possible use for them. This is discussed in a new section on
"A Rate-Reduced Nonce?"
* Specified that a Quick-Start-capable router denying a request
SHOULD delete the Quick-Start option, and if this is not
possible, SHOULD zero the QS TTL and the Rate Request fields.
* Made the following change: If the Quick-Start Response is lost
in the network, it is not retransmitted.
* For PMTUD, in Section 4.6, added a suggestion to send one large
packet in the initial window for PMTUD, and to send the other
packets at 576 bytes.
* Added a paragraph to Section 4.6.3 on retransmitted SYN packets,
saying they should use an RTO of three seconds and a new ISN
on the retransmitted SYN packet.
* Added that "TCP SHOULD NOT use Quick-Start" after an
application-limited period at this time, in Section 4.1, in
addition to the old sentence that this "requires further thought
and investigation".
* Added an appendix on "Possible Router Algorithm".
* Moved the section on "Quick-Start with DCCP" to the appendix.
* Name changed from draft-amit-quick-start-04.txt to
draft-tsvwg-quickstart-00.txt.

Changes from draft-amit-quick-start-03.txt:
* Added a citation to the paper on "Evaluating Quick-Start for
TCP", and added pointers to the work in that paper.
This work includes:
- Discussions of router algorithms.
- Discussions of sizing Quick-Start requests.
* Added sections on "Misbehaving Middleboxes", and on "Attacks on
Quick-Start".

Changes from draft-amit-quick-start-02.txt:
* Added a discussion on Using Quick-Start in the Middle of a
Connection. The request would be on the total rate,
not on the additional rate.
* Changed name "Initial Rate" to "Rate Request", and changed
the units from packets per second to bytes per second.
* The following sections are new:
- The Quick-Start Request Option for IPv6
- Quick-Start in IP Tunnels
- When to Use Quick-Start
- TCP: Responding to a Loss of a Quick-Start Packet
- TCP: A Quick-Start Request for a Larger Initial Window
- TCP: A Quick-Start Request after an Idle Period
- The Quick-Start Mechanisms in DCCP and other Transport
Protocols
- Quick-Start with DCCP
- Implementation and Deployment Issues
- Design Decisions
* Added a discussion of Kunniyur's Anti-ECN proposal.
* Added a section on simulations, with a brief discussion of the
simulations by Srikanth Sundarrajan.

Changes from draft-amit-quick-start-01.txt:
* Added a discussion in the related work section about the
possibility of optimistically sending a large initial window,
without explicit permission of routers.
* Added a discussion in the related work section about the
tradeoffs of XCP vs. Quick-Start.
* Added a section on "The Quick-Start Request: Packets or Bytes?"

Changes from draft-amit-quick-start-00.txt:
* The addition of a citation to [KHR02].
* The addition of a Related Work section.

* Deleted the QS Nonce, in favor of a random initial value for the
QS TTL.

Table of Contents

1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 9 10
2. Assumptions and General Principles. . . . . . . . . . . . . . 10 11
2.1. Overview of Quick-Start. . . . . . . . . . . . . . . . . 11 13
3. The Quick-Start Request Option in IP IP. . . . . . . . . . . . . . . . . 14 15
3.1. The Quick-Start Request Option for IPv4. . . . . . . . . 14 . . . . 15
3.2. The Quick-Start Request Option for IPv6. . . . . . . . . 16 . . . . 18
3.3. Processing the Quick-Start Request at
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4. The QS Nonce . . 19
3.3.1. Processing the Report of Approved
Rate . . . . . . . . . . . . . . . . . . . . 18 . . . . . . . 20
3.4. The QS Nonce . . . . . . . . . . . . . . . . . . . . . . 21
4. The Quick-Start Mechanisms in TCP . . . . . . . . . . . . . . 20 23
4.1. When to Use Quick-Start. . . . . . . . . . . . . . . . . 21 24
4.2. The Quick-Start Response Option in the TCP
header. . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 26
4.3. TCP: Sending the Quick-Start Response. . . . . . . . . . 24 27
4.4. TCP: Receiving and Using the Quick-Start
Response Packet . . . . . . . . . . . . . . . . . . . . . . . 24 27
4.5. TCP: Responding to a Loss of a Quick-Start
Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 29
4.6. TCP: A Quick-Start Request for a Larger Ini-
tial Window . . . . . . . . . . . . . . . . . . . . . . . . . 27 30
4.6.1. Interactions with Path MTU Discovery. . . . . . . . 27 30
4.6.2. Quick-Start Request Packets that are
Discarded by Middleboxes . . . . . . . . . . . . . . . . . 27 31
4.7. TCP: A Quick-Start Request in the Middle of
a Connection. . . . . . . . . . . . . . . . . . . . . . . . . . 29 32
4.8. An Example Quick-Start Scenario with TCP . . . . . . . . 29 33
5. Quick-Start and IPsec AH. . . . . . . . . . . . . . . . . . . 30 34
6. Quick-Start in IP Tunnels . . . . . . . . . . . . . . . . . . 31 34
6.1. Simple Tunnels That Are Compatible with
Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 33 36
6.1.1. Simple Tunnels that are Aware of Quick-
Start. . . . . . . . . . . . . . . . . . . . . . . . . . . 33 37
6.2. Simple Tunnels That Are Not Compatible with
Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 34 37
6.3. Tunnels That Support Quick-Start . . . . . . . . . . . . 35 38
7. The Quick-Start Mechanism in other Transport Pro-
tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 39
8. Using Quick-Start . . . . . . . . . . . . . . . . . . . . . . 37 40
8.1. Determining the Rate to Request. . . . . . . . . . . . . 37 40
8.2. Deciding the Permitted Rate Request at a
Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 41
9. Evaluation of Quick-Start . . . . . . . . . . . . . . . . . . 38 42
9.1. Benefits of Quick-Start. . . . . . . . . . . . . . . . . 39 42
9.2. Costs of Quick-Start . . . . . . . . . . . . . . . . . . 39 42
9.3. Quick-Start with QoS-enabled Traffic . . . . . . . . . . 41 44
9.4. Protection against Misbehaving Nodes . . . . . . . . . . 41 44
9.4.1. Misbehaving Senders . . . . . . . . . . . . . . . . 44
9.4.2. Receivers Lying about Whether the
Request was Approved . . . . . . . . . . . . . . . . . . . 41
9.4.2. 45
9.4.3. Receivers Lying about the Approved
Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.4.3. 46
9.4.4. Collusion between Misbehaving Routers . . . . . . . 43
9.4.4. 47
9.5. Misbehaving Middleboxes and the IP
TTL. . . . . . . . . . . . . . . . . . . TTL . . . . . . . . . 44
9.5. 49
9.6. Attacks on Quick-Start . . . . . . . . . . . . . . . . . 45
9.6. 49
9.7. Simulations with Quick-Start . . . . . . . . . . . . . . 45 50
10. Implementation and Deployment Issues . . . . . . . . . . . . 46 50
10.1. Implementation Issues for Sending Quick-
Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 46 50
10.2. Implementation Issues for Processing Quick-
Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 47 51
10.3. Possible Deployment Scenarios . . . . . . . . . . . . . 47 51
10.4. Would QuickStart packets take the slow path
in routers? . . . . . . . . . . . . . . . . . . . . . . . . . 48 52
10.5. A Comparison with the Deployment Problems
of ECN. . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 53
11. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 49 53
11.1. Fast Start-ups without Explicit Information
from Routers. . . . . . . . . . . . . . . . . . . . . . . . . 49 53
11.2. Optimistic Sending without Explicit Infor-
mation from Routers . . . . . . . . . . . . . . . . . . . . . 50 55
11.3. Fast Start-ups with other Information from
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 56
11.4. Fast Start-ups with more Fine-Grained Feed-
back from Routers . . . . . . . . . . . . . . . . . . . . . . 52 56
11.5. Fast Start-ups with Lower-Than-Best-Effort
Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
12. Security Considerations. . . . . . . . . . . . . . . . . . . 52 58
13. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . 53 58
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 59
A. Design Decisions. . . . . . . . . . . . . . . . . . . . . . . 54 59
A.1. Alternate Mechanisms for the Quick-Start
Request: ICMP and RSVP. . . . . . . . . . . . . . . . . . . . 54 59
A.1.1. ICMP. . . . . . . . . . . . . . . . . . . . . . . . 54 59
A.1.2. RSVP. . . . . . . . . . . . . . . . . . . . . . . . 56 61
A.2. Alternate Encoding Functions . . . . . . . . . . . . . . 57 62
A.3. The Quick-Start Request: Packets or Bytes? . . . . . . . 58 63
A.4. Quick-Start Semantics: Total Rate or Addi-
tional Rate?. . . . . . . . . . . . . . . . . . . . . . . . . 59 64
A.5. Alternate Responses to the Loss of a Quick-
Start Packet. . . . . . . . . . . . . . . . . . . . . . . . . 60 65
A.6. Why Not Include More Functionality?. . . . . . . . . . . 61 66
A.7. The Earlier Alternate Implementations for a QuickStart
Nonce . . . . . . . . . . . . . . 64
B. Quick-Start with DCCP . . . . . . . . . . . . . . 69
A.7.1. An Alternate Proposal for the Quick-
Start Nonce. . . . . . . 65
C. Possible Router Algorithm . . . . . . . . . . . . . . . . . 69
A.7.2. The Earlier Request-Approved QuickStart
Nonce. . 67
D. Possible Uses for the Reserved Fields . . . . . . . . . . . . 68
Normative . . . . . . . . . . . . . 70
B. Quick-Start with DCCP . . . . . . . . . . . . . . . . . . . . 71
C. Possible Router Algorithm . . . . . . . . . . . . . . . . . . 73
D. Possible Additional Uses for the Quick-Start
Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
E. Feedback from Bob Briscoe . . . . . . . . . . . . . . . . . . 75
E.1. Potential Deployment Scenarios . . . . . . . . . . . . . 76
E.2. Misbehaving Senders and Receivers. . . . . . . . . . . . 76
E.3. Fairness . . . . . . . . . . . . . . . . . . . . . . . . 77
E.4. Models of Under-Utilization. . . . . . . . . . . . . . . 78
E.5. Router Algorithms as Local Policy. . . . . . . . . . . . 78
E.6. An Alternate Proposal. . . . . . . . . . . . . . . . . . 79
Normative References . . . . . . . . . . . . . . . . . . . . . . 70 79
Informative References . . . . . . . . . . . . . . . . . . . . . 70
E. 80
F. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74
E.1. 85
F.1. IP Option. . . . . . . . . . . . . . . . . . . . . . . . 74
E.2. 85
F.2. TCP Option . . . . . . . . . . . . . . . . . . . . . . . 75 85
AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 75 85
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 75 87
Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 76 87

1. Introduction

Each TCP connection begins with a question: "What is the appropriate
sending rate for the current network path?" The question is not
answered explicitly for TCP, explicitly, but each TCP connection determines the sending
rate by probing the network path and altering the congestion window
(cwnd) based on perceived congestion. Each TCP connection starts
with a pre-configured initial congestion window (ICW). Currently,
TCP allows an initial window of between one and four MSS-sized
segments [RFC2581,RFC3390]. The TCP connection then probes the
network for available bandwidth using the slow-start procedure
[Jac88,RFC2581], doubling cwnd during each congestion-free round-
trip time (RTT).

The slow-start algorithm can be time-consuming --- especially over
networks with large bandwidth or long delays. It may take a number
of RTTs in slow-start before the TCP connection begins to fully use
the available bandwidth of the network. For instance, it takes
log_2(N) - 2 round-trip times to build cwnd up to N segments,
assuming an initial congestion window of 4 segments. This time in
slow-start is not a problem for large file transfers, where the
slow-start stage is only a fraction of the total transfer time.
However, in the case of moderate-sized transfers the connection
might carry out its entire transfer in the slow-start phase, taking
many round-trip times, where one or two RTTs might have been
appropriate in the current network conditions.

A fair amount of work has already been done to address the issue of
choosing the initial congestion window for TCP, with RFC 3390
allowing an initial window of up to four segments based on the MSS
used by the connection [RFC3390]. Our underlying premise is that
explicit feedback from all of the routers along the path would be
required, in the current architecture, for best-effort connections
to use initial windows significantly larger than those allowed by
[RFC3390], in the absence of other information about the path.

The Congestion Manager [RFC3124] and TCP control block sharing
[RFC2140] both propose sharing congestion information among multiple
TCP connections with the same endpoints. With the Congestion
Manager, a new TCP connection could start with a high initial cwnd
if it was sharing the path and the cwnd with a pre-existing TCP
connection to the same destination that had already obtained a high
congestion window. RFC 2140 discusses ensemble sharing, where an
established connection's congestion window could be `divided up' to
be shared with a new connection to the same host. However, neither
of these approaches addresses the case of a connection to a new
destination, with no existing or recent connection (and therefore
congestion control state) to that destination.

Quick-Start would not be the first mechanism for explicit
communication from routers to transport protocols about sending
rates. Explicit Congestion Notification (ECN) gives explicit
congestion control feedback from routers to transport protocols,
based on the router detecting congestion before buffer overflow
[RFC3168]. In contrast, routers would not use Quick-Start to get give
congestion information, but instead would use Quick-Start as an
optional mechanism to give permission to transport protocols to use
higher sending rates, based on the ability of all the routers along
the path to determine if their respective output links are
significantly underutilized.

2. Assumptions and General Principles

This section describes the assumptions and general principles behind
the design of the Quick-Start mechanism.

Assumptions:

* The data transfer in the two directions of a connection traverses
different queues, and possibly even different routers. Thus, any
mechanism for determining the allowed sending rate would have to be
used independently for each direction.

* The path between the two endpoints is relatively stable, such that
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]
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
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-
hosts without disturbing the current Internet semantics.

General Principles:

* Our underlying premise is We note
that explicit while Quick-Start is incrementally deployable in this sense, a
Quick-Start request can not be approved for a particular connection
unless both end-nodes and all of the routers along the path have
been configured to support Quick-Start.

General Principles:

* Our underlying premise is that explicit feedback from all of the
routers along the path would be required, in the current
architecture, for best-effort connections to use initial windows
significantly larger than those allowed by [RFC3390], in the absence
of other information about the path.

* A router should only approve a request for a higher sending rate
if the output link is underutilized. Any other approach will result
in either per-flow state at the router, or the possibility of a
(possibly transient) queue at the router.

* No per-flow state should be required at the router. Note that
while per-flow state is not required required, we also do not preclude a
router from storing per-flow state for making Quick-Start decisions. decisions
or for checking for misbehaving nodes.

There are also a number of questions regarding the Quick-Start
mechanism that are discussed later in this document.

Questions:

* Would the benefits of the Quick-Start mechanism be worth the added
complexity?

The benefits and drawbacks of Quick-Start are discussed in more
detail in Section 9 on "Evaluation of Quick-Start".

* One practical consideration is that packets with known and unknown
IP options are often dropped in the current Internet [MAF04].

This

We note that this does not preclude using Quick-Start in Intranets.
Further, [MAF04] also shows that over time the blocking of packets
negotiating ECN has become less common, and therefore an incremental
deployment story for Quick-Start based on IP Options is not out of
the question. question for the Internet. Appendix A.1 on "Alternate
Mechanisms for the Quick-
Start Quick-Start Request" discusses the possibility of
using RSVP or ICMP instead of IP Options for carrying Quick-Start
Requests to routers.

* A second practical consideration is that Quick-Start data packets
could be dropped at non-IP queues along the path. path, if the non-IP
queue is a point of congestion. This is discussed in more detail in
Section 9.2 . 9.2.

* Apart from the merits and shortcomings of the Quick-Start
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
ways to incorporate Quick-Start in mechanisms that, while more
complex, are also sufficiently more powerful than Quick-Start, or
should Quick-Start be considered as orthogonal to such mechanisms?
This is discussed further in Appendix A.6 on "Why Not Include More
Functionality".

2.1. Overview of Quick-Start

In this section we give an overview of the use of Quick-Start with
TCP,
TCP to request a higher congestion window. The description in this
section is non-normative; the normative description of Quick-Start
with IP and TCP follows in Sections 3 and 4. Quick-Start can could be
used in the middle of a connection, e.g., after an idle or
underutilized period, as well as for the initial sending rate; these
uses of Quick-Start are discussed later in the document.

Quick-Start requires end-points and routers to work together, with
end-points requesting a higher sending rate in the Quick-Start
Request (QSR) (QS)
option in IP, and routers along the path approving, modifying,
discarding or ignoring (and therefore disallowing) the Quick-Start
Request. The receiver uses reliable, transport-level mechanisms to
inform the sender of the status of the Quick-Start Request. In
addition, Quick-Start assumes a unicast, congestion-
controlled congestion-controlled
transport protocol; we do not consider the use of Quick-
Start Quick-Start for
multicast traffic.

The

When sent as a request, the Quick-Start Request Option includes a request
for a sending rate in bytes per second, and a Quick-Start TTL (QS
TTL) to be decremented by every router along the path that
understands the option and approves the request. The Quick-Start
TTL is initialized by the sender to a random value. The transport
receiver returns the rate and information about the TTL to the
sender using transport-
level transport-level mechanisms. In particular, the
receiver computes the difference between the Quick-Start TTL and the
IP TTL (the TTL in the IP header) of the Quick-Start request packet,
and returns this in the Quick-Start response. The sender uses this
information to determine if all of the routers along the path
decremented the Quick-Start TTL, approving the Quick-Start Request.

If the request is approved by all of the routers along the path,
then the TCP sender combines this allowed rate with the measurement
of the round-trip time, and ends up with an allowed TCP congestion
window. This window is sent rate-paced over the next round-trip
time, or until an ACK packet is received.

Figure 1 shows a successful use of Quick-Start, with both routers
along the path approving the Quick-Start Request. In this example,
Quick-Start is used by TCP to establish the initial congestion
window.

Figure 1: A successful Quick-Start Request.

Figure 2 shows an unsuccessful use of Quick-Start, with one of the
routers along the path not approving the Quick-Start Request. If
the Quick-Start Request is not approved, then the sender uses the
default congestion control mechanisms for that transport protocol,
including the default initial congestion window, response to idle
periods, etc.

Figure 2: An unsuccessful Quick-Start Request.

3. The Quick-Start Request Option in IP

3.1. The Quick-Start Request Option for IPv4

The Quick-Start Request for IPv4 is defined as follows:

Figure 3. The Quick-Start Request Option for IPv4.
A Quick-Start Request.

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
assigned by IANA).

The second byte contains the length field, indicating an option
length of eight bytes.

The third byte includes a four-bit Function field. If the Function
field is set to "0000", then the Quick-Start Option is a Rate
Request. In this case, the second half of the third byte is a four-
bit Rate Request field.

For a Rate Request, the fourth byte contains the Quick-Start TTL (QS
TTL) field. The sender MUST set the QS TTL field to a random value.
Routers that approve the Quick-Start Request decrement the QS TTL
(mod 256). 256) by the same amount that they decrement the IP TTL. The QS
TTL is used by the sender to detect if all of the routers along the
path understood and approved the Quick-Start option.

The

For a Rate Request, the transport sender MUST calculate and store
the TTL Diff, the difference between the IP TTL value and the QS TTL
value in the Quick-Start request packet, as follows:

TTL Diff = ( IP TTL - QS TTL ) mod 256 (1)

The fourth byte includes a four-bit Reserved field, and

For a four-bit Rate Request field. The Request, the second four bytes contain a 30-bit QS Nonce
and a two-bit Reserved field. The sender SHOULD set the reserved
fields
field to zero, and routers SHOULD ignore the reserved fields. field. The
sender SHOULD set the 30-bit QS Nonce to a random value.

The sender initializes the Rate Request to the desired sending rate,
including an estimate of the transport and IP header overhead. The
encoding function for the Rate Request sets the request rate to
K*2^N bps (bits per second), for N the value in the Rate Request
field, and for K set to 40,000. For N=0, the rate request would be
set to zero, regardless of the encoding function. This is
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)
--- -------------------
0 0
1 80
2 160
3 320
4 640
5 1,280
6 2,560
7 5,120
8 10,240
9 20,480
10 40,960
11 81,920
12 163,840
13 327,680
14 655,360
15 1,310,720

Table 1: Mapping from Rate Request field to rate request in Kbps.

Routers can approve the Quick-Start Request for a lower rate by
decreasing the Rate Request in the Quick-Start Request.

We note that unlike a Quick-Start Request sent at Section 4.2
discusses the beginning of a
connection, when a Quick-Start Request is sent in Response from the middle of a
connection, TCP receiver to the connection could already have an established
congestion window or sending rate. The Rate Request is TCP
sender, and Section 4.4 discusses the
requested total rate TCP sender's mechanism for the connection, including the current rate
of the connection; the Rate Request is *not* a request for an
additional sending rate over and above the current sending rate. If
the Rate Request is denied, or lowered to a value below the
connection's current sending rate, then the sender ignores the
request, and reverts to the default congestion control mechanisms of
the transport protocol.

In IPv4,
determining if a change in IP options at routers requires recalculating
the IP header checksum.

3.2. The Quick-Start Request Option for IPv6

The Quick-Start Request Option for IPv6 is placed in the Hop-by-Hop
Options extension header that is processed at every network node
along the communication path [RFC 2460]. The option format following
the generic Hop-by-Hop Options header is similar to the IPv4 format
with the exception that the Length field should exclude the common
type and length fields in the option format and be set to 6 bytes. has been approved.

Figure 4. The Quick-Start Request Option for IPv6.

The transport receiver compares the Quick-Start TTL with IPv4.
Report of Approved Rate.

If the IPv6
Hop Limit Function field in order to calculate the TTL Diff. (The Hop Limit
in IPv6 third byte of the Quick-Start Option is
set to "1000", then the equivalent Quick-Start Option is a Report of Approved
Rate. In this case the TTL second four bits in IPv4.) That is, TTL Diff
MUST be calculated and stored the third byte are the
Rate Report field, formatted exactly as follows:

TTL Diff = ( IPv6 Hop Limit - QS TTL ) mod 256 (2)

Unlike IPv4, modifying or deleting in the Quick-Start Rate Request IPv6 field in
a Rate Request. For a Report of Approved Rate, the last five bytes
of the Quick-Start Option does are not require checksum re-calculation, because used.

After an approved Rate Request, the IPv6
header does not have sender MUST report the Approved
Rate, using a checksum field, and modifying Quick-Start Option configured as a Report of Approved
Rate with the Rate Report field set to the approved rate. The
packet containing the Report of Approved Rate MUST be either a
control packet sent before the first Quick-Start
Request data packet, or a
Quick-Start Option in the IPv6 Hop-by-Hop options header first data packet itself. The Report of
Approved Rate does not affect have to be sent reliably; for example, if the
IPv6 pseudo-header checksum used
approved rate is reported in upper-layer checksum
calculations.

Note that [RFC2460] specifies that when a specific flow label has
been assigned to packets, the contents of the Hop-by-Hop options,
excluding separate control packet, the next header field, must originate with sender
does not necessarily know if the same
contents throughout control packet has been dropped in
the IP flow lifetime. However, network.

If the Quick-Start Rate Request option would be included in only is denied, the sender MUST sent a small fraction Report of
Approved Rate with the
packets during Rate Report field set to zero.

We note that unlike a flow lifetime. Thus, Quick-Start SHOULD NOT be
used in an IPv6 connection that uses flow labels unless Request sent at the
experimental specification of flow labels in Appendix A beginning of RFC 2460 a
connection, when a Quick-Start Request is changed. We note that RFC 2460 states that sent in the use middle of a
connection, the flow
label field in IPv6 "is, at connection could already have an established
congestion window or sending rate. The Rate Request is the time
requested total rate for the connection, including the current rate
of writing, still experimental
and subject to change as the requirements connection; the Rate Request is *not* a request for flow support in an
additional sending rate over and above the
Internet become clearer" [RFC2460].

3.3. Processing current sending rate. If
the Quick-Start Rate Request at Routers

Each participating router can either terminate is denied, or approve lowered to a value below the Quick-
Start Request. The router terminates
connection's current sending rate, then the Quick-Start Request if sender ignores the
router is not underutilized,
request, and therefore has decided not reverts to grant the Quick-Start Request.

A router default congestion control mechanisms of
the transport protocol.

We note that wishes to terminate in IPv4, a change in IP options at routers requires
recalculating the IP header checksum.

3.2. The Quick-Start Request SHOULD
delete the Option for IPv6

The Quick-Start Request from Option for IPv6 is placed in the IP header. This saves
resources as downstream routers will have no Hop-by-Hop Options
extension header that is processed at every network node along the
communication path [RFC 2460]. The option format following the
generic Hop-by-Hop Options header is identical to process. If
a Quick-Start-capable router wishes to deny the request but doesn't
delete IPv4 format,
with the Quick-Start Request from exception that the IP header, then Length field should exclude the router
SHOULD zero common
type and length fields in the QS TTL, QS Nonce, option format and Rate Request fields. This may be more efficient for routers set to implement than deleting the Quick-
Start option. A router that doesn't understand the 6 bytes
instead of 8 bytes.

For a Quick-Start
option will simply forward Request, the packet with transport receiver compares the
Quick-Start Request
unchanged.

If TTL with the participating router has decided IPv6 Hop Limit field in order to approve the Quick-Start
Request, it does the following:

* The router MUST decrement calculate
the QS TTL by one.

* If the router is only willing to approve a Rate Request less than
that Diff. (The Hop Limit in IPv6 is the Quick-Start Request, then the router replaces the Rate
Request with a smaller value. The router MUST NOT increase equivalent of the Rate
Request TTL
in the Quick-Start Request. If the router decreases the
Rate Request, the router IPv4.) That is, TTL Diff MUST also modify the QS Nonce, be calculated and stored as described
in Section 3.4.

* In
follows:

TTL Diff = ( IPv6 Hop Limit - QS TTL ) mod 256 (2)

Unlike IPv4, modifying or deleting the router MUST update Quick-Start IPv6 Option does
not require checksum re-calculation, because the IP IPv6 header checksum.

A non-participating router forwards does
not have a checksum field, and modifying the Quick-Start Request
unchanged, without decrementing in
the QS TTL. The non-participating
router still decrements IPv6 Hop-by-Hop options header does not affect the TTL field IPv6 pseudo-
header checksum used in the IP header, as is
required for all routers [RFC1812]. As upper-layer checksum calculations.

Note that [RFC2460] specifies that when a result, the sender will be
able specific flow label has
been assigned to detect that packets, the Quick-Start Request had not been understood
or approved by all contents of the routers along Hop-by-Hop options,
excluding the path.

3.4. The QS Nonce

The QS Nonce gives next header field, must originate with the Quick-Start sender some protection against
receivers lying about same
contents throughout the value IP flow lifetime. However, the Quick-Start
option would be included in only a small fraction of the received Rate Request. This 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 particularly important if changed.
We note that RFC 2460 states that the receiver knows use of the original value flow label field in
IPv6 "is, at the time of writing, still experimental and subject to
change as the Rate requirements for flow support in the Internet become
clearer" [RFC2460].

3.3. Processing the Quick-Start Request (e.g., when at Routers

The Quick-Start Request does not report the sender always requests current sending rate of
the same
value, and connection sending the receiver has a long history request; in the default case of communication with a router
that sender.) Without does not maintain per-flow state, a router makes the QS Nonce, there
conservative assumption that the flow's current sending rate is nothing
zero. Each participating router can either terminate or approve the
Quick-Start Request. A router should only approve a Quick-Start
request if the output link is underutilized, and if the router
judges that the output link will continue to prevent be underutilized if the
receiver from reporting back
request is approved. Otherwise, the router terminates the Quick-
Start Request.

A router that wishes to terminate the sender a Rate Quick-Start Request of K, when SHOULD
delete the received Rate Quick-Start Request was in fact less than K. This version of
the nonce is based on a proposal from Guohan Lu [L05]. Initial
versions of this document contained an eight-bit QS Nonce, and
subsequent versions discussed the possibility of a four-bit QS
Nonce.

Table 2 gives the format for the 30-bit QS Nonce.

Bits Purpose
--------- ------------------
Bits 0-1: Rate 15 -> Rate 14
Bits 2-3: Rate 14 -> Rate 13
Bits 4-5: Rate 13 -> Rate 12
Bits 6-7: Rate 12 -> Rate 11
Bits 8-9: Rate 11 -> Rate 10
Bits 10-11: Rate 10 -> Rate 9
Bits 12-13: Rate 9 -> Rate 8
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

Table 2: The QS Nonce.

The transport sender MUST initialize the QS Nonce IP header. This saves
resources as downstream routers will have no option to a random value. process. If the
a Quick-Start-capable router reduces wishes to deny the Rate request but doesn't
delete the Quick-Start Request from rate K to rate K-1, the IP header, then the router MUST set the field in
SHOULD zero the QS Nonce for "Rate K -> TTL, QS Nonce, and Rate
K-1" to a new random value. Similarly, if the router reduces Request fields. Zeroing
the Rate Request by N steps, the router MUST set the 2N bits in field may be more efficient for routers to
implement than deleting the
relevant fields Quick-Start option. As suggested in
[B05], future additions to Quick-Start could define error codes for
routers to insert into the QS Nonce field to report back to the
sender the reason that the Quick-Start request was denied, e.g.,
that the router is denying all Quick-Start requests at this time, or
that this router as a new random value. matter of policy does not grant Quick-Start
requests. A router that doesn't understand the Quick-Start option
will simply forward the packet with the Quick-Start Request
unchanged.

If the participating router has decided to approve the Quick-Start
Request, it does the following:

* The receiver router MUST report decrement the QS Nonce back to the sender. TTL by one.

* If the router is only willing to approve a Rate Request was not decremented less than
that in the network, Quick-Start Request, then the QS
Nonce should have its original router replaces the Rate
Request with a smaller value. Similarly, if The router MUST NOT increase the Rate
Request was decremented by N steps in the network, and Quick-Start Request. If the receiver
reports back a Rate Request of K, then router decreases the last 2K bits of
Rate Request, the QS
Nonce should have their original value.

With router MUST also modify the QS Nonce, the receiver has a 1/4 chance of cheating about
each step change as described
in Section 3.4.

* In IPv4, the rate request. Thus, if router MUST update the rate request was
reduced by two steps in IP header checksum.

If the network, router approves the receiver has Quick-Start request, this approval SHOULD
be taken into account in the router's decision to accept or reject
subsequent Quick-Start requests (e.g., in a 1/16 chance
of successfully reporting variable that tracks the original request was approved, as
this requires reporting
recent aggregate of accepted Quick-Start bandwidth), but this
approval SHOULD NOT be used by the original value for router to affect the QS nonce.
Similarly, if treatment of
the rate request is reduced many steps data packets that arrive from this connection in the network,
and next few
round-trip times. That is, the receiver receives a QS Option with a rate request of K, approval by the
receiver has a 1/16 chance router of guessing the original values for the
fields in the QS nonce for "Rate K+2 -> Rate K+1" and "Rate K+1 ->
Rate K". Thus, the receiver has a 1/16 chance in successfully lying
and saying Quick-
Start request does not give differential treatment for Quick-Start
data packets at that router; it is only a statement from the received rate request was K+2 instead of K.

We note router
that the protection offered by router believes that the QS Nonce is subsequent Quick-Start data
packets from this connection will not change the same
whether one router makes all current under-
utilized state of the decrements in router.

A non-participating router forwards the rate request,
or whether they are made at different routers along Quick-Start Request
unchanged, without decrementing the path. QS TTL. The requirements for randomization for non-participating
router still decrements the sender and routers in
setting `random' values TTL field in the QS Nonce are not stringent - almost
any form of pseudo-random numbers would do. The requirement from IP header, as is
required for all routers [RFC1812]. As a result, the sender is will be
able to detect that the original value for the QS Nonce is Quick-Start Request had not easily
guessable been understood
or approved by the receiver. Thus, if two bits all of the QS Nonce are
changed by a router routers along the path, the receiver should not be able
to guess those two bits from the other 28 bits in path.

3.3.1. Processing the QS Nonce.

A requirement Report of Approved Rate

If the routers is that Quick-Start Option has the receiver can not be able Function field set to
tell, from the QS Nonce itself, which numbers in the QS Nonce were
generated by the sender, "1000", then
this is a Report of Approved Rate, rather than a Rate Request. The
router MAY ignore such an option, and which were generated by routers along
the path. This makes in any case it harder for the receiver to infer MUST NOT modify
the value contents of the original rate request, making it one step harder option for the
receiver to cheat.

Section 9.4 also considers issues a Report of receiver cheating in more
detail.

4. The Quick-Start Mechanisms in TCP

This section describes how the Quick-Start mechanism would be used
in TCP. We first sketch Approved Rate. However,
the procedure and then tightly define it in router MAY use the subsequent subsections.

If a TCP sender, say host A, would like Approved Rate report to use Quick-Start, check that the TCP sender puts
is not lying about the approved rate. If the reported Approved Rate
is higher than the requested sending rate in bytes per second,
appropriately formatted, that the router actually approved for this
connection in the previous round-trip time, then the router may
decide to deny future Quick-Start Request option requests from this sender,
including, if desired, deleting Quick-Start requests from future
packets from this sender. Section 9.4.1 discusses misbehaving
senders in more detail. From the IP
header Report of Approved Rate, the TCP packet, called
router can also learn if some of the downstream routers have
approved the Quick-Start request packet.
(We will be somewhat loose in our use of "packet" vs. "segment" in
this section.) The Quick-Start Request also includes random values for the QS TTL a smaller rate, and adjust its
bandwidth allocations accordingly. From a Report of Approved Rate
with a Rate Report of zero, the QS Nonce. When used for initial start-up,
the Quick-Start request packet router can be either learn if downstream
routers denied the SYN or SYN/ACK
packet, as described above. earlier Quick-Start request.

3.4. The requested rate includes an estimate
for the transport and IP header overhead. QS Nonce

The TCP receiver, say
host B, returns QS Nonce gives the Quick-Start Response option in the TCP header in
the responding SYN/ACK packet or ACK packet, called sender some protection against
receivers lying about the Quick-Start
response packet, informing host A value of the results of their request.

If received Rate Request. This
is particularly important if the acknowledging packet does not contain a Quick-Start Response,
or contains a Quick-Start Response with receiver knows the wrong original value for
of the TTL
Diff or Rate Request (e.g., when the QS Nonce, then host A MUST assume that its Quick-Start
request failed. In this case, host A uses TCP's default congestion
control procedure. For initial start-up, host A uses sender always requests the default
initial congestion window.

If same
value, and the returning packet contains receiver has a valid Quick-Start Response, then
host A uses the information in the response, along with its
measurement long history of communication with
that sender). Without the round-trip time, QS Nonce, there is nothing to determine prevent the Quick-Start
congestion window (QS-cwnd). Quick-Start packets are defined as
packets sent as the result of a successful Quick-Start request, up
receiver from reporting back to the time sender a Rate Request of K, when
the first Quick-Start packet is acknowledged. In
order to use Quick-Start, the TCP host MUST use rate-based pacing to
transmit Quick-Start packets at the rate indicated received Rate Request was in the Quick-
Start Response, at the level fact less than K. This version of granularity possible by the sending
host. We note that
the limitations of interrupt timing nonce is based on computers
can limit the ability of the TCP host in rate-pacing the outgoing
packets.

The two TCP end-hosts can independently decide whether to request
Quick-Start. For example, host A could sent a Quick-Start Request
in the SYN packet, proposal from Guohan Lu [L05]. Initial
versions of this document contained an eight-bit QS Nonce, and host B could also send a Quick-Start Request
in the SYN/ACK packet.

4.1. When to Use Quick-Start

In addition to
subsequent versions discussed the use possibility of Quick-Start when a connection is
established, there are several additional points in a connection
when a transport protocol may want to issue a Rate Request. We
first re-iterate four-bit QS
Nonce.

Table 2 gives the notion that Quick-Start is a coarse-grained
mechanism. That is, Quick-Start's Rate Requests are not meant to be
used format for fine-grained control of the transport's sending rate.
Rather, the transport MAY issue a 30-bit QS Nonce.

Bits Purpose
--------- ------------------
Bits 0-1: Rate Request when no information
about the appropriate sending rate is available, and the default
congestion control mechanisms 15 -> Rate 14
Bits 2-3: Rate 14 -> Rate 13
Bits 4-5: Rate 13 -> Rate 12
Bits 6-7: Rate 12 -> Rate 11
Bits 8-9: Rate 11 -> Rate 10
Bits 10-11: Rate 10 -> Rate 9
Bits 12-13: Rate 9 -> Rate 8
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

Table 2: The QS Nonce.

The transport sender MUST initialize the QS Nonce to a random value.
If the router reduces the Rate Request from rate K to rate K-1, then
the router MUST set the field in the QS Nonce for "Rate K -> Rate
K-1" to a new random value, using the requirements for "randomness"
in the previous paragraph. Similarly, if the router reduces the
Rate Request by N steps, the router MUST set the 2N bits in the
relevant fields in the QS Nonce to a new random value. The receiver
MUST report the QS Nonce back to the sender.

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.

With the QS Nonce, the receiver has a 1/4 chance of cheating about
each step change in the rate request. Thus, if the rate request was
reduced by two steps in the network, the receiver has a 1/16 chance
of successfully reporting that the original request was approved, as
this requires reporting the original value for the QS nonce.
Similarly, if the rate request is reduced many steps in the network,
and the receiver receives a QS Option with a rate request of K, the
receiver has a 1/16 chance of guessing the original values for the
fields in the QS nonce for "Rate K+2 -> Rate K+1" and "Rate K+1 ->
Rate K". Thus, the receiver has a 1/16 chance in successfully lying
and saying that the received rate request was K+2 instead of K.

We note that the protection offered by the QS Nonce is the same
whether one router makes all of the decrements in the rate request,
or whether they are made at different routers along the path.

The requirements for randomization for the sender and routers in
setting `random' values in the QS Nonce are not stringent - almost
any form of pseudo-random numbers would do. The requirement is that
the original value for the QS Nonce is not easily guessable by the
receiver, and in particular, the nonce MUST NOT be easily determined
from inspection of the rest of the packet or from previous packets.
In particular, the nonce MUST NOT be based only on a combination of
specific packet header fields. Thus, if two bits of the QS Nonce
are changed by a router along the path, the receiver should not be
able to guess those two bits from the other 28 bits in the QS Nonce.

An additional requirement is that the receiver can not be able to
tell, from the QS Nonce itself, which numbers in the QS Nonce were
generated by the sender, and which were generated by routers along
the path. This makes it harder for the receiver to infer the value
of the original rate request, making it one step harder for the
receiver to cheat.

Section 9.4 also considers issues of receiver cheating in more
detail.

4. The Quick-Start Mechanisms in TCP

This section describes how the Quick-Start mechanism would be used
in TCP. We first sketch the procedure and then tightly define it in
the subsequent subsections.

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,
appropriately formatted, in the Quick-Start option in the IP header
of the TCP packet, called the Quick-Start request packet. (We will
be somewhat loose in our use of "packet" vs. "segment" in this
section.) The Quick-Start Request also includes random values for
the QS TTL and the QS Nonce. When used for initial start-up, the
Quick-Start request packet can be either the SYN or SYN/ACK packet,
as described above. The requested rate includes an estimate for the
transport and IP header overhead. The TCP receiver, say host B,
returns the Quick-Start Response option in the TCP header in 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,
or contains a Quick-Start Response with the wrong value for the TTL
Diff or the QS Nonce, then host A MUST assume that its Quick-Start
request failed. In this case, host A sends a Report of Approved
Rate with a Rate Report of zero, and uses TCP's default congestion
control procedure. For initial start-up, host A uses the default
initial congestion window.

If the returning packet contains a valid Quick-Start Response, then
host A uses the information in the response, along with its
measurement of the round-trip time, to determine the Quick-Start
congestion window (QS-cwnd). Quick-Start data packets are defined
as data packets sent as the result of a successful Quick-Start
request, up to the time when the first Quick-Start packet is
acknowledged. The sender sends a Report of Approved Rate. In order
to use Quick-Start, the TCP host MUST use rate-based pacing to
transmit Quick-Start packets at the rate indicated in the Quick-
Start Response, at the level of granularity possible by the sending
host. We note that the limitations of interrupt timing on computers
can limit the ability of the TCP host in rate-pacing the outgoing
packets.

The two TCP end-hosts can independently decide whether to request
Quick-Start. For example, host A could sent a Quick-Start Request
in the SYN packet, and host B could also send a Quick-Start Request
in the SYN/ACK packet.

4.1. When to Use Quick-Start

In addition to the use of Quick-Start when a connection is
established, there are several additional points in a connection
when a transport protocol may want to issue a Rate Request. We
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
used for fine-grained control of the transport's sending rate.
Rather, the transport MAY issue a Rate Request when no information
about the appropriate sending rate is available and the default
congestion control mechanisms might be significantly underestimating
the appropriate sending rate.

The following are potential points where Quick-Start may be useful:

(1) At or soon after connection initiation, when the transport
has no idea of the capacity of the network, as discussed above.
(A transport that uses TCP Control Block sharing, the Congestion
Manager, or the like may not need Quick-Start to determine an
appropriate rate.)
(2) After an idle period when the transport no longer has a
validated estimate of the available bandwidth for this flow.
(An example could be a persistent-HTTP connection when a new
HTTP request is received after an idle period.)

(3) After a host has received explicit indications that one of
the endpoints has moved its point of network attachment. This
can happen due to some underlying mobility mechanism like Mobile
IP [RFC3344,RFC3775]. Some transports, such as SCTP [RFC2960],
may associate with multiple IP addresses and can switch
addresses (and, therefore network paths) in mid-connection. If
the transport has concrete knowledge of a changing network path
then the current sending rate may not be appropriate and the
transport sender may use Quick-Start to probe the network for
the appropriate rate at which to send. see
if it can send at a higher rate. (Alternatively, traditional
slow-start should be used in this case when Quick-
Start Quick-Start is not
available.)

(4) After an application-limited period when the sender has been
using only a small amount of its appropriate share of the
network capacity, and has no valid estimate for its fair share.
In this case, Quick-Start may be an appropriate mechanism to
assess the available capacity on
determine if the network path. sender can send at a higher rate. For
instance, consider an application that steadily exchanges low-
rate control messages and suddenly needs to transmit a large
amount of data.

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
a TCP sender use Quick-Start for case (3) at the current time. Case
(3) requires external notifications not presently defined for TCP or
other transport protocols. Finally, a TCP SHOULD NOT use Quick-
Start for case (4) at the current time. Case (4) requires further
thought and investigation with regard to how the transport protocol
could determine it was in a situation that would warrant
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
connection initiation, and Section 4.7 discusses issues that arise
when Quick-Start is used to request a larger sending rate after an
idle period.

4.2. The Quick-Start Response Option in the TCP header

In order to approve the use of Quick-Start, the TCP receiver
responds to the receipt of a Quick-Start Request with a Quick-Start
Response, using the Quick-Start Response Option in the TCP header.
TCP's Quick-Start Response option is defined as follows:

Figure 6. 5. The Quick-Start Response option in the TCP header.

The first byte of the Quick-Start Response option contains the
option kind, identifying the TCP option (to be assigned by IANA).

The second byte of the Quick-Start Response option contains the
option length in bytes. The length field MUST be set to four bytes.

The third byte of the Quick-Start Response option contains a four-
bit Reserved field, and Quick-Start Response option contains a four-
bit Reserved field, and the four-bit allowed Rate Request, formatted
as in the Quick-Start option.

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
the received Quick-Start request packet, as calculated in equations
(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

An end host, say host B, that receives an IP packet containing a
Quick-Start Request passes the Quick-Start Request, along with the
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
Quick-Start Response option is included in the TCP header of the
corresponding acknowledgement packet. The Rate Request in the
Quick-Start Response option is set to the received value of the four-bit allowed Rate Request, formatted
as
Request in the Quick-Start Request option.

The fourth byte of option, or to a lower value if the TCP option contains the TTL Diff.
receiver is only willing to allow a lower Rate Request. The TTL
Diff contains in the Quick-Start Response is set to the difference between
the IP TTL value and the QS TTL fields in
the received Quick-Start request packet, value as calculated given in equations equation (1) or
(2) (depending on whether IPv4 or IPv6 is used). The last four bytes of QS Nonce in
the TCP option contain Response is set to the received value of the 30-bit QS Nonce in the
Quick-Start option.

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
path, in which case it is better not to approve the Quick-Start
Request.

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
receives a two-bit Reserved field.

We note Quick-Start Response in an acknowledgement first checks
that the Quick-Start Response Option for TCP is valid. The Quick-Start Response is
valid if it contains eight
bytes, the correct value for the TTL Diff, and an
equal or lesser value for the length Rate Request than that transmitted in
the Quick-Start Request. In addition, if the received Rate Request
is K, then the the rightmost 2K bits of the QS Nonce must match
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 option field is generally at most
40 bytes. Other host MUST use the default TCP options congestion window
that might be it would have 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 without Quick-Start. If the rightmost 2K
bits of the QS Nonce do not match those bits in the QS Nonce sent in
the Quick-Start Response

An end host, say host B, that receives an IP packet containing Request, for a
Quick-Start received Rate Request passes of K, then the
TCP host MUST NOT send additional Quick-Start Request, along with requests during the
value in
life of the IP TTL field, to connection. Whether the receiving TCP layer.

If Quick-Start request was
successful or not, the TCP host is willing to permit MUST send a Report of Approved Rate.

If the Quick-Start Request, checks of the TTL Diff and the Rate Request are successful,
then a
Quick-Start Response option is included in the TCP header host sets its Quick-Start congestion window (in terms
of MSS-sized segments), QS-cwnd, as follows:

QS-cwnd = (R * T) / (MSS + H) (3)

where R the
corresponding acknowledgement packet. The Rate Request in bytes per second, T the measured round-
trip time in seconds, and H the
Quick-Start Response option estimated TCP/IP header size in
bytes (e.g., 40 bytes).

Derivation: the sender is allowed to transmit at R 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
application data.

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. When
Quick-Start is used at the received value beginning of a connection, before any
packet marks or losses have been reported, the Rate
Request in TCP host MAY use the Quick-Start
reported Rate Request option, or to a lower value if set the TCP receiver is only willing slow-start threshold to allow a lower Rate Request. The
TTL Diff in the Quick-Start Response is set desired
value, e.g., to some small multiple of the difference
between the IP TTL value and the QS TTL congestion window. (The
initial value as given in equation
(1) or (2) (depending on whether IPv4 or IPv6 is used). The QS
Nonce in the Response of ssthresh is set allowed to be arbitrarily high, and
some TCP implementations use the received value size of the QS Nonce
in advertised window for
ssthresh [RFC2581].)

If QS-cwnd is used, the Quick-Start Request option.

The Quick-Start Response will NOT be resent if TCP host sets a flag that it is lost in the
network. Packet loss is an indication of congestion on the return
path, Quick-
Start mode, and while in which case it is better not to approve Quick-Start mode the TCP sender MUST use
rate-based pacing to pace out Quick-Start
Request.

4.4. TCP: Receiving and Using packets at the specified
Rate Request. If, during Quick-Start Response Packet

A TCP host, say mode, the TCP host A, that sender receives
ACKs for packets sent a before this Quick-Start Request and
receives a mode was entered,
these ACKs are processed as usual, following the default congestion
control mechanisms. Quick-Start Response in mode ends when the TCP host
receives an acknowledgement ACK for one of the Quick-Start packets.

If the congestion window has not been fully used when the first checks
that ack
arrives ending the Quick-Start Response mode, then the congestion window is valid. The
decreased to the amount that has actually been used so far. This is
necessary because when the Quick-Start Response is
valid if it contains received, the correct value TCP
sender's round-trip-time estimate might be longer than for
succeeding round-trip times, e.g., because of delays at routers
processing the TTL Diff, and an
equal IP QuickStart option, or lesser value for because of delays at the Rate Request than that transmitted
receiver in responding to the Quick-Start Request. In addition, if the received Rate Request
is K, then the packet. In this
case, an overly-large round-trip-time estimate could have caused the rightmost 2K bits of
TCP sender to translate the QS Nonce must match
those bits approved Quick-Start sending rate in
bytes per second into a congestion window that is larger than
needed, with the QS Nonce sent in TCP sender receiving an ACK for the Quick-Start Request. If
these checks are not successful, then first Quick-
Start packet before the Quick-Start request
failed, and entire congestion window has been used.
Thus, when the TCP host MUST use sender receives the default TCP first ACK for a Quick-Start
packet, the sender reduces its congestion window
that it would have used without Quick-Start.

If to the checks amount that
has actually been used.

As an example, a TCP sender with an approved Quick-Start request of the TTL Diff
R KBps, B-byte packets including headers, and an RTT estimate of T
seconds, would translate the Rate Request are successful,
then the TCP host sets its Quick-Start of R KBps to a congestion
window (in terms of MSS-sized segments), QS-cwnd, as follows:

QS-cwnd = (R * T) / (MSS + H) (3)

where R R*T/B packets. The TCP sender would send the Rate Request in bytes per second, T Quick-Start
packets rate-paced at R KBps. However, if the measured actual current round-
trip time in was T/2 seconds instead of T seconds, and H the estimated TCP/IP header size in
bytes (e.g., 40 bytes).

Derivation: then the sender is allowed
would begin to transmit at R 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
application data.

The receive acknowledgements for Quick-Start packets
after T/2 seconds. Following the paragraph above, the TCP host SHOULD set sender
would then reduce its congestion window cwnd from R*T/B to QS-cwnd only
if QS-cwnd is greater than cwnd; otherwise QS-cwnd is ignored. When
Quick-Start is used at R*T/(B*2)
packets, the beginning actual number of a connection, before any
packet marks or losses have been reported, the TCP host MAY use the
reported Rate Request packets that were needed to set fill the slow-start threshold to
pipe at a desired
value, e.g., to some small multiple of the congestion window. (The
initial value sending rate of ssthresh R KBps.

After Quick-Start mode is allowed to be arbitrarily high, exited and
some TCP implementations use the size of the advertised congestion window for
ssthresh [RFC2581].)

If QS-cwnd is used, adjusted
if necessary, the TCP host sets a flag that it is 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 Quick-
Start mode, slow-start prior to the Quick-Start request,
and while no packets were lost or marked since that time, then the sender
continues in slow-start after exiting Quick-Start mode mode, as allowed
by ssthresh.

To add robustness, the TCP sender MUST use
rate-based pacing to pace out Quick-Start Limited Slow-Start
[RFC3742] along with Quick-Start. With Limited Slow-Start, the TCP
sender limits the number of packets at by which the specified
Rate Request. If, congestion window
is increased for one window of data during slow-start.

4.5. TCP: Responding to a Loss of a Quick-Start mode, Packet

For TCP, we have defined a ``Quick-Start packet'' as one of the TCP sender receives
ACKs for
packets sent before this Quick-Start mode was entered,
these ACKs are processed as usual, in the window immediately following a successful Quick-
Start request. After detecting the loss of a Quick-Start packet,
TCP MUST revert to the default congestion control mechanisms. Quick-Start mode ends when the TCP host
receives an ACK for one of procedures that
would have been used if the Quick-Start packets.

If the congestion window has request had not been fully
approved. For example, if Quick-Start is used when the first ack
arrives ending for setting the Quick-Start mode, then
initial window, and a packet from the congestion initial window is
decreased to lost, then
the amount TCP sender MUST then slow-start with the default initial window
that has actually would have been used so far. This is
necessary because when the if Quick-Start Response is received, had not been used. In
addition to reverting to the TCP
sender's round-trip-time estimate might be longer than for
succeeding round-trip times, e.g., because of delays at routers
processing default congestion control mechanisms,
the IP QuickStart option, or because of delays sender MUST take into account that the Quick-Start congestion
window was too large. Thus, the sender SHOULD decrease ssthresh to
at most half the
receiver number of Quick-Start packets that were
successfully transmitted. Section A.5 discusses possible
alternatives in responding to the loss of a 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

We note that ECN [RFC3168] MAY be used with Quick-Start. As is larger than
needed,
always the case with ECN, the TCP sender receiving sender's congestion control response
to an ACK for the first Quick-
Start ECN-marked Quick-Start packet before the entire congestion window has been used.
Thus, when is the TCP sender receives same as the first ACK for response to a
dropped Quick-Start packet, thus reverting to slow start in the sender reduces its congestion window case
of Quick-Start packets marked as experiencing congestion.

4.6. TCP: A Quick-Start Request for a Larger Initial Window

Some of the issues of using Quick-Start are related to the amount that
has actually been specific
scenario in which Quick-Start is used.

As an example, a This section discusses the
following issues that arise when Quick-Start is used by TCP sender to
request a larger initial window: (1) interactions with an approved Path MTU
Discovery (PMTUD); and (2) Quick-Start request of
R KBps, B-byte packets including headers, that are
discarded by middleboxes.

4.6.1. Interactions with Path MTU Discovery

One issue when Quick-Start is used to request a large initial window
concerns the interactions between the large initial window and an RTT estimate Path
MTU Discovery. Some of T
seconds, would translate the Rate Request issues are discussed in RFC 3390:

"When larger initial windows are implemented along with Path MTU
Discovery [RFC1191], alternatives are to set the "Don't
Fragment" (DF) bit in all segments in the initial window, or to
set the "Don't Fragment" (DF) bit in one of R KBps the segments. It is
an open question as to a congestion
window which of R*T/B packets. The TCP these two alternatives is best."

If the sender would send knows the Quick-Start
packets rate-paced at R KBps. However, if Path MTU when the actual current round-
trip time was T/2 seconds instead of T seconds, initial window is sent
(e.g., from a PMTUD cache or from some other IETF-approved method),
then the sender
would begin to receive acknowledgements should use that MTU for Quick-Start segments in the initial
window. Unfortunately, the sender doesn't necessarily know the Path
MTU when it sends packets
after T/2 seconds. Following in the paragraph above, initial window. In this case, the TCP
sender
would then reduce its congestion window from R*T/B to R*T/(B*2)
packets, should be conservative in the actual packet size used. Sending a
large number of overly-large packets that were needed to fill with the
pipe at a DF bit set is not
desirable, but sending rate a large number of R KBps.

After Quick-Start mode is exited and packets that are fragmented
in the congestion network can be equally undesirable.

The sender SHOULD send one large packet in the initial window adjusted
if necessary, with
the TCP sender returns to using DF bit set, and send the default congestion
control mechanisms, processing further incoming ACK remaining packets as
specified by those congestion control mechanisms. For example, if in the initial window
with a smaller MTU of 576 bytes (or 1280 bytes with IPv6).

A second possibility would be for the TCP sender was in slow-start prior to delay sending the
Quick-Start request,
and no packets were lost or marked since that Request for one round-trip time, then sending 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
Request with Quick-Start. With Limited Slow-Start, the TCP
sender limits the number first window of packets data while also doing Path MTU
Discovery.

4.6.2. Quick-Start Request Packets that are Discarded by which the congestion window Middleboxes

It is increased always possible for one window of data during slow-start.

4.5. TCP: Responding to a Loss of TCP SYN packet carrying a Quick-Start Packet

For TCP, we have defined
request to be dropped in the network due to congestion, or to be
blocked due to interactions with middleboxes, where a ``Quick-Start packet'' middlebox is
defined as one any intermediary box performing functions apart from
normal, standard functions of an IP router on the
packets sent in the window immediately following data path between
a successful Quick-
Start request. After detecting the loss source host and destination host [RFC3234]. Measurement studies
of a Quick-Start packet,
TCP MUST revert to the default congestion control procedures interactions between transport protocols and middleboxes [MAF04]
show that
would have been used for 70% of the web servers investigated, no connection is
established if the Quick-Start request had not been
approved. For example, TCP SYN packet contains an unknown IP option (and
for 43% of the web servers, no connection is established if Quick-Start the TCP
SYN packet contains an IP TimeStamp Option). In both cases, this is used for setting
presumably due to middleboxes along that path.

If the
initial window, and TCP sender doesn't receive a response to the SYN or SYN/ACK
packet from containing the initial window is lost, Quick-Start Request, then the TCP sender MUST then slow-start with
SHOULD resend the default initial window
that would have been used if Quick-Start had not been used. In
addition to reverting to SYN or SYN/ACK packet without the default congestion control mechanisms, Quick-Start
Request. Similarly, if the TCP sender MUST take into account that receives a TCP reset in
response to the SYN or SYN/ACK packet containing the Quick-Start congestion
window was too large. Thus,
Request, then the TCP sender SHOULD decrease ssthresh to
at most half resend the SYN or SYN/ACK packet
without the number of Quick-Start packets Request [RFC3360].

RFC 1122 and 2988 recommend that were
successfully transmitted. Section A.5 discusses possible
alternatives in responding the sender should set the initial
RTO to three seconds, though many TCP implementations set the loss of
initial RTO to one second. For a Quick-Start packet.

We note that ECN [RFC3168] MAY be used TCP SYN packet sent with Quick-Start. As is
always a Quick-
Start request, the case with ECN, TCP sender SHOULD use an initial RTO of three
seconds.

In the sender's congestion control response case of a retransmission, in addition to an ECN-marked Quick-Start resending the SYN or
SYN/ACK packet is without the same as Quick-Start Request, the response to TCP sender
SHOULD use an RTO of three seconds and a
dropped Quick-Start packet, thus reverting to slow start in different Initial Sequence
Number. Using this scheme the case TCP sender MUST keep track of Quick-Start when
each of the SYN (or SYN/ACK) packets marked as experiencing congestion.

4.6. TCP: A Quick-Start Request was transmitted. In this way,
an acknowledgement for a Larger Initial Window

Some of the issues retransmitted SYN or SYN/ACK packet can
be matched with the SYN or SYN/ACK being acknowledged, and the
transmission time of using Quick-Start are related the SYN (or SYN/ACK) being acknowledged can be
used for an RTT measurement to seed the specific
scenario in which Quick-Start is used. This section discusses RTO. If only the
following issues that arise when Quick-Start
retransmitted SYN or SYN/ACK is used by acknowledged, the TCP to
request a larger initial window: (1) interactions with Path MTU
Discovery (PMTUD); and (2) Quick-Start request packets sender can
reasonably assume that are
discarded by middleboxes.

4.6.1. Interactions the earlier SYN or SYN/ACK with Path MTU Discovery

One issue when Quick-Start is used to request a large initial window
concerns the interactions between Quick-
Start option was dropped by the large initial window and Path
MTU Discovery. Some network because of the issues are discussed in RFC 3390:

"When larger initial windows are implemented along with Path MTU
Discovery [RFC1191], alternatives are to set option and
not because of congestion. In this case, the "Don't
Fragment" (DF) bit in all segments in TCP sender can refrain
from performing TCP's standard congestion control state changes.

We note that if the initial window, or to
set TCP SYN packet is using the "Don't Fragment" (DF) bit IP Quick-Start
Option for a Quick-Start request, and it is also using bits in one of the segments. It is
an open question as
TCP header to which of these two alternatives is best."

If the sender knows negotiate ECN-capability with the Path MTU when TCP host at the initial window is sent
(e.g., from a PMTUD cache or from some
other IETF-approved method), end, then the sender should use that MTU for segments in drop of a TCP SYN packet could be due to
congestion, to a middlebox dropping the initial
window. Unfortunately, packet because of the sender doesn't necessarily know IP
Option, or because of a middlebox dropping the Path
MTU when it sends packets packet because of the
information in the initial window. TCP header negotiating ECN. In this case, the
sender should be conservative in could resend the dropped packet size used. Sending a
large number of overly-large packets with without either the DF bit set is not
desirable, but sending a large number of packets that are fragmented
in Quick-
Start or the ECN requests. Alternately, the network can be equally undesirable.

The sender SHOULD send one large could resend the
dropped packet with only the ECN request in the initial window with TCP header,
resending the DF bit set, and send TCP SYN packet without either the remaining packets in Quick-Start or the
ECN requests if the initial window
with a smaller MTU of 576 bytes (or 1280 bytes with IPv6).

A second possibility would TCP SYN packet is dropped. The second
choice seems reasonable, given that a TCP SYN packet today is more
likely to be for the sender blocked due to delay sending IP Options than due to an ECN request in
the TCP header [MAF04].

It is always possible that some middlebox that doesn't drop TCP SYN
packets containing Quick-Start Request for options will still drop or delay TCP
data packets containing Quick-Start options as Approved Rate
reports. This would be one round-trip time, sending reason for a TCP sender to report the
Approved Rate in a separate control packet, rather than in a data
packet.

4.7. TCP: A Quick-Start Request with in the first window Middle of data while also doing Path MTU
Discovery.

4.6.2. Quick-Start Request Packets a Connection

This section discusses the following issues that are Discarded by Middleboxes

It arise when Quick-
Start is always possible for a used by TCP SYN packet carrying a Quick-Start
request to be dropped request a larger window in the network due to congestion, or to be
blocked due to interactions with middleboxes, where a middlebox is
defined as any intermediary box performing functions apart from
normal, standard functions middle of
connection, for example after an IP router on idle period: (1) determining the data path between
a source host and destination host [RFC3234]. Measurement studies
of interactions between transport protocols
rate to request; and middleboxes [MAF04]
show that for 70% of (2) the web servers investigated, no connection is
established response if Quick-Start packets are
dropped;

(1) Determining the TCP SYN packet contains rate to request:
In the middle of connection, an unknown IP option (and
for 43% easy rule of thumb would be for the web servers, no connection is established if
TCP sender to determine the largest congestion window that the TCP
SYN
connection achieved since the last packet contains an IP TimeStamp Option). In both cases, drop, to translate this is
presumably due
congestion window to middleboxes along that path. a sending rate, and use this rate in the Quick-
Start request. If the TCP sender doesn't receive a response to request is granted, then the SYN or SYN/ACK
packet containing sender
essentially restarts with its old congestion window from before it
was reduced, for example during an idle period.

In the Quick-Start Request, then case of an idle period, the TCP sender SHOULD resend NOT use Quick-Start
if the SYN or SYN/ACK packet without idle period has been less than an RTO, and the congestion
window has not decayed down to less than half of its value at the
start of the idle period. Such a use of Quick-Start
Request. Similarly, if requires
further investigation.

A Quick-Start Request sent in the TCP sender receives middle of a TCP reset connection could
be carried either in
response to the SYN or SYN/ACK a data packet containing the or in a pure acknowledgement
packet.

(2) Response if Quick-Start
Request, packets are dropped:

If Quick-Start packets are dropped in the middle of connection, then
the TCP sender SHOULD resend MUST revert to half of the SYN Quick-Start window, or SYN/ACK packet
without to the Quick-Start Request [RFC3360].

RFC 1122 and 2988 recommend
congestion window that the sender should set would have used if the initial
RTO to three seconds, though many Quick-Start
request had not been approved, whichever is smaller.

4.8. An Example Quick-Start Scenario with TCP implementations set

The following is an example scenario in the case when both hosts
request Quick-Start for setting their initial RTO windows. This is
similar to one second. For Figures 1 and 2 in Section 2.1, except that it
illustrates a TCP SYN packet sent connection with a Quick-
Start request, the both TCP hosts sending Quick-Start
Requests.

* The TCP sender SHOULD use an initial RTO of three
seconds.

In the case of a retransmission, in addition to resending the SYN or
SYN/ACK packet without the from Host A contains a Quick-Start Request, Request in
the TCP sender
SHOULD use an RTO of three seconds and a different Initial Sequence
Number. Using this scheme IP header.

* Routers along the TCP sender MUST keep track of when
each of forward path modify the SYN (or SYN/ACKs) was transmitted. In this way, an
acknowledgement for Quick-Start Request as
appropriate.

* Host B receives the retransmitted SYN or SYN/ACK packet can be
matched with Quick-Start Request in the SYN or SYN/ACK being acknowledged, packet, and
calculates the
transmission time of the SYN (or SYN/ACK) being acknowledged can be
used for an RTT measurement to seed the RTO. TTL Diff. If only Host B approves the
retransmitted SYN or SYN/ACK is acknowledged, Quick-Start
Request, then Host B sends a Quick-Start Response in the TCP sender can
reasonably assume that header
of the earlier SYN or SYN/ACK with the Quick-
Start option was dropped by the network because of packet. Host B also sends a Quick-Start Request in
the option and
not because IP header of congestion. In this case, the TCP sender can refrain
from performing TCP's standard congestion control state changes.

We note that if SYN/ACK packet.

* Routers along the TCP SYN packet is using reverse path modify the IP Quick-Start
Option for a Request as
appropriate.

* Host A receives the Quick-Start request, and it is also using bits Response in the
TCP header to negotiate ECN-capability with the TCP host at SYN/ACK packet,
and checks the
other end, TTL Diff, Rate Request, and QS Nonce for validity.
If they are valid, then the drop of a TCP SYN packet could be due to
congestion, Host A sets its initial congestion window
appropriately, and sets up rate-based pacing to a middlebox dropping the packet because of the IP
Option, or because of a middlebox dropping the packet because of be used with the
information in
initial window. If the TCP header negotiating ECN. Quick-Start Response is not valid, then Host
A uses TCP's default initial window. In this case, the
sender could resend the dropped packet without either case, Host A sends a
Report of Approved Rate.

Host A also calculates the Quick-
Start or the ECN requests. Alternately, the sender could resend TTL Diff for the
dropped packet with only Quick-Start Request in
the ECN request incoming SYN/ACK packet, and sends a Quick-Start Response in the
TCP header,
resending header of the TCP SYN packet without either ACK packet.

* Host B receives the Quick-Start or Response in an ACK packet, and
checks the
ECN requests if TTL Diff, Rate Request, and QS Nonce for validity. If
the second TCP SYN packet is dropped. The second
choice seems reasonable, given that a TCP SYN packet today Quick-Start Response is more
likely valid, then Host B sets its initial
congestion window appropriately, and sets up rate-based pacing to be blocked due to IP Options than due to an ECN request in
used with its initial window. If the TCP header [MAF04].

4.7. TCP: A Quick-Start Request in the Middle Response is not
valid, then Host B uses TCP's default initial window. In either
case, Host B sends a Report of Connection Approved Rate.

5. Quick-Start and IPsec AH

This section discusses the following issues shows that arise when Quick-
Start Quick-Start is used by TCP to request a larger window in the middle of
connection, for example after compatible with IPsec AH
(Authentication Header). AH uses an idle period: (1) determining Integrity Check Value (ICV) in
the
rate IPsec Authentication Header to request; verify both message
authentication and (2) integrity [RFC2402,2402bis]. Changes to the response if
Quick-Start packets are
dropped;

(1) Determining option in the rate IP header do not affect this AH ICV. The
tunnel considerations in Section 6 below apply to request:
In the middle of connection, an easy rule all IPsec tunnels,
regardless of thumb would be for the
TCP sender to determine the largest congestion window that what IPsec headers or processing are used in
conjunction with the TCP
connection achieved since tunnel.

Because the last packet drop, to translate this
congestion window to a sending rate, and use this rate in contents of the Quick-
Start request. If Quick-Start option can change along the request
path, it is granted, then important that these changes not affect the sender
essentially restarts 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 its old congestion window from before it
was reduced, existing IPsec AH implementations
for example during an idle period.

In the case of an idle period, IPv4. If the sender SHOULD NOT use Quick-Start
if the idle period has been less than an RTO, 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 congestion
window has not decayed down to less than half of its value at the
start of option is mutable; the idle period. Such a use of Quick-Start requires
further investigation.

(2) Response if Quick-Start packets are dropped:
If Quick-Start packets are dropped 3rd highest order bit in
the middle of connection, then
the sender MUST revert to half of IANA-allocated option type has the Quick-Start window, or value 1 to the
congestion window indicate that the sender would have used if the
Quick-Start
request had not been approved, whichever is smaller.

We note option data can change en route. RFC 2402 requires that a packet in
the middle of a connection carrying a
Quick-Start Request might or might not carry a option data payload. For
example, of any such option be zeroed for TCP, AH ICV computation
purposes. Therefore changes to the Quick-Start Request could be carried by a data
packet, or by a pure acknowledgement packet.

4.8. An Example Quick-Start Scenario with TCP

The following is an example scenario option in the case when both hosts
request IP
header do not affect the calculation of the AH ICV.

6. 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 IP Tunnels

This section considers interactions between Quick-Start Request 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 header.

* Routers along TTL and the Quick-Start TTL, mod 256.
Recall that the sender considers the Quick-Start request approved
only if the forward path modify value of TTL Diff for the Quick-Start Request as
appropriate.

* Host B receives packet entering the Quick-Start Request in network is
the SYN packet, and
calculates same as the value of TTL Diff. If Host B approves Diff for the Quick-Start
Request, then Host B sends a Quick-Start Response in packet exiting the TCP
network.

Simple tunnels: IP tunnel modes are generally based on adding a new
"outer" IP header
of that encapsulates the SYN/ACK original or "inner" IP
header and its associated packet. Host B also sends a Quick-Start Request in In many cases, the new "outer" IP
header of the SYN/ACK packet.

* Routers may be added and removed at intermediate points along a
connection, enabling the reverse path modify network to establish a tunnel without
requiring endpoint participation. We denote tunnels that specify
that the Quick-Start Request outer header be discarded at tunnel egress as
appropriate.

* Host A receives the Quick-Start Response in the SYN/ACK packet, "simple
tunnels", and checks we denote tunnels where the TTL Diff, Rate Request, and QS Nonce for validity.
If they are valid, then Host A sets its initial congestion window
appropriately, egress saves and sets up rate-based pacing to uses
information from the outer header before discarding it as "non-
simple tunnels". An example of a "non-simple tunnel" would be used 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 the
initial window. If the Quick-Start,
\ but Not Supporting Quick-Start Response is
\
\__ Tunnels Not Compatible with Quick-Start?

Figure 6: Categories of Tunnels.

Tunnels that are compatible with Quick-Start: We say that an IP
tunnel `is not valid, then Host
A uses TCP's default initial window.

Host A also calculates the TTL Diff for compatible with Quick-Start' if the Quick-Start use of a Quick-
Start Request in
the incoming SYN/ACK packet, and sends over such a Quick-Start Response in tunnel allows false positives, where the
TCP header of the ACK packet.

* Host B receives sender incorrectly believes that the Quick-Start Response in an ACK packet, and
checks Request was
approved by all routers along the TTL Diff, Rate Request, and QS Nonce for validity. path. If the use of Quick-Start Response is valid, then Host B sets its initial
congestion window appropriately, and sets up rate-based pacing to be
used
over the tunnel does not cause false positives, we say that the IP
tunnel `is compatible with its initial window. Quick-Start'.

If the Quick-Start Response IP TTL of the inner header is not
valid, decremented during forwarding
before tunnel encapsulation takes place, then Host B uses TCP's default initial window.

5. Quick-Start and IPsec AH

This section shows that Quick-Start the simple tunnel is
compatible with IPsec AH
(Authentication Header). AH uses an Integrity Check Value (ICV) Quick-Start, with Quick-Start requests being
rejected. Section 6.1 describes in more detail the IPsec Authentication Header to verify both message
authentication and integrity [RFC2402,2402bis]. Changes to ways that a
simple tunnel can be compatible with Quick-Start.

There are some simple tunnels that are not compatible with Quick-
Start, allowing `false positives' where the TCP sender incorrectly
believes that the Quick-Start option in Request was approved by all routers
along the IP header do not affect this AH ICV. The
tunnel considerations path. This is discussed in Section 3.6 below apply to all IPsec
tunnels, regardless 6.2 below.

One of what IPsec headers or processing are used our tasks in
conjunction with the tunnel.

Because future will be to investigate the contents occurrence
of tunnels that are not compatible with Quick-Start, and to track
the Quick-Start Request option can change
along extent to which such tunnels are modified over time. The
evaluation of the path, it is important problem of false positives from tunnels that these changes are
not compatible with Quick-Start will 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 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 Option data changing
en route does not cause problems with existing IPsec AH
implementations for IPv4. If tunnel `supports
Quick-Start' if it allows routers along the tunnel path to process
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 give feedback, resulting in the option
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 mutable; not able to
support Quick-Start.

From a security point of view, the 3rd
highest order bit use of Quick-Start in the IANA-allocated option type has outer
header of an IP tunnel might raise security concerns because an
adversary could tamper with the value 1
to indicate Quick-Start information that
propagates beyond the tunnel endpoint, or because the Quick-Start Request
Option exposes information to network scanners. Our approach is to
make supporting Quick-Start an option data can change en
route. RFC 2402 requires that for IP tunnels. That is, in
environments or tunneling protocols where the option data risks of any such option be
zeroed for AH ICV computation purposes. Therefore changes using Quick-
Start are judged to outweigh its benefits, the tunnel can simply
delete the Quick-Start option in or zero the Quick-Start rate request
and QS TTL fields before encapsulation. The result is that there
are two viable options for IP header do not affect tunnels to be compatible with Quick-
Start. The first option is the calculation of simple tunnel described above and in
Section 6.1, where the AH ICV.

6. 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 IP Section 6.3, where the tunnel actively
supports Quick-Start.

6.1. Simple Tunnels That Are Compatible with Quick-Start

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 describes the IP TTL and ways that a simple tunnel can be
compatible with Quick-Start but not support Quick-Start, resulting
in the rejection of all Quick-Start TTL, mod 256.
Recall requests that traverse the sender considers
tunnel.

If the Quick-Start request approved
only if tunnel ingress for the value 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 for will
be changed, correctly causing the packet entering Quick-Start request to be
rejected. For a simple tunnel it is preferable if the network Quick-Start
Request is not copied to the same as outer header, saving the value of TTL Diff for routers within
the packet exiting tunnel from unnecessarily processing the
network. 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: IP tunnel modes Tunnels that are generally based on adding Aware of Quick-Start

If a new
"outer" IP header that encapsulates tunnel ingress is aware of Quick-Start, but does not want to
support Quick-Start, then the original or "inner" IP
header tunnel ingress MUST either zero the
Quick-Start rate request, QS TTL, and its associated packet. In many cases, QS Nonce fields or remove the new "outer" IP
Quick-Start option from the inner header may be added and removed at intermediate points along a
connection, enabling before encapsulation.
Section 6.3 describes the network to establish procedures for a tunnel without
requiring endpoint participation. We denote tunnels that specify that does want to
support Quick-Start.

Deleting the outer header be discarded at tunnel egress as "simple
tunnels", and we denote tunnels where Quick-Start option or zeroing the egress saves Quick-Start rate
request *after decapsulation* also serves to prevent the propagation
of Quick-Start information, and uses
information from is compatible with Quick-Start. If
the outer header before discarding it as "non-
simple tunnels". An example of does not contain a "non-simple tunnel" would be Quick-Start Request, a Quick-
Start-aware tunnel configured to support ECN, where the egress router might copy MUST reject the ECN codepoint in inner Quick-Start Request
by zeroing the outer header to Rate Request field in the inner header before
discarding header, or by
deleting the outer header [RFC3168].

__ Tunnels Compatible with Quick-Start
/ 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 __/
\
\__ Tunnels That Are Not Compatible with Quick-Start
(False Positives!)

__ Tunnels Supporting Quick-Start
/
/
Non-Simple Tunnels __/_____ Tunnels Compatible with Quick-Start,
\ but Not Supporting

Sometimes a tunnel implementation that does not support Quick-Start
\
\__ Tunnels Not Compatible with Quick-Start?

Figure 5: Categories
is independent of Tunnels.

Tunnels the TCP sender or a router implementation that are compatible with Quick-Start: We say
supports Quick-Start. In these cases it is possible 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 gets erroneously approved without the
TCP sender incorrectly believes that routers in the Quick-Start Request was
tunnel having individually approved by all routers along the path. request, causing a false
positive.

If the use of Quick-Start
over the a tunnel does not cause false positives, we say 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
tunnel `is compatible TTL being decremented first,
or with Quick-Start'.

If the both IP TTL of the inner header is and QS TTL being decremented during forwarding before the tunnel
encapsulation takes place, then place. If the simple tunnel is
compatible with ingress does not know about
Quick-Start, with a valid Quick-Start requests being
rejected. Section 6.1 describes Request with unchanged TTL Diff
traverses in more detail the ways that inner header, while the outer header most likely
does not carry a
simple Quick-Start Request. If the tunnel can egress also
does not support Quick-Start, it remains possible that the Quick-
Start Request would be compatible 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 Quick-Start.

There are some simple tunnels that 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 not compatible with with
Quick-Start, allowing `false positives' 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 TCP sender
incorrectly believes that encryption occurs on an outboard processor, offloading the
encryption processing overhead from the Quick-Start Request was approved by
all routers along host or router [RFC2401].
The BITW device is usually IP addressable, which means that the path. This IP
TTL is discussed in Section 6.2 below.

One of our tasks in decremented before the future will be packet is passed to investigate the occurrence
of tunnels that are BITW. If the
QS TTL is not compatible with Quick-Start, and to track decremented, then the extent to which such tunnels are modified over time. The
evaluation value of TTL Diff is changed,
and the problem of false positives from tunnels that are
not compatible with Quick-Start request will affect be denied. However, if the progression of
Quick-Start from Experimental to Proposed Standard, BITW
supports a host and will affect does not have its own IP address, then 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
TTL is not decremented before the tunnel path packet is passed from the host to process
the Quick-Start Request BITW, and give feedback, resulting in the
appropriate possible acceptance of the Quick-Start request. Some a false positive could occur.

Other tunnels that are compatible with Quick-Start support Quick-Start,
while others do not. We note that a simple tunnel is not able need to
support Quick-Start.

From a security point of view, the use of Quick-Start in the outer
header of an be looked at are IP tunnel might raise security concerns because an
adversary could tamper with tunnels over non-
network protocols, such as IP over TCP and IP over UDP [RFC3948],
and tunnels using the Quick-Start information that
propagates beyond Layer Two Tunneling Protocol [RFC2661].

Section 9.2 discusses the tunnel endpoint, related issue of non-IP queues, such as
layer-two Ethernet or because ATM networks, as another instance of possible
bottlenecks that do not participate in the Quick-Start
Option exposes information feedback.

6.3. Tunnels That Support Quick-Start

This section discusses tunnels configured to network scanners. Our approach is support Quick-Start.

If the tunnel ingress node chooses to
make supporting Quick-Start an option for IP tunnels. That is, in
environments or tunneling protocols where locally approve the risks of using Quick-
Start are judged to outweigh its benefits, request, then the tunnel can simply
delete ingress node MUST decrement the Quick-Start option or zero
TTL at the Quick-Start rate request same time it decrements the IP TTL, and QS TTL fields before encapsulation. The result is that there
are two viable options for MUST copy IP tunnels to be compatible with Quick-
Start. The first option is the simple tunnel described above TTL
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 option from the path will be rejected. The second approach is a Quick-Start-
capable mode, described in Section 6.3, where inner IP header to the tunnel actively
supports Quick-Start.

6.1. Simple Tunnels That Are Compatible with Quick-Start

This section describes outer
header. During encapsulation, the ways that a simple tunnel can be
compatible with ingress MUST zero the
Quick-Start but not support Quick-Start, resulting rate request field in the rejection of all Quick-Start requests inner header to ensure that traverse
the
tunnel. Quick-Start request will be rejected if the tunnel egress does
not support Quick-Start.

If the tunnel ingress for node does not choose to locally approve the simple tunnel is at a router,
Quick-Start request, then it MUST either delete the IP
TTL of Quick-Start
option from the inner header is generally decremented during forwarding before tunnel encapsulation takes place. In this case encapsulation, or zero the QS
TTL Diff will
be changed, correctly causing and the Quick-Start request to be
rejected. For a simple tunnel it is preferable Rate Request fields before encapsulation.

Upon decapsulation, if the outer header contains a Quick-Start
Request is not copied to
option, the outer header, saving tunnel egress MUST copy the routers within IP TTL and the tunnel Quick-Start
option from unnecessarily processing the Quick-Start request.
However, outer IP header to the Quick-Start request will be rejected correctly 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
case whether or not document. Now that the Quick-Start Request
RFC for IKEv2 [RFC4306] is copied published, we plan to specify a
modification of IPsec to allow the outer
header.

6.1.1. Simple Tunnels that are Aware support of Quick-Start

If a to be
negotiated; this modification will specify the negotiation between
tunnel ingress is aware of Quick-Start, but does not want endpoints to allow or forbid support Quick-Start, then 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 ingress MUST either zero will be specified in a separate IPsec document.
This document will also include a discussion of the
Quick-Start rate request, QS TTL, and QS Nonce fields or remove potential
effects of an adversary's modifications of the Quick-Start option from field (as
in Sections 18 and 19 of RFC 3168), and of the inner header before encapsulation.
Section 6.3 describes security
considerations of exposing the procedures for a tunnel that does want Quick-Start rate request to
support Quick-Start.

Deleting the network
scanners.

7. The Quick-Start option or zeroing Mechanism in other Transport Protocols

The section earlier specified the use of Quick-Start rate
request *after decapsulation* also serves in TCP. In
this section, we generalize this to prevent give guidelines for the propagation use of
Quick-Start information, and with other transport protocols. We also discuss briefly
how Quick-Start could be specified for other transport protocols.

The general guidelines for Quick-Start in transport protocols are as
follows:

* Quick-Start is compatible only specified for unicast transport protocols with Quick-Start. If
the outer header does not contain a
appropriate congestion control mechanisms. Note: Quick-Start Request, is not
a Quick-
Start-aware tunnel egress MUST reject replacement for standard congestion control techniques, but meant
to augment their operation.

* A transport-level mechanism is needed for the inner Quick-Start Request
by resetting the Rate Request field in the inner header, or by
deleting response
from the Quick-Start Request option.

If receiver to the tunnel ingress is at a sending host or router where sender. This response contains the IP Rate
Request, TTL is not decremented prior to encapsulation, Diff, and neither tunnel
endpoint is aware QS Nonce.

* The sender checks the validity 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 response.

* The sender has an estimate of the TCP sender round-trip time, and translates
the Quick-Start response into an allowed window or allowed sending
rate. The sender sends 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 Report of Approved Rate. The sender
starts sending Quick-Start packets, rate-paced out at the
tunnel having individually approved
sending rate.

* After the request, causing a false
positive.

If a tunnel ingress is a separate component from sender receives the TCP first acknowledgement packet for a
Quick-Start packet, no more Quick-Start packets are sent. The
sender adjusts its current congestion window or
IP forwarding, it is possible that a packet sending rate to be
consistent with a the actual amount of data that was transmitted in
that round-trip time.

* When the last Quick-Start
option packet is encapsulated without acknowledged, the IP TTL being decremented first,
or with both IP TTL and QS TTL being decremented before sender
continues using the tunnel
encapsulation takes place. standard congestion control mechanisms of that
protocol.

* If one of the tunnel ingress does not know about
Quick-Start, a valid Quick-Start Request with unchanged TTL Diff
traverses in packets is lost, then the inner header, while sender reverts
to the outer header most likely
does not carry a Quick-Start Request. If standard congestion control method of that protocol that
would have been used if the tunnel egress also
does Quick-Start request had not support Quick-Start, it remains possible been
approved. In addition, the sender takes into account the
information that the Quick-
Start Quick-Start congestion window was too large
(e.g., by decreasing ssthresh in TCP).

8. Using Quick-Start

8.1. Determining the Rate to Request would be falsely approved, because the packet is
decapsulated using the Quick-Start request from

As discussed in [SAF05], the inner header,
and data sender does not necessarily have
information about the value size of TTL Diff echoed to the sender remains unchanged.
For data transfer at connection
initiation; for example, in request-response protocols such a scenario can occur with a Bump-In-The-Stack
(BITS), an IPSec encryption implementation where as HTTP,
the data encryption
occurs between server doesn't know the network drivers and size or name of the TCP/IP protocol stack
[RFC2401].

As one example, if a remote access VPN client uses a BITS structure,
then Quick-Start obstacles between requested object
during connection initiation. [SAF05] explores some of the client
performance implications of overly-large Quick-Start requests, and
discusses heuristics that end-nodes could use to size their requests
appropriately. For example, the VPN gateway
won't be seen. This is a particular problem because sender might have information about
the path
between bandwidth of the client and last-mile hop, the VPN gateway is likely to contain size of the most
congested part local socket
buffer, or of the path. Because most VPN clients are reported
to TCP receive window, and could use BITS [H05], we will explore this information
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 determining the packet is passed rate to the BITW. If the
QS TTL is request. Web servers that mostly have
small objects to transfer might decide not decremented, then the value to use Quick-Start at
all, since Quick-Start would be of TTL Diff is changed,
and the little benefit to them.

Quick-Start request will be denied. However, more effective if the BITW
supports a host and does Quick-Start requests are not have its own IP address, then the IP
TTL
larger than necessary; every Quick-Start request that is approved
but not decremented before the packet is passed used (or not fully used) takes away from the host to bandwidth pool
available for granting successive Quick-Start requests. Following
Section 4.1, the BITW, and sender SHOULD NOT request a false positive could occur.

Other tunnels that need sending rate larger
than it is able to be looked at are IP tunnels over non-
network protocols, such as IP over TCP and IP use 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 round-trip time of possible
bottlenecks that do the connection
(or over 100 ms, if the round-trip time is not participate in known), except as
required to round up the Quick-Start feedback.

6.3. Tunnels That Support Quick-Start

This desired sending rate to the next-highest
allowable request.

8.2. Deciding the Permitted Rate Request at a Router

In this section discusses tunnels configured we briefly outline how a router might decide whether
or not to support Quick-Start.

If approve a Quick-Start Request. The router should 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 tunnel ingress node chooses arrival rate was
to locally approve increase by the Quick-
Start request, then aggregate rate requests that the ingress node MUST decrement router has
approved over the Quick-Start
TTL at last fraction of a second?

In order to answer the same time it decrements last question, the IP TTL, and MUST copy IP TTL router must have some
knowledge of the available bandwidth on the output link and of the
Quick-Start option from the inner IP header 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 outer
header. During encapsulation, router can begin to
deny Quick-Start requests while the tunnel ingress MUST zero output link is still
underutilized.

A simple way for the
Quick-Start rate request field in router to keep track of the inner header potential bandwidth
from recently-approved requests is to ensure maintain two counters, one for
the total aggregate Rate Requests that have been approved in the Quick-Start request will be rejected if
current time interval [T1, T2], and one for the tunnel egress does
not support Quick-Start. 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 D, and
more discussion of these issues is available in [SAF05].)

* If the tunnel ingress node does not choose router's output link has been underutilized and the
aggregate of the Quick Start Request Rate options granted is low
enough to locally prevent a near-term bandwidth shortage, then the router
could approve the Quick-Start request, then it MUST either delete Request.

Section 10.2 discusses some of the implementation issues in
processing Quick-Start
option from the inner header before encapsulation, or zero the QS
TTL and requests at routers. [SAF05] discusses the Rate Request fields before encapsulation.

Upon decapsulation, if
range of possible Quick-Start algorithms at the outer header contains router for deciding
whether to approve a Quick-Start
option, request. In order to explore the tunnel egress MUST copy
limits of the IP TTL and 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
option from
requests.

9. Evaluation of Quick-Start

9.1. Benefits of Quick-Start

The main benefit of Quick-Start is the outer IP header faster start-up for the
transport connection itself. For a small TCP transfer of one to
five packets, Quick-Start is probably of very little benefit; at
best, it might shorten the inner header.

IPsec uses connection lifetime from three to two
round-trip times (including the IKE (Internet Key Exchange) Protocol round-trip time for security
associations. We do connection
establishment). Similarly, for a very large transfer, where the
slow-start phase would have been only a small fraction of the
connection lifetime, Quick-Start would be of limited benefit.
Quick-Start would not consider significantly shorten the interactions between Quick-
Start and IPsec with IKEv1 [RFC2409] in this document. When connection lifetime,
but it might eliminate or at least shorten the RFC start-up phase.
However, for IKEv2 [IKEv2] is published, we will specify moderate-sized connections in a modification of
IPsec to well-provisioned
environment, Quick-Start could possibly allow the support entire transfer of Quick-Start
M packets to be negotiated; this
modification will specify completed in one round-trip time (after the negotiation between tunnel endpoints
to allow or forbid support initial
round-trip time for Quick-Start within the tunnel. This
was done for ECN for IPsec tunnels, with IKEv1 [RFC3168, Section
9.2]. This negotiation SYN exchange), instead of Quick-Start capability the log_2(M)-2
round-trip times that it would normally take for the data transfer,
in an IPsec tunnel
will be specified in a separate IPsec document. This document will
also include a discussion of the potential effects of uncongested environments (assuming an adversary's
modifications initial window of four
packets).

9.2. Costs of the Quick-Start field (as in Sections 18 and 19

This section discusses the costs of
RFC 3168), Quick-Start for the connection
and of for the security considerations of exposing routers along the Quick-
Start rate request to network scanners.

7. path.

The cost of having a Quick-Start Mechanism in other Transport Protocols

The section earlier specified packet dropped:
For the use of sender the biggest risk in using Quick-Start lies in TCP. In
this section, we generalize this to give guidelines for the use
possibility of suffering from congestion-related losses of the
Quick-Start with other transport protocols. We also discuss briefly
how Quick-Start could packets. This should be specified for other transport protocols.

The general guidelines for an unlikely situation because
routers are expected to approve Quick-Start in transport protocols Requests only when they
are as
follows:

* significantly underutilized. However, a transient increase in
cross-traffic in one of the routers, a sudden decrease in available
bandwidth on one of the links, or congestion at a non-IP queue could
result in packet losses even when the Quick-Start Request was
approved by all of the routers along the path. If a Quick-Start
packet is only specified for unicast transport protocols with
appropriate dropped, then the sender reverts to the congestion control mechanisms. Note:
mechanisms it would have used if the Quick-Start is request had not
a replacement for standard congestion control techniques, but meant
been approved, so the performance cost to augment their operation.

* A transport-level mechanism is needed for the connection of having a
Quick-Start response
from the receiver packet dropped is small, compared to the sender. This response contains performance
without Quick-Start. (On the Rate
Request, TTL Diff, other hand, the performance difference
between Quick-Start with a Quick-Start packet dropped and QS Nonce.

* Quick-
Start with no Quick-Start packet dropped can be considerable.)

Added complexity at routers:

The sender checks the validity main cost of the Quick-Start response.

* The sender has an estimate at routers concerns the costs of added
complexity. The added complexity at the round-trip time, end-points is moderate, and translates
might easily be outweighed by the benefit of Quick-Start response into an allowed window or allowed sending
rate. to the end
hosts. The sender starts sending Quick-Start packets, rate-paced out added complexity at the approved sending rate.

* After routers is also somewhat
moderate; it involves estimating the sender receives unused bandwidth on the output
link over the last several seconds, processing the first acknowledgement packet for a Quick-Start packet, no more
request, and keeping a counter of the aggregate Quick-Start packets are sent. The
sender adjusts its current congestion window or sending rate
approved over the last fraction of a second. However, this added
complexity at routers adds to the development cycle, and could
prevent the addition of other competing functionality to routers.
Thus, careful thought would have to be
consistent with given to the actual amount addition of data that was transmitted
Quick-Start to IP.

The slow path in routers:
Another drawback of Quick-Start is that round-trip time.

* When packets containing the last
Quick-Start packet is acknowledged, Request message might not take the sender
continues using fast path in routers,
particularly in the standard congestion control mechanisms of that
protocol.

* If one beginning of Quick-Start's deployment in the Quick-Start packets is lost, then
Internet. This would mean some extra delay for the sender reverts
to end hosts, and
extra processing burden for the standard congestion control method of that protocol that routers. However, as discussed in
Sections 4.1 and 4.6, not all packets would have been used if carry the Quick-Start request had not been
approved.
option. In addition, for the sender takes into account underutilized links where Quick-Start
Requests could actually be approved, or in typical environments
where most of the
information that packets belong to large flows, the burden of the
Quick-Start congestion window was too large
(e.g., by decreasing ssthresh Option on routers would be considerably reduced.
Nevertheless, it is still conceivable, in TCP).

8. Using the worst case, that many
packets would carry Quick-Start

8.1. Determining requests; this could slow down the Rate to Request
processing of Quick-Start packets in routers considerably. As
discussed in [SAF05], the data sender does not necessarily have
information about the size of Section 9.6, routers can easily protect against this by
enforcing a limit on the data transfer rate at connection
initiation; for example, in request-response protocols such as HTTP,
the server doesn't know the size or name which Quick-Start requests will be
considered. [RW03] and [RW04] contain measurements of the requested object
during connection initiation. [SAF05] explores some impact of the
performance implications
IP Option Processing on packet round-trip times.

Multiple paths:
One limitation of overly-large Quick-Start requests, and
discusses heuristics is that it presumes that end-nodes could use to size their requests
appropriately. For example, the sender might have information about the bandwidth data
packets of a connection will follow the last-mile hop, same path as the size of Quick-Start
request packet. If this is not the local socket
buffer, or of case, then the TCP receive window, and connection could use this information
in determining
be sending the rate to request. Web servers that mostly have
small objects to transfer might decide not to use Quick-Start packets, at
all, since Quick-Start would be the approved rate, along a
path that was already congested, or that became congested as a
result of little benefit to them.

Quick-Start will be more effective if Quick-Start requests are not
larger than necessary; every this connection. Thus, Quick-Start request that could give poor
performance when there is approved
but not used (or not fully used) takes away from a routing change immediately after 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 approved, and the round-trip time Quick-Start data packets
follow a different path from that of the original Quick-Start
Request. This is, however, similar to what would happen, for a
connection
(or over 100 ms, with sufficient data, if the round-trip time is not known), except as
required to round up connection's path was
changed in the middle of the desired sending rate to connection, when the next-highest
allowable request.

8.2. Deciding connection had
already established the Permitted Rate Request at a Router

In this section we briefly outline how a allowed initial rate.

A router might decide whether
or not to that uses multipath routing for packets within a single
connection MUST NOT approve a Quick-Start Request. As request. Quick-Start
would not perform robustly in an example, environment with multipath routing,
where different packets in a connection routinely follow different
paths. In such an environment, the router
could ask Quick-Start request and some
fraction of the following questions:

* Has packets in the router's output link been connection might take an
underutilized for some time
(e.g., several seconds).

* Would path, while the output link remain underutilized if rest of the arrival rate was
to increase by packets take an alternate,
congested path.

Non-IP queues:
A problem of any mechanism for feedback from routers at the aggregate rate requests IP level
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
queues in layer-two Ethernet or ATM networks. One possibility would
be that an IP-level router has
approved over the last fraction of adjacent to such a second?

In order non-IP queue or
bottleneck would be configured to answer this question, the router must have some
knowledge of the available bandwidth on the output link and of the reject Quick-Start bandwidth requests if
that could arrive due to recently-approved was appropriate. One would hope that in general, IP networks
are configured so that non-IP queues between IP routers do not end
up being the congested bottlenecks.

9.3. Quick-Start Requests. In with QoS-enabled Traffic

The discussion in this way, if an underutilized router
experiences a flood document has largely been of Quick-Start requests, 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 router can begin traffic class into account when deciding
whether or not to
deny Quick-Start requests while grant the output link Quick-Start request. We don't address
this context further in this paper, since it is still
underutilized.

A simple way for the router orthogonal to keep track the
specification of Quick-Start.

9.4. Protection against Misbehaving Nodes

In this section we discuss the potential bandwidth
from recently-approved requests is to maintain two counters, one for protection against senders,
receivers, or colluding middleboxes lying about the total aggregate Rate Requests Quick-Start
Request. First, we note that have been approved it is not necessarily 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, sender's
or
make requirements for the appropriate time intervals for remembering receiver's interest to lie about 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].)

* Request. If the router's output link has been underutilized
sender sends at too-high of an initial rate, and the
aggregate Quick Start Request Rate options granted is low enough to
prevent has a near-term bandwidth shortage, then the router could
approve packet
dropped, this does not necessarily improve the Quick-Start Request.

Section 10.2 discusses some performance of the implementation issues in
processing
connection, relative to the case when the Quick-Start requests Request was
not approved.

9.4.1. Misbehaving Senders

A transport sender could try to transmit data at routers. [SAF05] discusses a higher rate than
that approved in the
range of possible Quick-Start algorithms Request, or transmit at the router for deciding
whether to approve a high rate
even without using Quick-Start request. In order at all. The network could use a
traffic policer to explore protect against such misbehaving senders, for
example by dropping packets that exceed the
limits allowed transmission
rate. The required Report of Approved Rate allows traffic policers
to check that the possible functionality at routers, [SAF05] also
discusses Extreme Quick-Start mechanisms at routers, where Report of Approved Rate does not exceed the
router would keep per-flow state concerning Rate
Request actually approved at that point in the network in the
previous Quick-Start
requests.

9. Evaluation of Quick-Start

9.1. Benefits of Quick-Start Request from that connection. The main benefit required
Approved Rate report also allows traffic policers to check that the
sender's sending rate does not exceed the rate in the Report of Quick-Start
Approved Rate.

If a router or receiver receives an Approved Rate report that is
larger than the faster start-up for Rate Request in the
transport Quick-Start request approved for
that sender for that connection itself. For a small TCP transfer of one to
five packets, in the previous round-trip time,
then the router or receiver could deny future Quick-Start requests
from that sender, e.g., by deleting the Quick-Start Request from
future packets from that sender. We note that routers are not
required to use Approved Rate reports to check if senders are
cheating; this is probably of very little benefit; at
best, it might shorten the connection lifetime from three to two
round-trip times (including discretion of the round-trip time for connection
establishment). Similarly, for router. If a very large transfer, where the
slow-start phase would have been only router sees
a small fraction of the
connection lifetime, Quick-Start would be Report of limited benefit.
Quick-Start would Approved Rate, and did not significantly shorten the connection lifetime,
but it might eliminate or at least shorten the start-up phase.
However, for moderate-sized connections in a well-provisioned
environment, see an earlier Quick-Start could possibly allow
request, then either the entire transfer of
M packets to sender could be completed in one round-trip time (after cheating, or the initial
round-trip time for
connection's path could have changed since the SYN exchange), instead of Quick-Start request
was sent. In either case, the log_2(M)-2
round-trip times that router could decide to deny future
Quick-Start requests from this sender. In particular, it would normally take is
reasonable for the data transfer,
in an uncongested environments (assuming an initial window of four
packets).

9.2. Costs of router to deny a Quick-Start

This section discusses request if either
the costs of Quick-Start for sender is cheating, or if the connection
and for the routers along the path.

The cost of having path suffers from path
changes or multi-pathing.

If a router approved a Quick-Start packet dropped:
For Request, but does not see a
subsequent Approved Rate report, then there are several
possibilities: (1) the sender did not send a Report of Approved
Rate; (2) the biggest risk Approved Rate report was dropped in the network; or
(3) the Approved Rate report took a different path from the Quick-
Start Request. In any of these three cases, the router would be
justified in using denying future Quick-Start lies in the
possibility of suffering Requests from congestion-related losses this sender.

In any of the
Quick-Start packets. This should be above mentioned cases (i.e., an unlikely situation because
routers are expected to approve Quick-Start Requests only when they
are significantly underutilized. However, a transient increase in
cross-traffic Approved Rate report
that is larger than the Rate Request in one the earlier Quick-Start
request; no Approved Rate report because of packet drops, path
changes, or the routers, sender's failure to send one), a sudden decrease traffic policer may
assume that Quick-Start is not being used appropriately, or is being
used in available
bandwidth on one an inappropriate environment, and take some corresponding
action.

9.4.2. Receivers Lying about Whether the Request was Approved

One form of misbehavior would be for the links, or congestion at a non-IP queue could
result in packet losses even when receiver to lie to the
sender about whether the Quick-Start Request was
approved approved, by all of the routers along
falsely reporting the path. TTL Diff and QS Nonce. If a router that
understands the Quick-Start
packet is dropped, then Request denies the sender reverts to request by deleting
the congestion control
mechanisms it would have used if request or by zeroing the QS TTL and QS Nonce, then the receiver
can ``lie" about whether the Quick-Start request has not
been approved, so was approved only by
successfully guessing the performance cost value of the TTL Diff and QS Nonce to
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 connection of having a Quick-Start packet dropped request is small, compared denied only by a non-Quick-
Start-capable router, or by a router that is unable to zero the performance
without Quick-Start. (On QS
TTL and QS Nonce fields, then the other hand, receiver could lie about whether
the performance difference
between Quick-Start with a Quick-Start packet dropped and Quick-
Start with no Quick-Start packet dropped can be considerable.)

Added complexity at routers:
The main cost of Quick-Start at routers concerns Requests were approved by modifying the costs of added
complexity. The added complexity at QS TTL in
successive requests received from the end-points is moderate, and
might easily be outweighed by same host. In particular, if
the benefit of sender does not act on a Quick-Start to Request, then the end
hosts. The added complexity at receiver
could decrement the routers is also somewhat
moderate; it involves estimating QS TTL by one in the unused bandwidth on next request received from
that host before calculating the output
link over TTL Diff, and decrement the last several seconds, processing QS TTL
by two in the Quick-Start following received request, and keeping a counter until the sender acts on
one of the aggregate Quick-Start rate
approved over the last fraction of Requests.

Unfortunately, if a second. However, this added
complexity at routers adds router doesn't understand Quick-Start, then it
is not possible for that router to take an active step such as
zeroing the development cycle, QS TTL and could
prevent the addition of other competing functionality to routers.
Thus, careful thought would have to be given to the addition of
Quick-Start QS Nonce to IP.

The slow path deny a request. As a result, the
QS TTL is not a fail-safe mechanism for preventing lying by
receivers in routers:
Another drawback the case of Quick-Start non-Quick-Start-capable routers.

As we noted above, it is that packets containing the
Quick-Start Request message might not take the fast path necessarily in routers, the receiver's interests
to lie about whether the rate request was approved, particularly
since such lying could result in the beginning of Quick-Start's deployment Quick-Start data packets dropped in
the
Internet. This network due to congestion.

9.4.3. Receivers Lying about the Approved Rate

A second form of receiver misbehavior would mean some extra delay be for the end hosts, and
extra processing burden for receiver to
lie to the routers. However, as discussed in
Sections 4.1 and 4.6, not all packets would carry sender about the Quick-Start Rate Request option. In addition, for the underutilized links where an approved Quick-Start Requests could actually be approved, or in typical
environments where most
Request, by increasing the value of the packets belong to large flows, Rate Request field.
However, the
burden of receiver doesn't necessarily know the Quick-Start Option on routers would be considerably
reduced. Nevertheless, it is still conceivable, Rate Request in
the worst case,
that many packets would carry Quick-Start requests; this could slow
down the processing of original Quick-Start packets in routers considerably.
As discussed in Section 9.5, routers can easily protect against this Request sent by enforcing the sender, and a limit on higher
Rate Request reported by the rate at which Quick-Start requests receiver will only be considered.

Multiple paths:
One limitation of Quick-Start is that considered valid
by the sender if it presumes that is no higher than the Rate Request originally
requested by the sender. For example, if the data
packets sender sends a Quick-
Start Request with a Rate Request of X, and the receiver reports
receiving a connection will follow Quick-Start Request with a Rate Request of Y > X, then
the sender knows that either some router along the same path as
malfunctioned (increasing the Quick-Start
request packet. If this Rate Request inappropriately), or the
receiver is not lying about the case, then Rate Request in the connection could
be sending received packet.

If the sender sends a Quick-Start packets, at Request with a Rate Request of Z,
the receiver receives the Quick-Start Request with an approved rate, along a
path that was already congested, or that became congested as Rate
Request of X, and reports a
result Rate Request of this connection. This is, however, similar to what would
happen, Y, for a connection with sufficient data, if X < Y <= Z, then
the connection's
path was changed receiver only succeeds in lying to the middle of sender about the connection, when approved
rate if the
connection had already established receiver successfully reports 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 rightmost 2Y bits in
the QS nonce.

If senders often use a connection routinely follow different
paths. In such an environment, configured default value for the Quick-Start request and some
fraction of Rate
Request, then receivers would often be able to guess the packets in original
Rate Request, and this would make it easier for the connection might take an
underutilized path, while receiver to lie
about the rest value 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 Rate Request field. Similarly, if the
Quick-Start request is approved,
receiver often communicates with a particular sender, and the Quick-Start data packets
follow a different path from sender
always uses the same Rate Request for that of receiver, then the original Quick-Start
Request. However, as noted in Section 6.2, this is similar
receiver might over time be able to what
can happen without Quick-Start when a connection path is changed
after the connection had already established a certain sending rate
on infer the original path.

Non-IP queues:
A problem Rate Request
used by the sender.

There are several possible additional forms of any mechanism for feedback from routers at protection against
receivers lying about the IP level
is that there can be queues and bottlenecks in value of the end-to-end path
that are not in IP-level routers. As an example, these include
queues in layer-two Ethernet or ATM networks. Rate Request. One possibility possible
additional protection would be that an IP-level router adjacent to such for a non-IP queue or
bottleneck would be configured to reject Quick-Start requests if
that was appropriate. One would hope that in general, IP networks
are configured so router that non-IP queues between IP routers do not end
up being the congested bottlenecks.

9.3. Quick-Start with QoS-enabled Traffic

The discussion decreases a Rate
Request in this document has largely been of a Quick-Start with
default, best-effort traffic. Request to report the decrease directly to
the sender. However, Quick-Start this could lead to many reports back to the
sender for a single request, and could also be used by traffic using some in address-
spoofing attacks.

A second limited form of differentiated services, and
routers could take the traffic class into account when deciding
whether or not protection would be for senders to grant the Quick-Start request. We don't address
this context further use some
degree of randomization in this paper, since the requested Rate Request, so that it is orthogonal
difficult for receivers to guess the
specification of Quick-Start.

9.4. Protection against Misbehaving Nodes

In original value for the Rate
Request. However, this section we discuss is difficult because there is a fairly
coarse granularity in the protection against receivers or
colluding middleboxes lying about set of rate requests available to the Quick-Start Request. First,
sender, and randomizing the initial request only offers limited
protection in any case.

Again, as we note that noted above, it is not necessarily in the receiver's interest
interests to lie about the value of the approved rate request,
particularly since such lying could result in Quick-Start Request. If data
packets dropped in the sender sends at too-high of network due to congestion.

9.4.4. Collusion between Misbehaving Routers

In addition to protecting against misbehaving receivers, it is
necessary also to protect against misbehaving routers. Consider
collusion between an initial rate, ingress router and has a packet dropped, this does not necessarily
improve the performance of the connection, relative an egress router belonging
to the case when same Intranet. The ingress router could decrement the Quick-Start Rate
Request was not approved.

9.4.1. Receivers Lying about Whether at the ingress, with the egress router increasing it again
at the egress. The routers between the ingress and egress that
approved the decremented rate request might not have been willing to
approve the Request was Approved

One larger, original request.

Another form of misbehavior collusion would be for the receiver to lie ingress router to inform
the
sender about whether the Quick-Start Request was approved, by
falsely reporting egress router out-of-band of the TTL Diff and QS Nonce. If a router that
understands the Quick-Start Request denies Nonce for the
request by deleting packet at the request or by zeroing ingress. This would enable the egress router
to modify the QS TTL and QS Nonce, then Nonce so that it appeared that all of
the receiver
can ``lie" about whether routers along the request was path had approved only by
successfully guessing the value of the TTL Diff and QS Nonce request. There does not
appear to
report. The chance of be any protection against a colluding ingress and egress
router. Even if an intermediate router had deleted the receiver successfully guessing Quick-Start
Option from the
correct value for packet, the TTL Diff is 1/256, and ingress router could have sent the chance of
Quick-Start Option to the
receiver successfully guessing egress router out-of-band, with the QS nonce for a reported rate
request of K is 1/(2K).

However, if egress
router inserting the Quick-Start request is denied only by a non-Quick-
Start-capable router, or by Option, with a router that is unable to zero the modified QS TTL and QS Nonce fields, the
field, back in the receiver could lie about whether packet.

However, unlike ECN, there is somewhat less incentive for
cooperating ingress and egress routers to collude to falsely modify
the Quick-Start Requests were Request so that it appears to have been approved by modifying the QS TTL in
successive requests received from
all of the same host. In particular, if routers along the sender does not act on path. With ECN, a Quick-Start Request, then the receiver colluding ingress
router could decrement falsely mark a packet as ECN-capable, with the QS TTL by one in
colluding egress router returning the next request received from
that host before calculating ECN field in the TTL Diff, IP header to
its original non-ECN-capable codepoint, and decrement congested routers along
the QS TTL path could have been fooled into not dropping that packet. This
collusion would give an unfair competitive advantage to the traffic
protected by two in the following received request, until colluding ingress and egress routers.

In contrast, with Quick-Start, the sender acts on
one collusion of the Quick-Start Requests.

Unfortunately, if a router doesn't understand Quick-Start, then ingress and
egress routers to make it
is falsely appear that a Quick-Start request
was approved does not possible for necessarily give an advantage to the traffic
covered by that collusion. If some router to take an active step such as
zeroing along the QS TTL and QS Nonce path really
does not have enough available bandwidth to deny a request. As a result, approve the
QS TTL is not a fail-safe mechanism for preventing lying by
receivers in Quick-Start
request, then the case Quick-Start packets sent as a result of non-Quick-Start-capable routers.

9.4.2. Receivers Lying about the Approved Rate

A second form of misbehavior would
falsely-approved request could be for dropped in the receiver to lie network, to the
sender about the Rate Request for an approved Quick-Start Request,
by increasing the value
resulting disadvantage of the Rate Request field. However, connection. Thus, while the
receiver doesn't ingress
and egress routers could collude to prevent intermediate routers
from denying a Quick-Start request, it would not necessarily know be to
the Rate Request in connection's advantage for this to happen. In addition, the original
Quick-Start Request sent by
router between the sender, ingress and egress nodes that denied the request
could be monitoring connection performance, actively penalizing
nodes that seem to be using Quick-Start after a higher Quick-Start request
was denied, or that are reporting an Approved Rate Request
reported higher than that
actually approved by that router.

If the receiver will only be considered valid by congested router was ECN-capable, and the sender
if it is no higher than colluding ingress
and egress routers were lying about ECN-capability as well as about
Quick-Start, then the Rate Request originally requested by result could be that the
sender. For example, if Quick-Start request
falsely appears to the sender sends a Quick-Start Request with
a Rate Request of X, to have been approved, and the receiver reports receiving a Quick-
Start Request with a Rate Request of Y > X, then packets falsely appear to the sender knows
that either some congested router along the path malfunctioned (increasing the
Rate Request inappropriately), or the receiver is lying about to be ECN-
capable. In this case, the
Rate Request colluding routers might succeed in the received packet.

If the sender sends a Quick-Start Request with
giving a Rate Request of Z,
the receiver receives competitive advantage to the Quick-Start Request with an approved Rate
Request of X, traffic protected by their
collusion (if no intermediate router is monitoring to catch such
misbehavior).

9.5. Misbehaving Middleboxes and reports a Rate Request of Y, for X < Y <= Z, then the receiver only succeeds IP TTL

One possible difficulty is that of traffic normalizers [HKP01] or
other middleboxes along that path that re-write IP TTLs, in lying order to the sender about the approved
rate if the receiver successfully reports the rightmost 2Y bits
foil other kinds of attacks in the QS nonce. network. If senders often use such a configured default value for traffic
normalizer re-wrote the Rate
Request, IP TTL, but did not adjust the Quick-Start
TTL by the same amount, then receivers would often be able to guess the original
Rate Request, and this would make it easier sender's mechanism for determining
if the receiver to lie
about the value of request was approved by all routers along the Rate Request field. Similarly, if path would no
longer be reliable. Re-writing the
receiver often communicates with a particular sender, and IP TTL could result in false
positives (with the sender
always uses the same Rate Request for incorrectly believing that receiver, then the
receiver might over time be able to infer Quick-
Start request was approved) as well as false negatives (with the original Rate Request
used by
sender incorrectly believing that the sender.

There are several possible additional forms Quick-Start request was
denied).

9.6. Attacks on Quick-Start

As discussed in [SAF05], Quick-Start is vulnerable to two kinds of protection against
receivers lying about
Quick-Start attacks: (1) attacks to increase the value of routers'
processing and state load; and (2) attacks with bogus Quick-Start
requests to temporarily tie up available Quick-Start bandwidth,
preventing routers from approving Quick-Start requests from other
connections. Routers can protect against the Rate Request. One possible
additional protection would be for a router that decreases a Rate
Request in first kind of attack
by applying a simple limit on the rate at which Quick-Start Request to report requests
will be considered by the decrease directly router.

The second kind of attack, attacks to tie up the sender. However, this could lead available Quick-
Start bandwidth, is more difficult to many reports back defend against. As discussed
in [SAF05]. Quick-Start Requests that are not going to the
sender for a single request, and could also be used used,
either because they are from malicious attackers or because they are
denied by routers downstream, can result in address-
spoofing attacks.

A second limited form `wasting' potential
Quick-Start bandwidth, resulting in routers denying subsequent
Quick-Start Requests that if approved would in fact have been used.
We note that the likelihood of protection malicious attacks would be for senders to use minimized
significantly when Quick-Start was deployed in a controlled
environment such as an Intranet, where there was some
degree form of randomization
centralized control over the users in the requested Rate Request, so system. We also note that
this form of attack could potentially make Quick-Start unusable, but
it is
difficult for receivers to guess would not do any further damage; in the original value worst case, the network
would function as a network without Quick-Start.

[SAF05] considers the potential of Extreme Quick-Start algorithms at
routers, which keep per-flow state for Quick-Start connections, in
protecting the Rate
Request. However, this is difficult because there availability of Quick-Start bandwidth in the face of
frequent overly-larqe Quick-Start requests.

9.7. Simulations with Quick-Start

Quick-Start was added to the NS simulator [SH02] by Srikanth
Sundarrajan, and additional functionality was added by Pasi
Sarolahti. The validation test is a fairly
coarse granularity at `test-all-quickstart' in the set
`tcl/test' directory in NS. The initial simulation studies from
[SH02] show a significant performance improvement using Quick-Start
for moderate-sized flows (between 4KB and 128KB) in under-utilized
environments. These studies are of rate requests available to file transfers, with the
sender, and randomizing
improvement measured as the initial request only offers limited
protection relative increase in any case.

9.4.3. Collusion between Misbehaving Routers

In addition to protecting against misbehaving receivers, it the overall
throughput for the file transfer. The study shows that potential
improvement from Quick-Start is
necessary also to protect against misbehaving routers. Consider
collusion between an ingress router and an egress router belonging proportional to the same Intranet. The ingress router could decrement delay-bandwidth
product of the Rate
Request at path.

The Quick-Start simulations in [SAF05] explore the ingress, with following: the egress router increasing it again
at
potential benefit of Quick-Start for the egress. The routers between connection; the ingress relative
benefits of different router-based algorithms for approving Quick-
Start requests; and egress that
approved the decremented rate request might not have been willing to
approve the larger, original request.

Another form effectiveness of Quick-Start as a function
of collusion would be for the ingress router to inform senders' algorithms for choosing the egress router out-of-band size of the TTL Diff rate
request.

10. Implementation and QS Nonce for the
request packet at Deployment Issues

This section discusses some of the ingress. implementation issues with Quick-
Start. This would enable section also discusses some of the egress router 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 modify the QS TTL work, and QS Nonce so that it appeared that all the problems posed by the wide deployment of
middleboxes today that block the routers along use of known or unknown IP Options.

10.1. Implementation Issues for Sending Quick-Start Requests

Section 4.6 discusses some of the path had approved issues with deciding the request. There does not
appear initial
sending rate to be any protection against a colluding ingress and egress
router. Even if an intermediate router had deleted the request. Quick-Start
Request Option from the packet, raises additional issues about
the ingress router could have sent communication between the Quick-Start Request Option to transport protocol and the egress router out-of-band,
with
application, and about the egress router inserting use of the Quick-Start Request Option, past history with a modified QS TTL field, back Quick-Start
in the packet.

However, unlike ECN, there end node.

One possibility is somewhat less incentive that a protocol implementation could provide an
API for
cooperating ingress and egress routers applications to collude indicate when they want to falsely modify request Quick-
Start, and what rate they would like to request. In the Quick-Start Request so
conventional socket API this could be a socket option that it appears to is set
before a connection is established. Some applications, such those
that use TCP for bulk transfers, do not have been approved by
all of interest in the routers along
transmission rate, but they might know the path. With ECN, a colluding ingress
router amount of data that can
be sent immediately. Based on this, the sender implementation could falsely mark
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 packet as ECN-capable, with specific preference on the
colluding egress router returning transmission rate
and they could indicate the ECN field in required rate explicitly to the IP header
transport protocol to
its original non-ECN-capable codepoint, and congested routers along be used in the path could have been fooled into not dropping Quick-Start Request.

We note that packet. This
collusion would give an unfair competitive advantage to when Quick-Start is used, the traffic
protected by TCP sender is required to
save the colluding ingress QS Nonce and egress routers.

In contrast, with Quick-Start, the collusion of TTL Diff when the ingress and
egress routers to make it falsely appear that a Quick-Start request
was approved does not necessarily give an advantage is
sent, and to implement an additional timer for the traffic
covered by that collusion. If some paced
transmission of Quick-Start packets.

10.2. Implementation Issues for Processing Quick-Start Requests

A router along or other network host must be able to determine the path really
does not have enough available
approximate bandwidth of its outbound network interfaces in order to approve the Quick-Start
request, then the
process incoming Quick-Start packets sent as a result of rate requests, including those that
originate from the
falsely-approved request could host itself. One possibility would be dropped in the network, for hosts
to rely on configuration information to determine link bandwidths;
this has the
resulting disadvantage drawback of the connection. Thus, while the ingress
and egress routers could collude not being robust to prevent intermediate routers
from denying a Quick-Start request, it errors in
configuration. Another possibility would not necessarily be to
the connection's advantage for this network device
drivers to happen. In addition, infer the
router between bandwidth for the ingress interface and egress nodes that denied to communicate
this to the request
could be monitoring connection performance, actively penalizing
nodes that seem IP layer.

Particular issues will arise for wireless links with variable
bandwidth, where decisions will have to be using Quick-Start after a Quick-Start request
was denied.

If the congested router was ECN-capable, and the colluding ingress
and egress routers were lying about ECN-capability as well as made about
Quick-Start, then how frequently
the result could be that network host gets updates of the changing bandwidth. It seems
appropriate that Quick-Start request
falsely appears to the sender Requests would be handled particularly
conservatively for links with variable bandwidth, to have been avoid cases
where Quick-Start Requests are approved, the link bandwidth is
reduced, and the Quick-
Start data packets falsely appear to the congested router to that are sent end up being dropped.

Difficult issues also arise for paths with multi-access links (e.g.,
Ethernet). Routers with multi-access links should be ECN-
capable. In this case, the colluding routers might succeed particularly
conservative in
giving a competitive advantage to the traffic protected by their
collusion (if no intermediate router is monitoring to catch such
misbehavior).

9.4.4. Misbehaving Middleboxes and granting Quick-Start requests.

10.3. Possible Deployment Scenarios

Because of possible problems discussed above concerning using Quick-
Start over some network paths, the IP TTL

A separate possibility is that most realistic initial deployment
of traffic normalizers [HKP01] or Quick-Start would most likely take place in Intranets and other middleboxes along that path
controlled environments. Quick-Start is most useful on high
bandwidth-delay paths that re-write IP TTLs, are significantly underutilized. The
primary initial users of Quick-Start would likely be in order
organizations that provide network services to
foil other kinds their users and also
have control over a large portion of attacks in the network. If such network path.

Below are a traffic
normalizer re-wrote the IP TTL, but did not adjust 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
TTL by in the same amount, then routers
and end-nodes, where the sender's mechanism incentives for determining
if the request was approved by all routers along to deploy Quick-
Start might be the path most clear.

* Centrally-administrated organizational Intranets: These intranets
often have large network capacity, with networks that are
underutilized for much of the time. Such Intranets might also
include high-bandwidth and high-delay paths to remote sites. In
such an environment, Quick-Start would no
longer be reliable. Re-writing of benefit to users, and
there would be a clear incentive for the IP TTL deployment of Quick-Start
in routers. For example, Quick-Start could result be quite useful in false
positives (with high-
bandwidth networks used for scientific computing.

* GPRS: Quick-Start could also be useful in high-delay environments
of Cellular Wide-Area Wireless Networks such as the sender incorrectly believing that 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 Quick-
Start request was approved) as well as false negatives (with GPRS round-trip times range typically from few
hundred milliseconds to over a second excluding any possible
queueing delays in the
sender incorrectly believing 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 request was
denied).

9.5. Attacks on Quick-Start

As discussed in [SAF05], Quick-Start is vulnerable to two kinds could
be of
Quick-Start attacks: (1) attacks to increase the routers'
processing and state load; and (2) attacks with bogus Quick-Start
requests significant benefit to temporarily tie up available Quick-Start bandwidth,
preventing routers from approving Quick-Start requests from other
connections. Routers can protect against users in these environments.

* Paths over satellite links: Geostationary Orbit (GEO) satellite
links have one-way propagation delays on the first kind order of attack
by applying a simple limit on 250 ms while
the rate at which Quick-Start requests
will bandwidth can be considered by the router.

The measured in megabits per second kind [RFC2488].
Because of attack, attacks to tie up the available Quick-
Start bandwidth, considerable bandwidth-delay product on the link,
TCP's slow-start is more difficult to defend against. As discussed a major performance limitation in [SAF05]. Quick-Start Requests that are not going to the beginning
of the connection. A large initial congestion window would be used,
either because they are from malicious attackers or because they are
denied by routers downstream, can result
useful to users of such satellite links.

10.4. Would QuickStart packets take the slow path in `wasting' potential routers?

How much delay would the slow path add to the processing time for
Quick-Start bandwidth, resulting in request packets? In addition, if QuickStart request
packets took the slow path, this could add stress to routers, though
routers denying subsequent
Quick-Start Requests that if approved would in fact have been used.
We note that could always rate-limit the likelihood number of malicious attacks would be minimized
significantly when Quick-Start was deployed in a controlled
environment such as an Intranet, where there was some form QuickStart request
packets they are willing to consider.

10.5. A Comparison with the Deployment Problems of
centralized control over ECN

Given the users glacially slow rate of deployment of ECN in the system. We also Internet
to date [MAF05], it is disconcerting to note that
this form some of the
deployment problems of attack could potentially make Quick-Start unusable, but are even greater than those of
ECN. First, unlike ECN, which can be of benefit even if it would not do any further damage; in is only
deployed on one of the worst case, routers along the network
would function as end-to-end path, a network without Quick-Start.

[SAF05] considers the potential
connection's use of Extreme Quick-Start algorithms at
routers, which keep per-flow state for Quick-Start connections, in
protecting the availability requires its deployment on all of Quick-Start bandwidth in
the face of
frequent overly-larqe Quick-Start requests.

9.6. Simulations with Quick-Start

Quick-Start was added to routers along the NS simulator [SH02] by Srikanth
Sundarrajan, and additional functionality was added by Pasi
Sarolahti. The validation test is at `test-all-quickstart' end-to-end path. Second, unlike ECN, which
uses an allocated field in the
`tcl/test' directory in NS. The initial simulation studies from
[SH02] show a significant performance improvement using IP header, Quick-Start
for moderate-sized flows (between 4KB and 128KB) in under-utilized
environments. These studies are requires the
extra complications of an IP Option.

However, in spite of file transfers, with the
improvement measured as these issues, there is some hope for the relative increase
deployment of Quick-Start, at least in protected corners of the overall
throughput for
Internet, because the file transfer. The study shows that potential
improvement from benefits of Quick-Start is proportional to the delay-bandwidth
product user
are considerably more dramatic than those of ECN. Rather than
simply replacing the path.

The occasional dropped packet by an ECN-marked
packet, Quick-Start simulations in [SAF05] explore the following: is capable of dramatically increasing the
potential benefit
throughput of connections in underutilized environments.

11. Related Work

The Quick-Start proposal, taken together with HighSpeed TCP
[RFC3649] or other transport protocols for high-bandwidth transfers,
could go a significant way towards extending the connection; the relative
benefits range of different router-based algorithms
performance for approving Quick-
Start requests; and best-effort traffic in the Internet. However, there
are many things that the effectiveness of Quick-Start as proposal would not accomplish.
Quick-Start is not a function congestion control mechanism, and would not
help in making more precise use of the senders' algorithms for choosing the size available bandwidth, that is,
of achieving the rate
request.

10. Implementation and Deployment Issues

This section discusses some goal of the implementation issues high throughput with Quick-
Start. This section also discusses some of low delay and low
packet loss rates. Quick-Start would not give routers more control
over the key deployment
issues, such as decrease rates of active connections.

In addition, any evaluation of Quick-Start must include a discussion
of the chicken-and-egg deployment problems relative benefits of
mechanisms approaches that have to be deployed in both routers and end nodes in
order to work, use no explicit
information from routers, and the problems posed by the wide deployment of
middleboxes today approaches that block the use more fine-
grained feedback from routers as part of known or unknown IP Options.

10.1. Implementation Issues for Sending Quick-Start Requests

Section 4.6 discusses some a larger congestion control
mechanism. We discuss several classes of the issues with deciding the initial
sending rate to request. Quick-Start raises additional issues proposals (no explicit
feedback from routers; explicit feedback about the communication between the transport protocol and the
application, initial rate;
more fine-grained feedback from routers; and about the use of the past history with Quick-Start proposals based on
lower-than-best-effort service) in the end node. sections below.

11.1. Fast Start-ups without Explicit Information from Routers

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 senders to use information from the
transmission rate, but they might know
packet streams to learn about the amount of data available bandwidth, without
explicit information from routers. These techniques would not allow
a start-up as fast as that can
be sent immediately. Based on this, the sender implementation could
decide whether available from Quick-Start would be useful, and what rate should be
requested. Datagram-based real-time streaming applications, on the
other hand, may in an
underutilized environment; one has to have a specific preference on the transmission rate
and they could indicate the required rate explicitly sent some packets
already to use the
transport protocol packet stream to be used in learn about available bandwidth.
However, these techniques could allow a start-up considerably faster
than the Quick-Start Request.

We note current slow-start. While it seems clear that when Quick-Start is used, approaches
*without* explicit feedback from the TCP sender routers will be strictly less
powerful that is required to
implement an additional timer for possible *with* explicit feedback, it is also
possible that approaches that are more aggressive than slow-start
are possible without explicit feedback from routers.

Periodic packet streams:
[JD02] explores the paced transmission use of Quick-
Start packets.

10.2. Implementation Issues for Processing Quick-Start Requests

A router or other network host must be able periodic packet streams to determine estimate the
approximate
available bandwidth along a path. The idea is that the one-way
delays of its outbound network interfaces in order to
process incoming Quick-Start a periodic packet stream show an increasing trend when the
stream's rate requests, including those that
originate from is higher than the host itself. One possibility would be for hosts
to rely on configuration information to determine link bandwidths;
this has available bandwidth. While [JD02]
states that the drawback of proposed mechanism does not being robust to errors cause significant
increases in
configuration. Another possibility would be for network device
drivers utilization, losses, or delays when done by one
flow at a time, the approach could be problematic if conducted
concurrently by a number of flows. [JD02] also gives an overview of
some of the earlier work on inferring the available bandwidth from
packet trains.

Swift-Start:
The Swift Start proposal from [PRAKS02] combines packet-pair and
packet-pacing techniques. An initial congestion window of four
segments is used to infer estimate the available bandwidth for along the interface and to communicate
this path.
This estimate is then used to dramatically increase the IP layer.

Particular issues will arise for wireless links with variable
bandwidth, where decisions will have to be made about how frequently congestion
window during the network host gets updates second RTT of data transmission.

SPAND:
In the changing bandwidth. It seems
appropriate that Quick-Start Requests would be handled particularly
conservatively TCP/SPAND proposal from [ZQK00] 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 speeding up being dropped.

10.3. Possible Deployment Scenarios

Because of possible problems discussed above concerning using Quick-
Start over some short data
transfers, 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 performance information would likely be in
organizations that provide network services shared among
many co-located hosts to their users and also
have control over a large portion estimate each connection's fair share 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 resources. Based on such estimation and end-nodes, where the incentives for routers to deploy Quick-
Start might be transfer
size, the most clear.

* Centrally-administrated organizational Intranets often have large
network capacity TCP sender would determine the optimal initial congestion
window size. The design for TCP/SPAND uses a performance gateway
that monitors all traffic entering and leaving an organization's
network.

While continued research on the networks are underutilized for most limits of the
time. Such Intranets might also include high-bandwidth ability of TCP and high-
delay paths
other transport protocols to remote sites. In such an environment, Quick-Start
would be learn of benefit to users, and there would be a clear incentive
for available bandwidth without
explicit feedback from the deployment router seems useful, we note that there
are several fundamental advantages of Quick-Start in explicit feedback from
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

(1) Explicit feedback is faster than implicit feedback:
One advantage of
Cellular Wide-Area Wireless Networks such as explicit feedback from the GPRS [BW97] and
their enhancements and next generations. For example, GPRS EDGE
(Enhanced Data for GSM Evolution) routers is expected that it
allows the transport sender to provide wireless
bandwidth reliably learn of up to 384 Kbps (roughly 32 1500-byte packets per
second) while the GPRS available bandwidth
in one round-trip times range typically from few
hundred milliseconds to over a time.

(2) Explicit feedback is more reliable than implicit feedback:
A second excluding any possible
queueing delays in advantage of explicit feedback from the network [GPAR02]. In addition, these networks
sometimes have variable additional delays due to resource allocation routers is that could be avoided by keeping the connection path constantly
utilized, starting from
available bandwidth along the path does not necessarily map to the
allowed sending rate for an individual flow. As an example, if the
TCP sender sends four packets back-to-back in the 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 window,
and the order of 250 ms while TCP receiver reports that the bandwidth data packets were received
with roughly the same spacing as they were transmitted, does this
mean that the flow can be measured infer an underutilized path? And how fast
can the flow send in
megabits per second [RFC2488]. Because of the considerable
bandwidth-delay product next round-trip time? Do the results
depend on the level of statistical multiplexing at the congested
link, TCP's slow-start is a major
performance limitation in and on the beginning number of flows attempting a faster start-up at the connection. A
same time?

11.2. Optimistic Sending without Explicit Information from Routers

Another possibility that has been suggested [S02] is for the sender
to start with 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 without explicit permission
from the slow path,
how much stress would it add to routers and without bandwidth estimation techniques, and
for there to be many more
packets on the slow path, because first packet of the number of packets using
QuickStart? These are both questions initial window to be explored while
experimenting with Quick-Start in contain information
such as the Internet.

10.5. A Comparison with size or sending rate of the initial window. The
proposal would be that congested routers would use this information
in the Deployment Problems first data packet to drop or delay many or all of ECN

Given the glacially slow rate of deployment of ECN packets
from that initial window. In this way a flow's optimistically-large
initial window would not force the router to drop packets from
competing flows in the Internet network. Such an approach would seem to date [MAF05], it is disconcerting
require some mechanism for the sender to note ensure that some of the
deployment problems of Quick-Start are even greater than those routers
along the path understood the mechanism for marking the first packet
of
ECN. First, unlike ECN, which can a large initial window.

Obviously there would be a number of benefit even if it is only
deployed on one questions to consider about an
approach of optimistic sending.

(1) Incremental deployment:
One question would be the routers along the end-to-end path, a
connection's use potential complications of Quick-Start requires its deployment on all incremental
deployment, where some of the routers along the end-to-end path. Second, unlike ECN, which
uses an allocated field in path might not
understand the IP header, Quick-Start requires packet information describing the
extra complications of an IP Option.

However, in spite initial window.

(2) Congestion collapse:
There could also be concerns about congestion collapse if many flows
used large initial windows, many packets were dropped from
optimistic initial windows, and many congested links ended up
carrying packets that are only going to be dropped downstream.

(3) Distributed Denial of these issues, there is some hope for Service attacks:

A third key question would be the
deployment potential role of Quick-Start, at least optimistic
senders in protected corners of the
Internet, because amplifying the potential benefits damage done by a Distributed Denial of Quick-Start
Service (DDoS) attack.

(4) Performance hits if a packet is dropped:
A fourth issue would be to quantify the user
are considerably more dramatic than those of ECN. Rather than
simply replacing performance hit to the occasional dropped
connection when a packet by an ECN-marked
packet, Quick-Start is capable dropped from one of dramatically increasing the
throughput of connections in underutilized environments.

11. Related Work

The Quick-Start proposal, taken together initial windows.

11.3. Fast Start-ups with HighSpeed TCP [F03] or other Information from Routers

There have been several proposals somewhat similar to Quick-Start,
where the transport protocols for high-bandwidth transfers,, could go a
significant way towards extending protocol collects explicit information from the range of performance for best-
effort traffic in
routers along the Internet. However, there are many things that path.

An IP Option about the free buffer size:
In related work, [P00] investigates 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 a slightly different
IP option for TCP connections to discover the available bandwidth, bandwidth
along the path. In that is, of achieving proposal, the
goal of high throughput with low delay and low packet loss rates.
Quick-Start IP option would not give query the
routers more control over along the decrease
rates of active connections. % One of path about the open questions addressed
later in this % document is whether smallest available free buffer
size. Also, the % limited capabilities of
Quick-Start are sufficient to warrant % standardization and
deployment, or whether more work is % needed first to explore IP option would have been sent after the initial SYN
exchange, when the
space of potential mechanisms.

In addition, any evaluation of Quick-Start must include a discussion TCP sender already had an estimate of the relative benefits of approaches round-
trip time.

The Performance Transparency Protocol:
The Performance Transparency Protocol (PTP) includes a proposal for
a single PTP packet that use no explicit would collect 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
along the initial rate; and
more fine-grained feedback path from routers) in the sections below.

11.1. Fast Start-ups without Explicit Information from Routers

One possibility would be for senders sender to use information from the receiver [W00]. For example,
a single PTP packet streams could be used to learn about determine the available bandwidth, without bottleneck
bandwidth along a path.

ETEN:
Additional proposals for end nodes to collect explicit information
from routers. These techniques would not allow routers include Explicit Transport Error Notification (ETEN),
which includes a start-up as fast as that available from Quick-Start in an
underutilized environment; one has to have sent some packets
already cumulative mechanism to use notify endpoints of
aggregate congestion statistics along the packet stream to learn about available bandwidth.
However, these techniques could allow a start-up considerably faster
than path [KAPS02].

11.4. Fast Start-ups with more Fine-Grained Feedback from Routers

Proposals for more fine-grained congestion-related feedback from
routers include XCP [KHR02], MaxNet [MaxNet], and AntiECN marking
[K03]. Section A.6 discusses in more detail the current slow-start. While it seems clear that approaches
*without* explicit relationship
between Quick-Start and proposals for more fine-grained per-packet
feedback from routers.

XCP:
Proposals such as XCP for new congestion control mechanisms based on
more feedback from the routers will be strictly less are more powerful that is possible *with* explicit feedback, it is than Quick-Start, but
also
possible that approaches that are more aggressive complex to understand and more difficult to deploy.
XCP routers maintain no per-flow state, but provide more fine-
grained feedback to end-nodes than slow-start
are possible without explicit the one-bit congestion feedback
of ECN. The per-packet feedback from routers.

Periodic packet streams:
[JD02] explores XCP can be positive or
negative, and specifies the use of periodic packet streams to estimate increase or decrease in the
available bandwidth along a path. sender's
congestion window when this packet is acknowledged.

AntiECN:
The idea AntiECN proposal is for a single bit in the packet header that
routers could set to indicate that they are underutilized. For each
TCP ACK arriving at the one-way
delays of sender indicating that a periodic packet stream show an increasing trend when the
stream's rate is higher than has been
received with the available bandwidth. While [JD02]
states that Anti-ECN bit set, the proposed mechanism does not cause significant
increases in network utilization, losses, or delays when done sender would be able to
increase its congestion window by one
flow at packet, as it would during
slow-start.

11.5. Fast Start-ups with Lower-Than-Best-Effort Service

There have been proposals for routers to provide a time, the approach Lower Effort
differentiated service that would be lower than best effort
[RFC3662]. Such a service could carry traffic for which delivery is
strictly optional, or could carry traffic that is important but that
has low priority in terms of time. Because it does not interfere
with best-effort traffic, Lower Effort services would be problematic if conducted
concurrently used by
transport protocols that start-up faster than slow-start. For
example, [SGF05] is a number proposal for the transport sender to use low-
priority traffic for much of flows. [JD02] also gives an overview the initial traffic, with routers
configured to use strict priority queueing.

A separate but related issue is that of
some below-best-effort TCP,
variants of the earlier work TCP that would not rely on inferring Lower Effort services in the available bandwidth from
packet trains.

Swift-Start:
The Swift Start proposal from [PRAKS02] combines packet-pair
network, but would approximate below-best-effort traffic by
detecting and
packet-pacing techniques. An initial congestion window of four
segments is used to estimate the available bandwidth along the path.
This estimate is then used responding to dramatically increase the congestion
window during the second RTT of data transmission.

While continued research on sooner that standard TCP.
TCP Nice [V02] and TCP Low Priority (TCP-LP) [KK03] are two such
proposals for below-best-effort TCP, with the limits purpose of allowing
TCP connections to use the ability of bandwidth unused by TCP and other transport protocols to learn of available bandwidth without
explicit feedback from traffic
in a non-intrusive fashion. Both TCP Nice and TCP Low Priority use
the router seems useful, we default slow-start mechanisms of TCP.

We note that there
are several fundamental advantages of explicit feedback from
routers.

(1) Explicit feedback Quick-Start is faster than implicit feedback:
One advantage of explicit feedback quite different from the routers is that it
allows the transport sender to reliably learn of available bandwidth
in one round-trip time.

(2) Explicit feedback is more reliable than implicit feedback:
A second advantage either a Lower
Effort service or a below-best-effort variant of explicit feedback from the routers TCP. Unlike these
proposals, Quick-Start is intended to be useful for best-effort
traffic that the
available wishes to receive at least as much bandwidth along as
competing best-effort connections.

12. Security Considerations

Sections 9.4 and 9.6 discuss the path does not necessarily map security considerations related to
Quick-Start. Section 9.4 discusses the
allowed sending rate for an individual flow. As an example, if potential abuse of Quick-
Start by senders or receivers lying about whether the
TCP sender sends four packets back-to-back in request was
approved or about the initial window, approved rate, and the TCP receiver reports that the data packets were received of routers in collusion to
misuse Quick-Start. Section 9.5 discusses potential problems with roughly the same spacing as they were transmitted, does this
mean
traffic normalizers that the flow can infer an underutilized path? And how fast
can the flow send rewrite IP TTLs in the next round-trip time? Do the results
depend on the level packet headers. All of statistical multiplexing
these problems could result in the sender using a Rate Request that
was inappropriately large, or thinking that a request was approved
when it was in fact denied by at least one router along the congested
link, path.
This inappropriate use of Quick-Start would result in congestion and on
an unacceptable level of packet drops along the number path, Such
congestion could also be part of flows attempting a faster start-up at the
same time?

11.2. Optimistic Sending without Explicit Information from Routers

Another possibility that has been suggested [S02] is for the sender
to start with Denial of Service attack.

Section 9.6 discusses a large initial window without explicit permission potential attack on the routers' processing
and state load from an attack of Quick-Start Requests. Section 9.6
also discusses a potential attack on the routers and without available Quick-Start
bandwidth estimation techniques, and by sending bogus Quick-Start requests for bandwidth that
will not in fact be used.

Section 4.6.2 discusses the first packet potential problem of packets with Quick-
Start Requests dropped by middleboxes along the initial window to contain information
such as the size or sending rate of path.

As discussed in Section 5, for IPv4 IPsec Authentication Header
Integrity Check Value (AH ICV) calculation, the initial window. The
proposal would Quick-Start option
MUST be that congested routers would use treated as a mutable IPv4 option, and hence completely
zeroed for AH ICV calculation purposes; this information
in is also the first data packet treatment
required by RFC 2402 for unrecognized IPv4 options. The IPv6 Quick-
Start option's IANA-allocated option type indicates that it is a
mutable option, hence, according to drop or delay many or all RFC 2402, its option data MUST
be zeroed for AH ICV computation purposes. See RFC 2402 for further
explanation.

Section 6.2 discusses possible problems of the packets
from Quick-Start used by
connections carried over simple tunnels that initial window. are not compatible with
Quick-Start. In this way case it is possible that a flow's optimistically-large
initial window would not force the router to drop packets from
competing flows in the network. Such an approach would seem to
require some mechanism for Quick-Start
Request is erroneously considered approved by the sender to ensure that without the
routers
along in the path understood tunnel having individually approved the mechanism for marking request,
causing a false positive.

13. Conclusions

We are presenting the first packet
of 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 window.

Obviously
rates, or large initial congestion windows, in overprovisioned,
high-bandwidth environments. We expect there would will be a an increasing
number of questions to consider about an
approach overprovisioned, high-bandwidth environments where the
Quick-Start mechanism, or another mechanism of optimistic sending.

(1) Incremental deployment:
One question would similar power, could
be the potential complications of incremental
deployment, where some significant benefit to a wide range of traffic. We are
presenting the routers along Quick-Start mechanism as a request for the path might not
understand community
to provide feedback and experimentation on issues relating to Quick-
Start.

14. Acknowledgements

The authors wish to thank Mark Handley for discussions of these
issues. The authors also thank the packet information describing End-to-End Research Group, the
Transport Services Working Group, and members of IPAM's program on
Large Scale Communication Networks for both positive and negative
feedback on this proposal. We thank Srikanth Sundarrajan for the
initial window.

(2) Congestion collapse:
There could also be concerns about congestion collapse if many flows
used large initial windows, many packets were dropped from
optimistic initial windows, implementation of Quick-Start in the NS simulator, and many congested links ended up
carrying packets that are only going for
the initial simulation study. Many thanks to be dropped downstream.

(3) Distributed Denial of Service attacks:
A third key question would be David Black and Joe
Touch for extensive feedback on QuickStart and IP tunnels. We also
thank Mohammed Ashraf, John Border, Bob Briscoe, Martin Duke, Tom
Dunigan, Gorry Fairhurst, John Heidemann, Paul Hyder, Dina Katabi
and Vern Paxson for feedback. This draft builds upon the potential role concepts
described in [RFC3390], [AHO98], [RFC2415], and [RFC3168]. Some of optimistic
senders
the text on Quick-Start in amplifying tunnels was borrowed directly from RFC
3168.

This document is the damage done by a Distributed Denial development of
Service (DDoS) attack.

(4) Performance hits if a packet is dropped:
A fourth issue would be to quantify proposal originally by Amit
Jain for Initial Window Discovery.

A. Design Decisions

A.1. Alternate Mechanisms for the performance hit to Quick-Start Request: ICMP and RSVP

This document has proposed using an IP Option for the
connection when a packet is dropped Quick-Start
Request from one of the initial windows.

11.3. Fast Start-ups with other Information from Routers

There have been several proposals somewhat similar sender to Quick-Start,
where the receiver, and using transport protocol collects explicit information from
mechanisms for the
routers along Quick-Start Response from the path.

An IP Option about receiver back to
the free buffer size: sender. In related work, [P00] investigates this section we discuss alternate mechanisms, and
consider whether ICMP [RFC792, RFC2463] or RSVP [RFC2205] protocols
could be used for delivering the use of Quick-Start Request.

A.1.1. ICMP

Being a slightly different
IP option control protocol used between Internet nodes, one could
argue that ICMP is the ideal method for TCP connections to discover requesting a permission for
faster startup from routers. The ICMP header is above the available bandwidth
along IP
header. Quick-Start could be accomplished with ICMP as follows: If
the path. In that proposal, ICMP protocol is used to implement Quick-Start, the equivalent
of the Quick-Start IP option would query be carried in the ICMP header of
the ICMP Quick-Start Request. The ICMP Quick-Start Request would
have to pass by the routers along on the path about to the smallest available free buffer
size. Also, receiver, possibly
using the IP Router Alert option would have been sent after the initial SYN
exchange, when the TCP sender already had an estimate of the round-
trip time.

The Performance Transparency Protocol:
The Performance Transparency Protocol (PTP) includes a proposal for
a single PTP packet [RFC2113]. A router that approves
the Quick-Start Request would collect information from routers
along take the path from same actions as in the sender to case
with the Quick-Start IP Option, and forward the receiver [W00]. For example,
a single PTP packet could be used to determine the bottleneck
bandwidth next
router along a the path.

ETEN:
Additional proposals for end nodes to collect explicit information
from routers include Explicit Transport Error Notification (ETEN),
which includes a cumulative mechanism to notify endpoints of
aggregate congestion statistics along A router that does not approve the path [KAPS02].

11.4. Fast Start-ups Quick-
Start Request, even with more Fine-Grained Feedback from Routers

Proposals a decreased value for more fine-grained congestion-related feedback from
routers include XCP [KHR02], MaxNet [MaxNet], and AntiECN marking
[K03]. Section A.6 discusses in more detail the relationship
between Requested Rate,
would delete the ICMP Quick-Start Request, and proposals for more fine-grained per-packet
feedback from routers.

XCP:
Proposals such as XCP for new congestion control mechanisms based on
more feedback from routers are more powerful than Quick-Start, but
also are more complex to understand and more difficult to deploy.
XCP routers maintain no per-flow state, but provide more fine-
grained feedback send an ICMP Reply to end-nodes than
the one-bit congestion feedback sender that the request was not approved. If the ICMP Reply was
dropped in the network, and did not reach the receiver, the sender
would still know that the request was not approved from the absence
of ECN. The per-packet feedback from XCP can be positive or
negative, and specifies the increase or decrease in receiver. If the sender's
congestion window when this packet is acknowledged.

AntiECN:
The AntiECN proposal is for a single bit ICMP Quick-Start request was
dropped in the packet header that
routers could set network due to indicate that they are underutilized. For each
TCP ACK arriving at congestion, the sender indicating would assume
that a packet has been
received with the Anti-ECN bit set, the sender would be able to
increase its congestion window by one packet, as it request was not approved. The ICMP message would during
slow-start.

12. Security Considerations

Sections 9.4 need the
source and 9.5 discuss destination port numbers for demultiplexing at the security considerations related end
nodes. If the ICMP Quick-Start Request reached the receiver, the
receiver would use transport-level or application-level mechanisms
to send a response to
Quick-Start. Section 9.4 discusses the potential abuse sender, exactly as with the IP Option.

One benefit of Quick-
Start using ICMP would be that the delivery of receivers lying about whether the request was approved TCP SYN
packet or
about other initial packet would not be delayed by IP option
processing at routers. A greater advantage is that if middleboxes
were blocking packets with Quick-Start Requests, using the approved rate; of routers Quick-
Start Request in collusion a separate ICMP packet would mean that the
middlebox behavior would not affect the connection as a whole. (To
get this robustness to misuse Quick-
Start; and of potential problems middleboxes with traffic normalizers that
rewrite TCP using an IP TTLs in Quick-Start
Option, one would have to have a TCP-level Quick-Start Request
packet headers. All of these problems that could
result in be sent concurrently but separately from the sender using TCP
SYN packet.)

However, there are a Rate number of disadvantages to using ICMP. Some
firewalls and middleboxes may not forward the ICMP Quick-Start
Request that was inappropriately
large, or thinking that packets. (If an ICMP Reply packet from a request was approved when it was in fact
denied by at least one router along to the path. This inappropriate
use of Quick-Start would result
sender is dropped in congestion and an unacceptable
level of packet drops along the path, Such congestion could also network, the sender would still know that
the request was not approved, as stated earlier, so this would not
be
part as serious of a Denial of Service attack.

Section 9.5 discusses problem.) In addition, it would be difficult, if
not impossible, for a potential attack on router in the routers' processing
and state load from an attack middle of Quick-Start Requests. Section 9.5
also discusses a potential attack on an IP tunnel to
deliver an ICMP Reply packet to the available Quick-Start
bandwidth by sending bogus Quick-Start requests actual source, for bandwidth that
will not example when
the inner IP header is encrypted as in fact IPsec tunnel mode [RFC2401].
Again, however, the ICMP Reply packet would not be used.

Section 4.6.2 discusses essential to the
correct operation of ICMP Quick-Start.

Unauthenticated out-of-band ICMP messages could enable some types of
attacks by third-party malicious hosts that are not possible when
the potential problem of packets control information is carried in-band with Quick-
Start Requests dropped the IP packets that
can only be altered by middleboxes along the routers on the connection path.

As discussed Finally,
as a minor concern, using ICMP would cause a small amount of
additional traffic in Section 5, for IPv4 IPsec Authentication Header
Integrity Check Value (AH ICV) calculation, the Quick-Start Request
option MUST network, which is not the case when using
IP options.

A.1.2. RSVP

With some modifications RSVP [RFC2205] could be treated used as a mutable IPv4 option, and hence
completely zeroed bearer
protocol for AH ICV calculation purposes; this is also carrying 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 Requests. Because routers are
expected to RFC 2402,
its option data MUST be zeroed for AH ICV computation purposes. See
RFC 2402 for further explanation.

Section 6.2 discusses possible problems of process RSVP packets more extensively than the normal
transport protocol IP packets, delivering a Quick-Start used by
connections carried over simple tunnels that are not compatible rate request
using an RSVP packet would seem an appealing choice. However, Quick-
Start with
Quick-Start. In this case it is possible that RSVP would require a few differences from the
conventional usage of RSVP. Quick-Start
Request is erroneously considered approved by would not require periodical
refreshing of soft state, because Quick-Start does not require per-
connection state in routers. Quick-Start Requests would be
transmitted downstream from the sender without to receiver in the RSVP Path
messages, which is different from the
routers in conventional RSVP model where
the tunnel having individually approved reservations originate from the request,
causing a false positive.

13. Conclusions

We are presenting receiver. Furthermore, the
Quick-Start mechanism as a simple,
understandable, and incrementally-deployable mechanism that Response would be
sufficient to allow some connections to start up with large initial
rates, sent using the transport-level or large initial congestion windows, in overprovisioned,
high-bandwidth environments. We expect there will be an increasing
number
application-level mechanisms instead of overprovisioned, high-bandwidth environments where using the RSVP Resv message.

If RSVP was used for carrying a Quick-Start mechanism, or another mechanism of similar power, could Request, a new "Quick-
Start Request" class object would be of significant benefit included in the RSVP Path
message that is sent from the sender to a wide range of traffic. We are
presenting receiver. The object would
contain the Quick-Start mechanism as a rate request for the community field in addition to provide feedback the common length and experimentation on issues relating to Quick-
Start.

14. Acknowledgements
type fields. The authors wish to thank Mark Handley for discussions Send_TTL field in the RSVP common header could be
used as the equivalent of these
issues. the QS TTL field. The authors also thank Quick-Start capable
routers along the End-to-End Research Group, path would inspect the
Transport Services Working Group, and members of IPAM's program on
Large Scale Communication Networks for both positive Quick-Start Request object
in the RSVP Path message, decrement Send_TTL and negative
feedback on this proposal. We thank Srikanth Sundarrajan for adjust the rate
request field if needed. If an RSVP router did not understand the
Quick-Start Request object, it would reject the entire RSVP message
and send an RSVP PathErr message back to the sender. When an RSVP
message with the
initial implementation of Quick-Start in Request object reaches the NS simulator, and for receiver,
the initial simulation study. Many thanks to David Black and Joe
Touch for extensive feedback on QuickStart and IP tunnels. We also
thank Mohammed Ashraf, John Border, Martin Duke, Tom Dunigan, Gorry
Fairhurst, John Heidemann, Paul Hyder, Dina Katabi and Vern Paxson,
for feedback. This draft builds upon receiver sends a Quick-Start Reply message in the concepts corresponding
transport protocol header in the same way as described in
[RFC3390], [AHO98], [RFC2415], and [RFC3168]. Some the
context of IP options earlier. If the text on
Quick-Start in tunnels RSVP message with the Quick-
Start Request object was borrowed directly from RFC 3168.

This is a modification dropped along the path, the transport
sender would simply proceed with the normal congestion control
procedures.

Much of a draft originally by Amit Jain for
Initial Window Discovery.

A. Design Decisions

A.1. Alternate Mechanisms for the Quick-Start Request: ICMP discussion about benefits and RSVP

This document has proposed drawbacks of using an IP Option ICMP
for making the Quick-Start Request from also applies to the sender RSVP case. If
the Quick-Start Request was transmitted in a separate packet instead
of as an IP option, the transport protocol packet delivery would not
be delayed due to IP option processing at the receiver, routers, and using the
initial transport
mechanisms for packets would reach their destination more
reliably. The possible disadvantages of using ICMP and RSVP are also
expected to be similar: middleboxes in the network may not be able
to forward the Quick-Start Response from Request messages, and the receiver back to IP tunnels
might cause problems for processing the sender. Quick-Start Requests.

A.2. Alternate Encoding Functions

In this section we discuss look at alternate mechanisms, and
consider whether ICMP [RFC792, RFC2463] or RSVP [RFC2205] protocols
could be used encoding functions for delivering the Rate
Request field in the Quick-Start Request.

A.1.1. ICMP

Being a control protocol used between Internet nodes, one could
argue that ICMP is the ideal method The main requirements for requesting
this function is that it should have a permission sufficiently wide range for
faster startup from routers. The ICMP header
the requested rate. There is above no need for overly-fine-grained
precision in the IP
header. Quick-Start could requested rate. Similarly, while it would be accomplished with ICMP as follows: If
attractive for the ICMP protocol encoding function to be easily computable, it is used
also possible for end-nodes and routers to implement Quick-Start, simply store the equivalent
of table
giving the Quick-Start IP option would be carried in mapping between the ICMP header of value N in the ICMP Quick-Start Request. The ICMP Quick-Start Rate Request would
have to pass by the routers on the path to field,
and the receiver; for now, actual rate request f(N). In this section we
don't address the mechanisms that consider
possible encoding methods for Rate Request fields of different
sizes, including four-bit, eight-bit, and larger Rate Request
fields.

Linear functions:
One possible proposal would be needed to accomplish this
task. A router that approves for the Quick-Start Rate Request would take the
same actions as field to be
formatted in bits per second, scaled so that one unit equals M Kbps,
for some fixed value of M. Thus, for the case with the Quick-Start IP Option, and
forward the packet to value N in the next router along Rate
Request field, the path. A router that
does not approve requested rate would be M*N Kbps.

Powers of two:
If a granularity of factors of two is sufficient for the Quick-Start Rate
Request, even then the encoding function with a decreased
value for the Requested Rate, most range would delete be for
the ICMP Quick-Start
Request, and send an ICMP Reply requested rate to be K*2^N, for N the sender that the request was
not approved. If the ICMP Reply was dropped value in the network, Rate Request
field, and did
not reach the receiver, the sender would still know that for K some constant. For N=0, the rate request
was not approved from the absence would be
set to zero, regardless of feedback from the receiver. If encoding function. For example, for
K=40,000 and an eight-bit Rate Request field, the ICMP Quick-Start request was dropped in the network due range
would be from 80 Kbps to
congestion, the sender 40*2^255 Kbps. This clearly would assume that the be an
unnecessarily large request was not
approved. If the ICMP Quick-Start range.

For a four-bit Rate Request reached field, the receiver, upper limit on the
receiver rate
request is 1.3 Gbps. It seems to us that an upper limit of 1.3 Gbps
would use transport-level mechanisms be fine for the Quick-Start rate request, and that connections
wishing to send start up with a response higher initial sending rate should be
encouraged to
the sender, exactly use other mechanisms, such as with the IP Option.

One benefit explicit reservation
of using ICMP would be that the delivery bandwidth. If an upper limit of the TCP SYN
packet or other initial packet would 1.3 Gbps was not acceptable,
then five or six bits could be delayed by IP option
processing at routers. A greater advantage is that if middleboxes
were blocking packets with Quick-Start Requests, using used for the Quick-
Start Rate Request in a separate ICMP packet would mean that field.

If the
middlebox behavior would not affect granularity of factors of two was too coarse, then the connection as
encoding function could use a whole. (To
get this robustness to middleboxes with TCP using an IP Quick-Start
Option, one base less than two. An alternate form
for the encoding function would have be to have a TCP-level Quick-Start Request
packet that was sent concurrently but separately from the TCP SYN
packet.)

However, there are use a number hybrid of disadvantages to using ICMP. Some
firewalls linear and middleboxes may not forward
exponential functions.

A mantissa and exponent representation:
Section 4.4 of [B05] suggests a mantissa and exponent representation
for the ICMP Quick-Start
Request packets. (If an ICMP Reply packet from a router to encoding function. With e and f as the
sender is dropped binary
numbers in the network, the sender would still know that
the request was not approved, as stated earlier, so exponent and mantissa fields, and with 0 <= f < 1,
this would not
be represent the rate (1+f)*2^e. [B05] suggests a problem.) In addition, it would be difficult, if not
impossible, mantissa
field for a router in the middle f of 8, 16, or 24 bits, with an IP tunnel to deliver an
ICMP Reply packet to the actual source, exponent field for example when the inner
IP header is encrypted as in IPsec tunnel mode [RFC2401]. Again,
however, the ICMP Reply packet e of 8
bits. This representation would not be essential to allow larger rate requests, with an
encoding that is less coarse than the correct
operation of ICMP Quick-Start.

Unauthenticated out-of-band ICMP messages could enable some types powers-of-two encoding used in
this document.

Constraints of
attacks by third-party malicious hosts the transport protocol:
We note that are not possible when the control information Rate Request is carried in-band with the IP packets that
can only be altered also constrained by the routers on the connection path. Finally,
as a minor concern, using ICMP would cause a small amount abilities
of
additional traffic in the network, which is not the case when using
IP options.

A.1.2. RSVP

With some modifications RSVP [RFC2205] could be used as a bearer
protocol transport protocol. For example, for carrying the Quick-Start Requests. Because routers are
expected to process RSVP packets more extensively than TCP with Window
Scaling, the normal
transport protocol IP packets, delivering maximum window is at most 2**30 bytes. For a Quick-Start rate request
using an RSVP packet would seem an appealing choice. However, Quick-
Start TCP
connection with RSVP a long, 1 second round-trip time, this would require give a few differences from the
conventional usage
maximum sending rate of RSVP. 1.07 Gbps.

A.3. The Quick-Start would not require periodical
refreshing Request: Packets or Bytes?

One of soft state, because Quick-Start does not require per-
connection state in routers. Quick-Start Requests would be
transmitted downstream from the sender to receiver in the RSVP Path
messages, which design questions is different from the conventional RSVP model where whether the reservations originate Rate Request field should
be in bytes per second or in packets per second. We discuss this
separately from the receiver. Furthermore, perspective of the
Quick-Start Response would be sent using transport, and from the transport-level
mechanisms instead
perspective of using the RSVP Resv message.

If RSVP was used for carrying a router.

For TCP, the results from the Quick-Start Request, Request are translated
into a new "Quick-
Start Request" class object would be included congestion window in bytes, using the RSVP Path
message that is sent from the sender to receiver. The object would
contain measured round-trip
time and the rate request field in addition MSS. This window applies only to the common length bytes of data
payload, and
type fields. The Send_TTL field does not include the bytes in the RSVP common header could be
used as TCP or IP packet
headers. Other transport protocols would conceivably use the equivalent of Quick-
Start Request directly in packets per second, or could translate the QS TTL field. The
Quick-Start capable
routers along Request to a congestion window in packets.

The assumption of this draft is that the path would inspect router only approves the
Quick-Start Request object
in when the RSVP Path message, decrement Send_TTL and adjust output link is significantly
underutilized. For this, the rate
request field if needed. If an RSVP router did not understand could measure the available
bandwidth in bytes per second, or could convert between packets and
bytes by some mechanism.

If the Quick-Start Request object, it would reject the entire RSVP message was in bytes per second, and send an RSVP PathErr message back applied only
to the sender. When an RSVP
message with data payload, then the Quick-Start router would have to convert from
bytes per second of data payload, to bytes per second of packets on
the wire. If the Rate Request object reaches field was in bytes per second and the receiver,
sender ended up using very small packets, this could translate to a
significantly larger number in terms of bytes per second on the receiver sends
wire. Therefore, for a Quick-Start Reply message Request in bytes per second, it
makes most sense for this to include the corresponding transport protocol header in the same way as described in the
context of and IP options earlier. If headers as
well as the RSVP message with data payload. Of course, this will be at best a rough
approximation on the Quick-
Start Request object was dropped along part of the path, sender; the transport transport-level sender would simply proceed with
might not know the normal congestion control
procedures.

Much size of the discussion about benefits transport and drawbacks of using ICMP
for making IP headers in bytes,
and might know nothing at all about the separate headers added in IP
tunnels downstream. This rough estimate seems sufficient, however,
given the overall lack of fine precision in Quick-Start Request also applies to
functionality.

It has been suggested that the RSVP case. If router could possibly use information
from the Quick-Start Request was transmitted MSS option in a separate the TCP packet instead header of as an IP option, the transport protocol SYN packet delivery would not
be delayed due to IP option processing at the routers, and
convert the
initial transport Quick-Start Request from packets would reach their destination more
reliably. per second to bytes per
second, or vice versa. The possible disadvantages of using ICMP and RSVP are MSS option is defined as the maximum MSS
that the TCP sender expects to receive, not the maximum MSS that the
TCP sender plans to send [RFC793]. However, it is probably often
the case that this MSS also
expected to be similar: middleboxes applies as an upper bound on the MSS
used by the TCP sender in sending.

We note that the network may sender does not be able
to forward necessarily know the Path MTU when
the Quick-Start Request messages, and is sent, or when the IP tunnels
might cause problems for processing initial window of data
is sent. Thus, with IPv4, packets from the Quick-Start Requests.

A.2. Alternate Encoding Functions

In this section we look at alternate encoding functions for initial window could end
up being fragmented in the network if the "Don't Fragment" (DF) bit
is not set [RFC1191]. A Rate Request field in the Quick-Start Request. The main requirements for
this function bytes per second is that it should have
reasonably robust to fragmentation. Clearly a sufficiently wide range for
the requested rate. There Rate Request in
packets per second is no need for overly-fine-grained
precision less robust in the requested rate. Similarly, while it would be
attractive for the encoding function to be easily computable, it is
also possible for end-nodes presence of fragmentation.
Interactions between larger initial windows and routers to simply store Path MTU Discovery
are discussed in more detail in RFC 3390 [RFC3390].

For a Quick-Start Request in bytes per second, the table
giving transport senders
would have the mapping between additional complication of estimating the value N bandwidth
usage added by the packet headers.

We have chosen a Rate Request field in bytes per second rather than
in packets per second because it seems somewhat more robust,
particularly to routers.

A.4. Quick-Start Semantics: Total Rate or Additional Rate?

For a Quick-Start Request sent in the Rate Request field,
and middle of a connection, there
are two possible semantics for the actual rate request f(N). In this section we consider both
four-bit and eight-bit Rate Request fields.

Linear functions: field, as follows:

(1) Total Rate: The Quick-Start requested Rate Request contains an 8-bit field is the requested total
rate for the connection, including the current rate; or

(2) Additional Rate: The requested Rate
Request. One possible proposal would be for this field to be
formatted Request is the requested
increase in bits per second, scaled so that one unit equals 80
Kbps. Thus, the total rate for that connection, over and above the value N in
current sending rate.

When the Rate Quick-Start Request field, is sent after an idle period, the
requested
current sending rate is 80,000*N bps. This gives a request range between
80 Kbps zero, and 20.48 Mbps. For 1500-byte packets, this corresponds to
a request range there is no difference between 6 (1)
and 1706 packets per second.

Powers of two:
If (2) above. However, a granularity of factors of two is sufficient for the Rate
Request, then the encoding function with the most range would Quick-Start Request can also be for sent in
the requested rate middle of a connection that has not been idle, e.g., after a
mobility event, or after an application-limited period when the
sender is suddenly ready to send at a much higher rate. In this
case, there can be K*2^N, for N the value in the Rate Request
field, a significant difference between (1) and for K some constant. For N=0, (2)
above. In this section we consider briefly the rate request would be
set to zero, regardless of tradeoffs between
these two options, and explain why we have chosen the encoding function. For example, `Total Rate'
semantics.

The Total Rate semantics makes it easier for
K=40,000, routers to ``allocate''
the request range would be from 80 Kbps same rate to 40*2^256 Kbps. all connections. This clearly would be an unnecessarily large request range.

For a four-bit lends itself to fairness,
and improves convergence times between old and new connections.
With the Additional Rate Request field, semantics, the upper limit on router would not necessarily
know the rate
request is 1.3 Gbps. It is possible that an upper limit current sending rates of 1.3 Gbps
would be fine for the Quick-Start rate request, flows requesting additional
rates, and that connections
wishing to start up with a higher initial sending rate should be
encouraged therefore would not have sufficient information to use other mechanisms, such
fairness as a metric in granting rate requests. With the explicit reservation
of bandwidth. If an upper limit of 1.3 Gbps is not acceptable, then
five bits could be used for the Total Rate Request field.

If
semantics, the granularity of factors of two fairness is too coarse, then automatic; the
encoding function could use a base less than two. An alternate form router is not granting
rate requests for *additional* bandwidth without knowing the encoding function would be to use a hybrid current
sending rates of linear and
exponential functions.

We note that the different flows.

The Additional Rate Request semantics also has lends itself to be constrained gaming by the
abilities
connection, with senders sending frequent Quick-Start Requests in
the hope of gaining a higher rate. If the transport protocol. For example, for TCP with
Window Scaling, router is granting the
same maximum window rate for all rate requests, then there is at most 2**30 bytes. For little
benefit to a
TCP connection with a long, 1 second round-trip time, this would
give a maximum of sending a rate of 1.07 Gbps.

A.3. The Quick-Start Request: Packets or Bytes?

One of request over and over
again. However, if the design questions router is whether granting an *additional* rate with
each rate request, over and above the Rate Request field should
be current sending rate, then it
is in bytes per second or a connection's interest to send as many rate requests as
possible, even if very few of them are in packets per second. We will discuss fact granted.

Appendix D discusses a Report of Current Sending Rate as one
possible function in the Quick-Start Option. However, we have not
standardized this separately from possible use at this time.

A.5. Alternate Responses to the perspective Loss of a Quick-Start Packet

Section 4.5 discusses TCP's response to the transport, and from the
perspective loss of a Quick-Start
packet in the router.

For TCP, initial window. This section discusses several
alternate responses.

One possible alternative to reverting to the results from default slow-start
after the Quick-Start Request are translated
into loss of a congestion window in bytes, using the measured round-trip
time and Quick-Start packet from the MSS. This initial window applies only would
have been to halve the bytes of data
payload, congestion window and does not include the bytes continue in congestion
avoidance. However, we note that this would not have been a
desirable response for either the TCP connection or IP for the network as a
whole. The packet
headers. Other transport protocols would conceivably use loss in the initial window indicates that Quick-
Start Request directly failed in packets per second, or could translate finding an appropriate congestion window, meaning
that the
Quick-Start Request to a congestion window after halving may easily also be wrong.

A more moderate alternate would be to continue in packets.

The assumption congestion
avoidance from a window of this draft (W-D)/2, where W is that the router only approves the Quick-Start Request when the output link
congestion window, and D is significantly
underutilized. For this, the router could measure number of packets dropped or marked
from that window. However, such an approach would implicitly assume
that the number of Quick-Start packets delivered is a good
indication of the appropriate available bandwidth in bytes per second, or could convert between for that flow,
even though other packets and
bytes by some mechanism.

If the Quick-Start Request was from that window were dropped in bytes per second, and applied only
to the data payload, then the router
network. We believe that such an assumption would have to convert from
bytes per second of data payload, to bytes per second require more
analysis at this point, particularly in a network with a range of packets on
the wire. If
packet dropping mechanisms at the Rate Request field was in bytes per second router, and the
sender ended up using very small packets, we cannot recommend it
at this could translate time.

Another drawback of approaches that don't revert back to slow-start
when a
significantly larger number Quick-Start packet in terms of bytes per second on the
wire. Therefore, for initial window is dropped is that
any such approaches could give the TCP receiver an incentive to lie
about the Quick-Start request. That is, if the sender reverts to
slow-start when a Quick-Start Request in bytes per second, packet is dropped, then it
makes most sense for this is
generally not to include the transport and IP headers as
well as receiver's advantage to report a larger rate
request than was actually approved if the data payload. Of course, this will result is going to be at best a rough
approximation on
Quick-Start packet dropped in the part of network. However, if the sender; receiver
benefits from a larger Quick-Start window even when the transport-level sender
might not know larger
window results in Quick-Start packets dropped in the size of network, then
the transport and IP headers in bytes,
and might know nothing at all receiver has a greater incentive to lie about the separate headers added received rate
request, in IP
tunnels downstream. This rough estimate seems sufficient, however,
given an effort to get the overall lack of fine precision in sender to use a larger initial
sending rate.

A.6. Why Not Include More Functionality?

This proposal for Quick-Start
functionality.

It has been suggested is a rather coarse-grained mechanism
that the router could possibly would allow connections to use information
from the MSS option in the TCP packet header of the SYN packet higher sending rates along
underutilized paths, but that does not attempt to
convert provide a next-
generation transport protocol, and does not attempt the Quick-Start Request from packets per second to bytes per
second, or vice versa. The MSS option is defined goal of
providing very high throughput with very low delay. As Section 11.4
discusses, there are a number of proposals such as XCP, MaxNet, and
AntiECN for more fine-grained per-packet feedback from routers than
the maximum MSS current congestion control mechanisms, that the TCP sender expects do attempt these
more ambitious goals.

Compared to receive, proposals such as XCP and AntiECN, Quick-Start offers
much less control. Quick-Start does not the maximum MSS that the
TCP sender plans attempt to send [RFC793]. However, it is probably often
the case that this MSS also applies provide a new
congestion control mechanism, but simply to get permission from
routers for a higher sending rate at start-up, or after an idle
period. Quick-Start can be thought of as an upper bound on the MSS
used by the TCP sender in sending.

We note "anti-congestion-
control" mechanism, that the sender does not necessarily know the Path MTU is only of any use when all of the routers
along the path are significantly under-utilized. Thus, Quick-Start Request
is sent, or when the initial window of data
is sent. Thus, with IPv4, packets from the initial window could end
up being fragmented no use towards a target of high link utilization, or fairness
in a high-utilization scenario, or controlling queueing delay during
high-utilization, or anything of the network if like.

At the "Don't Fragment" (DF) bit
is not set [RFC1191]. A Rate Request in bytes per second is
reasonably robust same time, Quick-Start would allow larger initial windows
than would proposals such as AntiECN, requires less input to fragmentation. Clearly a Rate Request in
packets per second routers
than XCP (e.g., XCP's cwnd and rtt fields), and would require less
frequent feedback from routers than any new congestion control
mechanism. Thus, Quick-Start is significantly less robust powerful than
proposals for new congestion control mechanisms such as XCP and
AntiECN, but as powerful or more powerful in terms of the presence specific
issue of fragmentation.
Interactions between allowing larger initial windows windows, and Path MTU Discovery
are discussed in (we think) more detail in RFC 3390 [RFC3390].

For a Quick-Start Request
amenable to incremental deployment in bytes per second, the transport senders
would have the additional complication of estimating the bandwidth
usage added by the packet headers. current Internet.

We have chosen a Rate Request field in bytes per second rather than do not discuss proposals such as XCP in packets per second because it seems somewhat more robust,
particularly to routers.

A.4. Quick-Start Semantics: Total Rate or Additional Rate?

For detail, but simply note
that there are a Quick-Start Request sent in the middle number of a connection, open questions. One question concerns
whether there
are two possible semantics for the Rate Request field, as follows:

(1) Total Rate: The requested Rate Request is the requested total
rate a pressing need for the connection, including the current rate; or

(2) Additional Rate: The requested Rate Request is the requested
increase more sophisticated congestion
control mechanisms such as XCP in the total rate for that connection, over and above the
current sending rate.

When the Internet. Quick-Start Request is sent after an idle period, the
current sending rate is zero,
inherently a rather crude tool that does not deliver assurances
about maintaining high link utilization and there low queueing delay;
Quick-Start is no difference between (1) designed for use in environments that are
significantly underutilized, and (2) above. However, addresses the single question of
whether a Quick-Start Request can also be sent higher sending rate is allowed. New congestion control
mechanisms with more fine-grained feedback from routers could allow
faster startups even in environments with rather high link
utilization. Is this a pressing requirement? Are the middle other
benefits of more fine-grained congestion control feedback from
routers a connection pressing requirement?

We would argue that has not been idle, e.g., after even if more fine-grained per-packet feedback
from routers was implemented, it is reasonable to have a
mobility event, separate
mechanism such as Quick-Start for indicating an allowed initial
sending rate, or an allowed total sending rate after an application-limited period when the
sender is suddenly ready to send at a much higher rate. In this
case, there can be a significant idle or
underutilized period.

One difference between (1) and (2)
above. In this section we consider briefly the tradeoffs between
these two options, Quick-Start and explain why we have chosen the `Total Rate'
semantics.

The Total Rate semantics makes it easier current proposals for routers to ``allocate''
the same rate to all connections. This lends itself fine-
grained per-packet feedback such as XCP is that XCP is designed to fairness,
and improves convergence times between old and new connections.
With the Additional Rate semantics, the router would not necessarily
know the current sending rates of
give robust performance even in the flows requesting additional
rates, and therefore would not have sufficient information to use
fairness as case where different packets
within a metric connection routinely follow different paths. XCP achieves
relatively robust performance in granting rate requests. With the Total Rate
semantics, presence of multi-path routing
by using per-packet feedback, where the fairness feedback carried in a single
packet is automatic; about the router relative increase or decrease in the rate or
window to take effect when that particular packet is acknowledged,
not granting about the allowed sending rate requests for *additional* bandwidth without knowing the current
sending rates of connection as a whole.

In contrast, Quick-Start sends a single Quick-Start request, and the different flows.

The Additional Rate semantics also lends itself
answer to gaming by that request gives the
connection, with senders allowed sending frequent rate for an entire
window of data. As a result, Quick-Start Requests could be problematic in
the hope an
environment where some fraction of gaining the packets in a higher rate. If window of data
take path A, and the router is granting rest of the
same maximum rate packets take path B; for all rate requests, then there is little
benefit to a connection example,
the Quick-Start Request could have travelled on path A, while half
of sending a rate request over and over
again. However, if the router is granting an *additional* rate with
each rate request, over Quick-Start packets sent in the succeeding round-trip time
are routed on path B.

There are also differences between Quick-Start and above some of the current sending rate, then it
is
proposals for per-packet feedback in a connection's interest terms of the number of bits of
feedback required from the routers to send as many rate requests as
possible, even if very few the end-nodes. Quick-Start
uses four bits of them are feedback in fact granted.

For either of these alternatives, the rate request field to indicate the
allowed sending rate. XCP allocates a byte for per-packet feedback,
though there has been discussion of variants of XCP with less per-
packet feedback. This would not be room more like other proposals such as
anti-ECN that use a single bit of feedback from routers to report indicate
that the current sending rate sender can increase as fast as slow-starting, in the Quick-Start Option using the current
minimal format for the Quick-Start Request. Thus, either the Quick-
Start Option would have to take more than four bytes response
to include a
report this particular packet acknowledgement. In general, there is
probably considerable power in fine-grained proposals with only two
bits of feedback, indicating that the current sending rate, sender should decrease,
maintain, or increase the current sending rate
would not be reported to the routers.

A.5. Alternate Responses to or window when this packet is
acknowledged. However, the Loss power of a Quick-Start Packet

Section 4.5 discusses TCP's response would be
considerably limited if it was restricted to the loss only two bits of a Quick-Start
packet in
feedback; it seems likely that determining the initial window. This section discusses several
alternate responses.

One possible alternative to reverting to the default slow-start
after the loss sending rate
fundamentally requires more bits of a Quick-Start packet feedback from routers than does
the initial window would
have been steady-state, per-packet feedback to halve increase or decrease the congestion window
sending rate.

On a more practical level, one difference between Quick-Start and continue in congestion
avoidance. However, we note
proposals for per-packet feedback is that this there are fewer open
issues with Quick-Start than there would not have been be with a new congestion
control mechanism. Because Quick-Start is a mechanism for
requesting an initial sending rate in an underutilized environment,
its fairness issues are less severe than those of a
desirable response general
congestion control mechanism. With Quick-Start, there is no need
for either the connection or for end nodes to tell the network as a
whole. The packet loss in routers the initial window indicates that Quick-
Start failed in finding an appropriate round-trip time and
congestion window, meaning as is done in XCP; all that is needed is for the congestion window after halving may easily also be wrong.

A more moderate alternate would be
end nodes to continue in congestion
avoidance from report the requested sending rate.

Table 3 provides a window summary of (W-D)/2, where W is the differences between Quick-Start
congestion window,
and D is the number of packets dropped proposals for per-packet congestion control feedback.

Proposals for
Quick-Start Per-Packet Feedback
+------------------+----------------------+----------------------+
Semantics: | Allowed sending rate | Change in rate/window,
| per connection. | per-packet.
+------------------+----------------------+----------------------+
Relationship to | In addition. | Replacement.
congestion ctrl: | |
+------------------+----------------------+----------------------+
Frequency: | Start-up, or marked
from that window. However, such after | Every packet.
| an approach would implicitly assume
that the number idle period. |
+------------------+----------------------+----------------------+
Limitations: | Only useful on | General congestion
| underutilized paths.| control mechanism.
+------------------+----------------------+----------------------+
Input to routers: | Rate request. |RTT, cwnd, request (XCP)
| | None (Anti-ECN).
+------------------+----------------------+----------------------+
Bits of feedback: | Four bits for | A few bits would
| rate request. | suffice?
+------------------+----------------------+----------------------+

Table 3: Differences between Quick-Start packets delivered is a good
indication of the appropriate available bandwidth and Proposals for that flow,
even though other packets from that window were dropped in the
network. We believe that
Fine-Grained Per-Packet Feedback.

A separate question concerns whether mechanisms such an assumption would require more
analysis at this point, particularly as Quick-Start,
in a network combination with HighSpeed TCP and other changes in progress,
would make a range significant contribution towards meeting some of these
needs for new congestion control mechanisms. This could be viewed
as a positive step towards meeting some of
packet dropping mechanisms at the router, more pressing current
needs with a simple and we cannot recommend it
at this time.

Another drawback reasonably deployable mechanism, or
alternately, as a negative step of approaches unnecessarily delaying more
fundamental changes. Without answering this question, we would note
that don't revert back our own approach tends to slow-start
when a Quick-Start packet in favor the initial window is dropped is that
any such approaches could give incremental deployment of
relatively simple mechanisms, as long as the TCP receiver an incentive to lie
about simple mechanisms are
not short-term hacks but mechanisms that lead the Quick-Start request. That is, if overall
architecture in the sender reverts to
slow-start when fundamentally correct direction.

A.7. Alternate Implementations for a Quick-Start packet is dropped, then it is
generally not to QuickStart Nonce

A.7.1. An Alternate Proposal for the receiver's advantage to report a larger rate
request than was actually approved if QuickStart Nonce

An alternate proposal for the result is going to be a Quick-Start packet dropped in Nonce from [B05] would be
for an n-bit field for the network. However, if QS Nonce, with the receiver
benefits from sender generating a larger Quick-Start window even
random nonce when the larger
window results in it generates a Quick-Start packets dropped in Request. Each router
that reduces the network, then Rate Request by r would hash the QS nonce r times,
using a one-way hash function such as MD5 [RFC1321] or the secure
hash 1 [SHA1]. The receiver has a greater incentive returns the QS nonce to lie about the received sender.
Because the sender knows the original value for the nonce, and the
original rate request, in an effort to get the sender knows the total number of steps s
that the rate has been reduced. The sender then hashes the original
nonce s times, to use a larger initial
sending rate.

A.6. Why Not Include More Functionality? check whether the result is the same as the nonce
returned by the receiver.

This alternate proposal for Quick-Start is a rather coarse-grained mechanism
that the nonce would allow connections to use higher sending rates along
underutilized paths, but that does not attempt to provide a next-
generation transport protocol, and does not attempt be considerably more
powerful than the goal of
providing very high throughput with very low delay. As QS nonce described in Section 11.4
discusses, there are a number of proposals such as XCP, MaxNet, and
AntiECN for 3.4, but it would
also require more fine-grained per-packet feedback CPU cycles from routers that the current congestion control mechanisms, that do attempt these
more ambitious goals.

Compared to proposals such as XCP and AntiECN, Quick-Start offers
much less control. Quick-Start does not attempt to provide a new
congestion control mechanism, but simply to get permission from routers for when they reduce a higher sending rate at start-up, or after an idle
period.
Quick-Start can be thought of as an "anti-congestion-
control" mechanism, that is only of any use when all request, and from the sender in verifying the nonce
returned by the receiver. As reported in [B05], routers could
protect themselves from processor exhaustion attacks by limiting the
rate at which they will approve reductions of Quick-Start requests.

Both the routers
along Function field and the Reserved field in the path are significantly under-utilized. Thus, Quick-Start
is
Option would allow the extension of no Quick-Start to use towards a target Quick-Start
requests with the alternate proposal for the Quick-Start Nonce, if
it was ever desired.

A.7.2. The Earlier Request-Approved QuickStart Nonce

An earlier version of high link utilization, or fairness
in this document included a high-utilization scenario, or controlling queueing delay during
high-utilization, or anything of Request-Approved
QuickStart Nonce (QS Nonce) that was initialized by the like.

At sender to a
non-zero, `random' eight-bit number, along with a QS TTL that was
initialized to the same time, Quick-Start would allow larger initial windows
than would proposals such value as AntiECN, requires less input to routers
than XCP, and the TTL in the IP header. The
Request-Approved QuickStart Nonce would require less frequent feedback from routers than
any new congestion control mechanism. Thus, have been returned by the
transport receiver to the transport sender in the Quick-Start is
significantly less powerful than proposals for new congestion
control mechanisms such as XCP and AntiECN, but as powerful
Response. A router could deny the Quick-Start request by failing to
decrement the QS TTL field, by zeroing the QS Nonce field, or more
powerful in terms of by
deleting the specific issue Quick-Start Request from the packet header. The QS
Nonce was included to provide some protection against broken
downstream routers, or against misbehaving TCP receivers that might
be inclined to lie about whether the Rate Request was approved.
This protection is now provided by the QS Nonce, by the use of allowing larger a
random initial
windows, value for the QS TTL field, and (we think) more amenable by Quick-Start-
capable routers hopefully either deleting the Quick-Start Option or
zeroing the QS TTL and QS Nonce fields when they deny a request.

With the old Request-Approved QuickStart Nonce, along with the QS
TTL field set to incremental deployment in the current Internet.

We do not discuss proposals such same value as XCP the TTL field in detail, but simply note
that there are the IP header,
the Quick-Start Request mechanism would have been self-terminating;
the Quick-Start Request would terminate at the first participating
router after a number non-participating router had been encountered on the
path. This minimizes unnecessary overhead incurred by routers
because of open questions. One question concerns
whether there is a pressing need option processing for more sophisticated congestion
control mechanisms such as XCP in the Internet. Quick-Start Request. In the
current specification, this "self-terminating" property is
inherently provided
by Quick-Start-capable routers hopefully either deleting the Quick-
Start Option or zeroing the Rate Request field when they deny a rather crude tool that does not deliver assurances
about maintaining high link utilization and low queueing delay;
Quick-Start is designed for use in environments that are
significantly underutilized, and addresses
request. Because the single question of
whether current specification uses a higher sending rate is allowed. New congestion control
mechanisms with more fine-grained feedback from random initial
value for the QS TTL, Quick-Start-capable routers could allow
faster startups even in environments with rather high link
utilization. Is this a pressing requirement? Are can't tell if the other
benefits
Quick-Start Request is invalid because of more fine-grained congestion control feedback from non-Quick-Start-capable
routers upstream. This is the cost of using a pressing requirement?

We would argue design that even if more fine-grained per-packet feedback
from routers was implemented, makes it is reasonable
difficult for the receiver to have a separate
mechanism such as cheat about the value of the QS TTL.

B. Quick-Start with DCCP

DCCP is a new transport protocol for indicating an allowed initial
sending rate, or an allowed total sending rate after an idle or
underutilized period.

One difference between Quick-Start and current proposals congestion-controlled,
unreliable datagrams, intended for fine-
grained per-packet feedback applications such as XCP is that XCP is designed to
give robust performance even in streaming
media, Internet telephony, and on-line games. In DCCP, the case where different packets
within
application has a connection routinely follow different paths. XCP achieves
relatively robust performance in choice of congestion control mechanisms, with the presence
currently-specified Congestion Control Identifiers (CCIDs) being
CCID 2 for TCP-like congestion control, and CCID 3 for TFRC, an
equation-based form of multi-path routing
by using per-packet feedback, where congestion control. We refer the feedback carried in reader to
[KHF05] for a single
packet is about more detailed description of DCCP, and of the relative increase or decrease in
congestion control mechanisms.

Because CCID 3 uses a rate-based congestion control mechanism, it
raises some new issues about the rate or
window use of Quick-Start with transport
protocols. In this document we don't attempt to take effect when specify the use of
Quick-Start with DCCP. However, we do discuss some of the issues
that particular packet is acknowledged,
not about might arise.

In considering the allowed sending rate use of Quick-Start with CCID 3 for the connection as requesting a whole.

In contrast, Quick-Start sends
higher initial sending rate, the following questions arise: (1) how
does the sender respond if a single Quick-Start request, packet is dropped; and (2)
when does the
answer to sender determine that request gives there has been no feedback from
the receiver, and reduce the allowed sending rate for an entire
window of data. As rate?

(1) How does the sender respond if a result, Quick-Start could be problematic packet is dropped:
As in TCP, if an
environment where some fraction of the packets in a window of data
take path A, and the rest of initial Quick-Start packet is dropped, the packets take path B; for example, CCID 3
sender should revert to the Quick-Start Request could congestion control mechanisms it would
have travelled on path A, while half
of used if the Quick-Start packets sent in request had not been approved.

(2) When does the succeeding round-trip time
are routed on path B.

There are also differences between Quick-Start and some of sender decide there has been no feedback from the
proposals
receiver:
Unlike TCP, CCID 3 does not use acknowledgements for per-packet every packet,
or for every other packet. In contrast, the CCID 3 receiver sends
feedback to the sender roughly once per round-trip time. In CCID 3,
the allowed sending rate is halved if no feedback is received from
the receiver in terms of at least four round-trip times (when the sender is
sending at least one packet every two round-trip times). When a
Quick-Start request is used, it would seem necessary to use a
smaller time interval, e.g., to reduce the number of bits of sending rate if no
feedback required is received from the routers to the end-nodes. Quick-Start
uses four bits of feedback receiver in at least two round-trip
times.

The question also arises of how the rate request field to indicate the
allowed sending rate. XCP allocates a byte for per-packet feedback,
though there has been discussion of variants of XCP with less per-
packet feedback. This would rate should be more like other proposals such as
anti-ECN that use reduced
after a single bit period of no feedback from routers to indicate
that the sender can increase as fast as slow-starting, in response
to this particular packet acknowledgement. In general, there is
probably considerable power in fine-grained proposals receiver. As with only two
bits of feedback, indicating that TCP, the sender should decrease,
maintain, or increase
default CCID 3 response of halving the sending rate or window when this packet is
acknowledged. However, the power of Quick-Start would be
considerably limited if it was restricted not
necessarily a sufficient response to only two bits the absence of feedback; it seems likely that determining an
alternative is to reduce the initial sending rate
fundamentally requires more bits of feedback from routers than does
the steady-state, per-packet feedback to increase or decrease the sending rate.

On rate that
would have been used if no Quick-Start request had been approved.
That is, if a CCID 3 sender uses a more practical level, one difference between Quick-Start and
proposals for per-packet request, special
rules might be required to handle the sender's response to a period
of no feedback is that there are fewer open
issues with from the receiver regarding the Quick-Start packets.

Similarly, in considering the use of Quick-Start than there would be with a new congestion
control mechanism. For example, for a mechanism CCID 3 for
requesting a
initial higher sending rate in after an underutilized environment, idle period, the fairness
issues of following
questions arise: (1) what rate does the sender request; (2) what is
the response to a general congestion control mechanism go away, packet loss; and (3) when does the sender
determine that there
is has been no need for feedback from the end nodes to tell receiver, and the routers
sending rate must be reduced?

(1) What rate does the round-trip time
and congestion window, as is done sender request:
As in XCP; all that is needed TCP, there is for
the end nodes to report the requested sending rate.

Table 2 provides a summary of straightforward answer to the differences between Quick-Start
and proposals for per-packet congestion control feedback.

Table 2: Differences between Quick-Start and Proposals for
Fine-Grained Per-Packet Feedback.

A separate question concerns whether mechanisms such as Quick-Start,
in combination with HighSpeed TCP and other changes
that the CCID 3 sender should use in progress,
would make a significant contribution towards meeting some of these
needs for new congestion control mechanisms. This could be viewed
as requesting a positive step of meeting some of higher sending
rate after an idle period. The sender knows the current needs with a
simple and reasonably deployable mechanism, loss event
rate, either from its own calculations or alternately, as a
negative step of unnecessarily delaying more fundamental changes.
Without answering this question, we would note from feedback from the
receiver, and can determine the sending rate allowed by that our own approach
tends to favor loss
event rate. This is the incremental deployment upper bound on the sending rate that should
be requested by the CCID 3 sender. A Quick-Start request is useful
with CCID 3 when the sender is coming out of relatively simple
mechanisms, an idle or
underutilized period, because in standard operation CCID 3 does not
allow the sender to send more than twice as long fast as the simple mechanisms are not short-term
hacks but mechanisms that lead the overall architecture receiver has
reported received in the
fundamentally correct direction.

A.7. most recent feedback message.

(2) What is the response to loss:
The Earlier QuickStart Nonce

An earlier version of this document included a Request-Approved
QuickStart Nonce (QS Nonce) that was initialized by response to the sender loss of Quick-Start packets should be to a
non-zero, `random' eight-bit number, along with a QS TTL that was
initialized return
to the same value as sending rate that would have been used if Quick-Start had not
been requested.

(3) When does the sender decide there has been no feedback from the TTL
receiver:
As in the IP header. The
Request-Approved QuickStart Nonce would have been returned by case of the
transport receiver initial sending rate, it would seem prudent to
reduce the transport sender sending rate if no feedback is received from the receiver
in at least two round-trip times. It seems likely that in this
case, the Quick-Start
Response. A router could deny sending rate should be reduced to the sending rate that
would have been used if no Quick-Start request by failing to
decrement the QS TTL field, by zeroing the QS Nonce field, or by
deleting had been approved.

C. Possible Router Algorithm

This specification does not tightly define the algorithm a router
uses when deciding whether to approve a Quick-Start Rate Request from the packet header. The QS
Nonce was included to provide some protection against broken
downstream routers, or against misbehaving TCP receivers that might
be inclined to lie about
whether the and how to reduce a Rate Request was approved.
This protection Request. A range of algorithms is now provided by the QS Nonce, by
likely useful in this space and we consider the use algorithm a
particular router uses to be a local policy decision. In addition,
we believe that additional experimentation with router algorithms is
necessary to have a solid understanding of the dynamics various
algorithms impose. However, we provide one particular algorithm in
this appendix as an example and as a
random initial value framework for thinking about
additional mechanisms.

[SAF05] provides several algorithms routers can use to consider
incoming Rate Requests. The decision process involves two
algorithms. First, the router needs to track the QS TTL field, and link utilization
over the recent past. Second, this utilization needs to be updated
by Quick-Start-
capable routers hopefully either deleting the potential new bandwidth from recent Quick-Start Option or
zeroing the QS TTL approvals,
and QS Nonce fields when they deny a request.

With the old Request-Approved QuickStart Nonce, along then compared with the QS
TTL field set router's notion of when it is
underutilized enough to approve Quick-Start requests (of some size).

First, we define the same value as the TTL field in "peak utilization" estimation technique (from
[SAF05]). This mechanism records the IP header, utilization of the Quick-Start Request mechanism would have been self-terminating; link every
S seconds and stores the Quick-Start Request would terminate at most recent N of these measurements. The
utilization is then taken as the first participating
router after a non-participating router had been encountered on highest utilization of the
path. N
samples. This minimizes unnecessary overhead incurred by routers
because method, therefore, keeps N*S seconds of option processing for history.
This algorithm reacts rapidly to increases in the Quick-Start Request. link utilization.
In the
current specification, this "self-terminating" property [SAF05] S is provided
by Quick-Start-capable routers hopefully either deleting the Quick-
Start Option or zeroing the Rate Request field when they deny a
request. Because the current specification uses a random initial
value set to 0.15 seconds, and experiments use values for
N ranging from 3 to 20.

Second, we define the QS TTL, Quick-Start-capable routers can't tell if the "target" algorithm for processing incoming
Quick-Start Request is invalid because of non-Quick-Start-capable
routers upstream. This is Rate Requests (also from [SAF05]). The algorithm relies
on knowing the cost bandwidth of using a design that makes it
difficult for the receiver to cheat about outgoing link (which in many cases
can be easily configured), the value utilization of the QS TTL.

B. Quick-Start with DCCP

DCCP is a new transport protocol for congestion-controlled,
unreliable datagrams, intended for applications outgoing link
(from an estimation technique such as streaming
media, Internet telephony, given above) and on-line games. In DCCP, the
application has a choice an estimate
of congestion control mechanisms, with the
currently-specified Congestion Control Identifiers (CCIDs) being
CCID 2 for TCP-like congestion control, and CCID 3 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.
The simpliest method, outlined in Section 8.2, is for TFRC, an
equation-based form of congestion control. We refer the reader router to
[KHF05] for a more detailed description
keep track of DCCP, the aggregate Quick-Start rate requests approved in
the most recent two or more time intervals, including the current
time interval, and to use the sum of the
congestion control mechanisms.

Because CCID 3 uses a rate-based congestion control mechanism, it
raises some new issues about aggregate rate requests
over these time intervals as the use estimate of Quick-Start with transport
protocols. In this document we don't attempt to specify the use approved Rate
Requests. The experiments in [SAF05] keep track of
Quick-Start with DCCP. However, we do discuss some the aggregate
approved Rate Requests over the most recent two time intervals, for
intervals of 150~msec.

The target algorithm also depends on a threshold (qs_thresh) that is
the fraction of the issues outgoing link bandwidth that might arise.

In considering represents the use
router's notion of "significantly underutilized". If the
utilization, augmented by the potential bandwidth from recent Quick-
Start approvals, is above this threshold then no Quick-Start with CCID 3 for requesting a
higher initial sending rate, Rate
Requests will be approved. If the following questions arise: (1) how
does utilization, again augmented by
the sender respond if a potential bandwidth from recent Quick-Start packet approvals, is dropped; and (2)
when does less
than the sender determine threshold then Rate Requests can be approved. The Rate
Requests will be reduced such that there has been no feedback from the receiver, and reduce bandwidth allocated would not
drive the sending rate?

(1) How does utilization to more than the sender respond given threshold. The
algorithm is:

util_bw = bandwidth * utilization;
util_bw = util_bw + recent_qs_approvals;
if a Quick-Start packet is dropped:
As in TCP, (util_bw < (qs_thresh * bandwidth))
{
approved = (qs_thresh * bandwidth) - util_bw;
if an initial (rate_request < approved)
approved = rate_request;
approved = round_down (approved);
recent_qs_approvals += approved;
}

Also note that given that Rate Requests are fairly coarse, the
approved rate should be rounded down when it does not fall exactly
on one of the rates allowed by the encoding scheme.

Routers that wish to keep close track of the allocated Quick-Start packet is dropped,
bandwidth could use Approved Rate reports to learn when rate
requests had been decremented downstream in the CCID 3 network, and also to
learn when a sender should revert begins to use the congestion control mechanisms it would
have used if approved Quick-Start request.

D. Possible Additional Uses for the Quick-Start request had not been approved.

(2) When does the sender decide there has been no feedback from Option

The Quick-Start Option contains a four-bit Function field in the
receiver:
Unlike TCP, CCID 3 does not use acknowledgements for every packet,
or
third byte, enabling additional uses to be defined for every other packet. the Quick-
Start Option. In contrast, this section we discuss some of the CCID 3 receiver sends
feedback possible
additional uses that have been discussed for Quick-Start. The
Function field makes it easy to add new functions for the sender roughly once per round-trip time. In CCID 3,
the allowed sending rate is halved if no feedback is received from Quick-
Start Option.

Report of Current Sending Rate: A Quick-Start Request with the receiver
`Report of Current Sending Rate' codepoint set in at least four round-trip times (when the sender is
sending at least one packet every two round-trip times). When a
Quick-Start request is used, it Function field
would seem prudent to use a smaller
time interval, e.g., be using the Rate Request field to reduce report the current
estimated sending rate if no feedback is
received from the receiver for that connection. This could accompany a
second Quick-Start Request in at least two round-trip times.

The question also arises of how the sending same packet containing a standard
rate should be reduced
after request, for a period of no feedback from the receiver. As with TCP, connection that is using Quick-Start to increase
its current sending rate.

Request to Increase Sending Rate: A codepoint for `Request to
Increase Sending Rate' in the
default CCID 3 response of halving Function field would indicate that the sending rate
connection is not
necessarily sufficient; an alternative idle or just starting up, but is attemmpting to reduce the sending rate
use Quick-Start to the increase its current sending rate that rate. This
codepoint would have been used if no Quick-Start
request had been approved. That is, if a CCID 3 sender uses a
Quick-Start request, special rules might be required to handle not change the
sender's response to a period semantics of no feedback from the receiver
regarding Rate Request field.

RTT Estimate: If a codepoint for `RTT Estimate' was used, a field
for the Quick-Start packets.

Similarly, in considering RTT Estimate would contain one or more bits giving the use
sender's rough estimate of Quick-Start with CCID 3 for
requesting a higher sending rate after an idle period, the following
questions arise: (1) what rate does round-trip time, if known. E.g., the
sender request; (2) what is could estimate whether the response to a loss; and (3) when does RTT was greater or less than 200
ms. Alternately, if the sender determine that
there has been no feedback from had an estimate of the receiver, and RTT when it
sends the sending rate
must be reduced?

(1) What rate does Rate Request, the sender request:
As in TCP, there is a straightforward answer to two-bit Reserved field at the rate request
that end of the CCID 3 sender should use in requesting
Quick-Start Option could be used for a higher sending
rate after an idle period. The sender knows the current loss event
rate, either from its own calculations or from feedback from the
receiver, and can determine coarse-grained encoding of
the sending rate allowed by RTT.

Informational Request: An Informational Request codepoint in the
Function field would indicate that loss
event rate. This a request is purely
informational, for the upper bound on the sending sender to find out if a rate that should request would be requested by the CCID 3 sender. A Quick-Start
approved, and what size rate request is useful
with CCID 3 would be approved, when the sender
Informational Request is coming out of sent. For example, an idle or
underutilized period, because in Informational
Request could be followed one round-trip time later by a standard operation CCID 3 does
Quick-Start Request. A router approving an Informational Request
would not
allow the sender to send more that twice as fast consider this as the receiver has
reported received in the most recent feedback message.

(2) What is the response an approval for Quick-Start bandwidth to loss:
The response
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 loss of Rate Request Field: A Quick-Start packets should be to return
to codepoint for
`Use Format X for the sending rate that Rate Request Field' would have been indicate that an
alternate format was being used if for the Rate Request field.

Do Not Decrement: A Do Not Decrement codepoint could be used for a
Quick-Start had not
been requested.

(3) When does request where the sender decide there has been no feedback from the
receiver:
As in the case of the initial sending rate, it would seem prudent to
reduce the sending rate if no feedback is received from the receiver
in at least two round-trip times. It seems likely that in this
case, would rather have the sending rate should be reduced request
denied than to have the sending rate that
would have been request decremented in the network.
This could be used if no Quick-Start the sender was only interested in using Quick-
Start if the original rate request had been was approved.

C. Possible Router Algorithm

This specification does not tightly define the algorithm a router
uses when deciding whether to approve a Quick-Start Rate Request or
whether and how to reduce

E. Feedback from Bob Briscoe

[B05] in a Rate Request. A range review of an earlier version of algorithms is
likely useful in this space and we consider the algorithm a
particular router uses to be a local policy decision. In addition,
we believe that additional experimentation with router algorithms is
necessary to have Quick-Start proposal
discussed a solid understanding number of the dynamics various
algorithms impose. However, we provide one particular algorithm in
this appendix as an example potential problems with Quick-Start, and as a framework
argued for thinking about
additional mechanisms.

[SAF05] provides several algorithms routers can use to consider
incoming Rate Requests. The decision process involves two
algorithms. First, the router needs to track the link utilization
over an alternate approach for policing congestion in networks
using re-feedback [BJCG+05,BJS05]. However, [B05] didn't oppose the recent past. Second, this utilization needs
move to be updated
by the potential new bandwidth from recent Quick-Start approvals,
and then compared with to experimental status as long as its
applicability is made clear.

E.1. Potential Deployment Scenarios

[B05] argues that because the router's notion of when sender's trustworthiness is not
necessarily verified, Quick-Start, if it is
underutilized enough remain stateless, should
be confined to approve environments where every source is trusted. Section
3.2 of [B05] argues that either (1) Quick-Start should be
recommended for deployment only in trusted environments, or (2)
Quick-Start requests (of could be recommended for deployment also in untrusted
environments, with flow state required at some size).

First, or all routers.

Since [B05], we define the "peak utilization" estimation technique (from
[SAF05]). This mechanism records have added the utilization Report of the link every
S seconds Approved Rate as a required
part of Quick-Start, and stores discussed ways that this could be used by
routers or by traffic policers, if desired, to check on the most recent N use of these measurements. The
utilization is then taken as
Quick-Start by senders. We also note that senders can send at an
initial high rate even in the highest utilization absence of Quick-Start, in the N
samples. This method, therefore, keeps N*S seconds of history.
This algorithm reacts rapidly current
network; that is, in our view, Quick-Start does not change the
dangers to increases the network from malicious senders. Thus, while we are
clearly not recommending Quick-Start for widespread deployment in
the link utilization.
In [SAF05] S global Internet, we also don't feel the need to explicitly
restrict its deployment to environments where every source is set
trusted, or to 0.15 seconds, and experiments use values explicitly require per-flow state at Quick-Start
routers. We assume that Quick-Start will only be enabled at routers
if the system administrators feel either that they have sufficient
trust in senders, sufficient policing mechanisms for
N ranging from 3 checking for
misbehaving nodes, or sufficient oversite to 20.

Second, we define disable Quick-Start if
it is determined to be causisng problems..

E.2. Misbehaving Senders and Receivers

Some of the "target" algorithm criticisms of Quick-Start in [B05] are criticisms for processing incoming
mechanisms that allocate rates to senders, but this is not what
Quick-Start Rate Requests (also from [SAF05]). The algorithm relies
on knowing the bandwidth does. Quick-Start requests apply to individual
connections, not to unique addresses or unique tuples of addresses.
Further, the outgoing link (which in many cases
can be easily configured), the utilization approval by routers of the outgoing link
(from an estimation technique such as given above) and Quick-Start requests does not
result in an estimate allocation of the potential bandwidth from recent Quick-Start approvals.

Tracking for the potential sender making that
request; the approval by routers does not result in any allocation
of bandwidth at all. The state used by routers from recent Quick-Start past Quick-
Start approvals is another case where local policy dictates how it should be done.
The simpliest method, outlined in Section 8.2, is for used only to guide the router to
keep track in its approval or
rejection of future Quick-Start requests. We have added text to
this document to make this quite explicit.

[B05] discusses the aggregate dangers of sender spoofing and identity
splitting. Identify splitting would not be a problem with Quick-
Start, because Quick-Start rate requests approved in
the most recent two apply to individual connections,
not to unique addresses or unique tuples of addresses. Because
Quick-Start does not allocate rates to senders, sender-spoofing is
also not a critical issue (except as it would make it more time intervals, including the current
time interval, difficult
for those Quick-Start routers that maintain per-flow state to
identify senders that send Quick-Start requests that are not in fact
used, due either to malicious requests or due to requests denied
downstream).

In Section 3.3, [B05] says that "the lack of a secure binding
between a request and subsequent traffic means that any other node
could send a burst of traffic and claim it requests it, with no-one
being able to use prove it didn't." In the sum current Internet, any node
can send a burst of traffic any time it would like, even without
Quick-Start. However, in the aggregate absense of Quick-Start, sending at a
high rate requests
over these time intervals is not always in the sender's interest, as the estimate packets
that are send might have a high probability of the approved Rate
Requests. The experiments being dropped in [SAF05] keep track of the aggregate
approved Rate Requests over
network, particularly in the most recent two time intervals, for
intervals absense of 150~msec. Quick-Start. The target algorithm also depends on a threshold (qs_thresh) that is
the fraction addition
of the outgoing link bandwidth that represents the
router's notion Report of "significantly underutilized". If Approved Rate to Quick-Start gives traffic policers
the
utilization, augmented by ability to check on some of the potential bandwidth from recent Quick-
Start approvals, is above this threshold then no abuses of Quick-Start,
if they so desire.

In Section 3.8, [B05] states that "not only do Quick-Start Rate
Requests will be approved. If the utilization is less than the
threshold then Rate Requests will be approved. The Rate Requests
will senders
have to be reduced such trusted, but also other senders who could claim their
data had been authorised by a Quick-Start response when it hadn't
(Section 3.3)." In response, we would again clarify that with Quick-
Start, the bandwidth allocated would not drive Quick-Start request makes no difference in how the utilization to more than
subsequent Quick-Start data packets are treated at the given threshold. The algorithm is:

util_bw = bandwidth * utilization;
util_bw = util_bw + recent_qs_approvals;
if (util_bw < (qs_thresh * bandwidth))
{
approved = (qs_thresh * bandwidth) - util_bw;
if (rate_request < approved)
approved = rate_request;
approved = round_down (approved);
recent_qs_approvals += approved;
}

Also note that given router,
compared to non-Quick-Start data packets. Thus, a sender's claim
that Rate Requests its data results from a previous Quick-Start request should
make no difference in how those data packets are fairly gross treated at routers.
The approval of a Quick-Start request is not a promise by the
approved rate should be rounded down when router
that the subsequent data packets will receive differential treatment
at the router; it does not fall exactly
on one of is only a statement from the rates allowed by router that the encoding scheme.

D. Possible Uses for
router believes that the Reserved Fields

The Quick-Start Request Option contains a four-bit Reserved field in data packets will not change
the first four bytes, and a two-bit Reserved field in current under-utilized state of the last four
bytes. In router. We have clarified
this section we discuss some in Section 3.3 of this document.

E.3. Fairness

In its abstract, [B05] says the possible uses that
have been discussed for these Reserved bits.

Reporting Approved Rate: A Quick-Start Request with following: "Because traffic variance
will always blur the Reporting
Approved Rate bit set would not be requesting Quick-Start bandwidth,
but would boundary, we argue that under-utilisation
should be reporting treated as the approved rate extreme of a spectrum where fairness is
always an issue to some extent."

The specification for Quick-Start bandwidth
that was approved one round-trip time earlier. This could be used
by routers to track which now says the following: "A router
should only approve a Quick-Start requests were actually
approved request if the output link is
underutilized, and in use, along with if the approved rate.

Report of Current Sending Rate: A Quick-Start Request with router judges that the
`Report of Current Sending Rate' bit set would output link will
continue to be using underutilized if the Rate
Request field request is approved."

We changed the quote "for a mechanism for requesting an initial
sending rate in an underutilized environment, the fairness issues of
a general congestion control mechanism go away" to report the current estimated sending rate for that
connection. This could accompany a second following:
"because Quick-Start Request in
the same packet containing is a standard rate request, mechanism for requesting an initial
sending rate in an underutilized environment, its fairness issues
are less severe than those of a connection general congestion control
mechanism."

However, we did not add the sentence recommended in Ssection 3.4 of
[B05], that "Quick-Start is using targeted at an experimental environment
where the more intractable issues can be set aside". In particular,
we don't agree that Quick-Start needs to increase its current sending rate.

Request to Increase Sending Rate: A bit be targeted only for `Request to Increase
Sending Rate' would indicate that the connection is not idle or just
starting up, but
environments where fairness is attemmpting to use Quick-Start to increase its
current sending rate. This bit would not change the semantics an issue.

E.4. Models of Under-Utilization

[B05] states that "One of the Rate Request field.

RTT Estimate: A field for under-utilisation assumptions I had in
my head while reading the RTT Estimate would contain paper was that any one or more
bits giving host is generally
able to over-fill available capacity, but that, given a high rate,
the sender's rough estimate of flow would end quickly." We are sorry that this is the round-trip time, if
known. E.g., model
that the sender could estimate whether author inferred from the RTT draft, but we can give assurances
that this `one big flow at a time" model was greater *never* the implicit or less than 200 ms.

Informational Request: An Informational Request bit
explicit model underlying the Quick-Start design. (We would indicate also
note that every version of this document since the first version
back in 2002 has discussed router responses when the router
experiences a request is purely informational, for flood of Quick-Start requests.)

[B05] also says the sender following: "By reverse engineering this
algorithm, it was possible to find out
if guess that there was an assumption
that host capacity was smaller than the network's, so meeting a rate
request in full would be approved, and what size rate request still leave a lot of spare capacity for the
next request." Again, we would be approved, when like to clarify that there has been
no such assumption underlying 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 design.

E.5. Router Algorithms as an approval Local Policy

[B05] recommends that either this document should set constraints on
possible router algorithms, or say that experiments are needed "in
order to establish constraints required on router algorithms for
Quick-Start bandwidth
interworking, robustness, fairness etc." While it is possible that
experiments will lead to be used, and would an understanding of constraints that are
needed on router algorithms, we think it is more likely that there
will not be under any
obligation to approve a similar standard Quick-Start Request one
round-trip time later.

Use Format X need for explicit constraints on router algorithms for
accepting or rejecting Quick-Start requests.

Our approach is that, while the Rate Request Field: A Quick-Start bit for `Use
Format X for IETF documentation
standardizes the semantics of Quick-Start and the Rate Request Field' would indicate that an
alternate format was being of the
Quick-Start IP Option and the Quick-Start Response TCP Option, the
IETF documentation should not and does not standardize the
algorithms used at routers for the Rate Request field.

Do Not Decrement: A Do Not Decrement bit could be set approving or denying Quick-Start
request. Appendix D in this document has presented one possible
router algorithm for approving or denying Quick-Start requests, but
further discussion of the range of possibilities in a Quick-
Start request if router
algorithms is available elsewhere [SAF05]. As an example, the sender would rather have
fairness criteria that routers might apply in granting or denying
Quick-Start requests are discussed in [SAF05], but are not discussed
in the request denied
than same detail in this document. This document leaves routers
free to have the rate request decremented apply any criteria they choose in accepting or denying
Quick-Start requests, modulo the network. requirements given in Section 3.3
above.

This
could be used if approach of the sender was only interested in using Quick-Start
if the original rate request was approved.

If any router algorithm as a matter of these functions were
local policy is consistent with the approach in RFC 3168 on
standardizing Explicit Congestion Notification (ECN). RFC 3168
standardized the semantics of the ECN field, but did not standardize
a router's Active Queue Management mechanisms for Quick-Start, deciding when to
set the
standardization would also have Congestion Experienced codepoint in packets.

E.6. An Alternate Proposal

[B05] proposes an alternate to address Quick-Start where endpoints allocate
rates to themselves. [B05] argues that adding rate allocation to
interior routers is not the issue of backwards
compatibility fundamenally correct direction.

[B05] argues for an approach that associates senders with their
ingress attachment point, with older Quick-Start routers or end-nodes reporting their impairment
status back to the sender [BJCG+05, BJS05]. The source declares the
impairment that do it believes it will accumulate along the path, and
routers effectively subtract the local impairment status. If the
sender is reporting correctly, and the impairment has not understand changed
significantly from one round-trip time to the newly-added function. next, the reported
impairment at the egress router should be close to zero.

Normative References

[RFC793] J. Postel, Transmission Control Protocol, RFC 793,
September 1981.

[RFC1191] Mogul, J. and S. Deering, Path MTU Discovery, RFC 1191,
November 1990.

[RFC2460] S. Deering and R. Hinden. Internet Protocol, Version 6
(IPv6) Specification. RFC 2460, December 1998.

[RFC2581] M. Allman, V. Paxson, and W. Stevens. TCP Congestion
Control. RFC 2581. April 1999.

[RFC3168] Ramakrishnan, K.K., Floyd, S., and Black, D. The Addition
of Explicit Congestion Notification (ECN) to IP. RFC 3168, Proposed
Standard, September 2001.

[RFC3390] M. Allman, S. Floyd, and C. Partridge. Increasing TCP's
Initial Window. RFC 3390, October 2002.

[RFC3742] Floyd, S., Limited Slow-Start for TCP with Large
Congestion Windows, RFC 3742, Experimental, March 2004.

Informative References

[RFC792] J. Postel. Internet Control Message Protocol. RFC 792,
September 1981.

[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.

[RFC1812] F. Baker (ed.). Requirements for IP Version 4 Routers. RFC
1812, June 1995.

[RFC2003] Perkins, C., IP Encapsulation within IP, RFC 2003,
October 1996.

[RFC2113] D. Katz. P Router Alert Option. RFC 2113, February 1997.

[RFC2140] J. Touch. TCP Control Block Interdependence. RFC 2140.
April 1997.

[RFC2205] R. Braden, et al. Resource ReSerVation Protocol (RSVP) --
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,
D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L.
Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang,
Recommendations on Queue Management and Congestion Avoidance in the
Internet, RFC 2309, April 1998.

[RFC2401] S. Kent and R. Atkinson. Security Architecture for the
Internet Protocol. RFC 2401, November 1998.

[2401bis] S. Kent and K. Seo, Security Architecture for the Internet
Protocol, internet-draft draft-ietf-ipsec-rfc2401bis-06.txt, work-
in-progress, March 2005.

[RFC2402] S. Kent and R. Atkinson. IP Authentication Header. RFC
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
Initial TCP Window Size. RFC 2415. September 1998.

[RFC2416] T. Shepard and C. Partridge. When TCP Starts Up With Four
Packets Into Only Three Buffers. RFC 2416. September 1998.

[RFC2463] A. Conta and S. Deering. Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification.
RFC 2463, December 1998.

[RFC2488] M. Allman, D. Glover, and L. Sanchez. Enhancing TCP Over
Satellite Channels using Standard Mechanisms. RFC 2488. January
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.
RFC 2960, October 2000.

[RFC3124] H. Balakrishnan and S. Seshan. The Congestion Manager. RFC
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,
August 2002.

[RFC3360] S. Floyd. Inappropriate TCP Resets Considered Harmful.
RFC 3360, August 2002.

[RFC3649] Floyd, S., HighSpeed TCP for Large Congestion Windows, RFC
3649, December 2003.

[RFC3662] R. Bless, K. Nichols, and K. Wehrle. A Lower Effort Per-
Domain Behavior (PDB) for Differentiated Services. RFC 3662,
December 2003.

[RFC3775] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in
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.

[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.

[AHO98] M. Allman, C. Hayes and S. Ostermann. An evaluation of TCP
with Larger Initial Windows. ACM Computer Communication Review, July
1998.

[B05] B. Briscoe, Review: Quick-Start for TCP and IP, internet-draft
draft-briscoe-tsvwg-quickstart-rvw-00, work-in-progress, URL
"http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html", November 2005.

[BJCG+05] Briscoe, B., Jacquet, A., Di Cairano-Gilfedder, C.,
Salvatori, A., Soppera, A., and M. Koyabe, "Policing Congestion
Response in an Internetwork Using Re-Feedback", SIGCOMM, August
2005.

[BJS05] Briscoe, B., Jacquet, A., and A. Salvatori, "Re-ECN: Adding
Accountability for Causing Congestion to TCP/IP", internet-draft
draft-briscoe-tsvwg-re-ecn-tcp-00.txt, work-in-progress, October
2005.

[BW97] G. Brasche and B. Walke. Concepts, Services and Protocols of
the new GSM Phase 2+ General Packet Radio Service. IEEE
Communications Magazine, pages 94--104, August 1997.

[FF99] Floyd, S., and Fall, K., Promoting the Use of End-to-End
Congestion Control in the Internet, IEEE/ACM Transactions on
Networking, August 1999.

[F03] Floyd, S., HighSpeed TCP for Large Congestion Windows, RFC
3649, December 2003.

[GPAR02] A. Gurtov, M. Passoja, O. Aalto, and M. Raitola. Multi-
Layer Protocol Tracing in a GPRS Network. In Proceedings of the IEEE
Vehicular Technology Conference (Fall VTC2002), Vancouver, Canada,
September 2002.

[H05] P. Hoffman, email, October 2005. Citation for acknowledgement
purposes only.

[HKP01] M. Handley, C. Kreibich and V. Paxson, Network Intrusion
Detection: Evasion, Traffic Normalization, and End-to-End Protocol
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

[JD02] Manish Jain, Constantinos Dovrolis, End-to-End Available
Bandwidth: Measurement Methodology, Dynamics, and Relation with TCP
Throughput, SIGCOMM 2002.

[KHR02] Dina Katabi, Mark Handley, and Charles Rohrs, Internet
Congestion Control for Future High Bandwidth-Delay Product
Environments. ACM Sigcomm 2002, August 2002. URL
"http://ana.lcs.mit.edu/dina/XCP/".

[KHF05] E. Kohler, M. Handley, and S. Floyd, Datagram Congestion
Control Protocol (DCCP), internet draft draft-ietf-dccp-spec-11.txt,
work in progress, March 2005.

[K03] S. Kunniyur, "AntiECN Marking: A Marking Scheme for High
Bandwidth Delay Connections", Proceedings, IEEE ICC '03, May 2003.
URL "http://www.seas.upenn.edu/~kunniyur/".

[KAPS02] Rajesh Krishnan, Mark Allman, Craig Partridge, James P.G.
Sterbenz. Explicit Transport Error Notification (ETEN) for Error-
Prone Wireless and Satellite Networks. Technical Report No. 8333,
BBN Technologies, March 2002. URL
"http://www.icir.org/mallman/papers/".

[KHF05] E. Kohler, M. Handley, and S. Floyd, Datagram Congestion
Control Protocol (DCCP), internet draft draft-ietf-dccp-spec-11.txt,
work in progress, March 2005.

[KK03] A. Kuzmanovic and E. W. Knightly. TCP-LP: A Distributed
Algorithm for Low Priority Data Transfer. INFOCOM 2003, April 2003.

[L05] Guohan Lu, Nonce in TCP Quick Start, draft, September 2005.
URL "http://www.net-glyph.org/~lgh/nonce-usage.pdf".

[MAF04] Alberto Medina, Mark Allman, and Sally Floyd, Measuring
Interactions Between Transport Protocols and Middleboxes, Internet
Measurement Conference 2004, August 2004. URL
"http://www.icir.org/tbit/".

[MAF05] Alberto Medina, Mark Allman, and Sally Floyd. Measuring the
Evolution of Transport Protocols in the Internet. To appear in Computer
Communications Review, April 2004.

[MaxNet] MaxNet Home Page, URL
"http://netlab.caltech.edu/~bartek/maxnet.htm".

[PK98] Venkata N. Padmanabhan and Randy H. Katz, TCP Fast Start: A
Technique For Speeding Up Web Transfers, IEEE GLOBECOM '98, November
1998.

[P00] Joon-Sang Park, Bandwidth Discovery of a TCP Connection,
report to John Jeidemann, 2000, private communication. Citation for
acknowledgement purposes only.

[PRAKS02] Craig Partridge, Dennis Rockwell, Mark Allman, Rajesh
Krishnan, James P.G. Sterbenz. A Swifter Start for TCP. Technical
Report No. 8339, BBN Technologies, March 2002. URL
"http://www.icir.org/mallman/papers/".

[RW03] Mattia Rossi and Michael Welzl, On the Impact of IP Option
Processing, Preprint-Reihe des Fachbereichs Mathematik - Informatik,
No. 15, October 2003.

[RW04] Mattia Rossi and Michael Welzl, On the Impact of IP Option
Processing - Part 2, Preprint-Reihe des Fachbereichs Mathematik -
Informatik, No. 26, July 2004.

[S02] Ion Stoica, private communication, 2002. Citation for
acknowledgement purposes only.

[SAF05] Pasi Sarolahti, Mark Allman, and Sally Floyd. Evaluating
Quick-Start for TCP. Under submission, May 2005. URL
"http://www.icir.org/floyd/quickstart.html".

[SGF05] Singh, M., Guha, S., and P. Francis, "Utilizing spare
network bandwidth to improve TCP performance", ACM SIGCOMM 2005 Work
in Progress session , August 2005,
https://www.guha.cc/saikat/pub/sigcomm05-lowtcp.pdf.

[SHA1] "Secure Hash Standard", FIPS, U.S. Department of Commerce,
Washington, D.C. publication 180-1, April 1995.

[SH02] Srikanth Sundarrajan and John Heidemann. Study of TCP Quick
Start with NS-2. Class Project, December 2002. Not publically
available; citation for acknowledgement purposes only.

[V02] A. Venkataramani, R. Kokku, and M. Dahlin. TCP Nice: A
Mechanism for Background Transfers. OSDI 2002.

[W00] Michael Welzl: PTP: Better Feedback for Adaptive Distributed
Multimedia Applications on the Internet, IPCCC 2000 (19th IEEE
International Performance, Computing, And Communications
Conference), Phoenix, Arizona, USA, 20-22 February 2000. URL
"http://informatik.uibk.ac.at/users/c70370/research/publications/".

[W03] Michael Welzl, PMTU-Options: Path MTU Discovery Using Options,
expired internet-draft draft-welzl-pmtud-options-01.txt, work-in-
progress. February 2003.

[ZPS00] Y. Zhang, V. Paxson, and S. Shenker, The Stationarity of
Internet Path Properties: Routing, Loss, and Throughput, ACIRI
Technical Report, May 2000.

[ZQK00] Y. Zhang, L. Qiu, and S. Keshav, Speeding Up Short Data
Transfers: Theory, Architectural Support, and Simulation Results,
NOSSDAV 2000, June 2000.

F. IANA Considerations

Quick-Start requires an IP Option and a TCP Option.

E.1.

F.1. IP Option

Quick-Start requires that both an IPv4 and an IPv6 Option Number be
allocated. The IPv4 Option would have a copied flag of 0, a class
field of 00, and the assigned five-bit option number. The IPv6
Option would have the first three bits of "001" [RFC 2460, Section
4.2], with the first two bits indicating that the IPv6 node skip
over this option and continue processing the header if it doesn't
recognize the option type, and the third bit indicating that the
Option Data may change en-route.

In both cases the name of the option would be "QSR "QS - Quick-Start
Request", Quick-Start",
with this document as the reference document.

E.2.

F.2. TCP Option

Quick-Start also requires that a TCP Option Number be allocated.
The Length would be 4, and the Meaning would be "Quick-Start
Request", with this document as the reference document.

AUTHORS' ADDRESSES

Amit Jain
F5 Networks
Email : a.jain@f5.com

Sally Floyd
Phone: +1 (510) 666-2989
ICIR (ICSI Center for Internet Research)
Email: floyd@icir.org
URL: http://www.icir.org/floyd/

Mark Allman
ICSI Center for Internet Research
1947 Center Street, Suite 600
Berkeley, CA 94704-1198
Phone: (440) 243-7361
Email: mallman@icir.org
URL: http://www.icir.org/mallman/

Amit Jain
F5 Networks
Email : a.jain@f5.com

Pasi Sarolahti
Nokia Research Center
P.O. Box 407
FI-00045 NOKIA GROUP
Finland
Phone: +358 50 4876607
Email: pasi.sarolahti@iki.fi

Full Copyright Statement

Copyright (C) The Internet Society 2005. (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.