draft-ietf-tsvwg-quickstart-07.txt		rfc4782.txt
	Internet Engineering Task Force S. Floyd
	INTERNET-DRAFT M. Allman		Network Working Group S. Floyd
	draft-ietf-tsvwg-quickstart-07.txt ICIR		Request for Comments: 4782 M. Allman
	Expires: April 2007 A. Jain		Category: Experimental ICIR
			A. Jain
	F5 Networks		F5 Networks
	P. Sarolahti		P. Sarolahti
	Nokia Research Center		Nokia Research Center
	9 October 2006		January 2007
	Quick-Start for TCP and IP		Quick-Start for TCP and IP
	Status of this Memo		Status of This Memo
	By submitting this Internet-Draft, each author represents that any
	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		This memo defines an Experimental Protocol for the Internet
	http://www.ietf.org/ietf/1id-abstracts.txt.		community. It does not specify an Internet standard of any kind.
			Discussion and suggestions for improvement are requested.
			Distribution of this memo is unlimited.
	The list of Internet-Draft Shadow Directories can be accessed at		Copyright Notice
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 2007.		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document specifies an optional Quick-Start mechanism for		This document specifies an optional Quick-Start mechanism for
	transport protocols, in cooperation with routers, to determine an		transport protocols, in cooperation with routers, to determine an
	allowed sending rate at the start and at times in the middle of a		allowed sending rate at the start and, at times, in the middle of a
	data transfer (e.g., after an idle period). While Quick-Start is		data transfer (e.g., after an idle period). While Quick-Start is
	designed to be used by a range of transport protocols, in this		designed to be used by a range of transport protocols, in this
	document we only specify its use with TCP. Quick-Start is designed		document we only specify its use with TCP. Quick-Start is designed
	to allow connections to use higher sending rates when there is		to allow connections to use higher sending rates when there is
	significant unused bandwidth along the path and the sender and all		significant unused bandwidth along the path, and the sender and all
	of the routers along the path approve the Quick-Start Request.		of the routers along the path approve the Quick-Start Request.
	This document describes many paths where Quick-Start requests would		This document describes many paths where Quick-Start Requests would
	not be approved. These paths include all paths containing routers,		not be approved. These paths include all paths containing routers,
	IP tunnels, MPLS paths, and the like that do not support Quick-		IP tunnels, MPLS paths, and the like that do not support Quick-
	Start. These paths also include paths with routers or middleboxes		Start. These paths also include paths with routers or middleboxes
	that drop packets containing IP options. Quick-Start requests could		that drop packets containing IP options. Quick-Start Requests could
	be difficult to approve over paths that include multi-access layer-		be difficult to approve over paths that include multi-access layer-
	two networks. This document also describes environments where the		two networks. This document also describes environments where the
	Quick-Start process could fail with false positives, with the sender		Quick-Start process could fail with false positives, with the sender
	incorrectly assuming that the Quick-Start request had been approved		incorrectly assuming that the Quick-Start Request had been approved
	by all of the routers along the path. As a result of these		by all of the routers along the path. As a result of these concerns,
	concerns, and as a result of the difficulties and seeming absence of		and as a result of the difficulties and seeming absence of motivation
	motivation for routers such as core routers to deploy Quick-Start,		for routers, such as core routers to deploy Quick-Start, Quick-Start
	Quick-Start is being proposed as a mechanism that could be of use in		is being proposed as a mechanism that could be of use in controlled
	controlled environments, and not as a mechanism that would be		environments, and not as a mechanism that would be intended or
	intended or appropriate for ubiquitous deployment in the global		appropriate for ubiquitous deployment in the global Internet.
	Internet.
	TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION:
	Changes from draft-ietf-tsvwg-quickstart-06:
	* Changes in reponse to the review from the
	General Area Review Team:
	- Added text to Overview about the role of TCP feedback.
	- Updated the flow label discussion from RFC2460 to RFC3697.
	- Instead of saying that the router SHOULD remove the QS Option
	when denying a request, but MAY zero fields instead,
	said that the router SHOULD either remove the QS option
	or zero the fields.
	- Fixed typos and clarified some text.
	* Still needs feedback from the ipv6 or v6ops community;
	- perhaps also have IPv6 people read the discussion of
	end-point address changes in Section 4.1.
	Changes from draft-ietf-tsvwg-quickstart-05:
	* Minor editing in response to AD feedback from
	Lars Eggert.
	This includes changing one "should" to "SHOULD",
	and changing formatting of the IANA Considerations
	section.
	* Clarifying in the Introduction that the QS router
	does not give preferential treatment to QS packets.
	In response to email from Fil Dickinson.
	* Added a discussion of interactions between
	Quick-Start and draft-ietf-pmtud-method. In
	response to AD Feedback from Lars Eggert.
	* Deleted Appendix F on "Feedback from Bob Briscoe".
	From AD feedback about deleting unnecessary
	appendices.
	* Added a paragraph to the Introduction about which
	sections contain normative references, and which
	sections are general discussion. From AD feedback.
	* Added a discussion about congestion control for
	TCP's reverse-path traffic. From feedback from
	Mitchell Erblich.
	Changes from draft-ietf-tsvwg-quickstart-04:
	* Reformatted references so that "[RFC2581, RFC3390]"
	is instead "([RFC2581], [RFC3390])", to eliminate
	bug reports from the idnits tool. From feedback
	from Dan Romascanu.
	* Rephrased beginning of second paragraph in the
	Abstract. From feedback from James Polk.
	Changes from draft-ietf-tsvwg-quickstart-03:
	* Added a discussion of the lower limit of the rate request
	of 80 kbps, from feedback from Gorry Fairhurst.
	* Added the QS Nonce to the QS Approved Rate.
	From feedback from Gorry Fairhurst.
	* Moved the Related Work section to the appendix.
	From feedback from Gorry Fairhurst.
	Changes from draft-ietf-tsvwg-quickstart-02:
	* Some general editing.
	* Said that if the receiver receives a Quick-Start Request
	with a rate of zero, then the receiver SHOULD NOT send
	a Quick-Start response. And that if the sender
	receives an acknowledgement of its packet with no
	Quick-Start response, then the sender MUST assume that the
	request was denied, and send a Report of Approved Rate
	with a rate of zero.
	* Said that if a Quick-Start packet is dropped or marked,
	the sender should not make more Quick-Start requests in this
	connection.
	* Said that the Quick-Start Request SHOULD be sent on a packet
	that requires an acknowledgement, e.g., a SYN, SYN/ACK, or data
	packet.
	* Made changes to the section on "TCP: A Quick-Start Request in the
	Middle of a Connection".
	* Added that if the TCP host is going to use the successful
	Quick-Start Request, it MUST start using it within one
	round-trip time of receiving the Quick-Start Response,
	or within three seconds, whichever is smaller.
	* Added a stronger applicability statement, in the abstract
	and in Section 10 on "Implementation and Deployment Issues".
	From feedback from the working group.
	* Added a section about MPLS. From feedback from Mitchell
	Erblichs.
	* Strengthened the language of the difficulties presented by
	multi-access links.
	* Added a discussion in Section 10.3 about the deployment of
	Quick-Start on single-hop paths. From feedback from
	Mitchell Erblichs.
	* Clarified that the "router" function of approving
	Quick-Start requests includes the IP-layer processing
	at the sender.
	* Clarified in Section 3.3 on "Processing the Quick-Start
	Request at Routers" that this document standardizes only
	the semantics of Quick-Start, and not the specific
	algorithms for processing Quick-Start requests at routers.
	* Clarified in Section 3.3 on "Processing the Quick-Start
	Request at Routers" that a router will have to consider
	the previous Quick-Start requests in approving a new one.
	* In Section 9.3 on "Quick-Start with QoS-enabled Traffic",
	which says that routers are free to take into account
	the diff-serv codepoint in considering QS requests, clarified
	that routers are also free to take into account their own
	understanding of priorities.
	* Added the Temporary bit to Appendix on "Possible Additional
	Uses for the Quick-Start Option". Clarified that the Quick-Start
	mechanism is not designed to help routers achieve full link
	utilization.
	* Editing from feedback from Gorry Fairhurst.
	Changes from draft-ietf-tsvwg-quickstart-01:
	* Added a citation to SPAND: Speeding Up Short Data Transfers.
	* Added a sentence in Section 8.1 on "Implementation Issues for
	Processing Quick-Start Requests" about multi-access links.
	* Mentioned the IP Router Alert option, RFC 2113, in Appendix.
	* Added a discussion of lower-than-best-effort service.
	* Added a few sentences about the requirements for
	randomness in the nonce.
	* Changed the name of the option from the Quick-Start Request
	Option to the Quick-Start Option.
	* Changed the semantics of the Reserved field to the Function
	field, adding that a Quick-Start option is only interpreted
	as a request if this field is zero.
	* Changed the "Reporting Approved Rate" option from a
	"Possible Use" in Appendix to a required use in Section 3.1,
	to allow routers and receivers some protection against
	misbehaving senders.
	* Changes from feedback from Bob Briscoe:
	- Added Appendix about Sections 1-3 of
	Bob Briscoe's document.
	- Added a clarification that the approval of a
	Quick-Start request at a router does not affect
	the treatment of the subsequent arriving
	Quick-Start data packets.
	- Added the one-way hash function as an alternate
	implementation for the QS Nonce.
	- Clarified the phrase "incrementally deployable", adding
	the following:
	"We note that while Quick-Start is incrementally deployable
	in this sense, a Quick-Start request cannot be approved
	for a particular connection unless both end-nodes and all
	of the routers along the path have been configured to
	support Quick-Start."
	- Clarified semantics about additional rate.
	- Said that when denying a rate request, the router
	may in the future use the QS Nonce field to report
	an error code.
	- Add Bob's suggestion from Section 4.4 as an alternate
	possible rate encoding.
	- Made changes suggested in Section 5.1.3 of Bob's paper,
	including saying that the router should decrement the QS TTL
	by the same amount that it decrements the IP TTL (on the
	off chance that it decrements the IP TTL by more than one).
	- Fixed nits.
	Changes from draft-ietf-tsvwg-quickstart-00:
	* Added a 30-bit QS Nonce. Based on feedback from Guohan Lu
	and Gorry Fairhurst (and deleted the text about a possible
	four-bit QS nonce).
	* Added a new section "Quick-Start and IPsec AH", based on feedback
	from Joe Touch and David Black.
	* Revised "Quick-Start in IP Tunnels" Section, based on feedback
	from Joe Touch and David Black.
	* Added a section about "Possible Uses for the Reserved Fields".
	* Changes from feedback from Gorry Fairhurst:
	- Section 4.4, revised the explanation for reducing the
	congestion window when the first ACK for a Quick-Start
	packet is received.
	- Section 6.4, deleted the last sentence.
	- Minor editing changes.
	- Revised Section 4.6.2 to say that sender SHOULD send one packet
	with an initial RTO of three seconds.
	- Revised Section 4.6.3 to say that the TCP sender SHOULD use an
	initial RTO setting of three seconds.
	- Added text to Section 6.2 on Multiple Paths, discussing
	multipath 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		Table of Contents
	1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 12		1. Introduction ....................................................4
	1.1. Conventions and Terminology. . . . . . . . . . . . . . . 14		1.1. Conventions and Terminology ................................5
	2. Assumptions and General Principles. . . . . . . . . . . . . . 14		2. Assumptions and General Principles ..............................6
	2.1. Overview of Quick-Start. . . . . . . . . . . . . . . . . 15		2.1. Overview of Quick-Start ....................................7
	3. The Quick-Start Option in IP. . . . . . . . . . . . . . . . . 17		3. The Quick-Start Option in IP ...................................10
	3.1. The Quick-Start Option for IPv4. . . . . . . . . . . . . 17		3.1. The Quick-Start Option for IPv4 ...........................10
	3.2. The Quick-Start Option for IPv6. . . . . . . . . . . . . 21		3.2. The Quick-Start Option for IPv6 ...........................13
	3.3. Processing the Quick-Start Request at		3.3. Processing the Quick-Start Request at Routers .............14
	Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 22		3.3.1. Processing the Report of Approved Rate .............15
	3.3.1. Processing the Report of Approved		3.4. The QS Nonce ..............................................16
	Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 23		4. The Quick-Start Mechanisms in TCP ..............................18
	3.4. The QS Nonce . . . . . . . . . . . . . . . . . . . . . . 24		4.1. Sending the Quick-Start Request ...........................19
	4. The Quick-Start Mechanisms in TCP . . . . . . . . . . . . . . 26		4.2. The Quick-Start Response Option in the TCP header .........20
	4.1. Sending the Quick-Start Request. . . . . . . . . . . . . 27		4.3. TCP: Sending the Quick-Start Response .....................21
	4.2. The Quick-Start Response Option in the TCP		4.4. TCP: Receiving and Using the Quick-Start Response Packet ..22
	header. . . . . . . . . . . . . . . . . . . . . . . . . . . . 28		4.5. TCP: Controlling Acknowledgement Traffic on the
	4.3. TCP: Sending the Quick-Start Response. . . . . . . . . . 29		Reverse Path ..............................................24
	4.4. TCP: Receiving and Using the Quick-Start		4.6. TCP: Responding to a Loss of a Quick-Start Packet .........26
	Response Packet . . . . . . . . . . . . . . . . . . . . . . . 30		4.7. TCP: A Quick-Start Request for a Larger Initial Window ....26
	4.5. TCP: Controlling Acknowledgement Traffic on		4.7.1. Interactions with Path MTU Discovery ...............26
	the Reverse Path . . . . . . . . . . . . . . . . . . . . . . 32
	4.6. TCP: Responding to a Loss of a Quick-Start
	Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
	4.7. TCP: A Quick-Start Request for a Larger Ini-
	tial Window . . . . . . . . . . . . . . . . . . . . . . . . . 34
	4.7.1. Interactions with Path MTU Discovery. . . . . . . . 34
	4.7.2. Quick-Start Request Packets that are		4.7.2. Quick-Start Request Packets that are
	Discarded by Routers or Middleboxes. . . . . . . . . . . . 35		Discarded by Routers or Middleboxes ................27
	4.8. TCP: A Quick-Start Request in the Middle of		4.8. TCP: A Quick-Start Request in the Middle of a Connection ..28
	a Connection. . . . . . . . . . . . . . . . . . . . . . . . . 36		4.9. An Example Quick-Start Scenario with TCP ..................29
	4.9. An Example Quick-Start Scenario with TCP . . . . . . . . 37		5. Quick-Start and IPsec AH .......................................30
	5. Quick-Start and IPsec AH. . . . . . . . . . . . . . . . . . . 38		6. Quick-Start in IP Tunnels and MPLS .............................31
	6. Quick-Start in IP Tunnels and MPLS. . . . . . . . . . . . . . 39		6.1. Simple Tunnels that Are Compatible with Quick-Start .......33
	6.1. Simple Tunnels That Are Compatible with		6.1.1. Simple Tunnels that Are Aware of Quick-Start .......33
	Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 41		6.2. Simple Tunnels that Are Not Compatible with Quick-Start ...34
	6.1.1. Simple Tunnels that are Aware of Quick-		6.3. Tunnels That Support Quick-Start ..........................35
	Start. . . . . . . . . . . . . . . . . . . . . . . . . . . 41		6.4. Quick-Start and MPLS ......................................35
	6.2. Simple Tunnels That Are Not Compatible with		7. The Quick-Start Mechanism in Other Transport Protocols .........36
	Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 42		8. Using Quick-Start ..............................................37
	6.3. Tunnels That Support Quick-Start . . . . . . . . . . . . 43		8.1. Determining the Rate to Request ...........................37
	6.4. Quick-Start and MPLS . . . . . . . . . . . . . . . . . . 44		8.2. Deciding the Permitted Rate Request at a Router ...........37
	7. The Quick-Start Mechanism in other Transport Pro-		9. Evaluation of Quick-Start ......................................38
	tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44		9.1. Benefits of Quick-Start ...................................38
	8. Using Quick-Start . . . . . . . . . . . . . . . . . . . . . . 45		9.2. Costs of Quick-Start ......................................39
	8.1. Determining the Rate to Request. . . . . . . . . . . . . 45		9.3. Quick-Start with QoS-Enabled Traffic ......................41
	8.2. Deciding the Permitted Rate Request at a		9.4. Protection against Misbehaving Nodes ......................41
	Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . 45		9.4.1. Misbehaving Senders ................................41
	9. Evaluation of Quick-Start . . . . . . . . . . . . . . . . . . 46		9.4.2. Receivers Lying about Whether the Request
	9.1. Benefits of Quick-Start. . . . . . . . . . . . . . . . . 46		was Approved .......................................43
	9.2. Costs of Quick-Start . . . . . . . . . . . . . . . . . . 47		9.4.3. Receivers Lying about the Approved Rate ............43
	9.3. Quick-Start with QoS-enabled Traffic . . . . . . . . . . 49		9.4.4. Collusion between Misbehaving Routers ..............44
	9.4. Protection against Misbehaving Nodes . . . . . . . . . . 49		9.5. Misbehaving Middleboxes and the IP TTL ....................46
	9.4.1. Misbehaving Senders . . . . . . . . . . . . . . . . 49		9.6. Attacks on Quick-Start ....................................46
	9.4.2. Receivers Lying about Whether the		9.7. Simulations with Quick-Start ..............................47
	Request was Approved . . . . . . . . . . . . . . . . . . . 51		10. Implementation and Deployment Issues ..........................47
	9.4.3. Receivers Lying about the Approved		10.1. Implementation Issues for Sending Quick-Start Requests ...47
	Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 52		10.2. Implementation Issues for Processing Quick-Start
	9.4.4. Collusion between Misbehaving Routers . . . . . . . 53		Requests .................................................48
	9.5. Misbehaving Middleboxes and the IP TTL . . . . . . . . . 54		10.3. Possible Deployment Scenarios ............................48
	9.6. Attacks on Quick-Start . . . . . . . . . . . . . . . . . 54		10.4. A Comparison with the Deployment Problems of ECN .........50
	9.7. Simulations with Quick-Start . . . . . . . . . . . . . . 55		11. Security Considerations .......................................50
	10. Implementation and Deployment Issues . . . . . . . . . . . . 55		12. IANA Considerations ...........................................52
	10.1. Implementation Issues for Sending Quick-		12.1. IP Option ................................................52
	Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 56		12.2. TCP Option ...............................................52
	10.2. Implementation Issues for Processing Quick-		13. Conclusions ...................................................53
	Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 56		14. Acknowledgements ..............................................53
	10.3. Possible Deployment Scenarios . . . . . . . . . . . . . 57		Appendix A. Related Work ..........................................54
	10.4. A Comparison with the Deployment Problems		A.1. Fast Start-Ups without Explicit Information from Routers ..54
	of ECN. . . . . . . . . . . . . . . . . . . . . . . . . . . . 58		A.2. Optimistic Sending without Explicit Information from
	11. Security Considerations. . . . . . . . . . . . . . . . . . . 58		Routers ...................................................56
	12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 60		A.3. Fast Start-Ups with Other Information from Routers ........56
	12.1. IP Option . . . . . . . . . . . . . . . . . . . . . . . 60		A.4. Fast Start-Ups with More Fine-Grained Feedback from
	12.2. TCP Option. . . . . . . . . . . . . . . . . . . . . . . 60		Routers ...................................................57
	13. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . 61		A.5. Fast Start-ups with Lower-Than-Best-Effort Service ........58
	14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 61		Appendix B. Design Decisions ......................................59
	A. Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 62		B.1. Alternate Mechanisms for the Quick-Start Request:
	A.1. Fast Start-ups without Explicit Information		ICMP and RSVP .............................................59
	from Routers. . . . . . . . . . . . . . . . . . . . . . . . . 62		B.1.1. ICMP ...............................................59
	A.2. Optimistic Sending without Explicit Informa-		B.1.2. RSVP ...............................................60
	tion from Routers . . . . . . . . . . . . . . . . . . . . . . 64		B.2. Alternate Encoding Functions ..............................61
	A.3. Fast Start-ups with other Information from		B.3. The Quick-Start Request: Packets or Bytes? ................63
	Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 65		B.4. Quick-Start Semantics: Total Rate or Additional Rate? .....64
	A.4. Fast Start-ups with more Fine-Grained Feed-		B.5. Alternate Responses to the Loss of a Quick-Start Packet ...65
	back from Routers . . . . . . . . . . . . . . . . . . . . . . 65		B.6. Why Not Include More Functionality? .......................66
	A.5. Fast Start-ups with Lower-Than-Best-Effort		B.7. Alternate Implementations for a Quick-Start Nonce .........69
	Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 66		B.7.1. An Alternate Proposal for the Quick-Start Nonce ....69
	B. Design Decisions. . . . . . . . . . . . . . . . . . . . . . . 66		B.7.2. The Earlier Request-Approved Quick-Start Nonce .....69
	B.1. Alternate Mechanisms for the Quick-Start		Appendix C. Quick-Start with DCCP .................................70
	Request: ICMP and RSVP. . . . . . . . . . . . . . . . . . . . 67		Appendix D. Possible Router Algorithm .............................72
	B.1.1. ICMP. . . . . . . . . . . . . . . . . . . . . . . . 67		Appendix E. Possible Additional Uses for the Quick-Start ..........74
	B.1.2. RSVP. . . . . . . . . . . . . . . . . . . . . . . . 68		Normative References ..............................................75
	B.2. Alternate Encoding Functions . . . . . . . . . . . . . . 69		Informative References ............................................75
	B.3. The Quick-Start Request: Packets or Bytes? . . . . . . . 71
	B.4. Quick-Start Semantics: Total Rate or Addi-
	tional Rate?. . . . . . . . . . . . . . . . . . . . . . . . . 72
	B.5. Alternate Responses to the Loss of a Quick-
	Start Packet. . . . . . . . . . . . . . . . . . . . . . . . . 73
	B.6. Why Not Include More Functionality?. . . . . . . . . . . 74
	B.7. Alternate Implementations for a Quick-Start
	Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
	B.7.1. An Alternate Proposal for the Quick-
	Start Nonce. . . . . . . . . . . . . . . . . . . . . . . . 77
	B.7.2. The Earlier Request-Approved Quick-
	Start Nonce. . . . . . . . . . . . . . . . . . . . . . . . 78
	C. Quick-Start with DCCP . . . . . . . . . . . . . . . . . . . . 79
	D. Possible Router Algorithm . . . . . . . . . . . . . . . . . . 80
	E. Possible Additional Uses for the Quick-Start
	Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
	Normative References . . . . . . . . . . . . . . . . . . . . . . 83
	Informative References . . . . . . . . . . . . . . . . . . . . . 84
	AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 89
	Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 90
	Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 90
	1. Introduction		1. Introduction
	Each connection begins with a question: "What is the appropriate		Each connection begins with a question: "What is the appropriate
	sending rate for the current network path?" The question is not		sending rate for the current network path?" The question is not
	answered explicitly, but each TCP connection determines the sending		answered explicitly, but each TCP connection determines the sending
	rate by probing the network path and altering the congestion window		rate by probing the network path and altering the congestion window
	(cwnd) based on perceived congestion. Each TCP connection starts		(cwnd) based on perceived congestion. Each TCP connection starts
	with a pre-configured initial congestion window (ICW). Currently,		with a pre-configured initial congestion window (ICW). Currently,
	TCP allows an initial window of between one and four MSS-sized		TCP allows an initial window of between one and four segments of
	segments ([RFC2581], [RFC3390]). The TCP connection then probes the		maximum segment size (MSS) ([RFC2581], [RFC3390]). The TCP
	network for available bandwidth using the slow-start procedure		connection then probes the network for available bandwidth using the
	([Jac88], [RFC2581]), doubling cwnd during each congestion-free		slow-start procedure ([Jac88], [RFC2581]), doubling cwnd during each
	round-trip time (RTT).		congestion-free round-trip time (RTT).
	The slow-start algorithm can be time-consuming --- especially over		The slow-start algorithm can be time-consuming --- especially over
	networks with large bandwidth or long delays. It may take a number		networks with large bandwidth or long delays. It may take a number
	of RTTs in slow-start before the TCP connection begins to fully use		of RTTs in slow-start before the TCP connection begins to fully use
	the available bandwidth of the network. For instance, it takes		the available bandwidth of the network. For instance, it takes
	log_2(N) - 2 round-trip times to build cwnd up to N segments,		log_2(N) - 2 round-trip times to build cwnd up to N segments,
	assuming an initial congestion window of 4 segments. This time in		assuming an initial congestion window of 4 segments. This time in
	slow-start is not a problem for large file transfers, where the		slow-start is not a problem for large file transfers, where the
	slow-start stage is only a fraction of the total transfer time.		slow-start stage is only a fraction of the total transfer time.
	However, in the case of moderate-sized transfers the connection		However, in the case of moderate-sized transfers, the connection
	might carry out its entire transfer in the slow-start phase, taking		might carry out its entire transfer in the slow-start phase, taking
	many round-trip times, where one or two RTTs might have been		many round-trip times, where one or two RTTs might have been
	sufficient when using the currently available bandwidth along the		sufficient when using the currently available bandwidth along the
	path.		path.
	A fair amount of work has already been done to address the issue of		A fair amount of work has already been done to address the issue of
	choosing the initial congestion window for TCP, with RFC 3390		choosing the initial congestion window for TCP, with RFC 3390
	allowing an initial window of up to four segments based on the MSS		allowing an initial window of up to four segments based on the MSS
	used by the connection [RFC3390]. Our underlying premise is that		used by the connection [RFC3390]. Our underlying premise is that
	explicit feedback from all of the routers along the path would be		explicit feedback from all the routers along the path would be
	required, in the current architecture, for best-effort connections		required, in the current architecture, for best-effort connections to
	to use initial windows significantly larger than those allowed by		use initial windows significantly larger than those allowed by
	[RFC3390], in the absence of other information about the path.		[RFC3390], in the absence of other information about the path.
	In using Quick-Start, a TCP host, say, host A, would indicate its		In using Quick-Start, a TCP host (say, host A) would indicate its
	desired sending rate in bytes per second, using a Quick-Start option		desired sending rate in bytes per second, using a Quick-Start Option
	in the IP header of a TCP packet. Each router along the path could,		in the IP header of a TCP packet. Each router along the path could,
	in turn, either approve the requested rate, reduce the requested		in turn, either approve the requested rate, reduce the requested
	rate, or indicate that the Quick-Start request is not approved. (We		rate, or indicate that the Quick-Start Request is not approved. (We
	note that the `routers' referred to in this document also include		note that the `routers' referred to in this document also include the
	the IP-layer processing of the Quick-Start request at the sender.)		IP-layer processing of the Quick-Start Request at the sender.) In
	In approving a Quick-Start request, a router does not give		approving a Quick-Start Request, a router does not give preferential
	preferential treatment to subsequent packets from that connection;		treatment to subsequent packets from that connection; the router is
	the router is only asserting that it is currently underutilized and		only asserting that it is currently underutilized and believes there
	believes there is sufficient available bandwidth to accommodate the		is sufficient available bandwidth to accommodate the sender's
	sender's requested rate. The Quick-Start mechanism can determine if		requested rate. The Quick-Start mechanism can determine if there are
	there are routers along the path that do not understand the Quick-		routers along the path that do not understand the Quick-Start Option,
	Start option, or have not agreed to the Quick-Start rate request.		or have not agreed to the Quick-Start rate request. TCP host B
	TCP host B communicates the final rate request to TCP host A in a		communicates the final rate request to TCP host A in a transport-
	transport-level Quick-Start Response in an answering TCP packet.		level Quick-Start Response in an answering TCP packet.
	If the Quick-Start request is approved by all routers along the		If the Quick-Start Request is approved by all routers along the path,
	path, then the TCP host can send at up to the approved rate for a		then the TCP host can send at up to the approved rate for a window of
	window of data. Subsequent transmissions will be governed by the		data. Subsequent transmissions will be governed by the default TCP
	default TCP congestion control mechanisms of that connection. If		congestion control mechanisms of that connection. If the Quick-Start
	the Quick-Start request is not approved, then the sender would use		Request is not approved, then the sender would use the default
	the default congestion control mechanisms.		congestion control mechanisms.
	Quick-Start would not be the first mechanism for explicit		Quick-Start would not be the first mechanism for explicit
	communication from routers to transport protocols about sending		communication from routers to transport protocols about sending
	rates. Explicit Congestion Notification (ECN) gives explicit		rates. Explicit Congestion Notification (ECN) gives explicit
	congestion control feedback from routers to transport protocols,		congestion control feedback from routers to transport protocols,
	based on the router detecting congestion before buffer overflow		based on the router detecting congestion before buffer overflow
	[RFC3168]. In contrast, routers would not use Quick-Start to give		[RFC3168]. In contrast, routers would not use Quick-Start to give
	congestion information, but instead would use Quick-Start as an		congestion information, but instead would use Quick-Start as an
	optional mechanism to give permission to transport protocols to use		optional mechanism to give permission to transport protocols to use
	higher sending rates, based on the ability of all the routers along		higher sending rates, based on the ability of all the routers along
	the path to determine if their respective output links are		the path to determine if their respective output links are
	significantly underutilized.		significantly underutilized.
	Section 2 gives an overview of Quick-Start. The formal		Section 2 gives an overview of Quick-Start. The formal
	specifications for Quick-Start are contained in Sections 3, 4,		specifications for Quick-Start are contained in Sections 3, 4, 6.1.1,
	6.1.1, and 6.3. In particular, Quick-Start is specified for IPv4		and 6.3. In particular, Quick-Start is specified for IPv4 and for
	and for IPv6 in Section 3, and is specified for TCP in Section 4.		IPv6 in Section 3, and is specified for TCP in Section 4. Section 6
	Section 6 consists mostly of a non-normative discussion of		consists mostly of a non-normative discussion of interactions of
	interactions of Quick-Start with IP tunnels and MPLS; however,		Quick-Start with IP tunnels and MPLS; however, Section 6.1.1 and 6.3
	Section 6.1.1 and 6.3 specify behavior for IP tunnels that are aware		specify behavior for IP tunnels that are aware of Quick-Start.
	of Quick-Start.
	The rest of the document is non-normative, as follows. Section 5		The rest of the document is non-normative, as follows. Section 5
	shows that Quick-Start is compatible with IPsec AH (Authentication		shows that Quick-Start is compatible with IPsec AH (Authentication
	Header). Section 7 gives a non-normative set of guidelines for		Header). Section 7 gives a non-normative set of guidelines for
	specifying Quick-Start in other transport protocols, and Section 8		specifying Quick-Start in other transport protocols, and Section 8
	discusses using Quick-Start in transport end-nodes and in routers.		discusses using Quick-Start in transport end-nodes and routers.
	Section 9 gives an evaluation of the costs and benefits of Quick-		Section 9 gives an evaluation of the costs and benefits of Quick-
	Start, and Section 10 discusses implementation and deployment		Start, and Section 10 discusses implementation and deployment issues.
	issues. The appendices discuss related work, Quick-Start design		The appendices discuss related work, Quick-Start design decisions,
	decisions, and possible router algorithms.		and possible router algorithms.
	1.1. Conventions and Terminology		1.1. Conventions and Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Assumptions and General Principles		2. Assumptions and General Principles
	This section describes the assumptions and general principles behind		This section describes the assumptions and general principles behind
	the design of the Quick-Start mechanism.		the design of the Quick-Start mechanism.
	Assumptions:		Assumptions:
	* The data transfer in the two directions of a connection traverses		* The data transfer in the two directions of a connection traverses
	different queues, and possibly even different routers. Thus, any		different queues, and possibly even different routers. Thus, any
	mechanism for determining the allowed sending rate would have to be		mechanism for determining the allowed sending rate would have to be
	used independently for each direction.		used independently for each direction.
	* The path between the two endpoints is relatively stable, such that		* The path between the two endpoints is relatively stable, such that
	the path used by the Quick-Start request is generally the same path		the path used by the Quick-Start Request is generally the same path
	used by the Quick-Start packets one round-trip time later. [ZDPS01]		used by the Quick-Start packets one round-trip time later.
	shows this assumption should be generally valid. However, [RFC3819]		[ZDPS01] shows this assumption should be generally valid. However,
	discusses a range of Bandwidth on Demand subnets that could cause		[RFC3819] discusses a range of Bandwidth on Demand subnets that
	the characteristics of the path to change over time.		could cause the characteristics of the path to change over time.
	* Any new mechanism must be incrementally deployable, and might not		* Any new mechanism must be incrementally deployable and might not be
	be supported by all of the routers and/or end-hosts. Thus, any new		supported by all the routers and/or end-hosts. Thus, any new
	mechanism must be able to accommodate non-supporting routers or end-		mechanism must be able to accommodate non-supporting routers or
	hosts without disturbing the current Internet semantics. We note		end-hosts without disturbing the current Internet semantics. We
	that while Quick-Start is incrementally deployable in this sense, a		note that, while Quick-Start is incrementally deployable in this
	Quick-Start request cannot be approved for a particular connection		sense, a Quick-Start Request cannot be approved for a particular
	unless both end-nodes and all of the routers along the path have		connection unless both end-nodes and all the routers along the path
	been configured to support Quick-Start.		have been configured to support Quick-Start.
	General Principles:		General Principles:
	* Our underlying premise is that explicit feedback from all of the		* Our underlying premise is that explicit feedback from all the
	routers along the path would be required, in the current		routers along the path would be required, in the current
	architecture, for best-effort connections to use initial windows		architecture, for best-effort connections to use initial windows
	significantly larger than those allowed by [RFC3390], in the absence		significantly larger than those allowed by [RFC3390], in the
	of other information about the path.		absence of other information about the path.
	* A router should only approve a Quick-Start request if the output		* A router should only approve a Quick-Start Request if the output
	link is underutilized. Any other approach will result in either		link is underutilized. Any other approach will result in either
	per-flow state at the router, or the possibility of a (possibly		per-flow state at the router, or the possibility of a (possibly
	transient) queue at the router.		transient) queue at the router.
	* No per-flow state should be required at the router. Note that		* No per-flow state should be required at the router. Note that,
	while per-flow state is not required, we also do not preclude a		while per-flow state is not required, we also do not preclude a
	router from storing per-flow state for making Quick-Start decisions		router from storing per-flow state for making Quick-Start decisions
	or for checking for misbehaving nodes.		or for checking for misbehaving nodes.
	2.1. Overview of Quick-Start		2.1. Overview of Quick-Start
	In this section we give an overview of the use of Quick-Start with		In this section, we give an overview of the use of Quick-Start with
	TCP to request a higher congestion window. The description in this		TCP to request a higher congestion window. The description in this
	section is non-normative; the normative description of Quick-Start		section is non-normative; the normative description of Quick-Start
	with IP and TCP follows in Sections 3 and 4. Quick-Start could be		with IP and TCP follows in Sections 3 and 4. Quick-Start could be
	used in the middle of a connection, e.g., after an idle or		used in the middle of a connection, e.g., after an idle or
	underutilized period, as well as for the initial sending rate; these		underutilized period, as well as for the initial sending rate; these
	uses of Quick-Start are discussed later in the document.		uses of Quick-Start are discussed later in the document.
	Quick-Start requires end-points and routers to work together, with		Quick-Start requires end-points and routers to work together, with
	end-points requesting a higher sending rate in the Quick-Start (QS)		end-points requesting a higher sending rate in the Quick-Start (QS)
	option in IP, and routers along the path approving, modifying,		option in IP, and routers along the path approving, modifying,
	discarding or ignoring (and therefore disallowing) the Quick-Start		discarding, or ignoring (and therefore disallowing) the Quick-Start
	Request. The receiver uses reliable, transport-level mechanisms to		Request. The receiver uses reliable, transport-level mechanisms to
	inform the sender of the status of the Quick-Start Request. For		inform the sender of the status of the Quick-Start Request. For
	example, when TCP is used, the TCP receiver sends feedback to the		example, when TCP is used, the TCP receiver sends feedback to the
	sender using a Quick-Start Response option in the TCP header. In		sender using a Quick-Start Response option in the TCP header. In
	addition, Quick-Start assumes a unicast, congestion-controlled		addition, Quick-Start assumes a unicast, congestion-controlled
	transport protocol; we do not consider the use of Quick-Start for		transport protocol; we do not consider the use of Quick-Start for
	multicast traffic.		multicast traffic.
	When sent as a request, the Quick-Start Option includes a request		When sent as a request, the Quick-Start Option includes a request for
	for a sending rate in bits per second, and a Quick-Start TTL (QS		a sending rate in bits per second, and a Quick-Start Time to Live (QS
	TTL) to be decremented by every router along the path that		TTL) to be decremented by every router along the path that
	understands the option and approves the request. The Quick-Start		understands the option and approves the request. The Quick-Start TTL
	TTL is initialized by the sender to a random value. The transport		is initialized by the sender to a random value. The transport
	receiver returns the rate, information about the TTL and the Quick-		receiver returns the rate, information about the TTL, and the Quick-
	Start Nonce to the sender using transport-level mechanisms; for TCP,		Start Nonce to the sender using transport-level mechanisms; for TCP,
	the receiver sends this information in the Quick-Start Response in		the receiver sends this information in the Quick-Start Response in
	the TCP header. In particular, the receiver computes the difference		the TCP header. In particular, the receiver computes the difference
	between the Quick-Start TTL and the IP TTL (the TTL in the IP		between the Quick-Start TTL and the IP TTL (the TTL in the IP header)
	header) of the Quick-Start request packet, and returns this in the		of the Quick-Start Request packet, and returns this in the Quick-
	Quick-Start response. The sender uses the TTL difference to		Start Response. The sender uses the TTL difference to determine if
	determine if all of the routers along the path decremented the		all the routers along the path decremented the Quick-Start TTL,
	Quick-Start TTL, approving the Quick-Start Request.		approving the Quick-Start Request.
	If the request is approved by all of the routers along the path,		If the request is approved by all the routers along the path, then
	then the TCP sender combines this allowed rate with the measurement		the TCP sender combines this allowed rate with the measurement of the
	of the round-trip time, and ends up with an allowed TCP congestion		round-trip time, and ends up with an allowed TCP congestion window.
	window. This window is sent rate-paced over the next round-trip		This window is sent rate-paced over the next round-trip time, or
	time, or until an ACK packet is received.		until an ACK packet is received.
	Figure 1 shows a successful use of Quick-Start, with the sender's IP		Figure 1 shows a successful use of Quick-Start, with the sender's IP
	layer and both routers along the path approving the Quick-Start		layer and both routers along the path approving the Quick-Start
	Request, and the TCP receiver using the Quick-Start Response to		Request, and the TCP receiver using the Quick-Start Response to
	return information to the TCP sender. In this example, Quick-Start		return information to the TCP sender. In this example, Quick-Start
	is used by TCP to establish the initial congestion window.		is used by TCP to establish the initial congestion window.
	Sender Router 1 Router 2 Receiver		Sender Router 1 Router 2 Receiver
	------ -------- -------- --------		------ -------- -------- --------
	| <IP TTL: 63>		| <IP TTL: 63>
	skipping to change at page 16, line 45		skipping to change at page 8, line 39
	| info to sender in		| info to sender in
	| Quick-Start Response		| Quick-Start Response
	| <-- in TCP ACK packet.		| <-- in TCP ACK packet.
	|		|
	| <TTL Diff: 28>		| <TTL Diff: 28>
	| Quick-Start approved,		| Quick-Start approved,
	| translate to cwnd.		| translate to cwnd.
	| Report Approved Rate.		| Report Approved Rate.
	V Send cwnd paced over one RTT. -->		V Send cwnd paced over one RTT. -->
	Figure 1: A successful Quick-Start Request.		Figure 1: A Successful Quick-Start Request.
	Figure 2 shows an unsuccessful use of Quick-Start, with one of the		Figure 2 shows an unsuccessful use of Quick-Start, with one of the
	routers along the path not approving the Quick-Start Request. If		routers along the path not approving the Quick-Start Request. If the
	the Quick-Start Request is not approved, then the sender uses the		Quick-Start Request is not approved, then the sender uses the default
	default congestion control mechanisms for that transport protocol,		congestion control mechanisms for that transport protocol, including
	including the default initial congestion window, response to idle		the default initial congestion window, response to idle periods, etc.
	periods, etc.
	Sender Router 1 Router 2 Receiver		Sender Router 1 Router 2 Receiver
	------ -------- -------- --------		------ -------- -------- --------
	| <IP TTL: 63>		| <IP TTL: 63>
	| <QS TTL: 91>		| <QS TTL: 91>
	| <TTL Diff: 28>		| <TTL Diff: 28>
	| Quick-Start Request		| Quick-Start Request
	| in SYN or SYN/ACK.		| in SYN or SYN/ACK.
	| IP: Decrement QS TTL		| IP: Decrement QS TTL
	| to approve request -->		| to approve request -->
	skipping to change at page 17, line 36		skipping to change at page 9, line 34
	| <IP TTL: 60>		| <IP TTL: 60>
	| <QS TTL: 89>		| <QS TTL: 89>
	| <TTL Diff: 29>		| <TTL Diff: 29>
	| Return Quick-Start		| Return Quick-Start
	| info to sender in		| info to sender in
	| Quick-Start Response		| Quick-Start Response
	| <-- in TCP ACK packet.		| <-- in TCP ACK packet.
	|		|
	| <TTL Diff: 29>		| <TTL Diff: 29>
	| Quick-Start not approved.		| Quick-Start not approved.
	| Report Approved Rate.		| Report approved rate.
	V Use default initial cwnd. -->		V Use default initial cwnd. -->
	Figure 2: An unsuccessful Quick-Start Request.		Figure 2: An Unsuccessful Quick-Start Request.
	3. The Quick-Start Option in IP		3. The Quick-Start Option in IP
	3.1. The Quick-Start Option for IPv4		3.1. The Quick-Start Option for IPv4
	The Quick-Start Request for IPv4 is defined as follows:		The Quick-Start Request for IPv4 is defined as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Option | Length=8 | Func. | Rate | QS TTL |		| Option | Length=8 | Func. | Rate | QS TTL |
	| | | 0000 |Request| |		| | | 0000 |Request| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| QS Nonce | R |		| QS Nonce | R |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3. The Quick-Start Option for IPv4.		Figure 3: The Quick-Start Option for IPv4.
	A Quick-Start Request.		A Quick-Start Request.
	The first byte contains the option field, which includes the one-bit		The first byte contains the option field, which includes the one-bit
	copy flag, the 2-bit class field, and the 5-bit option number (to be		copy flag, the 2-bit class field, and the 5-bit option number.
	assigned by IANA).
	The second byte contains the length field, indicating an option		The second byte contains the length field, indicating an option
	length of eight bytes.		length of eight bytes.
	The third byte includes a four-bit Function field. If the Function		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		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-		Request. In this case, the second half of the third byte is a four-
	bit Rate Request field.		bit Rate Request field.
	For a Rate Request, the fourth byte contains the Quick-Start TTL (QS		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.		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		Routers that approve the Quick-Start Request decrement the QS TTL
	(mod 256) by the same amount that they decrement the IP TTL. (As		(mod 256) by the same amount that they decrement the IP TTL. (As
	elsewhere in this document, we use the term `router' imprecisely to		elsewhere in this document, we use the term `router' imprecisely to
	also include the Quick-Start functionality at the IP layer at the		also include the Quick-Start functionality at the IP layer at the
	sender.) The QS TTL is used by the sender to detect if all of the		sender.) The QS TTL is used by the sender to detect if all the
	routers along the path understood and approved the Quick-Start		routers along the path understood and approved the Quick-Start
	option.		option.
	For a Rate Request, the transport sender MUST calculate and store		For a Rate Request, the transport sender MUST calculate and store the
	the TTL Diff, the difference between the IP TTL value and the QS TTL		TTL Diff, the difference between the IP TTL value, and the QS TTL
	value in the Quick-Start request packet, as follows:		value in the Quick-Start Request packet, as follows:
	TTL Diff = ( IP TTL - QS TTL ) mod 256 (1)		TTL Diff = ( IP TTL - QS TTL ) mod 256 (1)
			For a Rate Request, bytes 5-8 contain a 30-bit QS Nonce, discussed in
	For a Rate Request, bytes 5-8 contain a 30-bit QS Nonce, discussed		Section 3.4, and a two-bit Reserved field. The sender SHOULD set the
	in Section 3.4, and a two-bit Reserved field. The sender SHOULD set		reserved field to zero, and routers and receivers SHOULD ignore the
	the reserved field to zero, and routers and receivers SHOULD ignore		reserved field. The sender SHOULD set the 30-bit QS Nonce to a
	the reserved field. The sender SHOULD set the 30-bit QS Nonce to a
	random value.		random value.
	The sender initializes the Rate Request to the desired sending rate,		The sender initializes the Rate Request to the desired sending rate,
	including an estimate of the transport and IP header overhead. The		including an estimate of the transport and IP header overhead. The
	encoding function for the Rate Request sets the request rate to		encoding function for the Rate Request sets the request rate to K*2^N
	K*2^N bps (bits per second), for N the value in the Rate Request		bps (bits per second), for N the value in the Rate Request field, and
	field, and for K set to 40,000. For N=0, the rate request would be		for K set to 40,000. For N=0, the rate request would be set to zero,
	set to zero, regardless of the encoding function. This is		regardless of the encoding function. This is illustrated in Table 1
	illustrated in Table 1 below. For the four-bit Rate Request field,		below. For the four-bit Rate Request field, the request range is
	the request range is from 80 Kbps to 1.3 Gbps. Alternate encodings		from 80 Kbps to 1.3 Gbps. Alternate encodings that were considered
	that were considered for the Rate Request are given in Appendix B.2.		for the Rate Request are given in Appendix B.2.
	N Rate Request (in Kbps)		N Rate Request (in Kbps)
	--- -------------------		--- ----------------------
	0 0		0 0
	1 80		1 80
	2 160		2 160
	3 320		3 320
	4 640		4 640
	5 1,280		5 1,280
	6 2,560		6 2,560
	7 5,120		7 5,120
	8 10,240		8 10,240
	9 20,480		9 20,480
	10 40,960		10 40,960
	11 81,920		11 81,920
	12 163,840		12 163,840
	13 327,680		13 327,680
	14 655,360		14 655,360
	15 1,310,720		15 1,310,720
	Table 1: Mapping from Rate Request field to rate request in Kbps.		Table 1: Mapping from Rate Request Field to Rate Request in Kbps.
	Routers can approve the Quick-Start Request for a lower rate by		Routers can approve the Quick-Start Request for a lower rate by
	decreasing the Rate Request in the Quick-Start Request. Section 4.2		decreasing the Rate Request in the Quick-Start Request. Section 4.2
	discusses the Quick-Start Response from the TCP receiver to the TCP		discusses the Quick-Start Response from the TCP receiver to the TCP
	sender, and Section 4.4 discusses the TCP sender's mechanism for		sender, and Section 4.4 discusses the TCP sender's mechanism for
	determining if a Quick-Start Request has been approved.		determining if a Quick-Start Request has been approved.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Option | Length=8 | Func. | Rate | Not Used |		| Option | Length=8 | Func. | Rate | Not Used |
	| | | 1000 | Report| |		| | | 1000 | Report| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| QS Nonce | R |		| QS Nonce | R |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4. The Quick-Start Option for IPv4.		Figure 4: The Quick-Start Option for IPv4.
	Report of Approved Rate.		Report of Approved Rate.
	If the Function field in the third byte of the Quick-Start Option is		If the Function field in the third byte of the Quick-Start Option is
	set to "1000", then the Quick-Start Option is a Report of Approved		set to "1000", then the Quick-Start Option is a Report of Approved
	Rate. In this case the second four bits in the third byte are the		Rate. In this case, the second four bits in the third byte are the
	Rate Report field, formatted exactly as in the Rate Request field in		Rate Report field, formatted exactly as in the Rate Request field in
	a Rate Request. For a Report of Approved Rate, the fourth byte of		a Rate Request. For a Report of Approved Rate, the fourth byte of
	the Quick-Start Option are not used. Bytes 5-8 contain a 30-bit QS		the Quick-Start Option is not used. Bytes 5-8 contain a 30-bit QS
	Nonce and a two- bit Reserved field.		Nonce and a 2-bit Reserved field.
	After an approved Rate Request, the sender MUST report the Approved		After an approved Rate Request, the sender MUST report the Approved
	Rate, using a Quick-Start Option configured as a Report of Approved		Rate, using a Quick-Start Option configured as a Report of Approved
	Rate with the Rate Report field set to the approved rate, and the QS		Rate with the Rate Report field set to the approved rate, and the QS
	Nonce set to the QS Nonce sent in the Quick-Start Request. The		Nonce set to the QS Nonce sent in the Quick-Start Request. The
	packet containing the Report of Approved Rate MUST be either a		packet containing the Report of Approved Rate MUST be either a
	control packet sent before the first Quick-Start data packet, or a		control packet sent before the first Quick-Start data packet, or a
	Quick-Start Option in the first data packet itself. The Report of		Quick-Start Option in the first data packet itself. The Report of
	Approved Rate does not have to be sent reliably; for example, if the		Approved Rate does not have to be sent reliably; for example, if the
	approved rate is reported in a separate control packet, the sender		approved rate is reported in a separate control packet, the sender
	does not necessarily know if the control packet has been dropped in		does not necessarily know if the control packet has been dropped in
	the network. If the packet contained the Quick-Start Request is		the network. If the packet containing the Quick-Start Request is
	acknowledged, but the acknowledgement packet does not contain a		acknowledged, but the acknowledgement packet does not contain a
	Quick-Start Response, then the sender MUST assume that the Quick-		Quick-Start Response, then the sender MUST assume that the Quick-
	Start Request was denied, and set a Report of Approved Rate with a		Start Request was denied, and set a Report of Approved Rate with a
	rate of zero. Routers may choose to ignore the Report of Approved		rate of zero. Routers may choose to ignore the Report of Approved
	Rate, or to use the Report of Approved Rate but ignore the QS Nonce.		Rate, or to use the Report of Approved Rate but ignore the QS Nonce.
	Alternately, some routers that use the Report of Approved Rate may		Alternately, some routers that use the Report of Approved Rate may
	choose to match the QS Nonce, masked by the approved rate, with the		choose to match the QS Nonce, masked by the approved rate, with the
	QS Nonce seen in the original request.		QS Nonce seen in the original request.
	If the Rate Request is denied, the sender MUST send a Report of		If the Rate Request is denied, the sender MUST send a Report of
	Approved Rate with the Rate Report field set to zero.		Approved Rate with the Rate Report field set to zero.
	We note that unlike a Quick-Start Request sent at the beginning of a		We note that, unlike a Quick-Start Request sent at the beginning of a
	connection, when a Quick-Start Request is sent in the middle of a		connection, when a Quick-Start Request is sent in the middle of a
	connection, the connection could already have an established		connection, the connection could already have an established
	congestion window or sending rate. The Rate Request is the		congestion window or sending rate. The Rate Request is the requested
	requested total rate for the connection, including the current rate		total rate for the connection, including the current rate of the
	of the connection; the Rate Request is *not* a request for an		connection; the Rate Request is *not* a request for an additional
	additional sending rate over and above the current sending rate. If		sending rate over and above the current sending rate. If the Rate
	the Rate Request is denied, or lowered to a value below the		Request is denied, or lowered to a value below the connection's
	connection's current sending rate, then the sender ignores the		current sending rate, then the sender ignores the request, and
	request, and reverts to the default congestion control mechanisms of		reverts to the default congestion control mechanisms of the transport
	the transport protocol.		protocol.
	The use of the Quick-Start Option does not require the additional		The use of the Quick-Start Option does not require the additional use
	use of the Router Alert Option [RFC2113].		of the Router Alert Option [RFC2113].
	We note that in IPv4, a change in IP options at routers requires		We note that in IPv4, a change in IP options at routers requires
	recalculating the IP header checksum.		recalculating the IP header checksum.
	3.2. The Quick-Start Option for IPv6		3.2. The Quick-Start Option for IPv6
	The Quick-Start Option for IPv6 is placed in the Hop-by-Hop Options		The Quick-Start Option for IPv6 is placed in the Hop-by-Hop Options
	extension header that is processed at every network node along the		extension header that is processed at every network node along the
	communication path [RFC2460]. The option format following the		communication path [RFC2460]. The option format following the
	generic Hop-by-Hop Options header is identical to the IPv4 format,		generic Hop-by-Hop Options header is identical to the IPv4 format,
	skipping to change at page 21, line 36		skipping to change at page 13, line 35
	instead of 8 bytes.		instead of 8 bytes.
	For a Quick-Start Request, the transport receiver compares the		For a Quick-Start Request, the transport receiver compares the
	Quick-Start TTL with the IPv6 Hop Limit field to calculate the TTL		Quick-Start TTL with the IPv6 Hop Limit field to calculate the TTL
	Diff. (The Hop Limit in IPv6 is the equivalent of the TTL in IPv4.)		Diff. (The Hop Limit in IPv6 is the equivalent of the TTL in IPv4.)
	That is, TTL Diff MUST be calculated and stored as follows:		That is, TTL Diff MUST be calculated and stored as follows:
	TTL Diff = ( IPv6 Hop Limit - QS TTL ) mod 256 (2)		TTL Diff = ( IPv6 Hop Limit - QS TTL ) mod 256 (2)
	Unlike IPv4, modifying or deleting the Quick-Start IPv6 Option does		Unlike IPv4, modifying or deleting the Quick-Start IPv6 Option does
	not require checksum re-calculation, because the IPv6 header does		not require checksum re-calculation, because the IPv6 header does not
	not have a checksum field, and modifying the Quick-Start Request in		have a checksum field, and modifying the Quick-Start Request in the
	the IPv6 Hop-by-Hop options header does not affect the IPv6 pseudo-		IPv6 Hop-by-Hop options header does not affect the IPv6 pseudo-
	header checksum used in upper-layer checksum calculations.		header checksum used in upper-layer checksum calculations.
	Appendix A of RFC 2460 requires that all packets with the same flow		Appendix A of RFC 2460 requires that all packets with the same flow
	label must be originated with the same hop-by-hop header contents,		label must be originated with the same hop-by-hop header contents,
	which would be incompatible with Quick-Start. However, a later IPv6		which would be incompatible with Quick-Start. However, a later IPv6
	flow label specification [RFC3697] updates the use of flow labels in		flow label specification [RFC3697] updates the use of flow labels in
	IPv6 and removes this restriction. Therefore Quick-Start is		IPv6 and removes this restriction. Therefore, Quick-Start is
	compatible with the current IPv6 specifications.		compatible with the current IPv6 specifications.
	3.3. Processing the Quick-Start Request at Routers		3.3. Processing the Quick-Start Request at Routers
	The Quick-Start Request does not report the current sending rate of		The Quick-Start Request does not report the current sending rate of
	the connection sending the request; in the default case of a router		the connection sending the request; in the default case of a router
	(or IP layer implementation at an end-node) that does not maintain		(or IP-layer implementation at an end-node) that does not maintain
	per-flow state, a router makes the conservative assumption that the		per-flow state, a router makes the conservative assumption that the
	flow's current sending rate is zero. Each participating router can		flow's current sending rate is zero. Each participating router can
	either terminate or approve the Quick-Start Request. A router MUST		either terminate or approve the Quick-Start Request. A router MUST
	only approve a Quick-Start request if the output link is		only approve a Quick-Start Request if the output link is
	underutilized, and if the router judges that the output link will		underutilized, and if the router judges that the output link will
	continue to be underutilized if this and earlier approved requests		continue to be underutilized if this and earlier approved requests
	are used by the senders. Otherwise, the router reduces or		are used by the senders. Otherwise, the router reduces or terminates
	terminates the Quick-Start Request.		the Quick-Start Request.
	While the paragraph above defines the *semantics* of approving a		While the paragraph above defines the *semantics* of approving a
	Quick-Start request, this document does not specify the specific		Quick-Start Request, this document does not specify the specific
	algorithms to be used by routers in processing Quick-Start Requests		algorithms to be used by routers in processing Quick-Start Requests
	or Reports. This is similar to RFC 3168, which specifics the		or Reports. This is similar to RFC 3168, which specifics the
	semantics of the ECN codepoints in the IP header, but does not		semantics of the ECN codepoints in the IP header, but does not
	specify specific algorithms for routers to use in deciding when to		specify specific algorithms for routers to use in deciding when to
	drop or mark packets before buffer overflow.		drop or mark packets before buffer overflow.
	A router that wishes to terminate the Quick-Start Request SHOULD		A router that wishes to terminate the Quick-Start Request SHOULD
	either delete the Quick-Start Request from the IP header or zero the		either delete the Quick-Start Request from the IP header or zero the
	QS TTL, QS Nonce, and Rate Request fields. Deleting the Quick-Start		QS TTL, QS Nonce, and Rate Request fields. Deleting the Quick-Start
	Request saves resources because downstream routers will have no		Request saves resources because downstream routers will have no
	option to process, but zeroing the Rate Request field may be more		option to process, but zeroing the Rate Request field may be more
	efficient for routers to implement. As suggested in [B05], future		efficient for routers to implement. As suggested in [B05], future
	additions to Quick-Start could define error codes for routers to		additions to Quick-Start could define error codes for routers to
	insert into the QS Nonce field to report back to the sender the		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		reason that the Quick-Start Request was denied, e.g., that the router
	router is denying all Quick-Start requests at this time, or that		is denying all Quick-Start Requests at this time, or that this
	this router as a matter of policy does not grant Quick-Start		router, as a matter of policy, does not grant Quick-Start requests.
	requests. A router that doesn't understand the Quick-Start option		A router that doesn't understand the Quick-Start Option will simply
	will simply forward the packet with the Quick-Start Request		forward the packet with the Quick-Start Request unchanged (ensuring
	unchanged (ensuring that the TTL Diff will not match and Quick-Start		that the TTL Diff will not match and Quick-Start will not be used).
	will not be used).
	If the participating router has decided to approve the Quick-Start		If the participating router has decided to approve the Quick-Start
	Request, it does the following:		Request, it does the following:
	* The router MUST decrement the QS TTL by the amount the IP TTL is		* The router MUST decrement the QS TTL by the amount the IP TTL is
	decremented (usually one).		decremented (usually one).
	* If the router is only willing to approve a Rate Request less than		* If the router is only willing to approve a Rate Request less than
	that in the Quick-Start Request, then the router replaces the Rate		that in the Quick-Start Request, then the router replaces the Rate
	Request with a smaller value. The router MUST NOT increase the Rate		Request with a smaller value. The router MUST NOT increase the
	Request in the Quick-Start Request. If the router decreases the		Rate Request in the Quick-Start Request. If the router decreases
	Rate Request, the router MUST also modify the QS Nonce, as described		the Rate Request, the router MUST also modify the QS Nonce, as
	in Section 3.4.		described in Section 3.4.
	* In IPv4, the router MUST update the IP header checksum.		* In IPv4, the router MUST update the IP header checksum.
	If the router approves the Quick-Start request, this approval SHOULD		If the router approves the Quick-Start Request, this approval SHOULD
	be taken into account in the router's decision to accept or reject		be taken into account in the router's decision to accept or reject
	subsequent Quick-Start requests (e.g., using a variable that tracks		subsequent Quick-Start Requests (e.g., using a variable that tracks
	the recent aggregate of accepted Quick-Start requests). This		the recent aggregate of accepted Quick-Start Requests). This
	consideration of earlier approved Quick-Start request is necessary		consideration of earlier approved Quick-Start Requests is necessary
	to ensure that the router only approves a Quick-Start request when		to ensure that the router only approves a Quick-Start Request when
	the router judges that the output link will remain underutilized if		the router judges that the output link will remain underutilized if
	this and earlier Quick-Start requests are used by the senders.		this and earlier Quick-Start Requests are used by the senders.
	In addition, the approval of a Quick-Start request SHOULD NOT be		In addition, the approval of a Quick-Start Request SHOULD NOT be used
	used by the router to affect the treatment of the data packets that		by the router to affect the treatment of the data packets that arrive
	arrive from this connection in the next few round-trip times. That		from this connection in the next few round-trip times. That is, the
	is, the approval by the router of a Quick-Start request does not		approval by the router of a Quick-Start Request does not give
	give differential treatment for Quick-Start data packets at that		differential treatment for Quick-Start data packets at that router;
	router; it is only a statement from the router that the router		it is only a statement from the router that the router believes that
	believes that the subsequent Quick-Start data packets from this		the subsequent Quick-Start data packets from this connection will not
	connection will not change the current under-utilized state of the		change the current underutilized state of the router.
	router.
	A non-participating router forwards the Quick-Start Request		A non-participating router forwards the Quick-Start Request
	unchanged, without decrementing the QS TTL. The non-participating		unchanged, without decrementing the QS TTL. The non-participating
	router still decrements the TTL field in the IP header, as is		router still decrements the TTL field in the IP header, as is
	required for all routers [RFC1812]. As a result, the sender will be		required for all routers [RFC1812]. As a result, the sender will be
	able to detect that the Quick-Start Request had not been understood		able to detect that the Quick-Start Request had not been understood
	or approved by all of the routers along the path.		or approved by all of the routers along the path.
	A router that uses multipath routing for packets within a single		A router that uses multipath routing for packets within a single
	connection MUST NOT approve a Quick-Start request. This is		connection MUST NOT approve a Quick-Start Request. This is discussed
	discussed in more detail in Section 9.2.		in more detail in Section 9.2.
	3.3.1. Processing the Report of Approved Rate		3.3.1. Processing the Report of Approved Rate
	If the Quick-Start Option has the Function field set to "1000", then		If the Quick-Start Option has the Function field set to "1000", then
	this is a Report of Approved Rate, rather than a Rate Request. The		this is a Report of Approved Rate, rather than a Rate Request. The
	router MAY ignore such an option, and in any case it MUST NOT modify		router MAY ignore such an option, and, in any case, it MUST NOT
	the contents of the option for a Report of Approved Rate. However,		modify the contents of the option for a Report of Approved Rate.
	the router MAY use the Approved Rate report to check that the sender		However, the router MAY use the Approved Rate report to check that
	is not lying about the approved rate. If the reported Approved Rate		the sender is not lying about the approved rate. If the reported
	is higher than the rate that the router actually approved for this		Approved Rate is higher than the rate that the router actually
	connection in the previous round-trip time, then the router may		approved for this connection in the previous round-trip time, then
	implement some policy for cheaters. For instance, the router MAY		the router may implement some policy for cheaters. For instance, the
	decide to deny future Quick-Start requests from this sender,		router MAY decide to deny future Quick-Start Requests from this
	including, if desired, deleting Quick-Start requests from future		sender, including, if desired, deleting Quick-Start Requests from
	packets from this sender. Section 9.4.1 discusses misbehaving		future packets from this sender. Section 9.4.1 discusses misbehaving
	senders in more detail. From the Report of Approved Rate, the		senders in more detail. From the Report of Approved Rate, the router
	router can also learn if some of the downstream routers have		can also learn if some of the downstream routers have approved the
	approved the Quick-Start request for a smaller rate or denied the		Quick-Start Request for a smaller rate or denied the use of Quick-
	use of Quick-Start, and adjust its bandwidth allocations		Start, and adjust its bandwidth allocations accordingly.
	accordingly.
	3.4. The QS Nonce		3.4. The QS Nonce
	The QS Nonce gives the Quick-Start sender some protection against		The QS Nonce gives the Quick-Start sender some protection against
	receivers lying about the value of the received Rate Request. This		receivers lying about the value of the received Rate Request. This
	is particularly important if the receiver knows the original value		is particularly important if the receiver knows the original value of
	of the Rate Request (e.g., when the sender always requests the same		the Rate Request (e.g., when the sender always requests the same
	value, and the receiver has a long history of communication with		value, and the receiver has a long history of communication with that
	that sender). Without the QS Nonce, there is nothing to prevent the		sender). Without the QS Nonce, there is nothing to prevent the
	receiver from reporting back to the sender a Rate Request of K, when		receiver from reporting back to the sender a Rate Request of K, when
	the received Rate Request was in fact less than K.		the received Rate Request was, in fact, less than K.
	Table 2 gives the format for the 30-bit QS Nonce.		Table 2 gives the format for the 30-bit QS Nonce.
	Bits Purpose		Bits Purpose
	--------- ------------------		--------- ------------------
	Bits 0-1: Rate 15 -> Rate 14		Bits 0-1: Rate 15 -> Rate 14
	Bits 2-3: Rate 14 -> Rate 13		Bits 2-3: Rate 14 -> Rate 13
	Bits 4-5: Rate 13 -> Rate 12		Bits 4-5: Rate 13 -> Rate 12
	Bits 6-7: Rate 12 -> Rate 11		Bits 6-7: Rate 12 -> Rate 11
	Bits 8-9: Rate 11 -> Rate 10		Bits 8-9: Rate 11 -> Rate 10
	skipping to change at page 25, line 9		skipping to change at page 17, line 6
	The transport sender MUST initialize the QS Nonce to a random value.		The transport sender MUST initialize the QS Nonce to a random value.
	If the router reduces the Rate Request from rate K to rate K-1, then		If the router reduces the Rate Request from rate K to rate K-1, then
	the router MUST set the field in the QS Nonce for "Rate K -> Rate		the router MUST set the field in the QS Nonce for "Rate K -> Rate
	K-1" to a new random value. Similarly, if the router reduces the		K-1" to a new random value. Similarly, if the router reduces the
	Rate Request by N steps, the router MUST set the 2N bits in the		Rate Request by N steps, the router MUST set the 2N bits in the
	relevant fields in the QS Nonce to a new random value. The receiver		relevant fields in the QS Nonce to a new random value. The receiver
	MUST report the QS Nonce back to the sender.		MUST report the QS Nonce back to the sender.
	If the Rate Request was not decremented in the network, then the QS		If the Rate Request was not decremented in the network, then the QS
	Nonce should have its original value. Similarly, if the Rate		Nonce should have its original value. Similarly, if the Rate Request
	Request was decremented by N steps in the network, and the receiver		was decremented by N steps in the network, and the receiver reports
	reports back a Rate Request of K, then the last 2K bits of the QS		back a Rate Request of K, then the last 2K bits of the QS Nonce
	Nonce should have their original value.		should have their original value.
	With the QS Nonce, the receiver has a 1/4 chance of cheating about		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		each step change in the rate request. Thus, if the rate request is
	reduced by two steps in the network, the receiver has a 1/16 chance		reduced by two steps in the network, the receiver has a 1/16 chance
	of successfully reporting that the original request was approved, as		of successfully reporting that the original request was approved, as
	this requires reporting the original value for the QS nonce.		this requires reporting the original value for the QS nonce.
	Similarly, if the rate request is reduced many steps in the network,		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		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		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 ->		fields in the QS nonce for "Rate K+2 -> Rate K+1" and "Rate K+1 ->
	Rate K". Thus, the receiver has a 1/16 chance in successfully lying		Rate K". Thus, the receiver has a 1/16 chance of successfully lying
	and saying that the received rate request was K+2 instead of K.		and saying that the received rate request was K+2 instead of K.
	We note that the protection offered by the QS Nonce is the same		We note that the protection offered by the QS Nonce is the same
	whether one router makes all of the decrements in the rate request,		whether one router makes all the decrements in the rate request, or
	or whether they are made at different routers along the path.		whether they are made at different routers along the path.
	The requirements for randomization for the sender and routers in		The requirements for randomization for the sender and routers in
	setting `random' values in the QS Nonce are not stringent - almost		setting `random' values in the QS Nonce are not stringent -- almost
	any form of pseudo-random numbers would do. The requirement is that		any form of pseudo-random numbers will do. The requirement is that
	the original value for the QS Nonce is not easily predictable by the		the original value for the QS Nonce is not easily predictable by the
	receiver, and in particular, the nonce MUST NOT be easily determined		receiver, and in particular, the nonce MUST NOT be easily determined
	from inspection of the rest of the packet or from previous packets.		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		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		specific packet header fields. Thus, if two bits of the QS Nonce are
	are changed by a router along the path, the receiver should not be		changed by a router along the path, the receiver should not be able
	able to guess those two bits from the other 28 bits in the QS Nonce.		to guess those two bits from the other 28 bits in the QS Nonce.
	An additional requirement is that the receiver cannot be able to		An additional requirement is that the receiver cannot be able to
	tell, from the QS Nonce itself, which numbers in the QS Nonce were		tell, from the QS Nonce itself, which numbers in the QS Nonce were
	generated by the sender, and which were generated by routers along		generated by the sender, and which were generated by routers along
	the path. This makes it harder for the receiver to infer the value		the path. This makes it harder for the receiver to infer the value
	of the original rate request, making it one step harder for the		of the original rate request, making it one step harder for the
	receiver to cheat.		receiver to cheat.
	Section 9.4 also considers issues of receiver cheating in more		Section 9.4 also considers issues of receiver cheating in more
	detail.		detail.
	4. The Quick-Start Mechanisms in TCP		4. The Quick-Start Mechanisms in TCP
	This section describes how the Quick-Start mechanism would be used		This section describes how the Quick-Start mechanism would be used in
	in TCP. We first sketch the procedure and then tightly define it in		TCP. We first sketch the procedure and then tightly define it in the
	the subsequent subsections.		subsequent subsections.
	If a TCP sender, say host A, would like to use Quick-Start, the TCP		If a TCP sender (say, host A) would like to use Quick-Start, the TCP
	sender puts the requested sending rate in bits per second,		sender puts the requested sending rate in bits per second,
	appropriately formatted, in the Quick-Start option in the IP header		appropriately formatted, in the Quick-Start Option in the IP header
	of the TCP packet, called the Quick-Start request packet. (We will		of the TCP packet, called the Quick-Start Request packet. (We will
	be somewhat loose in our use of "packet" vs. "segment" in this		be somewhat loose in our use of "packet" vs. "segment" in this
	section.) When used for initial start-up, the Quick-Start request		section.) When used for initial start-up, the Quick-Start Request
	packet can be either the SYN or SYN/ACK packet, as illustrated in		packet can be either the SYN or SYN/ACK packet, as illustrated in
	Figure 1. The requested rate includes an estimate for the transport		Figure 1. The requested rate includes an estimate for the transport
	and IP header overhead. The TCP receiver, say host B, returns the		and IP header overhead. The TCP receiver (say, host B) returns the
	Quick-Start Response option in the TCP header in the responding		Quick-Start Response option in the TCP header in the responding
	SYN/ACK packet or ACK packet, called the Quick-Start response		SYN/ACK packet or ACK packet, called the Quick-Start Response packet,
	packet, informing host A of the results of their request.		informing host A of the results of their request.
	If the acknowledging packet does not contain a Quick-Start Response,		If the acknowledging packet does not contain a Quick-Start Response,
	or contains a Quick-Start Response with the wrong value for the TTL		or contains a Quick-Start Response with the wrong value for the TTL
	Diff or the QS Nonce, then host A MUST assume that its Quick-Start		Diff or the QS Nonce, then host A MUST assume that its Quick-Start
	request failed. In this case, host A sends a Report of Approved		request failed. In this case, host A sends a Report of Approved Rate
	Rate with a Rate Report of zero, and uses TCP's default congestion		with a Rate Report of zero, and uses TCP's default congestion control
	control procedure. For initial start-up, host A uses the default		procedure. For initial start-up, host A uses the default initial
	initial congestion window ([RFC2581], [RFC3390]).		congestion window ([RFC2581], [RFC3390]).
	If the returning packet contains a valid Quick-Start Response, then		If the returning packet contains a valid Quick-Start Response, then
	host A uses the information in the response, along with its		host A uses the information in the response, along with its
	measurement of the round-trip time, to determine the Quick-Start		measurement of the round-trip time, to determine the Quick-Start
	congestion window (QS-cwnd). Quick-Start data packets are defined		congestion window (QS-cwnd). Quick-Start data packets are defined as
	as data packets sent as the result of a successful Quick-Start		data packets sent as the result of a successful Quick-Start request,
	request, up to the time when the first Quick-Start packet is		up to the time when the first Quick-Start packet is acknowledged.
	acknowledged. The sender also sends a Report of Approved Rate. In		The sender also sends a Report of Approved Rate. In order to use
	order to use Quick-Start, the TCP host MUST use rate-based pacing		Quick-Start, the TCP host MUST use rate-based pacing [VH97] to
	[VH97] to transmit Quick-Start packets at the rate indicated in the		transmit Quick-Start packets at the rate indicated in the Quick-Start
	Quick-Start Response, at the level of granularity possible by the		Response, at the level of granularity possible by the sending host.
	sending host. We note that the limitations of interrupt timing on		We note that the limitations of interrupt timing on computers can
	computers can limit the ability of the TCP host in rate-pacing the		limit the ability of the TCP host in rate-pacing the outgoing
	outgoing packets.		packets.
	The two TCP end-hosts can independently decide whether to request		The two TCP end-hosts can independently decide whether to request
	Quick-Start. For example, host A could sent a Quick-Start Request		Quick-Start. For example, host A could send a Quick-Start Request in
	in the SYN packet, and host B could also send a Quick-Start Request		the SYN packet, and host B could also send a Quick-Start Request in
	in the SYN/ACK packet.		the SYN/ACK packet.
	4.1. Sending the Quick-Start Request		4.1. Sending the Quick-Start Request
	When sending a Quick-Start Request, the TCP sender SHOULD send the		When sending a Quick-Start Request, the TCP sender SHOULD send the
	request on a packet that requires an acknowledgement, such as a SYN,		request on a packet that requires an acknowledgement, such as a SYN,
	SYN/ACK, or data packet. In this case, if the packet is		SYN/ACK, or data packet. In this case, if the packet is acknowledged
	acknowledged but no Quick-Start Response is included, then the		but no Quick-Start Response is included, then the sender knows that
	sender knows that the Quick-Start request has been denied, and can		the Quick-Start Request has been denied, and can send a Report of
	send a Report of Approved Rate.		Approved Rate.
	In addition to the use of Quick-Start when a connection is		In addition to the use of Quick-Start when a connection is
	established, there are several additional points in a connection		established, there are several additional points in a connection when
	when a transport protocol may want to issue a Rate Request. We		a transport protocol may want to issue a Rate Request. We first
	first re-iterate the notion that Quick-Start is a coarse-grained		reiterate the notion that Quick-Start is a coarse-grained mechanism.
	mechanism. That is, Quick-Start's Rate Requests are not meant to be		That is, Quick-Start's Rate Requests are not meant to be used for
	used for fine-grained control of the transport's sending rate.		fine-grained control of the transport's sending rate. Rather, the
	Rather, the transport MAY issue a Rate Request when no information		transport MAY issue a Rate Request when no information about the
	about the appropriate sending rate is available and the default		appropriate sending rate is available, and the default congestion
	congestion control mechanisms might be significantly underestimating		control mechanisms might be significantly underestimating the
	the appropriate sending rate.		appropriate sending rate.
	The following are potential points where Quick-Start may be useful:		The following are potential points where Quick-Start may be useful:
	(1) At or soon after connection initiation, when the transport		(1) At or soon after connection initiation, when the transport has no
	has no idea of the capacity of the network path, as discussed		idea of the capacity of the network path, as discussed above. (A
	above. (A transport that uses TCP Control Block sharing		transport that uses TCP Control Block sharing [RFC2140], the
	[RFC2140], the Congestion Manager [RFC3124], or other mechanisms		Congestion Manager [RFC3124], or other mechanisms for sharing
	for sharing congestion information may not need Quick-Start to		congestion information may not need Quick-Start to determine an
	determine an appropriate rate.)		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		(2) After an idle period when the transport no longer has a validated
	the endpoints has moved its point of network attachment. This		estimate of the available bandwidth for this flow. (An example
	can happen due to some underlying mobility mechanism like Mobile		could be a persistent-HTTP connection when a new HTTP request is
	IP ([RFC3344], [RFC3775]). Some transports, such as SCTP		received after an idle period.)
	[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 to see if it can send at a higher rate.
	(Alternatively, traditional slow-start should be used in this
	case when Quick-Start is not available.)
	(4) After an application-limited period when the sender has been		(3) After a host has received explicit indications that one of the
	using only a small amount of its appropriate share of the		endpoints has moved its point of network attachment. This can
	network capacity, and has no valid estimate for its fair share.		happen due to some underlying mobility mechanism like Mobile IP
	In this case, Quick-Start may be an appropriate mechanism to		([RFC3344], [RFC3775]). Some transports, such as Steam Control
	determine if the sender can send at a higher rate. For		Transmission Protocol (SCTP) [RFC2960], may associate with
	instance, consider an application that steadily exchanges low-		multiple IP addresses and can switch addresses (and therefore
	rate control messages and suddenly needs to transmit a large		network paths) in mid-connection. If the transport has concrete
	amount of data.		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 to see if it can send at a
			higher rate. (Alternatively, traditional slow-start should be
			used in this case when 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 determine if
			the 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		Of the above, this document recommends that a TCP sender MAY attempt
	to use Quick-Start in cases (1) and (2). It is NOT RECOMMENDED that		to use Quick-Start in cases (1) and (2). It is NOT RECOMMENDED that
	a TCP sender use Quick-Start for case (3) at the current time. Case		a TCP sender use Quick-Start for case (3) at the current time. Case
	(3) requires external notifications not presently defined for TCP or		(3) requires external notifications not presently defined for TCP or
	other transport protocols. Finally, a TCP SHOULD NOT use Quick-		other transport protocols. Finally, a TCP SHOULD NOT use Quick-
	Start for case (4) at the current time. Case (4) requires further		Start for case (4) at the current time. Case (4) requires further
	thought and investigation with regard to how the transport protocol		thought and investigation with regard to how the transport protocol
	could determine it was in a situation that would warrant		could determine it was in a situation that would warrant transmitting
	transmitting a Quick-Start Request.		a Quick-Start Request.
	As a general guideline, a TCP sender SHOULD NOT request a sending		As a general guideline, a TCP sender SHOULD NOT request a sending
	rate larger than it is able to use over the next round-trip time of		rate larger than it is able to use over the next round-trip time of
	the connection (or over 100 ms, if the round-trip time is not		the connection (or over 100 ms, if the round-trip time is not known),
	known), except as required to round up the desired sending rate to		except as required to round up the desired sending rate to the next-
	the next-highest allowable request.		highest allowable request.
	In any circumstances, the sender MUST NOT make a QS request if it		In any circumstances, the sender MUST NOT make a QS request if it has
	has made a QS request within the most recent round-trip time.		made a QS request within the most recent round-trip time.
	Section 4.7 discusses some of the issues of using Quick-Start at		Section 4.7 discusses some of the issues of using Quick-Start at
	connection initiation, and Section 4.8 discusses issues that arise		connection initiation, and Section 4.8 discusses issues that arise
	when Quick-Start is used to request a larger sending rate after an		when Quick-Start is used to request a larger sending rate after an
	idle period.		idle period.
	4.2. The Quick-Start Response Option in the TCP header		4.2. The Quick-Start Response Option in the TCP header
	In order to approve the use of Quick-Start, the TCP receiver		In order to approve the use of Quick-Start, the TCP receiver responds
	responds to the receipt of a Quick-Start Request with a Quick-Start		to the receipt of a Quick-Start Request with a Quick-Start Response,
	Response, using the Quick-Start Response Option in the TCP header.		using the Quick-Start Response Option in the TCP header. TCP's
	TCP's Quick-Start Response option is defined as follows:		Quick-Start Response option is defined as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Kind | Length=8 | Resv. | Rate | TTL Diff |		| Kind | Length=8 | Resv. | Rate | TTL Diff |
	| | | |Request| |		| | | |Request| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| QS Nonce | R |		| QS Nonce | R |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 5. The Quick-Start Response option in the TCP header.		Figure 5: The Quick-Start Response Option in the TCP Header.
	The first byte of the Quick-Start Response option contains the		The first byte of the Quick-Start Response option contains the option
	option kind, identifying the TCP option (to be assigned by IANA).		kind, identifying the TCP option.
	The second byte of the Quick-Start Response option contains the		The second byte of the Quick-Start Response option contains the
	option length in bytes. The length field MUST be set to 8 bytes.		option length in bytes. The length field MUST be set to 8 bytes.
	The third byte of the Quick-Start Response option contains a four-		The third byte of the Quick-Start Response option contains a four-
	bit Reserved field, and the four-bit allowed Rate Request, formatted		bit Reserved field, and the four-bit allowed Rate Request, formatted
	as in the Quick-Start Rate Request option.		as in the Quick-Start Rate Request option.
	The fourth byte of the TCP option contains the TTL Diff. The TTL		The fourth byte of the TCP option contains the TTL Diff. The TTL
	Diff contains the difference between the IP TTL and QS TTL fields in		Diff contains the difference between the IP TTL and QS TTL fields in
	the received Quick-Start request packet, as calculated in equations		the received Quick-Start Request packet, as calculated in equations
	(1) or (2) (depending on whether IPv4 or IPv6 is used).		(1) or (2) (depending on whether IPv4 or IPv6 is used).
	Bytes 5-8 of the TCP option contain the 30-bit QS Nonce and a two-		Bytes 5-8 of the TCP option contain the 30-bit QS Nonce and a two-
	bit Reserved field.		bit Reserved field.
	We note that while there are limitations on the potential size of		We note that, while there are limitations on the potential size of
	the Quick-Start Response Option, a Quick-Start Response Option of		the Quick-Start Response Option, a Quick-Start Response Option of
	eight bytes should not be a problem. The TCP Options field can		eight bytes should not be a problem. The TCP Options field can
	contain up to 40 bytes. Other TCP options that might be used in a		contain up to 40 bytes. Other TCP options that might be used in a
	SYN or SYN/ACK packet include Maximum Segment Size (four bytes),		SYN or SYN/ACK packet include Maximum Segment Size (four bytes), Time
	Time Stamp (ten bytes), Window Scale (three bytes), and Selective		Stamp (ten bytes), Window Scale (three bytes), and Selective
	Acknowledgments Permitted (two bytes).		Acknowledgments Permitted (two bytes).
	4.3. TCP: Sending the Quick-Start Response		4.3. TCP: Sending the Quick-Start Response
	An end host, say host B, that receives an IP packet containing a		An end host (say, host B) that receives an IP packet containing a
	Quick-Start Request passes the Quick-Start Request, along with the		Quick-Start Request passes the Quick-Start Request, along with the
	value in the IP TTL field, to the receiving TCP layer.		value in the IP TTL field, to the receiving TCP layer.
	If the TCP host is willing to permit the Quick-Start Request, then a		If the TCP host is willing to permit the Quick-Start Request, then a
	Quick-Start Response option is included in the TCP header of the		Quick-Start Response option is included in the TCP header of the
	corresponding acknowledgement packet. The Rate Request in the		corresponding acknowledgement packet. The Rate Request in the
	Quick-Start Response option is set to the received value of the Rate		Quick-Start Response option is set to the received value of the Rate
	Request in the Quick-Start option, or to a lower value if the TCP		Request in the Quick-Start Option, or to a lower value if the TCP
	receiver is only willing to allow a lower Rate Request. The TTL		receiver is only willing to allow a lower Rate Request. The TTL Diff
	Diff in the Quick-Start Response is set to the difference between		in the Quick-Start Response is set to the difference between the IP
	the IP TTL value and the QS TTL value as given in equation (1) or		TTL value and the QS TTL value as given in equation (1) or (2)
	(2) (depending on whether IPv4 or IPv6 is used). The QS Nonce in		(depending on whether IPv4 or IPv6 is used). The QS Nonce in the
	the Response is set to the received value of the QS Nonce in the		Response is set to the received value of the QS Nonce in the Quick-
	Quick-Start option.		Start Option.
	If an end host receives an IP packet with a Quick-Start Request with		If an end host receives an IP packet with a Quick-Start Request with
	a rate request of zero, then that host SHOULD NOT send a Quick-Start		a rate request of zero, then that host SHOULD NOT send a Quick-Start
	Response.		Response.
	The Quick-Start Response MUST NOT be resent if it is lost in the		The Quick-Start Response MUST NOT be resent if it is lost in the
	network. Packet loss could be an indication of congestion on the		network. Packet loss could be an indication of congestion on the
	return path, in which case it is better not to approve the Quick-		return path, in which case it is better not to approve the Quick-
	Start Request.		Start Request.
	4.4. TCP: Receiving and Using the Quick-Start Response Packet		4.4. TCP: Receiving and Using the Quick-Start Response Packet
	A TCP host, say TCP host A, that sent a Quick-Start Request and		A TCP host (say, TCP host A) that sent a Quick-Start Request and
	receives a Quick-Start Response in an acknowledgement first checks		receives a Quick-Start Response in an acknowledgement first checks
	that the Quick-Start Response is valid. The Quick-Start Response is		that the Quick-Start Response is valid. The Quick-Start Response is
	valid if it contains the correct value for the TTL Diff, and an		valid if it contains the correct value for the TTL Diff, and an equal
	equal or lesser value for the Rate Request than that transmitted in		or lesser value for the Rate Request than that transmitted in the
	the Quick-Start Request. In addition, if the received Rate Request		Quick-Start Request. In addition, if the received Rate Request is K,
	is K, then the rightmost 2K bits of the QS Nonce must match those		then the rightmost 2K bits of the QS Nonce must match those bits in
	bits in the QS Nonce sent in the Quick-Start Request. If these		the QS Nonce sent in the Quick-Start Request. If these checks are
	checks are not successful, then the Quick-Start request failed, and		not successful, then the Quick-Start Request failed, and the TCP host
	the TCP host MUST use the default TCP congestion window that it		MUST use the default TCP congestion window that it would have used
	would have used without Quick-Start. If the rightmost 2K bits of		without Quick-Start. If the rightmost 2K bits of the QS Nonce do not
	the QS Nonce do not match those bits in the QS Nonce sent in the		match those bits in the QS Nonce sent in the Quick-Start Request, for
	Quick-Start Request, for a received Rate Request of K, then the TCP		a received Rate Request of K, then the TCP host MUST NOT send
	host MUST NOT send additional Quick-Start requests during the life		additional Quick-Start Requests during the life of the connection.
	of the connection. Whether the Quick-Start request was successful		Whether or not the Quick-Start Request was successful, the host
	or not, the host receiving the Quick-Start Response MUST send a		receiving the Quick-Start Response MUST send a Report of Approved
	Report of Approved Rate. Similarly, if the packet containing the		Rate. Similarly, if the packet containing the Quick-Start Request is
	Quick-Start Request is acknowledged, but the acknowledgement does		acknowledged, but the acknowledgement does not include a Quick-Start
	not include a Quick-Start Response, then the sender MUST send a		Response, then the sender MUST send a Report of Approved Rate.
	Report of Approved Rate.
	If the checks of the TTL Diff and the Rate Request are successful,		If the checks of the TTL Diff and the Rate Request are successful,
	and the TCP host is going to use the Quick-Start Request, it MUST		and the TCP host is going to use the Quick-Start Request, it MUST
	start using it within one round-trip time of receiving the Quick-		start using it within one round-trip time of receiving the Quick-
	Start Response, or within three seconds, whichever is smaller. To		Start Response, or within three seconds, whichever is smaller. To
	use the Quick-Start Request, the host sets its Quick-Start		use the Quick-Start Request, the host sets its Quick-Start congestion
	congestion window (in terms of MSS-sized segments), QS-cwnd, as		window (in terms of MSS-sized segments), QS-cwnd, as follows:
	follows:
	QS-cwnd = (R * T) / (MSS + H) (3)		QS-cwnd = (R * T) / (MSS + H) (3)
			where R is the Rate Request in bytes per second, T is the measured
	where R the Rate Request in bytes per second, T the measured round-		round-trip time in seconds, and H is the estimated TCP/IP header size
	trip time in seconds, and H the estimated TCP/IP header size in		in bytes (e.g., 40 bytes).
	bytes (e.g., 40 bytes).
	Derivation: the sender is allowed to transmit at R bytes per second		Derivation: the sender is allowed to transmit at R bytes per second
	including packet headers, but only R*MSS/(MSS+H) bytes per second,		including packet headers, but only R*MSS/(MSS+H) bytes per second, or
	or equivalently R*T*MSS/(MSS+H) bytes per round-trip time, of		equivalently R*T*MSS/(MSS+H) bytes per round-trip time, of
	application data.		application data.
	The TCP host SHOULD set its congestion window cwnd to QS-cwnd only		The TCP host SHOULD set its congestion window cwnd to QS-cwnd only if
	if QS-cwnd is greater than cwnd; otherwise QS-cwnd is ignored. If		QS-cwnd is greater than cwnd; otherwise, QS-cwnd is ignored. If
	QS-cwnd is used, the TCP host sets a flag that it is in Quick-Start		QS-cwnd is used, the TCP host sets a flag that it is in Quick-Start
	mode, and while in Quick-Start mode the TCP sender MUST use rate-		mode, and while in Quick-Start mode, the TCP sender MUST use rate-
	based pacing to pace out Quick-Start packets at the approved rate.		based pacing to pace out Quick-Start packets at the approved rate.
	If, during Quick-Start mode, the TCP sender receives ACKs for		If, during Quick-Start mode, the TCP sender receives ACKs for packets
	packets sent before this Quick-Start mode was entered, these ACKs		sent before this Quick-Start mode was entered, these ACKs are
	are processed as usual, following the default congestion control		processed as usual, following the default congestion control
	mechanisms. Quick-Start mode ends when the TCP host receives an ACK		mechanisms. Quick-Start mode ends when the TCP host receives an ACK
	for one of the Quick-Start packets.		for one of the Quick-Start packets.
	If the congestion window has not been fully used when the first ack		If the congestion window has not been fully used when the first ack
	arrives ending the Quick-Start mode, then the congestion window is		arrives ending the Quick-Start mode, then the congestion window is
	decreased to the amount that has actually been used so far. This is		decreased to the amount that has actually been used so far. This is
	necessary because when the Quick-Start Response is received, the TCP		necessary because when the Quick-Start Response is received, the TCP
	sender's round-trip-time estimate might be longer than for		sender's round-trip-time estimate might be longer than for succeeding
	succeeding round-trip times, e.g., because of delays at routers		round-trip times, e.g., because of delays at routers processing the
	processing the IP Quick-Start option, or because of delays at the		IP Quick-Start Option, or because of delays at the receiver in
	receiver in responding to the Quick-Start Request packet. In this		responding to the Quick-Start Request packet. In this case, an
	case, an overly-large round-trip-time estimate could have caused the		overly large round-trip-time estimate could have caused the TCP
	TCP sender to translate the approved Quick-Start sending rate in		sender to translate the approved Quick-Start sending rate in bytes
	bytes per second into a congestion window that is larger than		per second into a congestion window that is larger than needed, with
	needed, with the TCP sender receiving an ACK for the first Quick-		the TCP sender receiving an ACK for the first Quick- Start packet
	Start packet before the entire congestion window has been used.		before the entire congestion window has been used. Thus, when the
	Thus, when the TCP sender receives the first ACK for a Quick-Start		TCP sender receives the first ACK for a Quick-Start packet, the
	packet, the sender MUST reduce the congestion window to the amount		sender MUST reduce the congestion window to the amount that has
	that has actually been used.		actually been used.
	As an example, a TCP sender with an approved Quick-Start request of		As an example, a TCP sender with an approved Quick-Start Request of R
	R KBps, B-byte packets including headers, and an RTT estimate of T		KBps, B-byte packets including headers, and an RTT estimate of T
	seconds, would translate the Rate Request of R KBps to a congestion		seconds, would translate the Rate Request of R KBps to a congestion
	window of R*T/B packets. The TCP sender would send the Quick-Start		window of R*T/B packets. The TCP sender would send the Quick-Start
	packets rate-paced at R KBps. However, if the actual current round-		packets rate-paced at R KBps. However, if the actual current round-
	trip time was T/2 seconds instead of T seconds, then the sender		trip time was T/2 seconds instead of T seconds, then the sender would
	would begin to receive acknowledgements for Quick-Start packets		begin to receive acknowledgements for Quick-Start packets after T/2
	after T/2 seconds. Following the paragraph above, the TCP sender		seconds. Following the paragraph above, the TCP sender would then
	would then reduce its congestion window from R*T/B to approximately		reduce its congestion window from R*T/B to approximately R*T/(B*2)
	R*T/(B*2) packets, the actual number of packets that were needed to		packets, the actual number of packets that were needed to fill the
	fill the pipe at a sending rate of R KBps. (Note: this is just an		pipe at a sending rate of R KBps. (Note: this is just an
	illustration and that the congestion window is actually set to the		illustration; the congestion window is actually set to the amount of
	amount of data sent before the ACK arrives and not based on		data sent before the ACK arrives and not based on equations above.)
	equations above.)
	After Quick-Start mode is exited and the congestion window adjusted		After Quick-Start mode is exited and the congestion window adjusted
	if necessary, the TCP sender returns to using the default congestion		if necessary, the TCP sender returns to using the default congestion-
	control mechanisms, processing further incoming ACK packets as		control mechanisms, processing further incoming ACK packets as
	specified by those congestion control mechanisms. For example, if		specified by those congestion control mechanisms. For example, if
	the TCP sender was in slow-start prior to the Quick-Start request,		the TCP sender was in slow-start prior to the Quick-Start Request,
	and no packets were lost or marked since that time, then the sender		and no packets were lost or marked since that time, then the sender
	continues in slow-start after exiting Quick-Start mode, as allowed		continues in slow-start after exiting Quick-Start mode, as allowed by
	by ssthresh.		ssthresh.
	To add robustness, the TCP sender MUST use Limited Slow-Start		To add robustness, the TCP sender MUST use Limited Slow-Start
	[RFC3742] along with Quick-Start. With Limited Slow-Start, the TCP		[RFC3742] along with Quick-Start. With Limited Slow-Start, the TCP
	sender limits the number of packets by which the congestion window		sender limits the number of packets by which the congestion window is
	is increased for one window of data during slow-start.		increased for one window of data during slow-start.
	When Quick-Start is used at the beginning of a connection, before		When Quick-Start is used at the beginning of a connection, before any
	any packet marks or losses have been reported, the TCP host MAY use		packet marks or losses have been reported, the TCP host MAY use the
	the reported Rate Request to set the slow-start threshold to a		reported Rate Request to set the slow-start threshold to a desired
	desired value, e.g., to some small multiple of the congestion		value, e.g., to some small multiple of the congestion window. A
	window. A possible future research topic is how the sender might		possible future research topic is how the sender might modify the
	modify the show-start threshold at the beginning of a connection to		slow-start threshold at the beginning of a connection to avoid
	avoid overshooting the path capacity. (The initial value of		overshooting the path capacity. (The initial value of ssthresh is
	ssthresh is allowed to be arbitrarily high, and some TCP		allowed to be arbitrarily high, and some TCP implementations use the
	implementations use the size of the advertised window for ssthresh		size of the advertised window for ssthresh [RFC2581].)
	[RFC2581].)
	4.5. TCP: Controlling Acknowledgement Traffic on the Reverse Path		4.5. TCP: Controlling Acknowledgement Traffic on the Reverse Path
	When a Quick-Start Request is approved for a TCP sender, the		When a Quick-Start Request is approved for a TCP sender, the
	resulting Quick-Start data traffic can result in a sudden increase		resulting Quick-Start data traffic can result in a sudden increase in
	in traffic for pure ACK packets on the reverse path. For example,		traffic for pure ACK packets on the reverse path. For example, for
	for the largest Quick-Start request of 1.3 Gbps, given a TCP sender		the largest Quick-Start Request of 1.3 Gbps, given a TCP sender with
	with 1500-byte packets and a TCP receiver with delayed		1500-byte packets and a TCP receiver with delayed acknowledgements
	acknowledgements acking every other packet, this could result in		acking every other packet, this could result in 17.3 Mbps of
	17.3 Mbps of acknowledgement traffic on the reverse path.		acknowledgement traffic on the reverse path.
	One possibility, in cases with large Quick-Start requests, would be		One possibility, in cases with large Quick-Start Requests, would be
	for TCP receivers to send Quick-Start requests to request bandwidth		for TCP receivers to send Quick-Start Requests to request bandwidth
	for the acknowledgement traffic on the reverse path. However, in		for the acknowledgement traffic on the reverse path. However, in our
	our view, a better approach would be for TCP receivers to simply		view, a better approach would be for TCP receivers to simply control
	control the rate of sending acknowledgement traffic. The optimal		the rate of sending acknowledgement traffic. The optimal future
	future solution would involve the explicit use of congestion control		solution would involve the explicit use of congestion control for TCP
	for TCP acknowledgement traffic, as is done now for the		acknowledgement traffic, as is done now for the acknowledgement
	acknowledgement traffic in DCCP's CCID2 [RFC4341].		traffic in DCCP's CCID2 [RFC4341].
	In the absence of congestion control for acknowledgement traffic,		In the absence of congestion control for acknowledgement traffic, the
	the TCP receiver could limit its sending rate for ACK packets sent		TCP receiver could limit its sending rate for ACK packets sent in
	in response to Quick-Start data packets. The following information		response to Quick-Start data packets. The following information is
	is needed by the TCP receiver:		needed by the TCP receiver:
	* The RTT: TCP naturally measures the RTT of the path and therefore		* The RTT: TCP naturally measures the RTT of the path and therefore
	should have a sample of the RTT. If the TCP receiver does not		should have a sample of the RTT. If the TCP receiver does not have
	have a measurement of the round-trip time, it can use the time		a measurement of the round-trip time, it can use the time between
	between the receipt of the Quick-Start Request and the Report		the receipt of the Quick-Start Request and the Report of Approved
	of Approved Rate.		Rate.
	* The Approved Rate Request (R): When the TCP receiver receives the		* The Approved Rate Request (R): When the TCP receiver receives the
	Quick-Start Response packet, the receiver knows the value of the		Quick-Start Response packet, the receiver knows the value of the
	approved Rate Request.		approved Rate Request.
	* The MSS: TCP advertises the MSS during the initial three-way		* The MSS: TCP advertises the MSS during the initial three-way
	handshake and therefore the receiver should have an understanding		handshake; therefore, the receiver should have an understanding of
	of the packet size the sender will be using. If the receiver does		the packet size the sender will be using. If the receiver does not
	not have such an understanding or wishes to confirm the negotiated		have such an understanding or wishes to confirm the negotiated MSS,
	MSS, the size of the first data packet can be used.		the size of the first data packet can be used.
	With this set of information the TCP receiver can restrict its		With this set of information, the TCP receiver can restrict its
	sending rate for pure acknowledgment traffic to at most 100 pure ACK		sending rate for pure acknowledgment traffic to at most 100 pure ACK
	packets per RTT by sending at most one ACK for every K data packets,		packets per RTT by sending at most one ACK for every K data packets,
	for the ACK Ratio K set to R*RTT/(100*8*MSS). The receiver would		for the ACK Ratio K set to R*RTT/(100*8*MSS). The receiver would
	acknowledge the first Quick-Start data packet, and every succeeding		acknowledge the first Quick-Start data packet, and every succeeding K
	K data packets. Thus, for a somewhat extreme case of R=1.3 Gbps,		data packets. Thus, for a somewhat extreme case of R=1.3 Gbps,
	RTT=0.2 seconds, and MSS=1500 bytes, K would be set to 216, and the		RTT=0.2 seconds, and MSS=1500 bytes, K would be set to 216, and the
	receiver would acknowledge every 216 data packets. From [RFC2581],		receiver would acknowledge every 216 data packets. From [RFC2581],
	the ACK Ratio K should have a minimum value of two. When the ACK		the ACK Ratio K should have a minimum value of two. When the ACK
	Ratio is greater than two, and the TCP sender receives		Ratio is greater than two, and the TCP sender receives
	acknowledgements each acknowledging more than two data packets, the		acknowledgements each acknowledging more than two data packets, the
	TCP sender may want to use rate-based pacing to control the		TCP sender may want to use rate-based pacing to control the
	burstiness of its outgoing data traffic.		burstiness of its outgoing data traffic.
	In the absence of explicit congestion control mechanisms, the TCP		In the absence of explicit congestion control mechanisms, the TCP end
	end nodes cannot determine the packet drop rate for pure		nodes cannot determine the packet drop rate for pure acknowledgement
	acknowledgement traffic. This is true with or without Quick-Start.		traffic. This is true with or without Quick-Start. However, the TCP
	However, the TCP receiver could limit its increase in the sending		receiver could limit its increase in the sending rate for pure ACK
	rate for pure ACK packets by at most doubling the sending rate for		packets by at most doubling the sending rate for pure ACK packets
	pure ACK packets from one round-trip time to the next. The TCP		from one round-trip time to the next. The TCP receiver would do this
	receiver would do this by halving the ACK Ratio each round-trip		by halving the ACK Ratio each round-trip time.
	time.
	Note that the above is one particular mechanism that could be used		Note that the above is one particular mechanism that could be used to
	to control the ACK stream. Future work that investigates this		control the ACK stream. Future work that investigates this scheme
	scheme and others in detail is encouraged.		and others in detail is encouraged.
	4.6. TCP: Responding to a Loss of a Quick-Start Packet		4.6. TCP: Responding to a Loss of a Quick-Start Packet
	For TCP, we have defined a ``Quick-Start packet'' as one of the		For TCP, we have defined a "Quick-Start packet" as one of the packets
	packets sent in the window immediately following a successful Quick-		sent in the window immediately following a successful Quick-Start
	Start request. After detecting the loss or ECN-marking of a Quick-		Request. After detecting the loss or ECN-marking of a Quick-Start
	Start packet, TCP MUST revert to the default congestion control		packet, TCP MUST revert to the default congestion control procedures
	procedures that would have been used if the Quick-Start request had		that would have been used if the Quick-Start Request had not been
	not been approved. For example, if Quick-Start is used for setting		approved. For example, if Quick-Start is used for setting the
	the initial window, and a packet from the initial window is lost or		initial window, and a packet from the initial window is lost or
	marked, then the TCP sender MUST then slow-start with the default		marked, then the TCP sender MUST then slow-start with the default
	initial window that would have been used if Quick-Start had not been		initial window that would have been used if Quick-Start had not been
	used. In addition to reverting to the default congestion control		used. In addition to reverting to the default congestion control
	mechanisms, the sender MUST take into account that the Quick-Start		mechanisms, the sender MUST take into account that the Quick-Start
	congestion window was too large. Thus, the sender SHOULD decrease		congestion window was too large. Thus, the sender SHOULD decrease
	ssthresh to at most half the number of Quick-Start packets that were		ssthresh to, at most, half the number of Quick-Start packets that
	successfully transmitted. Section B.5 discusses possible		were successfully transmitted. Appendix B.5 discusses possible
	alternatives in responding to the loss of a Quick-Start packet.		alternatives in responding to the loss of a Quick-Start packet.
	If a Quick-Start packet is lost or ECN-marked, then the sender		If a Quick-Start packet is lost or ECN-marked, then the sender SHOULD
	SHOULD NOT make future Quick-Start requests for this connection.		NOT make future Quick-Start Requests for this connection.
	We note that ECN [RFC3168] MAY be used with Quick-Start. As is		We note that ECN [RFC3168] MAY be used with Quick-Start. As is
	always the case with ECN, the sender's congestion control response		always the case with ECN, the sender's congestion control response to
	to an ECN-marked Quick-Start packet is the same as the response to a		an ECN-marked Quick-Start packet is the same as the response to a
	dropped Quick-Start packet, thus reverting to slow start in the case		dropped Quick-Start packet, thus reverting to slow start in the case
	of Quick-Start packets marked as experiencing congestion.		of Quick-Start packets marked as experiencing congestion.
	4.7. TCP: A Quick-Start Request for a Larger Initial Window		4.7. TCP: A Quick-Start Request for a Larger Initial Window
	Some of the issues of using Quick-Start are related to the specific		Some of the issues of using Quick-Start are related to the specific
	scenario in which Quick-Start is used. This section discusses the		scenario in which Quick-Start is used. This section discusses the
	following issues that arise when Quick-Start is used by TCP to		following issues that arise when Quick-Start is used by TCP to
	request a larger initial window: (1) interactions with Path MTU		request a larger initial window: (1) interactions with Path MTU
	Discovery (PMTUD); and (2) Quick-Start request packets that are		Discovery (PMTUD); and (2) Quick-Start Request packets that are
	discarded by middleboxes.		discarded by middleboxes.
	4.7.1. Interactions with Path MTU Discovery		4.7.1. Interactions with Path MTU Discovery
	One issue when Quick-Start is used to request a large initial window		One issue when Quick-Start is used to request a large initial window
	concerns the interactions between the large initial window and Path		concerns the interactions between the large initial window and Path
	MTU Discovery. Some of the issues are discussed in RFC 3390:		MTU Discovery. Some of the issues are discussed in RFC 3390:
	"When larger initial windows are implemented along with Path MTU		"When larger initial windows are implemented along with Path MTU
	Discovery [RFC1191], alternatives are to set the "Don't		Discovery [RFC1191], alternatives are to set the `Don't Fragment'
	Fragment" (DF) bit in all segments in the initial window, or to		(DF) bit in all segments in the initial window, or to set the `Don't
	set the "Don't Fragment" (DF) bit in one of the segments. It is		Fragment' (DF) bit in one of the segments. It is an open question as
	an open question as to which of these two alternatives is best."		to which of these two alternatives is best."
	If the sender knows the Path MTU when the initial window is sent		If the sender knows the Path MTU when the initial window is sent
	(e.g., from a PMTUD cache or from some other IETF-approved method),		(e.g., from a PMTUD cache or from some other IETF-approved method),
	then the sender SHOULD use that MTU for segments in the initial		then the sender SHOULD use that MTU for segments in the initial
	window. Unfortunately, the sender doesn't necessarily know the Path		window. Unfortunately, the sender doesn't necessarily know the Path
	MTU when it sends packets in the initial window. In this case, the		MTU when it sends packets in the initial window. In this case, the
	sender should be conservative in the packet size used. Sending a		sender should be conservative in the packet size used. Sending a
	large number of overly-large packets with the DF bit set is not		large number of overly large packets with the DF bit set is not
	desirable, but sending a large number of packets that are fragmented		desirable, but sending a large number of packets that are fragmented
	in the network can be equally undesirable.		in the network can be equally undesirable.
	If the sender doesn't know the Path MTU when the initial window is		If the sender doesn't know the Path MTU when the initial window is
	sent, the sender SHOULD send one large packet in the initial window		sent, the sender SHOULD send one large packet in the initial window
	with the DF bit set, and send the remaining packets in the initial		with the DF bit set, and send the remaining packets in the initial
	window with a smaller MTU of 576 bytes (or 1280 bytes with IPv6).		window with a smaller MTU of 576 bytes (or 1280 bytes with IPv6).
	A second possibility would be for the sender to delay sending the		A second possibility would be for the sender to delay sending the
	Quick-Start Request for one round-trip time, sending the Quick-Start		Quick-Start Request for one round-trip time by sending the Quick-
	Request with the first window of data while also doing Path MTU		Start Request with the first window of data, while also doing Path
	Discovery.		MTU Discovery.
	The sender may be using an iterative approach such as Packetization		The sender may be using an iterative approach such as Packetization
	Layer Path MTU Discovery (PLPMTUD) [MH06] for Path MTU Discovery,		Layer Path MTU Discovery (PLPMTUD) [MH06] for Path MTU Discovery,
	where the sender tests successively larger MTUs. If a probe is		where the sender tests successively larger MTUs. If a probe is
	successfully delivered then the MTU can be raised to reflect the		successfully delivered, then the MTU can be raised to reflect the
	value used in that probe. We would note that PLPMTUD does not allow		value used in that probe. We would note that PLPMTUD does not allow
	the sender to determine the Path MTU before sending the initial		the sender to determine the Path MTU before sending the initial
	window of data.		window of data.
	4.7.2. Quick-Start Request Packets that are Discarded by Routers or		4.7.2. Quick-Start Request Packets that are Discarded by Routers or
	Middleboxes		Middleboxes
	It is always possible for a TCP SYN packet carrying a Quick-Start		It is always possible for a TCP SYN packet carrying a Quick-Start
	request to be dropped in the network due to congestion, or to be		request to be dropped in the network due to congestion, or to be
	blocked due to interactions with routers or middleboxes, where a		blocked due to interactions with routers or middleboxes, where a
	middlebox is defined as any intermediary box performing functions		middlebox is defined as any intermediary box performing functions
	apart from normal, standard functions of an IP router on the data		apart from normal, standard functions of an IP router on the data
	path between a source host and destination host [RFC3234].		path between a source host and destination host [RFC3234].
	Measurement studies of interactions between transport protocols and		Measurement studies of interactions between transport protocols and
	middleboxes [MAF04] show that for 70% of the web servers		middleboxes [MAF04] show that for 70% of the Web servers
	investigated, no connection is established if the TCP SYN packet		investigated, no connection is established if the TCP SYN packet
	contains an unknown IP option (and for 43% of the web servers, no		contains an unknown IP option (and for 43% of the Web servers, no
	connection is established if the TCP SYN packet contains an IP		connection is established if the TCP SYN packet contains an IP
	TimeStamp Option). In both cases, this is presumably due to routers		TimeStamp Option). In both cases, this is presumably due to routers
	or middleboxes along that path.		or middleboxes along that path.
	If the TCP sender doesn't receive a response to the SYN or SYN/ACK		If the TCP sender doesn't receive a response to the SYN or SYN/ACK
	packet containing the Quick-Start Request, then the TCP sender		packet containing the Quick-Start Request, then the TCP sender SHOULD
	SHOULD resend the SYN or SYN/ACK packet without the Quick-Start		resend the SYN or SYN/ACK packet without the Quick-Start Request.
	Request. Similarly, if the TCP sender receives a TCP reset in
	response to the SYN or SYN/ACK packet containing the Quick-Start
	Request, then the TCP sender SHOULD resend the SYN or SYN/ACK packet
	without the Quick-Start Request [RFC3360].
	RFC 1122 and 2988 specify that the sender should set the initial RTO		Similarly, if the TCP sender receives a TCP reset in response to the
	to three seconds, though many TCP implementations set the initial		SYN or SYN/ACK packet containing the Quick-Start Request, then the
	RTO to one second. For a TCP SYN packet sent with a Quick-Start		TCP sender SHOULD resend the SYN or SYN/ACK packet without the
	request, the TCP sender SHOULD use an initial RTO of three seconds.		Quick-Start Request [RFC3360].
	We note that if the TCP SYN packet is using the IP Quick-Start		RFCs 1122 and 2988 specify that the sender should set the initial RTO
	Option for a Quick-Start request, and it is also using bits in the		(retransmission timeout) to three seconds, though many TCP
	TCP header to negotiate ECN-capability with the TCP host at the		implementations set the initial RTO to one second. For a TCP SYN
	other end, then the drop of a TCP SYN packet could be due to		packet sent with a Quick-Start request, the TCP sender SHOULD use an
	congestion, to a router or middlebox dropping the packet because of		initial RTO of three seconds.
	the IP Option, or because of a router or middlebox dropping the
	packet because of the information in the TCP header negotiating ECN.		We note that if the TCP SYN packet is using the IP Quick-Start Option
	In this case, the sender could resend the dropped packet without		for a Quick-Start Request, and it is also using bits in the TCP
	either the Quick-Start or the ECN requests. Alternately, the sender		header to negotiate ECN-capability with the TCP host at the other
	could resend the dropped packet with only the ECN request in the TCP		end, then the drop of a TCP SYN packet could be due to congestion, a
	header, resending the TCP SYN packet without either the Quick-Start		router or middlebox dropping the packet because of the IP Option, or
	or the ECN requests if the second TCP SYN packet is dropped. The		a router or middlebox dropping the packet because of the information
	second choice seems reasonable, given that a TCP SYN packet today is		in the TCP header negotiating ECN. In this case, the sender could
	more likely to be blocked due to policies that discard packets with		resend the dropped packet without either the Quick-Start or the ECN
	IP Options than due to policies that discard packets with ECN		requests. Alternately, the sender could resend the dropped packet
	requests in the TCP header [MAF04].		with only the ECN request in the TCP header, resending the TCP SYN
			packet without either the Quick-Start or the ECN requests if the
			second TCP SYN packet is dropped. The second choice seems
			reasonable, given that a TCP SYN packet today is more likely to be
			blocked due to policies that discard packets with IP Options than due
			to policies that discard packets with ECN requests in the TCP header
			[MAF04].
	4.8. TCP: A Quick-Start Request in the Middle of a Connection		4.8. TCP: A Quick-Start Request in the Middle of a Connection
	This section discusses the following issues that arise when Quick-		This section discusses the following issues that arise when Quick-
	Start is used by TCP to request a larger window in the middle of a		Start is used by TCP to request a larger window in the middle of a
	connection, such as after an idle period: (1) determining the rate		connection, such as after an idle period: (1) determining the rate to
	to request; (2) when to make a request; and (3) the response if		request; (2) when to make a request; and (3) the response if Quick-
	Quick-Start packets are dropped;		Start packets are dropped.
	(1) Determining the rate to request:		(1) Determining the rate to request:
	For a connection that has not yet had a congestion event (that is, a		For a connection that has not yet had a congestion event (that
	marked or dropped packet), the TCP sender is not restricted in the		is, a marked or dropped packet), the TCP sender is not restricted
	rate that it requests. As an example, a server might wait and send		in the rate that it requests. As an example, a server might wait
	a Quick-Start request after a short interaction with the client.		and send a Quick-Start Request after a short interaction with the
			client.
	To use a Quick-Start Request in a connection that has already		To use a Quick-Start Request in a connection that has already
	experienced a congestion event, and that has not had a recent		experienced a congestion event, and that has not had a recent
	mobility event, the TCP sender can determine the largest congestion		mobility event, the TCP sender can determine the largest
	window that the TCP connection achieved since the last packet drop		congestion window that the TCP connection achieved since the last
	and translate this to a sending rate to get the maximum allowed		packet drop and translate this to a sending rate to get the
	request rate. If the request is granted, then the sender		maximum allowed request rate. If the request is granted, then
	essentially restarts with its old congestion window from before it		the sender essentially restarts with its old congestion window
	was reduced, for example during an idle period.		from before it was reduced, for example, during an idle period.
	A Quick-Start Request sent in the middle of a TCP connection SHOULD		A Quick-Start Request sent in the middle of a TCP connection
	be sent on a data packet.		SHOULD be sent on a data packet.
	(2) When to make a request:		(2) When to make a request:
	A TCP connection MAY make a Quick-Start request before the		A TCP connection MAY make a Quick-Start Request before the
	connection has experienced a congestion event, or after an idle		connection has experienced a congestion event, or after an idle
	period of at least one RTO.		period of at least one RTO.
	(3) Response if Quick-Start packets are dropped:		(3) Response if Quick-Start packets are dropped:
	If Quick-Start packets are dropped in the middle of connection, then		If Quick-Start packets are dropped in the middle of connection,
	the sender MUST revert to half of the Quick-Start window, or to the		then the sender MUST revert to half the Quick-Start window, or to
	congestion window that the sender would have used if the Quick-Start		the congestion window that the sender would have used if the
	request had not been approved, whichever is smaller.		Quick-Start request had not been approved, whichever is smaller.
	4.9. An Example Quick-Start Scenario with TCP		4.9. An Example Quick-Start Scenario with TCP
	The following is an example scenario in the case when both hosts		The following is an example scenario of when both hosts request
	request Quick-Start for setting their initial windows. This is		Quick-Start for setting their initial windows. This is similar to
	similar to Figures 1 and 2 in Section 2.1, except that it		Figures 1 and 2 in Section 2.1, except that it illustrates a TCP
	illustrates a TCP connection with both TCP hosts sending Quick-Start		connection with both TCP hosts sending Quick-Start Requests.
	Requests.
	* The TCP SYN packet from Host A contains a Quick-Start Request in		* The TCP SYN packet from Host A contains a Quick-Start Request in
	the IP header.		the IP header.
	* Routers along the forward path modify the Quick-Start Request as		* Routers along the forward path modify the Quick-Start Request as
	appropriate.		appropriate.
	* Host B receives the Quick-Start Request in the SYN packet, and		* Host B receives the Quick-Start Request in the SYN packet, and
	calculates the TTL Diff. If Host B approves the Quick-Start		calculates the TTL Diff. If Host B approves the Quick-Start
	Request, then Host B sends a Quick-Start Response in the TCP header		Request, then Host B sends a Quick-Start Response in the TCP header
	of the SYN/ACK packet. Host B also sends a Quick-Start Request in		of the SYN/ACK packet. Host B also sends a Quick-Start Request in
	the IP header of the SYN/ACK packet.		the IP header of the SYN/ACK packet.
	* Routers along the reverse path modify the Quick-Start Request as		* Routers along the reverse path modify the Quick-Start Request as
	appropriate.		appropriate.
	* Host A receives the Quick-Start Response in the SYN/ACK packet,		* Host A receives the Quick-Start Response in the SYN/ACK packet, and
	and checks the TTL Diff, Rate Request, and QS Nonce for validity.		checks the TTL Diff, Rate Request, and QS Nonce for validity. If
	If they are valid, then Host A sets its initial congestion window		they are valid, then Host A sets its initial congestion window
	appropriately, and sets up rate-based pacing to be used with the		appropriately, and sets up rate-based pacing to be used with the
	initial window. If the Quick-Start Response is not valid, then Host		initial window. If the Quick-Start Response is not valid, then
	A uses TCP's default initial window. In either case, Host A sends a		Host A uses TCP's default initial window. In either case, Host A
	Report of Approved Rate.		sends a Report of Approved Rate.
	Host A also calculates the TTL Diff for the Quick-Start Request in		Host A also calculates the TTL Diff for the Quick-Start Request in
	the incoming SYN/ACK packet, and sends a Quick-Start Response in the		the incoming SYN/ACK packet, and sends a Quick-Start Response in
	TCP header of the ACK packet.		the TCP header of the ACK packet.
	* Host B receives the Quick-Start Response in an ACK packet, and		* Host B receives the Quick-Start Response in an ACK packet, and
	checks the TTL Diff, Rate Request, and QS Nonce for validity. If		checks the TTL Diff, Rate Request, and QS Nonce for validity. If
	the Quick-Start Response is valid, then Host B sets its initial		the Quick-Start Response is valid, then Host B sets its initial
	congestion window appropriately, and sets up rate-based pacing to be		congestion window appropriately, and sets up rate-based pacing to
	used with its initial window. If the Quick-Start Response is not		be used with its initial window. If the Quick-Start Response is
	valid, then Host B uses TCP's default initial window. In either		not valid, then Host B uses TCP's default initial window. In
	case, Host B sends a Report of Approved Rate.		either case, Host B sends a Report of Approved Rate.
	5. Quick-Start and IPsec AH		5. Quick-Start and IPsec AH
	This section shows that Quick-Start is compatible with IPsec AH		This section shows that Quick-Start is compatible with IPsec
	(Authentication Header). AH uses an Integrity Check Value (ICV) in		Authentication Header (AH). AH uses an Integrity Check Value (ICV)
	the IPsec Authentication Header to verify both message		in the IPsec Authentication Header to verify both message
	authentication and integrity ([RFC4302], page 85). Changes to the		authentication and integrity [RFC4302]. Changes to the Quick-Start
	Quick-Start option in the IP header do not affect this AH ICV. The		Option in the IP header do not affect this AH ICV. The tunnel
	tunnel considerations in Section 6 below apply to all IPsec tunnels,		considerations in Section 6 below apply to all IPsec tunnels,
	regardless of what IPsec headers or processing are used in		regardless of what IPsec headers or processing are used in
	conjunction with the tunnel.		conjunction with the tunnel.
	Because the contents of the Quick-Start option can change along the		Because the contents of the Quick-Start Option can change along the
	path, it is important that these changes not affect the IPsec		path, it is important that these changes not affect the IPsec
	Authentication Header Integrity Check Value (AH ICV). For IPv4, RFC		Authentication Header Integrity Check Value (AH ICV). For IPv4, RFC
	4302 requires that unrecognized IPv4 options be zeroed for AH ICV		4302 requires that unrecognized IPv4 options be zeroed for AH ICV
	computation purposes, so Quick-Start IP Option data changing en		computation purposes, so Quick-Start IP Option data changing en route
	route does not cause problems with existing IPsec AH implementations		does not cause problems with existing IPsec AH implementations for
	for IPv4. If the Quick-Start option is recognized, it MUST be		IPv4. If the Quick-Start Option is recognized, it MUST be treated as
	treated as a mutable IPv4 option, and hence be completely zeroed for		a mutable IPv4 option, and hence be completely zeroed for AH ICV
	AH ICV calculation purposes. IPv6 option numbers explicitly		calculation purposes. IPv6 option numbers explicitly indicate
	indicate whether the option is mutable; the 3rd highest order bit in		whether the option is mutable; the third-highest order bit in the
	the IANA-allocated option type has the value 1 to indicate that the		IANA-allocated option type has the value 1 to indicate that the
	Quick-Start option data can change en route. RFC 4302 requires that		Quick-Start Option data can change en route. RFC 4302 requires that
	the option data of any such option be zeroed for AH ICV computation		the option data of any such option be zeroed for AH ICV computation
	purposes. Therefore changes to the Quick-Start option in the IP		purposes. Therefore, changes to the Quick-Start Option in the IP
	header do not affect the calculation of the AH ICV.		header do not affect the calculation of the AH ICV.
	6. Quick-Start in IP Tunnels and MPLS		6. Quick-Start in IP Tunnels and MPLS
	This section considers interactions between Quick-Start and IP		This section considers interactions between Quick-Start and IP
	tunnels, including IPsec ([RFC4301]), IP in IP [RFC2003], GRE		tunnels, including IPsec ([RFC4301]), IP in IP [RFC2003], GRE
	[RFC2784], and others. This section also considers interactions		[RFC2784], and others. This section also considers interactions
	between Quick-Start and MPLS [RFC3031].		between Quick-Start and MPLS [RFC3031].
	In the discussion, we use TTL Diff, defined earlier as the		In the discussion, we use TTL Diff, defined earlier as the difference
	difference between the IP TTL and the Quick-Start TTL, mod 256.		between the IP TTL and the Quick-Start TTL, mod 256. Recall that the
	Recall that the sender considers the Quick-Start request approved		sender considers the Quick-Start Request approved only if the value
	only if the value of TTL Diff for the packet entering the network is		of TTL Diff for the packet entering the network is the same as the
	the same as the value of TTL Diff for the packet exiting the		value of TTL Diff for the packet exiting the network.
	network.
	Simple tunnels: IP tunnel modes are generally based on adding a new		Simple tunnels: IP tunnel modes are generally based on adding a new
	"outer" IP header that encapsulates the original or "inner" IP		"outer" IP header that encapsulates the original or "inner" IP header
	header and its associated packet. In many cases, the new "outer" IP		and its associated packet. In many cases, the new "outer" IP header
	header may be added and removed at intermediate points along a path,		may be added and removed at intermediate points along a path,
	enabling the network to establish a tunnel without requiring		enabling the network to establish a tunnel without requiring endpoint
	endpoint participation. We denote tunnels that specify that the		participation. We denote tunnels that specify that the outer header
	outer header be discarded at tunnel egress as "simple tunnels", and		be discarded at tunnel egress as "simple tunnels", and we denote
	we denote tunnels where the egress saves and uses information from		tunnels where the egress saves and uses information from the outer
	the outer header before discarding it as "non-simple tunnels". An		header before discarding it as "non-simple tunnels". An example of a
	example of a "non-simple tunnel" would be a tunnel configured to		"non-simple tunnel" would be a tunnel configured to support ECN,
	support ECN, where the egress router might copy the ECN codepoint in		where the egress router might copy the ECN codepoint in the outer
	the outer header to the inner header before discarding the outer		header to the inner header before discarding the outer header
	header [RFC3168].		[RFC3168].
	__ Tunnels Compatible with Quick-Start		__ Tunnels Compatible with Quick-Start
	/		/
	Simple Tunnels __/		Simple Tunnels __/
	\		\
	\__ Tunnels Not Compatible with Quick-Start		\__ Tunnels Not Compatible with Quick-Start
	(False Positives!)		(False Positives!)
	__ Tunnels Supporting Quick-Start		__ Tunnels Supporting Quick-Start
	/		/
	skipping to change at page 40, line 15		skipping to change at page 32, line 15
	Tunnels that are compatible with Quick-Start: We say that an IP		Tunnels that are compatible with Quick-Start: We say that an IP
	tunnel `is not compatible with Quick-Start' if the use of a Quick-		tunnel `is not compatible with Quick-Start' if the use of a Quick-
	Start Request over such a tunnel allows false positives, where the		Start Request over such a tunnel allows false positives, where the
	TCP sender incorrectly believes that the Quick-Start Request was		TCP sender incorrectly believes that the Quick-Start Request was
	approved by all routers along the path. If the use of Quick-Start		approved by all routers along the path. If the use of Quick-Start
	over the tunnel does not cause false positives, we say that the IP		over the tunnel does not cause false positives, we say that the IP
	tunnel `is compatible with Quick-Start'.		tunnel `is compatible with Quick-Start'.
	If the IP TTL of the inner header is decremented during forwarding		If the IP TTL of the inner header is decremented during forwarding
	before tunnel encapsulation takes place, then the simple tunnel is		before tunnel encapsulation takes place, then the simple tunnel is
	compatible with Quick-Start, with Quick-Start requests being		compatible with Quick-Start, with Quick-Start Requests being
	rejected. Section 6.1 describes in more detail the ways that a		rejected. Section 6.1 describes in more detail the ways that a
	simple tunnel can be compatible with Quick-Start.		simple tunnel can be compatible with Quick-Start.
	There are some simple tunnels that are not compatible with Quick-		There are some simple tunnels that are not compatible with Quick-
	Start, allowing `false positives' where the TCP sender incorrectly		Start, allowing `false positives' where the TCP sender incorrectly
	believes that the Quick-Start Request was approved by all routers		believes that the Quick-Start Request was approved by all routers
	along the path. This is discussed in Section 6.2 below.		along the path. This is discussed in Section 6.2 below.
	One of our tasks in the future will be to investigate the occurrence		One of our tasks in the future will be to investigate the occurrence
	of tunnels that are not compatible with Quick-Start, and to track		of tunnels that are not compatible with Quick-Start, and to track the
	the extent to which such tunnels are modified over time. The		extent to which such tunnels are modified over time. The evaluation
	evaluation of the problem of false positives from tunnels that are		of the problem of false positives from tunnels that are not
	not compatible with Quick-Start will affect the progression of		compatible with Quick-Start will affect the progression of Quick-
	Quick-Start from Experimental to Proposed Standard, and will affect		Start from Experimental to Proposed Standard, and will affect the
	the degree of deployment of Quick-Start while in Experimental mode.		degree of deployment of Quick-Start while in Experimental mode.
	Tunnels that support Quick-Start: We say that an IP tunnel `supports		Tunnels that support Quick-Start: We say that an IP tunnel `supports
	Quick-Start' if it allows routers along the tunnel path to process		Quick-Start' if it allows routers along the tunnel path to process
	the Quick-Start Request and give feedback, resulting in the		the Quick-Start Request and give feedback, resulting in the
	appropriate possible acceptance of the Quick-Start request. Some		appropriate possible acceptance of the Quick-Start Request. Some
	tunnels that are compatible with Quick-Start support Quick-Start,		tunnels that are compatible with Quick-Start support Quick-Start,
	while others do not. We note that a simple tunnel is not able to		while others do not. We note that a simple tunnel is not able to
	support Quick-Start.		support Quick-Start.
	From a security point of view, the use of Quick-Start in the outer		From a security point of view, the use of Quick-Start in the outer
	header of an IP tunnel might raise security concerns because an		header of an IP tunnel might raise security concerns because an
	adversary could tamper with the Quick-Start information that		adversary could tamper with the Quick-Start information that
	propagates beyond the tunnel endpoint, or because the Quick-Start		propagates beyond the tunnel endpoint, or because the Quick-Start
	Option exposes information to network scanners. Our approach is to		Option exposes information to network scanners. Our approach is to
	make supporting Quick-Start an option for IP tunnels. That is, in		make supporting Quick-Start an option for IP tunnels. That is, in
	environments or tunneling protocols where the risks of using Quick-		environments or tunneling protocols where the risks of using Quick-
	Start are judged to outweigh its benefits, the tunnel can simply		Start are judged to outweigh its benefits, the tunnel can simply
	delete the Quick-Start option or zero the Quick-Start rate request		delete the Quick-Start Option or zero the Quick-Start rate request
	and QS TTL fields before encapsulation. The result is that there		and QS TTL fields before encapsulation. The result is that there are
	are two viable options for IP tunnels to be compatible with Quick-		two viable options for IP tunnels to be compatible with Quick-Start.
	Start. The first option is the simple tunnel described above and in		The first option is the simple tunnel described above and in Section
	Section 6.1, where the tunnel is compatible with Quick-Start but		6.1, where the tunnel is compatible with Quick-Start but does not
	does not support Quick-Start, where all Quick-Start requests along		support Quick-Start, where all Quick-Start Requests along the path
	the path will be rejected. The second approach is a Quick-Start-		will be rejected. The second approach is a Quick-Start-capable mode,
	capable mode, described in Section 6.3, where the tunnel actively		described in Section 6.3, where the tunnel actively supports Quick-
	supports Quick-Start.		Start.
	6.1. Simple Tunnels That Are Compatible with Quick-Start		6.1. Simple Tunnels that Are Compatible with Quick-Start
	This section describes the ways that a simple tunnel can be		This section describes the ways that a simple tunnel can be
	compatible with Quick-Start but not support Quick-Start, resulting		compatible with Quick-Start but not support Quick-Start, resulting in
	in the rejection of all Quick-Start requests that traverse the		the rejection of all Quick-Start Requests that traverse the tunnel.
	tunnel.
	If the tunnel ingress for the simple tunnel is at a router, the IP		If the tunnel ingress for the simple tunnel is at a router, the IP
	TTL of the inner header is generally decremented during forwarding		TTL of the inner header is generally decremented during forwarding
	before tunnel encapsulation takes place. In this case TTL Diff will		before tunnel encapsulation takes place. In this case, TTL Diff will
	be changed, correctly causing the Quick-Start request to be		be changed, correctly causing the Quick-Start Request to be rejected.
	rejected. For a simple tunnel it is preferable if the Quick-Start		For a simple tunnel, it is preferable if the Quick-Start Request is
	Request is not copied to the outer header, saving the routers within		not copied to the outer header, saving the routers within the tunnel
	the tunnel from unnecessarily processing the Quick-Start request.		from unnecessarily processing the Quick-Start Request. However, the
	However, the Quick-Start request will be rejected correctly in this		Quick-Start Request will be rejected correctly in this case whether
	case whether or not the Quick-Start Request is copied to the outer		or not the Quick-Start Request is copied to the outer header.
	header.
	6.1.1. Simple Tunnels that are Aware of Quick-Start		6.1.1. Simple Tunnels that Are Aware of Quick-Start
	If a tunnel ingress is aware of Quick-Start, but does not want to		If a tunnel ingress is aware of Quick-Start, but does not want to
	support Quick-Start, then the tunnel ingress MUST either zero the		support Quick-Start, then the tunnel ingress MUST either zero the
	Quick-Start rate request, QS TTL, and QS Nonce fields or remove the		Quick-Start rate request, QS TTL, and QS Nonce fields, or remove the
	Quick-Start option from the inner header before encapsulation.		Quick-Start Option from the inner header before encapsulation.
	Section 6.3 describes the procedures for a tunnel that does want to		Section 6.3 describes the procedures for a tunnel that does want to
	support Quick-Start.		support Quick-Start.
	Deleting the Quick-Start option or zeroing the Quick-Start rate		Deleting the Quick-Start Option or zeroing the Quick-Start rate
	request *after decapsulation* also serves to prevent the propagation		request *after decapsulation* also serves to prevent the propagation
	of Quick-Start information, and is compatible with Quick-Start. If		of Quick-Start information, and is compatible with Quick-Start. If
	the outer header does not contain a Quick-Start Request, a Quick-		the outer header does not contain a Quick-Start Request, a Quick-
	Start-aware tunnel egress MUST reject the inner Quick-Start Request		Start-aware tunnel egress MUST reject the inner Quick-Start Request
	by zeroing the Rate Request field in the inner header, or by		by zeroing the Rate Request field in the inner header, or by deleting
	deleting the Quick-Start option.		the Quick-Start Option.
	If the tunnel ingress is at a sending host or router where the IP		If the tunnel ingress is at a sending host or router where the IP TTL
	TTL is not decremented prior to encapsulation, and neither tunnel		is not decremented prior to encapsulation, and neither tunnel
	endpoint is aware of Quick-Start, then this allows false positives,		endpoint is aware of Quick-Start, then this allows false positives,
	described in the section below.		described in the section below.
	6.2. Simple Tunnels That Are Not Compatible with Quick-Start		6.2. Simple Tunnels that Are Not Compatible with Quick-Start
	Sometimes a tunnel implementation that does not support Quick-Start		Sometimes a tunnel implementation that does not support Quick-Start
	is independent of the TCP sender or a router implementation that		is independent of the TCP sender or a router implementation that
	supports Quick-Start. In these cases it is possible that a Quick-		supports Quick-Start. In these cases, it is possible that a Quick-
	Start Request gets erroneously approved without the routers in the		Start Request gets erroneously approved without the routers in the
	tunnel having individually approved the request, causing a false		tunnel having individually approved the request, causing a false
	positive.		positive.
	If a tunnel ingress is a separate component from the TCP sender or		If a tunnel ingress is a separate component from the TCP sender or IP
	IP forwarding, it is possible that a packet with a Quick-Start		forwarding, it is possible that a packet with a Quick-Start option is
	option is encapsulated without the IP TTL being decremented first,		encapsulated without the IP TTL being decremented first, or with both
	or with both IP TTL and QS TTL being decremented before the tunnel		IP TTL and QS TTL being decremented before the tunnel encapsulation
	encapsulation takes place. If the tunnel ingress does not know about		takes place. If the tunnel ingress does not know about Quick-Start,
	Quick-Start, a valid Quick-Start Request with unchanged TTL Diff		a valid Quick-Start Request with unchanged TTL Diff traverses in the
	traverses in the inner header, while the outer header most likely		inner header, while the outer header most likely does not carry a
	does not carry a Quick-Start Request. If the tunnel egress also		Quick-Start Request. If the tunnel egress also does not support
	does not support Quick-Start, it remains possible that the Quick-		Quick-Start, it remains possible that the Quick-Start Request would
	Start Request would be falsely approved, because the packet is		be falsely approved, because the packet is decapsulated using the
	decapsulated using the Quick-Start request from the inner header,		Quick-Start Request from the inner header, and the value of TTL Diff
	and the value of TTL Diff echoed to the sender remains unchanged.		echoed to the sender remains unchanged. For example, such a scenario
	For example, such a scenario can occur with a Bump-In-The-Stack		can occur with a Bump-In-The-Stack (BITS), an IPsec encryption
	(BITS), an IPSec encryption implementation where the data encryption		implementation where the data encryption occurs between the network
	occurs between the network drivers and the TCP/IP protocol stack		drivers and the TCP/IP protocol stack [RFC4301].
	[RFC4301].
	As one example, if a remote access VPN client uses a BITS structure,		As one example, if a remote access VPN client uses a BITS structure,
	then Quick-Start obstacles between the client and the VPN gateway		then Quick-Start obstacles between the client and the VPN gateway
	won't be seen. This is a particular problem because the path		won't be seen. This is a particular problem because the path between
	between the client and the VPN gateway is likely to contain the most		the client and the VPN gateway is likely to contain the most
	congested part of the path. Because most VPN clients are reported		congested part of the path. Because most VPN clients are reported to
	to use BITS [H05], we will explore this in more detail.		use BITS [H05], we will explore this in more detail.
	A Bump-In-The-Wire (BITW) is an IPSec encryption implementation		A Bump-In-The-Wire (BITW) is an IPsec encryption implementation where
	where the encryption occurs on an outboard processor, offloading the		the encryption occurs on an outboard processor, offloading the
	encryption processing overhead from the host or router [RFC4301].		encryption processing overhead from the host or router [RFC4301].
	The BITW device is usually IP addressable, which means that the IP		The BITW device is usually IP addressable, which means that the IP
	TTL is decremented before the packet is passed to the BITW. If the		TTL is decremented before the packet is passed to the BITW. If the
	QS TTL is not decremented, then the value of TTL Diff is changed,		QS TTL is not decremented, then the value of TTL Diff is changed, and
	and the Quick-Start request will be denied. However, if the BITW		the Quick-Start Request will be denied. However, if the BITW
	supports a host and does not have its own IP address, then the IP		supports a host and does not have its own IP address, then the IP TTL
	TTL is not decremented before the packet is passed from the host to		is not decremented before the packet is passed from the host to the
	the BITW, and a false positive could occur.		BITW, and a false positive could occur.
	Other tunnels that need to be looked at are IP tunnels over non-		Other tunnels that need to be looked at are IP tunnels over non-
	network protocols, such as IP over TCP and IP over UDP [RFC3948],		network protocols, such as IP over TCP and IP over UDP [RFC3948], and
	and tunnels using the Layer Two Tunneling Protocol [RFC2661].		tunnels using the Layer Two Tunneling Protocol [RFC2661].
	Section 9.2 discusses the related issue of non-IP queues, such as		Section 9.2 discusses the related issue of non-IP queues, such as
	layer-two Ethernet or ATM networks, as another instance of possible		layer-two Ethernet or ATM (Asynchronous Transfer Mode) networks, as
	bottlenecks that do not participate in the Quick-Start feedback.		another instance of possible bottlenecks that do not participate in
			the Quick-Start feedback.
	6.3. Tunnels That Support Quick-Start		6.3. Tunnels That Support Quick-Start
	This section discusses tunnels configured to support Quick-Start.		This section discusses tunnels configured to support Quick-Start.
	If the tunnel ingress node chooses to locally approve the Quick-		If the tunnel ingress node chooses to locally approve the Quick-
	Start request, then the ingress node MUST decrement the Quick-Start		Start Request, then the ingress node MUST decrement the Quick-Start
	TTL at the same time it decrements the IP TTL, and MUST copy IP TTL		TTL at the same time it decrements the IP TTL, and MUST copy IP TTL
	and the Quick-Start option from the inner IP header to the outer		and the Quick-Start Option from the inner IP header to the outer
	header. During encapsulation, the tunnel ingress MUST zero the		header. During encapsulation, the tunnel ingress MUST zero the
	Quick-Start rate request field in the inner header to ensure that		Quick-Start rate request field in the inner header to ensure that the
	the Quick-Start request will be rejected if the tunnel egress does		Quick-Start Request will be rejected if the tunnel egress does not
	not support Quick-Start.		support Quick-Start.
	If the tunnel ingress node does not choose to locally approve the		If the tunnel ingress node does not choose to locally approve the
	Quick-Start request, then it MUST either delete the Quick-Start		Quick-Start Request, then it MUST either delete the Quick-Start
	option from the inner header before encapsulation, or zero the QS		option from the inner header before encapsulation, or zero the QS TTL
	TTL and the Rate Request fields before encapsulation.		and the Rate Request fields before encapsulation.
	Upon decapsulation, if the outer header contains a Quick-Start		Upon decapsulation, if the outer header contains a Quick-Start
	option, the tunnel egress MUST copy the IP TTL and the Quick-Start		option, the tunnel egress MUST copy the IP TTL and the Quick-Start
	option from the outer IP header to the inner header.		option from the outer IP header to the inner header.
	IPsec uses the IKE (Internet Key Exchange) Protocol for security		IPsec uses the IKE (Internet Key Exchange) Protocol for security
	associations. We do not consider the interactions between Quick-		associations. We do not consider the interactions between Quick-
	Start and IPsec with IKEv1 [RFC2409] in this document. Now that the		Start and IPsec with IKEv1 [RFC2409] in this document. Now that the
	RFC for IKEv2 [RFC4306] is published, we plan to specify a		RFC for IKEv2 [RFC4306] is published, we plan to specify a
	modification of IPsec to allow the support of Quick-Start to be		modification of IPsec to allow the support of Quick-Start to be
	negotiated; this modification will specify the negotiation between		negotiated; this modification will specify the negotiation between
	tunnel endpoints to allow or forbid support for Quick-Start within		tunnel endpoints to allow or forbid support for Quick-Start within
	the tunnel. This was done for ECN for IPsec tunnels, with IKEv1		the tunnel. This was done for ECN for IPsec tunnels, with IKEv1
	[RFC3168, Section 9.2]. This negotiation of Quick-Start capability		[RFC3168, Section 9.2]. This negotiation of Quick-Start capability
	in an IPsec tunnel will be specified in a separate IPsec document.		in an IPsec tunnel will be specified in a separate IPsec document.
	This document will also include a discussion of the potential		This document will also include a discussion of the potential effects
	effects of an adversary's modifications of the Quick-Start field (as		of an adversary's modifications of the Quick-Start field (as in
	in Sections 18 and 19 of RFC 3168), and of the security		Sections 18 and 19 of RFC 3168), and of the security considerations
	considerations of exposing the Quick-Start rate request to network		of exposing the Quick-Start rate request to network scanners.
	scanners.
	6.4. Quick-Start and MPLS		6.4. Quick-Start and MPLS
	The behavior of Quick-Start with MPLS is similar to the behavior of		The behavior of Quick-Start with MPLS is similar to the behavior of
	Quick-Start with IP Tunnels. For those MPLS paths where the IP TTL		Quick-Start with IP Tunnels. For those MPLS paths where the IP TTL
	is decremented as part of traversing the MPLS path, these paths are		is decremented as part of traversing the MPLS path, these paths are
	compatible with Quick-Start, but do not support Quick-Start; Quick-		compatible with Quick-Start, but do not support Quick-Start; Quick-
	Start requests traversing these paths will be correctly understood		Start Requests that are traversing these paths will be correctly
	by the transport sender as having been denied. Any MPLS paths where		understood by the transport sender as having been denied. Any MPLS
	the IP TTL is not decremented as part of traversing the MPLS path		paths where the IP TTL is not decremented as part of traversing the
	would be not compatible with Quick-Start; such paths would result in		MPLS path would be not compatible with Quick-Start; such paths would
	false positives, where the TCP sender incorrectly believes that the		result in false positives, where the TCP sender incorrectly believes
	Quick-Start Request was approved by all routers along the path.		that the Quick-Start Request was approved by all routers along the
			path.
	For cases where the ingress node to the MPLS path is aware of Quick-		For cases where the ingress node to the MPLS path is aware of Quick-
	Start, this node should either zero the Quick-Start rate request, QS		Start, this node should either zero the Quick-Start rate request, QS
	TTL, and QS Nonce fields or remove the Quick-Start option from the		TTL, and QS Nonce fields, or remove the Quick-Start Option from the
	IP header.		IP header.
	7. The Quick-Start Mechanism in other Transport Protocols		7. The Quick-Start Mechanism in Other Transport Protocols
	The section earlier specified the use of Quick-Start in TCP. In		The section earlier specified the use of Quick-Start in TCP. In this
	this section, we generalize this to give guidelines for the use of		section, we generalize this to give guidelines for the use of Quick-
	Quick-Start with other transport protocols. We also discuss briefly		Start with other transport protocols. We also discuss briefly how
	how Quick-Start could be specified for other transport protocols.		Quick-Start could be specified for other transport protocols.
	The general guidelines for Quick-Start in transport protocols are as		The general guidelines for Quick-Start in transport protocols are as
	follows:		follows:
	* Quick-Start is only specified for unicast transport protocols with		* Quick-Start is only specified for unicast transport protocols with
	appropriate congestion control mechanisms. Note: Quick-Start is not		appropriate congestion control mechanisms. Note: Quick-Start is
	a replacement for standard congestion control techniques, but meant		not a replacement for standard congestion control techniques, but
	to augment their operation.		meant to augment their operation.
	* A transport-level mechanism is needed for the Quick-Start response		* A transport-level mechanism is needed for the Quick-Start Response
	from the receiver to the sender. This response contains the Rate		from the receiver to the sender. This response contains the Rate
	Request, TTL Diff, and QS Nonce.		Request, TTL Diff, and QS Nonce.
	* The sender checks the validity of the Quick-Start response.		* The sender checks the validity of the Quick-Start Response.
	* The sender has an estimate of the round-trip time, and translates		* The sender has an estimate of the round-trip time, and translates
	the Quick-Start response into an allowed window or allowed sending		the Quick-Start Response into an allowed window or allowed sending
	rate. The sender sends a Report of the Approved Rate. The sender		rate. The sender sends a Report of the Approved Rate. The sender
	starts sending Quick-Start packets, rate-paced out at the approved		starts sending Quick-Start packets, rate-paced out at the approved
	sending rate.		sending rate.
	* After the sender receives the first acknowledgement packet for a		* After the sender receives the first acknowledgement packet for a
	Quick-Start packet, no more Quick-Start packets are sent. The		Quick-Start packet, no more Quick-Start packets are sent. The
	sender adjusts its current congestion window or sending rate to be		sender adjusts its current congestion window or sending rate to be
	consistent with the actual amount of data that was transmitted in		consistent with the actual amount of data that was transmitted in
	that round-trip time.		that round-trip time.
	* When the last Quick-Start packet is acknowledged, the sender		* When the last Quick-Start packet is acknowledged, the sender
	continues using the standard congestion control mechanisms of that		continues using the standard congestion control mechanisms of that
	protocol.		protocol.
	* If one of the Quick-Start packets is lost, then the sender reverts		* If one of the Quick-Start packets is lost, then the sender reverts
	to the standard congestion control method of that protocol that		to the standard congestion control method of that protocol that
	would have been used if the Quick-Start request had not been		would have been used if the Quick-Start Request had not been
	approved. In addition, the sender takes into account the		approved. In addition, the sender takes into account the
	information that the Quick-Start congestion window was too large		information that the Quick-Start congestion window was too large
	(e.g., by decreasing ssthresh in TCP).		(e.g., by decreasing ssthresh in TCP).
	8. Using Quick-Start		8. Using Quick-Start
	8.1. Determining the Rate to Request		8.1. Determining the Rate to Request
	As discussed in [SAF06], the data sender does not necessarily have		As discussed in [SAF06], the data sender does not necessarily have
	information about the size of the data transfer at connection		information about the size of the data transfer at connection
	initiation; for example, in request-response protocols such as HTTP,		initiation; for example, in request-response protocols such as HTTP,
	the server doesn't know the size or name of the requested object		the server doesn't know the size or name of the requested object
	during connection initiation. [SAF06] explores some of the		during connection initiation. [SAF06] explores some of the
	performance implications of overly-large Quick-Start requests, and		performance implications of overly large Quick-Start Requests, and
	discusses heuristics that end-nodes could use to size their requests		discusses heuristics that end-nodes could use to size their requests
	appropriately. For example, the sender might have information about		appropriately. For example, the sender might have information about
	the bandwidth of the last-mile hop, the size of the local socket		the bandwidth of the last-mile hop, the size of the local socket
	buffer, or of the TCP receive window, and could use this information		buffer, or of the TCP receive window, and could use this information
	in determining the rate to request. Web servers that mostly have		in determining the rate to request. Web servers that mostly have
	small objects to transfer might decide not to use Quick-Start at		small objects to transfer might decide not to use Quick-Start at all,
	all, since Quick-Start would be of little benefit to them.		since Quick-Start would be of little benefit to them.
	Quick-Start will be more effective if Quick-Start requests are not		Quick-Start will be more effective if Quick-Start Requests are not
	larger than necessary; every Quick-Start request that is approved		larger than necessary; every Quick-Start Request that is approved but
	but not used (or not fully used) takes away from the bandwidth pool		not used (or not fully used) takes away from the bandwidth pool
	available for granting successive Quick-Start requests.		available for granting successive Quick-Start Requests.
	8.2. Deciding the Permitted Rate Request at a Router		8.2. Deciding the Permitted Rate Request at a Router
	In this section we briefly outline how a router might decide whether		In this section, we briefly outline how a router might decide whether
	or not to approve a Quick-Start Request. The router should ask the		or not to approve a Quick-Start Request. The router should ask the
	following questions:		following questions:
	* Has the router's output link been underutilized for some time		* Has the router's output link been underutilized for some time
	(e.g., several seconds).		(e.g., several seconds)?
	* Would the output link remain underutilized if the arrival rate was		* Would the output link remain underutilized if the arrival rate were
	to increase by the aggregate rate requests that the router has		to increase by the aggregate rate requests that the router has
	approved over the last fraction of a second?		approved over the last fraction of a second?
	In order to answer the last question, the router must have some		In order to answer the last question, the router must have some
	knowledge of the available bandwidth on the output link and of the		knowledge of the available bandwidth on the output link and of the
	Quick-Start bandwidth that could arrive due to recently-approved		Quick-Start bandwidth that could arrive due to recently approved
	Quick-Start Requests. In this way, if an underutilized router		Quick-Start Requests. In this way, if an underutilized router
	experiences a flood of Quick-Start requests, the router can begin to		experiences a flood of Quick-Start Requests, the router can begin to
	deny Quick-Start requests while the output link is still		deny Quick-Start Requests while the output link is still
	underutilized.		underutilized.
	A simple way for the router to keep track of the potential bandwidth		A simple way for the router to keep track of the potential bandwidth
	from recently-approved requests is to maintain two counters, one for		from recently approved requests is to maintain two counters: one for
	the total aggregate Rate Requests that have been approved in the		the total aggregate Rate Requests that have been approved in the
	current time interval [T1, T2], and one for the total aggregate Rate		current time interval [T1, T2], and one for the total aggregate Rate
	Requests approved over a previous time interval [T0, T1]. However,		Requests approved over a previous time interval [T0, T1]. However,
	this document doesn't specify router algorithms for approving Quick-		this document doesn't specify router algorithms for approving Quick-
	Start requests, or make requirements for the appropriate time		Start Requests, or make requirements for the appropriate time
	intervals for remembering the aggregate approved Quick-Start		intervals for remembering the aggregate approved Quick-Start
	bandwidth. A possible router algorithm is given in Appendix E, and		bandwidth. A possible router algorithm is given in Appendix E, and
	more discussion of these issues is available in [SAF06].)		more discussion of these issues is available in [SAF06].
	* If the router's output link has been underutilized and the		* If the router's output link has been underutilized and the
	aggregate of the Quick-Start Request Rate options granted is low		aggregate of the Quick-Start Request Rate options granted is low
	enough to prevent a near-term bandwidth shortage, then the router		enough to prevent a near-term bandwidth shortage, then the router
	could approve the Quick-Start Request.		could approve the Quick-Start Request.
	Section 10.2 discusses some of the implementation issues in		Section 10.2 discusses some of the implementation issues in
	processing Quick-Start requests at routers. [SAF06] discusses the		processing Quick-Start Requests at routers. [SAF06] discusses the
	range of possible Quick-Start algorithms at the router for deciding		range of possible Quick-Start algorithms at the router for deciding
	whether to approve a Quick-Start request. In order to explore the		whether to approve a Quick-Start Request. In order to explore the
	limits of the possible functionality at routers, [SAF06] also		limits of the possible functionality at routers, [SAF06] also
	discusses Extreme Quick-Start mechanisms at routers, where the		discusses Extreme Quick-Start mechanisms at routers, where the router
	router would keep per-flow state concerning approved Quick-Start		would keep per-flow state concerning approved Quick-Start requests.
	requests.
	9. Evaluation of Quick-Start		9. Evaluation of Quick-Start
	9.1. Benefits of Quick-Start		9.1. Benefits of Quick-Start
	The main benefit of Quick-Start is the faster start-up for the		The main benefit of Quick-Start is the faster start-up for the
	transport connection itself. For a small TCP transfer of one to		transport connection itself. For a small TCP transfer of one to five
	five packets, Quick-Start is probably of very little benefit; at		packets, Quick-Start is probably of very little benefit; at best, it
	best, it might shorten the connection lifetime from three to two		might shorten the connection lifetime from three to two round-trip
	round-trip times (including the round-trip time for connection		times (including the round-trip time for connection establishment).
	establishment). Similarly, for a very large transfer, where the		Similarly, for a very large transfer, where the slow-start phase
	slow-start phase would have been only a small fraction of the		would have been only a small fraction of the connection lifetime,
	connection lifetime, Quick-Start would be of limited benefit.		Quick-Start would be of limited benefit. Quick-Start would not
	Quick-Start would not significantly shorten the connection lifetime,		significantly shorten the connection lifetime, but it might eliminate
	but it might eliminate or at least shorten the start-up phase.		or at least shorten the start-up phase. However, for moderate-sized
	However, for moderate-sized connections in a well-provisioned		connections in a well-provisioned environment, Quick-Start could
	environment, Quick-Start could possibly allow the entire transfer of		possibly allow the entire transfer of M packets to be completed in
	M packets to be completed in one round-trip time (after the initial		one round-trip time (after the initial round-trip time for the SYN
	round-trip time for the SYN exchange), instead of the log_2(M)-2		exchange), instead of the log_2(M)-2 round-trip times that it would
	round-trip times that it would normally take for the data transfer,		normally take for the data transfer, in an uncongested environments
	in an uncongested environments (assuming an initial window of four		(assuming an initial window of four packets).
	packets).
	9.2. Costs of Quick-Start		9.2. Costs of Quick-Start
	This section discusses the costs of Quick-Start for the connection		This section discusses the costs of Quick-Start for the connection
	and for the routers along the path.		and for the routers along the path.
	The cost of having a Quick-Start packet dropped:		The cost of having a Quick-Start Request packet dropped:
	For the sender the biggest risk in using Quick-Start lies in the		Measurement studies cited earlier [MAF04] suggest that on a wide
			range of paths in the Internet, TCP SYN packets containing unknown IP
			options will be dropped. Thus, for the sender one risk in using
			Quick-Start is that the packet carrying the Quick-Start Request could
			be dropped in the network. It is particularly costly to the sender
			when a TCP SYN packet is dropped, because in this case the sender
			should wait for an RTO of three seconds before re-sending the SYN
			packet, as specified in Section 4.7.2.
			The cost of having a Quick-Start data packet dropped:
			Another risk for the sender in using Quick-Start lies in the
	possibility of suffering from congestion-related losses of the		possibility of suffering from congestion-related losses of the
	Quick-Start packets. This should be an unlikely situation because		Quick-Start data packets. This should be an unlikely situation
	routers are expected to approve Quick-Start Requests only when they		because routers are expected to approve Quick-Start Requests only
	are significantly underutilized. However, a transient increase in		when they are significantly underutilized. However, a transient
	cross-traffic in one of the routers, a sudden decrease in available		increase in cross-traffic in one of the routers, a sudden decrease in
	bandwidth on one of the links, or congestion at a non-IP queue could		available bandwidth on one of the links, or congestion at a non-IP
	result in packet losses even when the Quick-Start Request was		queue could result in packet losses even when the Quick-Start Request
	approved by all of the routers along the path. If a Quick-Start		was approved by all of the routers along the path. If a Quick-Start
	packet is dropped, then the sender reverts to the congestion control		packet is dropped, then the sender reverts to the congestion control
	mechanisms it would have used if the Quick-Start request had not		mechanisms it would have used if the Quick-Start Request had not been
	been approved, so the performance cost to the connection of having a		approved, so the performance cost to the connection of having a
	Quick-Start packet dropped is small, compared to the performance		Quick-Start packet dropped is small, compared to the performance
	without Quick-Start. (On the other hand, the performance difference		without Quick-Start. (On the other hand, the performance difference
	between Quick-Start with a Quick-Start packet dropped and Quick-		between Quick-Start with a Quick-Start packet dropped and Quick-
	Start with no Quick-Start packet dropped can be considerable.)		Start with no Quick-Start packet dropped can be considerable.)
	Added complexity at routers:		Added complexity at routers:
	The main cost of Quick-Start at routers concerns the costs of added		The main cost of Quick-Start at routers concerns the costs of added
	complexity. The added complexity at the end-points is moderate, and		complexity. The added complexity at the end-points is moderate, and
	might easily be outweighed by the benefit of Quick-Start to the end		might easily be outweighed by the benefit of Quick-Start to the end
	hosts. The added complexity at the routers is also somewhat		hosts. The added complexity at the routers is also somewhat
	skipping to change at page 48, line 17		skipping to change at page 40, line 16
	Quick-Start to IP.		Quick-Start to IP.
	The slow path in routers:		The slow path in routers:
	Another drawback of Quick-Start is that packets containing the		Another drawback of Quick-Start is that packets containing the
	Quick-Start Request message might not take the fast path in routers,		Quick-Start Request message might not take the fast path in routers,
	particularly in the beginning of Quick-Start's deployment in the		particularly in the beginning of Quick-Start's deployment in the
	Internet. This would mean some extra delay for the end hosts, and		Internet. This would mean some extra delay for the end hosts, and
	extra processing burden for the routers. However, as discussed in		extra processing burden for the routers. However, as discussed in
	Sections 4.1 and 4.7, not all packets would carry the Quick-Start		Sections 4.1 and 4.7, not all packets would carry the Quick-Start
	option. In addition, for the underutilized links where Quick-Start		option. In addition, for the underutilized links where Quick-Start
	Requests could actually be approved, or in typical environments		Requests could actually be approved, or in typical environments where
	where most of the packets belong to large flows, the burden of the		most of the packets belong to large flows, the burden of the Quick-
	Quick-Start Option on routers would be considerably reduced.		Start Option on routers would be considerably reduced. Nevertheless,
	Nevertheless, it is still conceivable, in the worst case, that many		it is still conceivable, in the worst case, that many packets would
	packets would carry Quick-Start requests; this could slow down the		carry Quick-Start Requests; this could slow down the processing of
	processing of Quick-Start packets in routers considerably. As		Quick-Start packets in routers considerably. As discussed in Section
	discussed in Section 9.6, routers can easily protect against this by		9.6, routers can easily protect against this by enforcing a limit on
	enforcing a limit on the rate at which Quick-Start requests will be		the rate at which Quick-Start Requests will be considered. [RW03]
	considered. [RW03] and [RW04] contain measurements of the impact of		and [RW04] contain measurements of the impact of IP Option Processing
	IP Option Processing on packet round-trip times.		on packet round-trip times.
	Multiple paths:		Multiple paths:
	One limitation of Quick-Start is that it presumes that the data		One limitation of Quick-Start is that it presumes that the data
	packets of a connection will follow the same path as the Quick-Start		packets of a connection will follow the same path as the Quick-Start
	request packet. If this is not the case, then the connection could		request packet. If this is not the case, then the connection could
	be sending the Quick-Start packets, at the approved rate, along a		be sending the Quick-Start packets, at the approved rate, along a
	path that was already congested, or that became congested as a		path that was already congested, or that became congested as a result
	result of this connection. Thus, Quick-Start could give poor		of this connection. Thus, Quick-Start could give poor performance
	performance when there is a routing change immediately after the		when there is a routing change immediately after the Quick-Start
	Quick-Start request is approved, and the Quick-Start data packets		Request is approved, and the Quick-Start data packets follow a
	follow a different path from that of the original Quick-Start		different path from that of the original Quick-Start Request. This
	Request. This is, however, similar to what would happen, for a		is, however, similar to what would happen for a connection with
	connection with sufficient data, if the connection's path was		sufficient data, if the connection's path was changed in the middle
	changed in the middle of the connection, when the connection had		of the connection, which had already established the allowed initial
	already established the allowed initial rate.		rate.
	As specified in Section 3.3, a router that uses multipath routing		As specified in Section 3.3, a router that uses multipath routing for
	for packets within a single connection must not approve a Quick-		packets within a single connection must not approve a Quick-Start
	Start request. Quick-Start would not perform robustly in an		Request. Quick-Start would not perform robustly in an environment
	environment with multipath routing, where different packets in a		with multipath routing, where different packets in a connection
	connection routinely follow different paths. In such an		routinely follow different paths. In such an environment, the
	environment, the Quick-Start request and some fraction of the		Quick-Start Request and some fraction of the packets in the
	packets in the connection might take an underutilized path, while		connection might take an underutilized path, while the rest of the
	the rest of the packets take an alternate, congested path.		packets take an alternate, congested path.
	Non-IP queues:		Non-IP queues:
	A problem of any mechanism for feedback from routers at the IP level		A problem of any mechanism for feedback from routers at the IP level
	is that there can be queues and bottlenecks in the end-to-end path		is that there can be queues and bottlenecks in the end-to-end path
	that are not in IP-level routers. As an example, these include		that are not in IP-level routers. As an example, these include
	queues in layer-two Ethernet or ATM networks. One possibility would		queues in layer-two Ethernet or ATM networks. One possibility would
	be that an IP-level router adjacent to such a non-IP queue or		be that an IP-level router adjacent to such a non-IP queue or
	bottleneck would be configured to reject Quick-Start requests if		bottleneck would be configured to reject Quick-Start Requests if that
	that was appropriate. One would hope that in general, IP networks		was appropriate. One would hope that, in general, IP networks are
	are configured so that non-IP queues between IP routers do not end		configured so that non-IP queues between IP routers do not end up
	up being the congested bottlenecks.		being the congested bottlenecks.
	9.3. Quick-Start with QoS-enabled Traffic		9.3. Quick-Start with QoS-Enabled Traffic
	The discussion in this document has largely been of Quick-Start with		The discussion in this document has largely been of Quick-Start with
	default, best-effort traffic. However, Quick-Start could also be		default, best-effort traffic. However, Quick-Start could also be
	used by traffic using some form of differentiated services, and		used by traffic using some form of differentiated services, and
	routers could take the traffic class into account when deciding		routers could take the traffic class into account when deciding
	whether or not to grant the Quick-Start request. We don't address		whether or not to grant the Quick-Start Request. We don't address
	this context further in this paper, since it is orthogonal to the		this context further in this paper, since it is orthogonal to the
	specification of Quick-Start.		specification of Quick-Start.
	Routers are also free to take into account their own priority		Routers are also free to take into account their own priority
	classifications in processing Quick-Start requests.		classifications in processing Quick-Start Requests.
	9.4. Protection against Misbehaving Nodes		9.4. Protection against Misbehaving Nodes
	In this section we discuss the protection against senders,		In this section, we discuss the protection against senders,
	receivers, or colluding routers or middleboxes lying about the		receivers, or colluding routers or middleboxes lying about the
	Quick-Start Request.		Quick-Start Request.
	9.4.1. Misbehaving Senders		9.4.1. Misbehaving Senders
	A transport sender could try to transmit data at a higher rate than		A transport sender could try to transmit data at a higher rate than
	that approved in the Quick-Start Request. The network could use a		that approved in the Quick-Start Request. The network could use a
	traffic policer to protect against misbehaving senders that exceed		traffic policer to protect against misbehaving senders that exceed
	the approved rate, for example by dropping packets that exceed the		the approved rate, for example, by dropping packets that exceed the
	allowed transmission rate. The required Report of Approved Rate		allowed transmission rate. The required Report of Approved Rate
	allows traffic policers to check that the Report of Approved Rate		allows traffic policers to check that the Report of Approved Rate
	does not exceed the Rate Request actually approved at that point in		does not exceed the Rate Request actually approved at that point in
	the network in the previous Quick-Start Request from that		the network in the previous Quick-Start Request from that connection.
	connection. The required Approved Rate report also allows traffic		The required Approved Rate report also allows traffic policers to
	policers to check that the sender's sending rate does not exceed the		check that the sender's sending rate does not exceed the rate in the
	rate in the Report of Approved Rate.		Report of Approved Rate.
	If a router or receiver receives an Approved Rate report that is		If a router or receiver receives an Approved Rate report that is
	larger than the Rate Request in the Quick-Start request approved for		larger than the Rate Request in the Quick-Start Request approved for
	that sender for that connection in the previous round-trip time,		that sender for that connection in the previous round-trip time, then
	then the router or receiver could deny future Quick-Start requests		the router or receiver could deny future Quick-Start Requests from
	from that sender, e.g., by deleting the Quick-Start Request from		that sender, e.g., by deleting the Quick-Start Request from future
	future packets from that sender. We note that routers are not		packets from that sender. We note that routers are not required to
	required to use Approved Rate reports to check if senders are		use Approved Rate reports to check if senders are cheating; this is
	cheating; this is at the discretion of the router.		at the discretion of the router.
	If a router sees a Report of Approved Rate, and did not see an		If a router sees a Report of Approved Rate, and did not see an
	earlier Quick-Start request, then either the sender could be		earlier Quick-Start Request, then either the sender could be
	cheating, or the connection's path could have changed since the		cheating, or the connection's path could have changed since the
	Quick-Start request was sent. In either case, the router could		Quick-Start Request was sent. In either case, the router could
	decide to deny future Quick-Start requests for this connection. In		decide to deny future Quick-Start Requests for this connection. In
	particular, it is reasonable for the router to deny a Quick-Start		particular, it is reasonable for the router to deny a Quick-Start
	request if either the sender is cheating, or if the connection path		request if either the sender is cheating, or if the connection path
	suffers from path changes or multipathing.		suffers from path changes or multipathing.
	If a router approved a Quick-Start Request, but does not see a		If a router approved a Quick-Start Request, but does not see a
	subsequent Approved Rate report, then there are several		subsequent Approved Rate report, then there are several
	possibilities: (1) the request was denied and/or dropped downstream		possibilities: (1) the request was denied and/or dropped downstream,
	and the sender did not send a Report of Approved Rate; (2) the		and the sender did not send a Report of Approved Rate; (2) the
	request was approved but the sender did not send a Report of		request was approved, but the sender did not send a Report of
	Approved Rate; (3) the Approved Rate report was dropped in the		Approved Rate; (3) the Approved Rate report was dropped in the
	network; or (4) the Approved Rate report took a different path from		network; or (4) the Approved Rate report took a different path from
	the Quick-Start Request. In any of these cases, the router would be		the Quick-Start Request. In any of these cases, the router would be
	justified in denying future Quick-Start Requests for this		justified in denying future Quick-Start Requests for this connection.
	connection.
	In any of the cases mentioned in the three paragraphs above (i.e.,		In any of the cases mentioned in the three paragraphs above (i.e., an
	an Approved Rate report that is larger than the Rate Request in the		Approved Rate report that is larger than the Rate Request in the
	earlier Quick-Start request; a Report of Approved Rate with no		earlier Quick-Start Request, a Report of Approved Rate with no
	preceding Rate Request, or a Rate Request with no Report of Approved		preceding Rate Request, or a Rate Request with no Report of Approved
	Rate), a traffic policer may assume that Quick-Start is not being		Rate), a traffic policer may assume that Quick-Start is not being
	used appropriately, or is being used in an unsuitable environment		used appropriately, or is being used in an unsuitable environment
	(e.g., with multiple paths), and take some corresponding action.		(e.g., with multiple paths), and take some corresponding action.
	What are the incentives for a sender to cheat by over-sending after		What are the incentives for a sender to cheat by over-sending after a
	a Quick-Start request? Assuming that the sender's interests are		Quick-Start Request? Assuming that the sender's interests are
	measured by a performance metric such as the completion time for its		measured by a performance metric such as the completion time for its
	connections, sometimes it might be in the sender's interests to		connections, sometimes it might be in the sender's interests to
	cheat, and sometimes it might not; in some cases it could be		cheat, and sometimes it might not; in some cases, it could be
	difficult for the sender to judge whether it would be in its		difficult for the sender to judge whether it would be in its
	interests to cheat. The incentives for a sender to cheat by over-		interests to cheat. The incentives for a sender to cheat by over-
	sending after a Quick-Start request are not that different from the		sending after a Quick-Start Request are not that different from the
	incentives for a sender to cheat by over-sending even in the absence		incentives for a sender to cheat by over-sending even in the absence
	of Quick-Start, with one difference: the use of Quick-Start could		of Quick-Start, with one difference: the use of Quick-Start could
	help a sender to evade policing actions from policers in the		help a sender evade policing actions from policers in the network.
	network. The Report of Approved Rate is designed to address this,		The Report of Approved Rate is designed to address this and to make
	to make it harder to senders to use Quick-Start to `cover' their		it harder for senders to use Quick-Start to `cover' their cheating.
	cheating.
	9.4.2. Receivers Lying about Whether the Request was Approved		9.4.2. Receivers Lying about Whether the Request was Approved
	One form of misbehavior would be for the receiver to lie to the		One form of misbehavior would be for the receiver to lie to the
	sender about whether the Quick-Start Request was approved, by		sender about whether the Quick-Start Request was approved, by falsely
	falsely reporting the TTL Diff and QS Nonce. If a router that		reporting the TTL Diff and QS Nonce. If a router that understands
	understands the Quick-Start Request denies the request by deleting		the Quick-Start Request denies the request by deleting the request or
	the request or by zeroing the QS TTL and QS Nonce, then the receiver		by zeroing the QS TTL and QS Nonce, then the receiver can "lie" about
	can ``lie" about whether the request was approved only by		whether the request was approved only by successfully guessing the
	successfully guessing the value of the TTL Diff and QS Nonce to		value of the TTL Diff and QS Nonce to report. The chance of the
	report. The chance of the receiver successfully guessing the		receiver successfully guessing the correct value for the TTL Diff is
	correct value for the TTL Diff is 1/256, and the chance of the		1/256, and the chance of the receiver successfully guessing the QS
	receiver successfully guessing the QS nonce for a reported rate		nonce for a reported rate request of K is 1/(2K).
	request of K is 1/(2K).
	However, if the Quick-Start request is denied only by a non-Quick-		However, if the Quick-Start Request is denied only by a non-Quick-
	Start-capable router, or by a router that is unable to zero the QS		Start-capable router, or by a router that is unable to zero the QS
	TTL and QS Nonce fields, then the receiver could lie about whether		TTL and QS Nonce fields, then the receiver could lie about whether
	the Quick-Start Requests were approved by modifying the QS TTL in		the Quick-Start Requests were approved by modifying the QS TTL in
	successive requests received from the same host. In particular, if		successive requests received from the same host. In particular, if
	the sender does not act on a Quick-Start Request, then the receiver		the sender does not act on a Quick-Start Request, then the receiver
	could decrement the QS TTL by one in the next request received from		could decrement the QS TTL by one in the next request received from
	that host before calculating the TTL Diff, and decrement the QS TTL		that host before calculating the TTL Diff, and decrement the QS TTL
	by two in the following received request, until the sender acts on		by two in the following received request, until the sender acts on
	one of the Quick-Start Requests.		one of the Quick-Start Requests.
	Unfortunately, if a router doesn't understand Quick-Start, then it		Unfortunately, if a router doesn't understand Quick-Start, then it is
	is not possible for that router to take an active step such as		not possible for that router to take an active step such as zeroing
	zeroing the QS TTL and QS Nonce to deny a request. As a result, the		the QS TTL and QS Nonce to deny a request. As a result, the QS TTL
	QS TTL is not a fail-safe mechanism for preventing lying by		is not a fail-safe mechanism for preventing lying by receivers in the
	receivers in the case of non-Quick-Start-capable routers.		case of non-Quick-Start-capable routers.
	What would be the incentives for a receiver to cheat in reporting on		What would be the incentives for a receiver to cheat in reporting on
	a Quick-Start request, in the absence of a mechanism such as the QS		a Quick-Start Request, in the absence of a mechanism such as the QS
	Nonce? In some cases, cheating would have been of clear benefit to		Nonce? In some cases, cheating would be of clear benefit to the
	the receiver, resulting in a faster completion time for the		receiver, resulting in a faster completion time for the transfer. In
	transfer. In other cases, where cheating would have resulted in		other cases, where cheating would result in Quick-Start packets being
	Quick-Start packets being dropped in the network, cheating might or		dropped in the network, cheating might or might not improve the
	might not have improved the receiver's performance metric, depending		receiver's performance metric, depending on the details of that
	on the details of that particular scenario.		particular scenario.
	9.4.3. Receivers Lying about the Approved Rate		9.4.3. Receivers Lying about the Approved Rate
	A second form of receiver misbehavior would be for the receiver to		A second form of receiver misbehavior would be for the receiver to
	lie to the sender about the Rate Request for an approved Quick-Start		lie to the sender about the Rate Request for an approved Quick-Start
	Request, by increasing the value of the Rate Request field.		Request, by increasing the value of the Rate Request field. However,
	However, the receiver doesn't necessarily know the Rate Request in		the receiver doesn't necessarily know the Rate Request in the
	the original Quick-Start Request sent by the sender, and a higher		original Quick-Start Request sent by the sender, and a higher Rate
	Rate Request reported by the receiver will only be considered valid		Request reported by the receiver will only be considered valid by the
	by the sender if it is no higher than the Rate Request originally		sender if it is no higher than the Rate Request originally requested
	requested by the sender. For example, if the sender sends a Quick-		by the sender. For example, if the sender sends a Quick-Start
	Start Request with a Rate Request of X, and the receiver reports		Request with a Rate Request of X, and the receiver reports receiving
	receiving a Quick-Start Request with a Rate Request of Y > X, then		a Quick-Start Request with a Rate Request of Y > X, then the sender
	the sender knows that either some router along the path		knows that either some router along the path malfunctioned
	malfunctioned (increasing the Rate Request inappropriately), or the		(increasing the Rate Request inappropriately), or the receiver is
	receiver is lying about the Rate Request in the received packet.		lying about the Rate Request in the received packet.
	If the sender sends a Quick-Start Request with a Rate Request of Z,		If the sender sends a Quick-Start Request with a Rate Request of Z,
	the receiver receives the Quick-Start Request with an approved Rate		the receiver receives the Quick-Start Request with an approved Rate
	Request of X, and reports a Rate Request of Y, for X < Y <= Z, then		Request of X, and reports a Rate Request of Y, for X < Y <= Z, then
	the receiver only succeeds in lying to the sender about the approved		the receiver only succeeds in lying to the sender about the approved
	rate if the receiver successfully reports the rightmost 2Y bits in		rate if the receiver successfully reports the rightmost 2Y bits in
	the QS nonce.		the QS nonce.
	If senders often use a configured default value for the Rate		If senders often use a configured default value for the Rate Request,
	Request, then receivers would often be able to guess the original		then receivers would often be able to guess the original Rate
	Rate Request, and this would make it easier for the receiver to lie		Request, and this would make it easier for the receiver to lie about
	about the value of the Rate Request field. Similarly, if the		the value of the Rate Request field. Similarly, if the receiver
	receiver often communicates with a particular sender, and the sender		often communicates with a particular sender, and the sender always
	always uses the same Rate Request for that receiver, then the		uses the same Rate Request for that receiver, then the receiver might
	receiver might over time be able to infer the original Rate Request		over time be able to infer the original Rate Request used by the
	used by the sender.		sender.
	There are several possible additional forms of protection against		There are several possible additional forms of protection against
	receivers lying about the value of the Rate Request. One possible		receivers lying about the value of the Rate Request. One possible
	additional protection would be for a router that decreases a Rate		additional protection would be for a router that decreases a Rate
	Request in a Quick-Start Request to report the decrease directly to		Request in a Quick-Start Request to report the decrease directly to
	the sender. However, this could lead to many reports back to the		the sender. However, this could lead to many reports back to the
	sender for a single request, and could also be used in address-		sender for a single request, and could also be used in address-
	spoofing attacks.		spoofing attacks.
	A second limited form of protection would be for senders to use some		A second limited form of protection would be for senders to use some
	degree of randomization in the requested Rate Request, so that it is		degree of randomization in the requested Rate Request, so that it is
	difficult for receivers to guess the original value for the Rate		difficult for receivers to guess the original value for the Rate
	Request. However, this is difficult because there is a fairly		Request. However, this is difficult because there is a fairly coarse
	coarse granularity in the set of rate requests available to the		granularity in the set of rate requests available to the sender, and
	sender, and randomizing the initial request only offers limited		randomizing the initial request only offers limited protection, in
	protection in any case.		any case.
	9.4.4. Collusion between Misbehaving Routers		9.4.4. Collusion between Misbehaving Routers
	In addition to protecting against misbehaving receivers, it is		In addition to protecting against misbehaving receivers, it is
	necessary also to protect against misbehaving routers. Consider		necessary to protect against misbehaving routers. Consider collusion
	collusion between an ingress router and an egress router belonging		between an ingress router and an egress router belonging to the same
	to the same Intranet. The ingress router could decrement the Rate		intranet. The ingress router could decrement the Rate Request at the
	Request at the ingress, with the egress router increasing it again		ingress, with the egress router increasing it again at the egress.
	at the egress. The routers between the ingress and egress that		The routers between the ingress and egress that approved the
	approved the decremented rate request might not have been willing to		decremented rate request might not have been willing to approve the
	approve the larger, original request.		larger, original request.
	Another form of collusion would be for the ingress router to inform		Another form of collusion would be for the ingress router to inform
	the egress router out-of-band of the TTL Diff and QS Nonce for the		the egress router out-of-band of the TTL Diff and QS Nonce for the
	request packet at the ingress. This would enable the egress router		request packet at the ingress. This would enable the egress router
	to modify the QS TTL and QS Nonce so that it appeared that all of		to modify the QS TTL and QS Nonce so that it appeared that all the
	the routers along the path had approved the request. There does not		routers along the path had approved the request. There does not
	appear to be any protection against a colluding ingress and egress		appear to be any protection against a colluding ingress and egress
	router. Even if an intermediate router had deleted the Quick-Start		router. Even if an intermediate router had deleted the Quick-Start
	Option from the packet, the ingress router could have sent the		Option from the packet, the ingress router could have sent the
	Quick-Start Option to the egress router out-of-band, with the egress		Quick-Start Option to the egress router out-of-band, with the egress
	router inserting the Quick-Start Option, with a modified QS TTL		router inserting the Quick-Start Option, with a modified QS TTL
	field, back in the packet.		field, back in the packet.
	However, unlike ECN, there is somewhat less incentive for		However, unlike ECN, there is somewhat less of an incentive for
	cooperating ingress and egress routers to collude to falsely modify		cooperating ingress and egress routers to collude to falsely modify
	the Quick-Start Request so that it appears to have been approved by		the Quick-Start Request so that it appears to have been approved by
	all of the routers along the path. With ECN, a colluding ingress		all the routers along the path. With ECN, a colluding ingress router
	router could falsely mark a packet as ECN-capable, with the		could falsely mark a packet as ECN-capable, with the colluding egress
	colluding egress router returning the ECN field in the IP header to		router returning the ECN field in the IP header to its original non-
	its original non-ECN-capable codepoint, and congested routers along		ECN-capable codepoint, and congested routers along the path could
	the path could have been fooled into not dropping that packet. This		have been fooled into not dropping that packet. This collusion would
	collusion would give an unfair competitive advantage to the traffic		give an unfair competitive advantage to the traffic protected by the
	protected by the colluding ingress and egress routers.		colluding ingress and egress routers.
	In contrast, with Quick-Start, the collusion of the ingress and		In contrast, with Quick-Start, the collusion of the ingress and
	egress routers to make it falsely appear that a Quick-Start request		egress routers to make it falsely appear that a Quick-Start Request
	was approved sometimes could give an advantage to the traffic		was approved sometimes would give an advantage to the traffic covered
	covered by that collusion, and sometimes would give a disadvantage,		by that collusion, and sometimes would give a disadvantage, depending
	depending on the details of the scenario. If some router along the		on the details of the scenario. If some router along the path really
	path really does not have enough available bandwidth to approve the		does not have enough available bandwidth to approve the Quick-Start
	Quick-Start request, then Quick-Start packets sent as a result of		Request, then Quick-Start packets sent as a result of the falsely
	the falsely-approved request could be dropped in the network, to the		approved request could be dropped in the network, to the possible
	possible disadvantage of the connection. Thus, while the ingress		disadvantage of the connection. Thus, while the ingress and egress
	and egress routers could collude to prevent intermediate routers		routers could collude to prevent intermediate routers from denying a
	from denying a Quick-Start request, it would not always be to the		Quick-Start Request, it would not always be to the connection's
	connection's advantage for this to happen. One defense against such		advantage for this to happen. One defense against such a collusion
	a collusion would be for some router between the ingress and egress		would be for some router between the ingress and egress nodes that
	nodes that denied the request to monitor connection performance,		denied the request to monitor connection performance, penalizing
	penalizing connections that seeem to be using Quick-Start after a		connections that seem to be using Quick-Start after a Quick-Start
	Quick-Start request was denied, or that are reporting an Approved		Request was denied, or that are reporting an Approved Rate higher
	Rate higher than that actually approved by that router.		than that actually approved by that router.
	If the congested router is ECN-capable, and the colluding ingress		If the congested router is ECN-capable, and the colluding ingress and
	and egress routers are lying about ECN-capability as well as about		egress routers are lying about ECN-capability as well as about
	Quick-Start, then the result could be that the Quick-Start request		Quick-Start, then the result could be that the Quick-Start Request
	falsely appears to the sender to have been approved, and the Quick-		falsely appears to the sender to have been approved, and the Quick-
	Start packets falsely appear to the congested router to be ECN-		Start packets falsely appear to the congested router to be ECN-
	capable. In this case, the colluding routers might succeed in		capable. In this case, the colluding routers might succeed in giving
	giving a competitive advantage to the traffic protected by their		a competitive advantage to the traffic protected by their collusion
	collusion (if no intermediate router is monitoring to catch such		(if no intermediate router is monitoring to catch such misbehavior).
	misbehavior).
	9.5. Misbehaving Middleboxes and the IP TTL		9.5. Misbehaving Middleboxes and the IP TTL
	One possible difficulty is that of traffic normalizers [HKP01] or		One possible difficulty is that of traffic normalizers [HKP01], or
	other middleboxes along that path that re-write IP TTLs in order to		other middleboxes along that path, that rewrite IP TTLs in order to
	foil other kinds of attacks in the network. If such a traffic		foil other kinds of attacks in the network. If such a traffic
	normalizer re-wrote the IP TTL, but did not adjust the Quick-Start		normalizer rewrote the IP TTL, but did not adjust the Quick-Start TTL
	TTL by the same amount, then the sender's mechanism for determining		by the same amount, then the sender's mechanism for determining if
	if the request was approved by all routers along the path would no		the request was approved by all routers along the path would no
	longer be reliable. Re-writing the IP TTL could result in false		longer be reliable. Rewriting the IP TTL could result in false
	positives (with the sender incorrectly believing that the Quick-		positives (with the sender incorrectly believing that the Quick-
	Start request was approved) as well as false negatives (with the		Start Request was approved) as well as false negatives (with the
	sender incorrectly believing that the Quick-Start request was		sender incorrectly believing that the Quick-Start Request was
	denied).		denied).
	9.6. Attacks on Quick-Start		9.6. Attacks on Quick-Start
	As discussed in [SAF06], Quick-Start is vulnerable to two kinds of		As discussed in [SAF06], Quick-Start is vulnerable to two kinds of
	attacks: (1) attacks to increase the routers' processing and state		attacks: (1) attacks to increase the routers' processing and state
	load; and (2) attacks with bogus Quick-Start requests to temporarily		load and (2) attacks with bogus Quick-Start Requests to temporarily
	tie up available Quick-Start bandwidth, preventing routers from		tie up available Quick-Start bandwidth, preventing routers from
	approving Quick-Start requests from other connections. Routers can		approving Quick-Start Requests from other connections. Routers can
	protect against the first kind of attack by applying a simple limit		protect against the first kind of attack by applying a simple limit
	on the rate at which Quick-Start requests will be considered by the		on the rate at which Quick-Start Requests will be considered by the
	router.		router.
	The second kind of attack, to tie up the available Quick-Start		The second kind of attack, to tie up the available Quick-Start
	bandwidth, is more difficult to defend against. As discussed in		bandwidth, is more difficult to defend against. As discussed in
	[SAF06]. Quick-Start Requests that are not going to be used, either		[SAF06], Quick-Start Requests that are not going to be used, either
	because they are from malicious attackers or because they are denied		because they are from malicious attackers or because they are denied
	by routers downstream, can result in short-term `wasting' potential		by routers downstream, can result in short-term `wasting' of
	Quick-Start bandwidth, resulting in routers denying subsequent		potential Quick-Start bandwidth, resulting in routers denying
	Quick-Start Requests that if approved would in fact have been used.		subsequent Quick-Start Requests that, if approved, would in fact have
			been used.
	We note that the likelihood of malicious attacks would be minimized		We note that the likelihood of malicious attacks would be minimized
	significantly when Quick-Start was deployed in a controlled		significantly when Quick-Start was deployed in a controlled
	environment such as an Intranet, where there was some form of		environment such as an intranet, where there was some form of
	centralized control over the users in the system. We also note that		centralized control over the users in the system. We also note that
	this form of attack could potentially make Quick-Start unusable, but		this form of attack could potentially make Quick-Start unusable, but
	it would not do any further damage; in the worst case, the network		it would not do any further damage; in the worst case, the network
	would function as a network without Quick-Start.		would function as a network without Quick-Start.
	[SAF06] considers the potential of Extreme Quick-Start algorithms at		[SAF06] considers the potential of Extreme Quick-Start algorithms at
	routers, which keep per-flow state for Quick-Start connections, in		routers, which keep per-flow state for Quick-Start connections, in
	protecting the availability of Quick-Start bandwidth in the face of		protecting the availability of Quick-Start bandwidth in the face of
	frequent overly-large Quick-Start requests.		frequent, overly large Quick-Start Requests.
	9.7. Simulations with Quick-Start		9.7. Simulations with Quick-Start
	Quick-Start was added to the NS simulator [SH02] by Srikanth		Quick-Start was added to the NS simulator [SH02] by Srikanth
	Sundarrajan, and additional functionality was added by Pasi		Sundarrajan, and additional functionality was added by Pasi
	Sarolahti. The validation test is at `test-all-quickstart' in the		Sarolahti. The validation test is at `test-all-quickstart' in the
	`tcl/test' directory in NS. The initial simulation studies from		`tcl/test' directory in NS. The initial simulation studies from
	[SH02] show a significant performance improvement using Quick-Start		[SH02] show a significant performance improvement using Quick-Start
	for moderate-sized flows (between 4KB and 128KB) in under-utilized		for moderate-sized flows (between 4 KB and 128 KB) in underutilized
	environments. These studies are of file transfers, with the		environments. These studies are of file transfers, with the
	improvement measured as the relative increase in the overall		improvement measured as the relative increase in the overall
	throughput for the file transfer. The study shows that potential		throughput for the file transfer. The study shows that potential
	improvement from Quick-Start is proportional to the delay-bandwidth		improvement from Quick-Start is proportional to the delay-bandwidth
	product of the path.		product of the path.
	The Quick-Start simulations in [SAF06] explore the following: the		The Quick-Start simulations in [SAF06] explore the following: the
	potential benefit of Quick-Start for the connection; the relative		potential benefit of Quick-Start for the connection, the relative
	benefits of different router-based algorithms for approving Quick-		benefits of different router-based algorithms for approving Quick-
	Start requests; and the effectiveness of Quick-Start as a function		Start Requests, and the effectiveness of Quick-Start as a function of
	of the senders' algorithms for choosing the size of the rate		the senders' algorithms for choosing the size of the rate request.
	request.
	10. Implementation and Deployment Issues		10. Implementation and Deployment Issues
	This section discusses some of the implementation issues with Quick-		This section discusses some of the implementation issues with Quick-
	Start. This section also discusses some of the key deployment		Start. This section also discusses some of the key deployment
	issues, such as the chicken-and-egg deployment problems of		issues, such as the chicken-and-egg deployment problems of mechanisms
	mechanisms that have to be deployed in both routers and end nodes in		that have to be deployed in both routers and end nodes in order to
	order to work, and the problems posed by the wide deployment of		work, and the problems posed by the wide deployment of middleboxes
	middleboxes today that block the use of known or unknown IP Options.		today that block the use of known or unknown IP Options.
	10.1. Implementation Issues for Sending Quick-Start Requests		10.1. Implementation Issues for Sending Quick-Start Requests
	Section 4.7 discusses some of the issues with deciding the initial		Section 4.7 discusses some of the issues with deciding the initial
	sending rate to request. Quick-Start raises additional issues about		sending rate to request. Quick-Start raises additional issues about
	the communication between the transport protocol and the		the communication between the transport protocol and the application,
	application, and about the use of the past history with Quick-Start		and about the use of past history with Quick-Start in the end node.
	in the end node.
	One possibility is that a protocol implementation could provide an		One possibility is that a protocol implementation could provide an
	API for applications to indicate when they want to request Quick-		API for applications to indicate when they want to request Quick-
	Start, and what rate they would like to request. In the		Start, and what rate they would like to request. In the conventional
	conventional socket API this could be a socket option that is set		socket API, this could be a socket option that is set before a
	before a connection is established. Some applications, such as		connection is established. Some applications, such as those that use
	those that use TCP for bulk transfers, do not have interest in the		TCP for bulk transfers, do not have interest in the transmission
	transmission rate, but they might know the amount of data that can		rate, but they might know the amount of data that can be sent
	be sent immediately. Based on this, the sender implementation could		immediately. Based on this, the sender implementation could decide
	decide whether Quick-Start would be useful, and what rate should be		whether Quick-Start would be useful, and what rate should be
	requested.		requested.
	We note that when Quick-Start is used, the TCP sender is required to		We note that when Quick-Start is used, the TCP sender is required to
	save the QS Nonce and the TTL Diff when the Quick-Start request is		save the QS Nonce and the TTL Diff when the Quick-Start Request is
	sent, and to implement an additional timer for the paced		sent, and to implement an additional timer for the paced transmission
	transmission of Quick-Start packets.		of Quick-Start packets.
	10.2. Implementation Issues for Processing Quick-Start Requests		10.2. Implementation Issues for Processing Quick-Start Requests
	A router or other network host must be able to determine the		A router or other network host must be able to determine the
	approximate bandwidth of its outbound network interfaces in order to		approximate bandwidth of its outbound network interfaces in order to
	process incoming Quick-Start rate requests, including those that		process incoming Quick-Start rate requests, including those that
	originate from the host itself. One possibility would be for hosts		originate from the host itself. One possibility would be for hosts
	to rely on configuration information to determine link bandwidths;		to rely on configuration information to determine link bandwidths;
	this has the drawback of not being robust to errors in		this has the drawback of not being robust to errors in configuration.
	configuration. Another possibility would be for network device		Another possibility would be for network device drivers to infer the
	drivers to infer the bandwidth for the interface and to communicate		bandwidth for the interface and to communicate this to the IP layer.
	this to the IP layer.
	Particular issues will arise for wireless links with variable		Particular issues will arise for wireless links with variable
	bandwidth, where decisions will have to be made about how frequently		bandwidth, where decisions will have to be made about how frequently
	the host gets updates of the changing bandwidth. It seems		the host gets updates of the changing bandwidth. It seems
	appropriate that Quick-Start Requests would be handled particularly		appropriate that Quick-Start Requests would be handled particularly
	conservatively for links with variable bandwidth, to avoid cases		conservatively for links with variable bandwidth; to avoid cases
	where Quick-Start Requests are approved, the link bandwidth is		where Quick-Start Requests are approved, the link bandwidth is
	reduced, and the data packets that are sent end up being dropped.		reduced, and the data packets that are sent end up being dropped.
	Difficult issues also arise for paths with multi-access links (e.g.,		Difficult issues also arise for paths with multi-access links (e.g.,
	Ethernet). Routers or end-nodes with multi-access links should be		Ethernet). Routers or end-nodes with multi-access links should be
	particularly conservative in granting Quick-Start requests. In		particularly conservative in granting Quick-Start Requests. In
	particular, for some multi-access links there may be no procedure		particular, for some multi-access links, there may be no procedure
	for an attached node to use to determine whether all parts of the		for an attached node to use to determine whether all parts of the
	multi-access link have been underutilized in the recent past.		multi-access link have been underutilized in the recent past.
	10.3. Possible Deployment Scenarios		10.3. Possible Deployment Scenarios
	Because of possible problems discussed above concerning using Quick-		Because of possible problems discussed above concerning using Quick-
	Start over some network paths and the security issues discussed in		Start over some network paths and the security issues discussed in
	section 11, the most realistic initial deployment of Quick-Start		Section 11, the most realistic initial deployment of Quick-Start
	would most likely take place in Intranets and other controlled		would most likely take place in intranets and other controlled
	environments. Quick-Start is most useful on high bandwidth-delay		environments. Quick-Start is most useful on high bandwidth-delay
	paths that are significantly underutilized. The primary initial		paths that are significantly underutilized. The primary initial
	users of Quick-Start would likely be in organizations that provide		users of Quick-Start would likely be in organizations that provide
	network services to their users and also have control over a large		network services to their users and also have control over a large
	portion of the network path.		portion of the network path.
	Quick-Start is not currently intended for ubiquitous deployment in		Quick-Start is not currently intended for ubiquitous deployment in
	the global Internet. In particular, Quick-Start should not be		the global Internet. In particular, Quick-Start should not be
	enabled by default in end-nodes or in routers; instead, when Quick-		enabled by default in end-nodes or in routers; instead, when Quick-
	Start is used, it should be explicitly enabled by users or system		Start is used, it should be explicitly enabled by users or system
	administrators.		administrators.
	Below are a few examples of networking environments where Quick-		Below are a few examples of networking environments where Quick-
	Start would potentially be useful. These are the environments that		Start would potentially be useful. These are the environments that
	might consider an initial deployment of Quick-Start in the routers		might consider an initial deployment of Quick-Start in the routers
	and end-nodes, where the incentives for routers to deploy Quick-		and end-nodes, where the incentives for routers to deploy Quick-
	Start might be the most clear.		Start might be the most clear.
	* Centrally-administrated organizational Intranets: These intranets		* Centrally administrated organizational intranets: These intranets
	often have large network capacity, with networks that are		often have large network capacity, with networks that are
	underutilized for much of the time [PABL+05]. Such Intranets might		underutilized for much of the time [PABL+05]. Such intranets might
	also include high-bandwidth and high-delay paths to remote sites.		also include high-bandwidth and high-delay paths to remote sites.
	In such an environment, Quick-Start would be of benefit to users,		In such an environment, Quick-Start would be of benefit to users,
	and there would be a clear incentive for the deployment of Quick-		and there would be a clear incentive for the deployment of Quick-
	Start in routers. For example, Quick-Start could be quite useful in		Start in routers. For example, Quick-Start could be quite useful
	high-bandwidth networks used for scientific computing.		in high-bandwidth networks used for scientific computing.
	* Wireless networks: Quick-Start could also be useful in high-delay		* Wireless networks: Quick-Start could also be useful in high-delay
	environments of Cellular Wide-Area Wireless Networks such as the		environments of Cellular Wide-Area Wireless Networks, such as the
	GPRS [BW97] and their enhancements and next generations. For		GPRS [BW97] and their enhancements and next generations. For
	example, GPRS EDGE (Enhanced Data for GSM Evolution) is expected to		example, GPRS EDGE (Enhanced Data for GSM Evolution) is expected to
	provide wireless bandwidth of up to 384 Kbps (roughly 32 1500-byte		provide wireless bandwidth of up to 384 Kbps (roughly 32 1500-byte
	packets per second) while the GPRS round-trip times range typically		packets per second) while the GPRS round-trip times range typically
	from few hundred milliseconds to over a second excluding any		from a few hundred milliseconds to over a second, excluding any
	possible queueing delays in the network [GPAR02]. In addition, these		possible queueing delays in the network [GPAR02]. In addition,
	networks sometimes have variable additional delays due to resource		these networks sometimes have variable additional delays due to
	allocation that could be avoided by keeping the connection path		resource allocation that could be avoided by keeping the connection
	constantly utilized, starting from initial slow-start. Thus, Quick-		path constantly utilized, starting from initial slow-start. Thus,
	Start could be of significant benefit to users in these		Quick-Start could be of significant benefit to users in these
	environments.		environments.
	* Paths over satellite links: Geostationary Orbit (GEO) satellite		* Paths over satellite links: Geostationary Orbit (GEO) satellite
	links have one-way propagation delays on the order of 250 ms while		links have one-way propagation delays on the order of 250 ms while
	the bandwidth can be measured in megabits per second [RFC2488].		the bandwidth can be measured in megabits per second [RFC2488].
	Because of the considerable bandwidth-delay product on the link,		Because of the considerable bandwidth-delay product on the link,
	TCP's slow-start is a major performance limitation in the beginning		TCP's slow-start is a major performance limitation in the beginning
	of the connection. A large initial congestion window would be		of the connection. A large initial congestion window would be
	useful to users of such satellite links.		useful to users of such satellite links.
	* Single-hop paths: Quick-Start should work well over point-to-point		* Single-hop paths: Quick-Start should work well over point-to-point
	single-hop paths, e.g., from a host to an adjacent server. Quick-		single-hop paths, e.g., from a host to an adjacent server. Quick-
	Start would work over a single-hop IP path consisting of a multi-		Start would work over a single-hop IP path consisting of a multi-
	access link only if the host was able to determine if the path to		access link only if the host was able to determine if the path to
	the next IP hop has been significantly underutilized over the recent		the next IP hop has been significantly underutilized over the
	past. If the multi-access link includes a layer-2 switch, then the		recent past. If the multi-access link includes a layer-2 switch,
	attached host cannot necessarily determine the status of the other		then the attached host cannot necessarily determine the status of
	links in the layer-2 network.		the other links in the layer-2 network.
	10.4. A Comparison with the Deployment Problems of ECN		10.4. A Comparison with the Deployment Problems of ECN
	Given the glacially slow rate of deployment of ECN in the Internet		Given the glacially slow rate of deployment of ECN in the Internet to
	to date [MAF05], it is disconcerting to note that some of the		date [MAF05], it is disconcerting to note that some of the deployment
	deployment problems of Quick-Start are even greater than those of		problems of Quick-Start are even greater than those of ECN. First,
	ECN. First, unlike ECN, which can be of benefit even if it is only		unlike ECN, which can be of benefit even if it is only deployed on
	deployed on one of the routers along the end-to-end path, a		one of the routers along the end-to-end path, a connection's use of
	connection's use of Quick-Start requires Quick-Start deployment on		Quick-Start requires Quick-Start deployment on all of the routers
	all of the routers along the end-to-end path. Second, unlike ECN,		along the end-to-end path. Second, unlike ECN, which uses an
	which uses an allocated field in the IP header, Quick-Start requires		allocated field in the IP header, Quick-Start requires the extra
	the extra complications of an IP Option, which can be difficult to		complications of an IP Option, which can be difficult to pass through
	pass through the current Internet [MAF05].		the current Internet [MAF05].
	However, in spite of these issues, there is some hope for the		However, in spite of these issues, there is some hope for the
	deployment of Quick-Start, at least in protected corners of the		deployment of Quick-Start, at least in protected corners of the
	Internet, because the potential benefits of Quick-Start to the user		Internet, because the potential benefits of Quick-Start to the user
	are considerably more dramatic than those of ECN. Rather than		are considerably more dramatic than those of ECN. Rather than simply
	simply replacing the occasional dropped packet by an ECN-marked		replacing the occasional dropped packet by an ECN-marked packet,
	packet, Quick-Start is capable of dramatically increasing the		Quick-Start is capable of dramatically increasing the throughput of
	throughput of connections in underutilized environments [SAF06].		connections in underutilized environments [SAF06].
	11. Security Considerations		11. Security Considerations
	Sections 9.4 and 9.6 discuss the security considerations related to		Sections 9.4 and 9.6 discuss the security considerations related to
	Quick-Start. Section 9.4 discusses the potential abuse of Quick-		Quick-Start. Section 9.4 discusses the potential abuse of Quick-
	Start by senders or receivers lying about whether the request was		Start by senders or receivers lying about whether the request was
	approved or about the approved rate, and of routers in collusion to		approved or about the approved rate, and of routers in collusion to
	misuse Quick-Start. Section 9.5 discusses potential problems with		misuse Quick-Start. Section 9.5 discusses potential problems with
	traffic normalizers that rewrite IP TTLs in packet headers. All of		traffic normalizers that rewrite IP TTLs in packet headers. All
	these problems could result in the sender using a Rate Request that		these problems could result in the sender using a Rate Request that
	was inappropriately large, or thinking that a request was approved		was inappropriately large, or thinking that a request was approved
	when it was in fact denied by at least one router along the path.		when it was in fact denied by at least one router along the path.
	This inappropriate use of Quick-Start could result in congestion and		This inappropriate use of Quick-Start could result in congestion and
	an unacceptable level of packet drops along the path, Such		an unacceptable level of packet drops along the path. Such
	congestion could also be part of a Denial of Service attack.		congestion could also be part of a Denial of Service attack.
	Section 9.6 discusses a potential attack on the routers' processing		Section 9.6 discusses a potential attack on the routers' processing
	and state load from an attack of Quick-Start Requests. Section 9.6		and state load from an attack of Quick-Start Requests. Section 9.6
	also discusses a potential attack on the available Quick-Start		also discusses a potential attack on the available Quick-Start
	bandwidth by sending bogus Quick-Start requests for bandwidth that		bandwidth by sending bogus Quick-Start Requests for bandwidth that
	will not in fact be used. While this impacts the global usability		will not, in fact, be used. While this impacts the global usability
	of Quick-Start it does not endanger the network as a whole since TCP		of Quick-Start, it does not endanger the network as a whole since TCP
	uses standard congestion control if Quick-Start is not available.		uses standard congestion control if Quick-Start is not available.
	Section 4.7.2 discusses the potential problem of packets with Quick-		Section 4.7.2 discusses the potential problem of packets with Quick-
	Start Requests dropped by middleboxes along the path.		Start Requests dropped by middleboxes along the path.
	As discussed in Section 5, for IPv4 IPsec Authentication Header		As discussed in Section 5, for IPv4 IPsec Authentication Header
	Integrity Check Value (AH ICV) calculation, the Quick-Start option		Integrity Check Value (AH ICV) calculation, the Quick-Start Option is
	is a mutable IPv4 option, and hence completely zeroed for AH ICV		a mutable IPv4 option and hence completely zeroed for AH ICV
	calculation purposes; this is also the treatment required by RFC		calculation purposes. This is also the treatment required by RFC
	4302 for unrecognized IPv4 options. The IPv6 Quick-Start option's		4302 for unrecognized IPv4 options. The IPv6 Quick-Start Option's
	IANA-allocated option type indicates that it is a mutable option,		IANA-allocated option type indicates that it is a mutable option;
	hence, according to RFC 4302, its option data is required to be		hence, according to RFC 4302, its option data is required to be
	zeroed for AH ICV computation purposes. See RFC 4302 for further		zeroed for AH ICV computation purposes. See RFC 4302 for further
	explanation.		explanation.
	Section 6.2 discusses possible problems of Quick-Start used by		Section 6.2 discusses possible problems of Quick-Start used by
	connections carried over simple tunnels that are not compatible with		connections carried over simple tunnels that are not compatible with
	Quick-Start. In this case it is possible that a Quick-Start		Quick-Start. In this case, it is possible that a Quick-Start Request
	Request is erroneously considered approved by the sender without the		is erroneously considered approved by the sender without the routers
	routers in the tunnel having individually approved the request,		in the tunnel having individually approved the request, causing a
	causing a false positive.		false positive.
	We note two high-order points here. First, the Quick-Start Nonce		We note two high-order points here. First, the Quick-Start Nonce
	goes a long way towards preventing large scale cheating. And,		goes a long way towards preventing large-scale cheating. Second,
	second, even if a host occasionally uses Quick-Start when it is not		even if a host occasionally uses Quick-Start when it is not approved
	approved by the entire network path the network will not collapse.		by the entire network path, the network will not collapse. Quick-
	Quick-Start does not remove TCP's basic congestion control		Start does not remove TCP's basic congestion control mechanisms;
	mechanisms and these will kick in when the network is heavily		these will kick in when the network is heavily loaded, relegating any
	loaded, relegating any Quick-Start mistake to a transient.		Quick-Start mistake to a transient.
	12. IANA Considerations		12. IANA Considerations
	Quick-Start requires an IP Option and a TCP Option.		Quick-Start requires an IP Option and a TCP Option.
	12.1. IP Option		12.1. IP Option
	Quick-Start requires both an IPv4 Option Number (Section 3.1) and an		Quick-Start requires both an IPv4 Option Number (Section 3.1) and an
	IPv6 Option Number (Section 3.2).		IPv6 Option Number (Section 3.2).
	IPv4 Option Number:		IPv4 Option Number:
	Copy Class Number Value Name		Copy Class Number Value Name
	---- ----- ------ ----- ----		---- ----- ------ ----- ----
	0 00 TBD1 TBD2 QS - Quick-Start		0 00 25 25 QS - Quick-Start
	IPv6 Option Number [RFC2460]:		IPv6 Option Number [RFC2460]:
	HEX act chg rest		HEX act chg rest
	--- --- --- -----		--- --- --- -----
	TBD3 00 1 TBD4 Quick-Start		6 00 1 00110 Quick-Start
	For the IPv6 Option Number, the first two bits indicate that the		For the IPv6 Option Number, the first two bits indicate that the IPv6
	IPv6 node skip over this option and continue processing the header		node may skip over this option and continue processing the header if
	if it doesn't recognize the option type, and the third bit indicates		it doesn't recognize the option type, and the third bit indicates
	that the Option Data may change en-route.		that the Option Data may change en-route.
	In both cases this document should be listed as the reference		In both cases, this document should be listed as the reference
	document.		document.
	12.2. TCP Option		12.2. TCP Option
	Quick-Start requires a TCP Option Number (Section 4.2).		Quick-Start requires a TCP Option Number (Section 4.2).
	TCP Option Number:		TCP Option Number:
	Kind Length Meaning		Kind Length Meaning
	---- ------ ------------------------------		---- ------ ------------------------------
	TBD5 8 Quick-Start Response		27 8 Quick-Start Response
	This document should be listed as the reference document.		This document should be listed as the reference document.
	13. Conclusions		13. Conclusions
	We are presenting the Quick-Start mechanism as a simple,		We are presenting the Quick-Start mechanism as a simple,
	understandable, and incrementally-deployable mechanism that would be		understandable, and incrementally deployable mechanism that would be
	sufficient to allow some connections to start up with large initial		sufficient to allow some connections to start up with large initial
	rates, or large initial congestion windows, in overprovisioned,		rates, or large initial congestion windows, in over-provisioned,
	high-bandwidth environments. We expect there will be an increasing		high-bandwidth environments. We expect there will be an increasing
	number of overprovisioned, high-bandwidth environments where the		number of over-provisioned, high-bandwidth environments where the
	Quick-Start mechanism, or another mechanism of similar power, could		Quick-Start mechanism, or another mechanism of similar power, could
	be of significant benefit to a wide range of traffic. We are		be of significant benefit to a wide range of traffic. We are
	presenting the Quick-Start mechanism as a request for the community		presenting the Quick-Start mechanism as a request for the community
	to provide feedback and experimentation on issues relating to Quick-		to provide feedback and experimentation on issues relating to Quick-
	Start.		Start.
	14. Acknowledgements		14. Acknowledgements
	The authors wish to thank Mark Handley for discussions of these		The authors wish to thank Mark Handley for discussions of these
	issues. The authors also thank the End-to-End Research Group, the		issues. The authors also thank the End-to-End Research Group, the
	Transport Services Working Group, and members of IPAM's program on		Transport Services Working Group, and members of IPAM's program on
	Large Scale Communication Networks for both positive and negative		Large-Scale Communication Networks for both positive and negative
	feedback on this proposal. We thank Srikanth Sundarrajan for the		feedback on this proposal. We thank Srikanth Sundarrajan for the
	initial implementation of Quick-Start in the NS simulator, and for		initial implementation of Quick-Start in the NS simulator, and for
	the initial simulation study. Many thanks to David Black and Joe		the initial simulation study. Many thanks to David Black and Joe
	Touch for extensive feedback on Quick-Start and IP tunnels. We also		Touch for extensive feedback on Quick-Start and IP tunnels. We also
	thank Mohammed Ashraf, John Border, Bob Briscoe, Martin Duke, Tom		thank Mohammed Ashraf, John Border, Bob Briscoe, Martin Duke, Tom
	Dunigan, Mitchell Erblich, Gorry Fairhurst, John Heidemann, Paul		Dunigan, Mitchell Erblich, Gorry Fairhurst, John Heidemann, Paul
	Hyder, Dina Katabi and Vern Paxson for feedback. Thanks also to		Hyder, Dina Katabi, and Vern Paxson for feedback. Thanks also to
	Gorry Fairhurst for the suggestion of adding the QS Nonce to the		Gorry Fairhurst for the suggestion of adding the QS Nonce to the
	Report of Approved Rate.		Report of Approved Rate.
	The version of the QS Nonce in this document is based on a proposal		The version of the QS Nonce in this document is based on a proposal
	from Guohan Lu [L05]. Earlier versions of this document contained		from Guohan Lu [L05]. Earlier versions of this document contained an
	an eight-bit QS Nonce, and subsequent versions discussed the		eight-bit QS Nonce, and subsequent versions discussed the possibility
	possibility of a four-bit QS Nonce.		of a four-bit QS Nonce.
	This draft builds upon the concepts described in [RFC3390], [AHO98],		This document builds upon the concepts described in [RFC3390],
	[RFC2415], and [RFC3168]. Some of the text on Quick-Start in		[AHO98], [RFC2415], and [RFC3168]. Some of the text on Quick-Start
	tunnels was borrowed directly from RFC 3168.		in tunnels was borrowed directly from RFC 3168.
	This document is the development of a proposal originally by Amit		This document is the development of a proposal originally by Amit
	Jain for Initial Window Discovery.		Jain for Initial Window Discovery.
	A. Related Work		Appendix A. Related Work
	The Quick-Start proposal, taken together with HighSpeed TCP		The Quick-Start proposal, taken together with HighSpeed TCP [RFC3649]
	[RFC3649] or other transport protocols for high-bandwidth transfers,		or other transport protocols for high-bandwidth transfers, could go a
	could go a significant way towards extending the range of		significant way towards extending the range of performance for best-
	performance for best-effort traffic in the Internet. However, there		effort traffic in the Internet. However, there are many things that
	are many things that the Quick-Start proposal would not accomplish.		the Quick-Start proposal would not accomplish. Quick-Start is not a
	Quick-Start is not a congestion control mechanism, and would not		congestion control mechanism, and would not help in making more
	help in making more precise use of the available bandwidth, that is,		precise use of the available bandwidth -- that is, of achieving the
	of achieving the goal of high throughput with low delay and low		goal of high throughput with low delay and low packet-loss rates.
	packet loss rates. Quick-Start would not give routers more control		Quick-Start would not give routers more control over the decrease
	over the decrease rates of active connections.		rates of active connections.
	In addition, any evaluation of Quick-Start must include a discussion		In addition, any evaluation of Quick-Start must include a discussion
	of the relative benefits of approaches that use no explicit		of the relative benefits of approaches that use no explicit
	information from routers, and of approaches that use more fine-		information from routers, and of approaches that use more fine-
	grained feedback from routers as part of a larger congestion control		grained feedback from routers as part of a larger congestion control
	mechanism. We discuss several classes of proposals in the sections		mechanism. We discuss several classes of proposals in the sections
	below.		below.
	A.1. Fast Start-ups without Explicit Information from Routers		A.1. Fast Start-Ups without Explicit Information from Routers
	One possibility would be for senders to use information from the		One possibility would be for senders to use information from the
	packet streams to learn about the available bandwidth, without		packet streams to learn about the available bandwidth, without
	explicit information from routers. These techniques would not allow		explicit information from routers. These techniques would not allow
	a start-up as fast as that available from Quick-Start in an		a start-up as fast as that available from Quick-Start in an
	underutilized environment; one has to have sent some packets		underutilized environment; one already has to have sent some packets
	already to use the packet stream to learn about available bandwidth.		in order to use the packet stream to learn about available bandwidth.
	However, these techniques could allow a start-up considerably faster		However, these techniques could allow a start-up considerably faster
	than the current slow-start. While it seems clear that approaches		than the current Slow-Start. While it seems clear that approaches
	*without* explicit feedback from the routers will be strictly less		*without* explicit feedback from the routers will be strictly less
	powerful that is possible *with* explicit feedback, it is also		powerful than is possible *with* explicit feedback, it is also
	possible that approaches that are more aggressive than slow-start		possible that approaches that are more aggressive than Slow-Start are
	are possible without the complexity involved in obtaining explicit		possible without the complexity involved in obtaining explicit
	feedback from routers.		feedback from routers.
	Periodic packet streams:		Periodic packet streams:
	[JD02] explores the use of periodic packet streams to estimate the		[JD02] explores the use of periodic packet streams to estimate the
	available bandwidth along a path. The idea is that the one-way		available bandwidth along a path. The idea is that the one-way
	delays of a periodic packet stream show an increasing trend when the		delays of a periodic packet stream show an increasing trend when the
	stream's rate is higher than the available bandwidth (due to an		stream's rate is higher than the available bandwidth (due to an
	increasing queue). While [JD02] states that the proposed mechanism		increasing queue). While [JD02] states that the proposed mechanism
	does not cause significant increases in network utilization, losses,		does not cause significant increases in network utilization, losses,
	or delays when done by one flow at a time, the approach could be		or delays when done by one flow at a time, the approach could be
	skipping to change at page 63, line 14		skipping to change at page 55, line 14
	Swift-Start:		Swift-Start:
	The Swift Start proposal from [PRAKS02] combines packet-pair and		The Swift Start proposal from [PRAKS02] combines packet-pair and
	packet-pacing techniques. An initial congestion window of four		packet-pacing techniques. An initial congestion window of four
	segments is used to estimate the available bandwidth along the path.		segments is used to estimate the available bandwidth along the path.
	This estimate is then used to dramatically increase the congestion		This estimate is then used to dramatically increase the congestion
	window during the second RTT of data transmission.		window during the second RTT of data transmission.
	SPAND:		SPAND:
	In the TCP/SPAND proposal from [ZQK00] for speeding up short data		In the TCP/SPAND proposal from [ZQK00] for speeding up short data
	transfers, network performance information would be shared among		transfers, network performance information would be shared among many
	many co-located hosts to estimate each connection's fair share of		co-located hosts to estimate each connection's fair share of the
	the network resources. Based on such estimation and the transfer		network resources. Based on such estimation and the transfer size,
	size, the TCP sender would determine the optimal initial congestion		the TCP sender would determine the optimal initial congestion window
	window size. The design for TCP/SPAND uses a performance gateway		size. The design for TCP/SPAND uses a performance gateway that
	that monitors all traffic entering and leaving an organization's		monitors all traffic entering and leaving an organization's network.
	network.
	Sharing information among TCP connections:		Sharing information among TCP connections:
	The Congestion Manager [RFC3124] and TCP control block sharing		The Congestion Manager [RFC3124] and TCP control block sharing
	[RFC2140] both propose sharing congestion information among multiple		[RFC2140] both propose sharing congestion information among multiple
	TCP connections with the same endpoints. With the Congestion		TCP connections with the same endpoints. With the Congestion
	Manager, a new TCP connection could start with a high initial cwnd		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		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		connection to the same destination that had already obtained a high
	congestion window. RFC 2140 discusses ensemble sharing, where an		congestion window. RFC 2140 discusses ensemble sharing, where an
	established connection's congestion window could be `divided up' to		established connection's congestion window could be `divided up' to
	be shared with a new connection to the same host. However, neither		be shared with a new connection to the same host. However, neither
	of these approaches addresses the case of a connection to a new		of these approaches addresses the case of a connection to a new
	destination, with no existing or recent connection (and therefore		destination, with no existing or recent connection (and therefore
	congestion control state) to that destination.		congestion control state) to that destination.
	While continued research on the limits of the ability of TCP and		While continued research on the limits of the ability of TCP and
	other transport protocols to learn of available bandwidth without		other transport protocols to learn of available bandwidth without
	explicit feedback from the router seems useful, we note that there		explicit feedback from the router seems useful, we note that there
	are several fundamental advantages of explicit feedback from		are several fundamental advantages of explicit feedback from routers.
	routers.
	(1) Explicit feedback is faster than implicit feedback:		(1) Explicit feedback is faster than implicit feedback:
	One advantage of explicit feedback from the routers is that it		One advantage of explicit feedback from the routers is that it
	allows the transport sender to reliably learn of available bandwidth		allows the transport sender to reliably learn of available
	in one round-trip time.		bandwidth in one round-trip time.
	(2) Explicit feedback is more reliable than implicit feedback:		(2) Explicit feedback is more reliable than implicit feedback:
	Techniques that attempt to assess the available bandwidth at		Techniques that attempt to assess the available bandwidth at
	connection startup using implicit techniques are more error-prone		connection start-up using implicit techniques are more error-
	than techniques that involve every element in the network path.		prone than techniques that involve every element in the network
	While explicit information from the network can be wrong, it has a		path. While explicit information from the network can be wrong,
	much better chance of being appropriate than an end-host trying to		it has a much better chance of being appropriate than an end-host
	*estimate* an appropriate sending rate using "block box" probing		trying to *estimate* an appropriate sending rate using "block
	techniques of the entire path.		box" probing techniques of the entire path.
	A.2. Optimistic Sending without Explicit Information from Routers		A.2. Optimistic Sending without Explicit Information from Routers
	Another possibility that has been suggested [S02] is for the sender		Another possibility that has been suggested [S02] is for the sender
	to start with a large initial window without explicit permission		to start with a large initial window without explicit permission from
	from the routers and without bandwidth estimation techniques, and		the routers and without bandwidth estimation techniques and for the
	for the first packet of the initial window to contain information		first packet of the initial window to contain information, such as
	such as the size or sending rate of the initial window. The		the size or sending rate of the initial window. The proposal would
	proposal would be that congested routers would use this information		be that congested routers would use this information in the first
	in the first data packet to drop or delay many or all of the packets		data packet to drop or delay many or all of the packets from that
	from that initial window. In this way a flow's optimistically-large		initial window. In this way, a flow's optimistically large initial
	initial window would not force the router to drop packets from		window would not force the router to drop packets from competing
	competing flows in the network. Such an approach would seem to		flows in the network. Such an approach would seem to require some
	require some mechanism for the sender to ensure that the routers		mechanism for the sender to ensure that the routers along the path
	along the path understood the mechanism for marking the first packet		understood the mechanism for marking the first packet of a large
	of a large initial window.		initial window.
	Obviously there would be a number of questions to consider about an		Obviously, there would be a number of questions to consider about an
	approach of optimistic sending.		approach of optimistic sending.
	(1) Incremental deployment:		(1) Incremental deployment:
	One question would be the potential complications of incremental		One question would be the potential complications of incremental
	deployment, where some of the routers along the path might not		deployment, where some of the routers along the path might not
	understand the packet information describing the initial window.		understand the packet information describing the initial window.
	(2) Congestion collapse:		(2) Congestion collapse:
	There could also be concerns about congestion collapse if many flows		There could also be concerns about congestion collapse if many
	used large initial windows, many packets were dropped from		flows used large initial windows, many packets were dropped from
	optimistic initial windows, and many congested links ended up		optimistic initial windows, and many congested links ended up
	carrying packets that are only going to be dropped downstream.		carrying packets that are only going to be dropped downstream.
	(3) Distributed Denial of Service attacks:		(3) Distributed Denial of Service attacks:
	A third question would be the potential role of optimistic senders		A third question would be the potential role of optimistic
	in amplifying the damage done by a Distributed Denial of Service		senders in amplifying the damage done by a Distributed Denial of
	(DDoS) attack (assuming attackers use compliant congestion control		Service (DDoS) attack (assuming attackers use compliant
	in the hopes of "flying under the radar").		congestion control in the hopes of "flying under the radar").
	(4) Performance hits if a packet is dropped:		(4) Performance hits if a packet is dropped:
	A fourth issue would be to quantify the performance hit to the		A fourth issue would be to quantify the performance hit to the
	connection when a packet is dropped from one of the initial windows.		connection when a packet is dropped from one of the initial
			windows.
	A.3. Fast Start-ups with other Information from Routers		A.3. Fast Start-Ups with Other Information from Routers
	There have been several proposals somewhat similar to Quick-Start,		There have been several proposals somewhat similar to Quick-Start,
	where the transport protocol collects explicit information from the		where the transport protocol collects explicit information from the
	routers along the path.		routers along the path.
	An IP Option about the free buffer size:		An IP Option about the free buffer size:
	In related work, [P00] investigates the use of a slightly different		In related work, [P00] investigates the use of a slightly different
	IP option for TCP connections to discover the available bandwidth		IP option for TCP connections to discover the available bandwidth
	along the path. In that proposal, the IP option would query the		along the path. In that proposal, the IP option would query the
	routers along the path about the smallest available free buffer		routers along the path about the smallest available free buffer size.
	size. Also, the IP option would have been sent after the initial SYN		Also, the IP option would have been sent after the initial SYN
	exchange, when the TCP sender already had an estimate of the round-		exchange, when the TCP sender already had an estimate of the round-
	trip time.		trip time.
	The Performance Transparency Protocol:		The Performance Transparency Protocol:
	The Performance Transparency Protocol (PTP) includes a proposal for		The Performance Transparency Protocol (PTP) includes a proposal for a
	a single PTP packet that would collect information from routers		single PTP packet that would collect information from routers along
	along the path from the sender to the receiver [W00]. For example,		the path from the sender to the receiver [W00]. For example, a
	a single PTP packet could be used to determine the bottleneck		single PTP packet could be used to determine the bottleneck bandwidth
	bandwidth along a path.		along a path.
	ETEN:		ETEN:
	Additional proposals for end nodes to collect explicit information		Additional proposals for end nodes to collect explicit information
	from routers include one variant of Explicit Transport Error		from routers include one variant of Explicit Transport Error
	Notification (ETEN), which includes a cumulative mechanism to notify		Notification (ETEN), which includes a cumulative mechanism to notify
	endpoints of aggregate congestion statistics along the path		endpoints of aggregate congestion statistics along the path [KAPS02].
	[KAPS02]. (A second variant in [KSEPA04] does not depend on		(A second variant in [KSEPA04] does not depend on cumulative
	cumulative congestion statistics from the network.)		congestion statistics from the network.)
	A.4. Fast Start-ups with more Fine-Grained Feedback from Routers		A.4. Fast Start-Ups with more Fine-Grained Feedback from Routers
	Proposals for more fine-grained congestion-related feedback from		Proposals for more fine-grained, congestion-related feedback from
	routers include XCP [KHR02], MaxNet [MaxNet], and AntiECN marking		routers include XCP [KHR02], MaxNet [MaxNet], and AntiECN marking
	[K03]. Section B.6 discusses in more detail the relationship		[K03]. Appendix B.6 discusses in more detail the relationship
	between Quick-Start and proposals for more fine-grained per-packet		between Quick-Start and proposals for more fine-grained per-packet
	feedback from routers.		feedback from routers.
	XCP:		XCP:
	Proposals such as XCP for new congestion control mechanisms based on		Proposals, such as XCP for new congestion control mechanisms based on
	more feedback from routers are more powerful than Quick-Start, but		more feedback from routers, are more powerful than Quick-Start, but
	also are more complex to understand and more difficult to deploy.		also are more complex to understand and more difficult to deploy.
	XCP routers maintain no per-flow state, but provide more fine-		XCP routers maintain no per-flow state, but provide more fine-
	grained feedback to end-nodes than the one-bit congestion feedback		grained feedback to end-nodes than the one-bit congestion feedback of
	of ECN. The per-packet feedback from XCP can be positive or		ECN. The per-packet feedback from XCP can be positive or negative,
	negative, and specifies the increase or decrease in the sender's		and specifies the increase or decrease in the sender's congestion
	congestion window when this packet is acknowledged. XCP is a full-		window when this packet is acknowledged. XCP is a full-fledge
	fledge congestion control scheme, whereas Quick-Start represents a		congestion control scheme, whereas Quick-Start represents a quick
	quick check to determine if the network path is significantly		check to determine if the network path is significantly underutilized
	underutilized such that a connection can start faster and then fall		such that a connection can start faster and then fall back to TCP's
	back to TCP's standard congestion control algorithms.		standard congestion control algorithms.
	AntiECN:		AntiECN:
	The AntiECN proposal is for a single bit in the packet header that		The AntiECN proposal is for a single bit in the packet header that
	routers could set to indicate that they are underutilized. For each		routers could set to indicate that they are underutilized. For each
	TCP ACK arriving at the sender indicating that a packet has been		TCP ACK arriving at the sender indicating that a packet has been
	received with the Anti-ECN bit set, the sender would be able to		received with the Anti-ECN bit set, the sender would be able to
	increase its congestion window by one packet, as it would during		increase its congestion window by one packet, as it would during
	slow-start.		slow-start.
	A.5. Fast Start-ups with Lower-Than-Best-Effort Service		A.5. Fast Start-Ups with Lower-Than-Best-Effort Service
	There have been proposals for routers to provide a Lower Effort		There have been proposals for routers to provide a Lower Effort
	differentiated service that would be lower than best effort		differentiated service that would be lower than best effort
	[RFC3662]. Such a service could carry traffic for which delivery is		[RFC3662]. Such a service could carry traffic for which delivery is
	strictly optional, or could carry traffic that is important but that		strictly optional, or could carry traffic that is important but that
	has low priority in terms of time. Because it does not interfere		has low priority in terms of time. Because it does not interfere
	with best-effort traffic, Lower Effort services could be used by		with best-effort traffic, Lower Effort services could be used by
	transport protocols that start-up faster than slow-start. For		transport protocols that start up faster than slow-start. For
	example, [SGF05] is a proposal for the transport sender to use low-		example, [SGF05] is a proposal for the transport sender to use low-
	priority traffic for much of the initial traffic, with routers		priority traffic for much of the initial traffic, with routers
	configured to use strict priority queueing.		configured to use strict priority queueing.
	A separate but related issue is that of below-best-effort TCP,		A separate but related issue is that of below-best-effort TCP,
	variants of TCP that would not rely on Lower Effort services in the		variants of TCP that would not rely on Lower Effort services in the
	network, but would approximate below-best-effort traffic by		network, but would approximate below-best-effort traffic by detecting
	detecting and responding to congestion sooner that standard TCP.		and responding to congestion sooner than standard TCP. TCP Nice
	TCP Nice [V02] and TCP Low Priority (TCP-LP) [KK03] are two such		[V02] and TCP Low Priority (TCP-LP) [KK03] are two such proposals for
	proposals for below-best-effort TCP, with the purpose of allowing		below-best-effort TCP, with the purpose of allowing TCP connections
	TCP connections to use the bandwidth unused by TCP and other traffic		to use the bandwidth unused by TCP and other traffic in a non-
	in a non-intrusive fashion. Both TCP Nice and TCP Low Priority use		intrusive fashion. Both TCP Nice and TCP Low Priority use the
	the default slow-start mechanisms of TCP.		default slow-start mechanisms of TCP.
	We note that Quick-Start is quite different from either a Lower		We note that Quick-Start is quite different from either a Lower-
	Effort service or a below-best-effort variant of TCP. Unlike these		Effort service or a below-best-effort variant of TCP. Unlike these
	proposals, Quick-Start is intended to be useful for best-effort		proposals, Quick-Start is intended to be useful for best-effort
	traffic that wishes to receive at least as much bandwidth as		traffic that wishes to receive at least as much bandwidth as
	competing best-effort connections.		competing best-effort connections.
	B. Design Decisions		Appendix B. Design Decisions
	B.1. Alternate Mechanisms for the Quick-Start Request: ICMP and RSVP		B.1. Alternate Mechanisms for the Quick-Start Request: ICMP and RSVP
	This document has proposed using an IP Option for the Quick-Start		This document has proposed using an IP Option for the Quick-Start
	Request from the sender to the receiver, and using transport		Request from the sender to the receiver, and using transport
	mechanisms for the Quick-Start Response from the receiver back to		mechanisms for the Quick-Start Response from the receiver back to the
	the sender. In this section we discuss alternate mechanisms, and		sender. In this section, we discuss alternate mechanisms, and
	consider whether ICMP ([RFC792], [RFC2463]) or RSVP [RFC2205]		consider whether ICMP ([RFC792], [RFC4443]) or RSVP [RFC2205]
	protocols could be used for delivering the Quick-Start Request.		protocols could be used for delivering the Quick-Start Request.
	B.1.1. ICMP		B.1.1. ICMP
	Being a control protocol used between Internet nodes, one could		Being a control protocol used between Internet nodes, one could argue
	argue that ICMP is the ideal method for requesting a permission for		that ICMP is the ideal method for requesting permission for faster
	faster startup from routers. The ICMP header is above the IP		start-up from routers. The ICMP header is above the IP header.
	header. Quick-Start could be accomplished with ICMP as follows: If		Quick-Start could be accomplished with ICMP as follows: If the ICMP
	the ICMP protocol is used to implement Quick-Start, the equivalent		protocol is used to implement Quick-Start, the equivalent of the
	of the Quick-Start IP option would be carried in the ICMP header of		Quick-Start IP option would be carried in the ICMP header of the ICMP
	the ICMP Quick-Start Request. The ICMP Quick-Start Request would		Quick-Start Request. The ICMP Quick-Start Request would have to pass
	have to pass by the routers on the path to the receiver, possibly		by the routers on the path to the receiver, possibly using the IP
	using the IP Router Alert option [RFC2113]. A router that approves		Router Alert option [RFC2113]. A router that approves the Quick-
	the Quick-Start Request would take the same actions as in the case		Start Request would take the same actions as in the case with the
	with the Quick-Start IP Option, and forward the packet to the next		Quick-Start IP Option, and forward the packet to the next router
	router along the path. A router that does not approve the Quick-		along the path. A router that does not approve the Quick-Start
	Start Request, even with a decreased value for the Requested Rate,		Request, even with a decreased value for the Requested Rate, would
	would delete the ICMP Quick-Start Request, and send an ICMP Reply to		delete the ICMP Quick-Start Request, and send an ICMP Reply to the
	the sender that the request was not approved. If the ICMP Reply was		sender that the request was not approved. If the ICMP Reply was
	dropped in the network, and did not reach the receiver, the sender		dropped in the network, and did not reach the receiver, the sender
	would still know that the request was not approved from the absence		would still know that the request was not approved from the absence
	of feedback from the receiver. If the ICMP Quick-Start request was		of feedback from the receiver. If the ICMP Quick-Start Request was
	dropped in the network due to congestion, the sender would assume		dropped in the network due to congestion, the sender would assume
	that the request was not approved. The ICMP message would need the		that the request was not approved. The ICMP message would need the
	source and destination port numbers for demultiplexing at the end		source and destination port numbers for demultiplexing at the end
	nodes. If the ICMP Quick-Start Request reached the receiver, the		nodes. If the ICMP Quick-Start Request reached the receiver, the
	receiver would use transport-level or application-level mechanisms		receiver would use transport-level or application-level mechanisms to
	to send a response to the sender, exactly as with the IP Option.		send a response to the sender, exactly as with the IP Option.
	One benefit of using ICMP would be that the delivery of the TCP SYN		One benefit of using ICMP would be that the delivery of the TCP SYN
	packet or other initial packet would not be delayed by IP option		packet or other initial packet would not be delayed by IP option
	processing at routers. A greater advantage is that if middleboxes		processing at routers. A greater advantage is that if middleboxes
	were blocking packets with Quick-Start Requests, using the Quick-		were blocking packets with Quick-Start Requests, using the Quick-
	Start Request in a separate ICMP packet would mean that the		Start Request in a separate ICMP packet would mean that the middlebox
	middlebox behavior would not affect the connection as a whole. (To		behavior would not affect the connection as a whole. (To get this
	get this robustness to middleboxes with TCP using an IP Quick-Start		robustness to middleboxes with TCP using an IP Quick-Start Option,
	Option, one would have to have a TCP-level Quick-Start Request		one would have to have a TCP-level Quick-Start Request packet that
	packet that could be sent concurrently but separately from the TCP		could be sent concurrently with, but separately from, the TCP SYN
	SYN packet.)		packet.)
	However, there are a number of disadvantages to using ICMP. Some		However, there are a number of disadvantages to using ICMP. Some
	firewalls and middleboxes may not forward the ICMP Quick-Start		firewalls and middleboxes may not forward the ICMP Quick-Start
	Request packets. (If an ICMP Reply packet from a router to the		Request packets. (If an ICMP Reply packet from a router to the
	sender is dropped in the network, the sender would still know that		sender is dropped in the network, the sender would still know that
	the request was not approved, as stated earlier, so this would not		the request was not approved, as stated earlier, so this would not be
	be as serious of a problem.) In addition, it would be difficult, if		as serious of a problem.) In addition, it would be difficult, if not
	not impossible, for a router in the middle of an IP tunnel to		impossible, for a router in the middle of an IP tunnel to deliver an
	deliver an ICMP Reply packet to the actual source, for example when		ICMP Reply packet to the actual source, for example, when the inner
	the inner IP header is encrypted as in IPsec ESP tunnel mode		IP header is encrypted, as in IPsec ESP tunnel mode [RFC4301].
	[RFC4301]. Again, however, the ICMP Reply packet would not be		Again, however, the ICMP Reply packet would not be essential to the
	essential to the correct operation of ICMP Quick-Start.		correct operation of ICMP Quick-Start.
	Unauthenticated out-of-band ICMP messages could enable some types of		Unauthenticated out-of-band ICMP messages could enable some types of
	attacks by third-party malicious hosts that are not possible when		attacks by third-party malicious hosts that are not possible when the
	the control information is carried in-band with the IP packets that		control information is carried in-band with the IP packets that can
	can only be altered by the routers on the connection path. Finally,		only be altered by the routers on the connection path. Finally, as a
	as a minor concern, using ICMP would cause a small amount of		minor concern, using ICMP would cause a small amount of additional
	additional traffic in the network, which is not the case when using		traffic in the network, which is not the case when using IP options.
	IP options.
	B.1.2. RSVP		B.1.2. RSVP
	With some modifications RSVP [RFC2205] could be used as a bearer		With some modifications, RSVP [RFC2205] could be used as a bearer
	protocol for carrying the Quick-Start Requests. Because routers are		protocol for carrying the Quick-Start Requests. Because routers are
	expected to process RSVP packets more extensively than the normal		expected to process RSVP packets more extensively than the normal
	transport protocol IP packets, delivering a Quick-Start rate request		transport protocol IP packets, delivering a Quick-Start rate request
	using an RSVP packet would seem an appealing choice. However, Quick-		using an RSVP packet would seem an appealing choice. However, Quick-
	Start with RSVP would require a few differences from the		Start with RSVP would require a few differences from the conventional
	conventional usage of RSVP. Quick-Start would not require periodical		usage of RSVP. Quick-Start would not require periodical refreshing
	refreshing of soft state, because Quick-Start does not require per-		of soft state, because Quick-Start does not require per-connection
	connection state in routers. Quick-Start Requests would be		state in routers. Quick-Start Requests would be transmitted
	transmitted downstream from the sender to receiver in the RSVP Path		downstream from the sender to receiver in the RSVP Path messages,
	messages, which is different from the conventional RSVP model where		which is different from the conventional RSVP model where the
	the reservations originate from the receiver. Furthermore, the		reservations originate from the receiver. Furthermore, the Quick-
	Quick-Start Response would be sent using the transport-level or		Start Response would be sent using the transport-level or
	application-level mechanisms instead of using the RSVP Resv message.		application-level mechanisms, instead of using the RSVP Resv message.
	If RSVP was used for carrying a Quick-Start Request, a new "Quick-		If RSVP was used for carrying a Quick-Start Request, a new "Quick-
	Start Request" class object would be included in the RSVP Path		Start Request" class object would be included in the RSVP Path
	message that is sent from the sender to receiver. The object would		message that is sent from the sender to receiver. The object would
	contain the rate request field in addition to the common length and		contain the rate request field in addition to the common length and
	type fields. The Send_TTL field in the RSVP common header could be		type fields. The Send_TTL field in the RSVP common header could be
	used as the equivalent of the QS TTL field. The Quick-Start capable		used as the equivalent of the QS TTL field. The Quick-Start capable
	routers along the path would inspect the Quick-Start Request object		routers along the path would inspect the Quick-Start Request object
	in the RSVP Path message, decrement Send_TTL and adjust the rate		in the RSVP Path message, decrement Send_TTL, and adjust the rate
	request field if needed. If an RSVP router did not understand the		request field if needed. If an RSVP router did not understand the
	Quick-Start Request object, it would reject the entire RSVP message		Quick-Start Request object, it would reject the entire RSVP message
	and send an RSVP PathErr message back to the sender. When an RSVP		and send an RSVP PathErr message back to the sender. When an RSVP
	message with the Quick-Start Request object reaches the receiver,		message with the Quick-Start Request object reaches the receiver, the
	the receiver sends a Quick-Start Reply message in the corresponding		receiver sends a Quick-Start Reply message in the corresponding
	transport protocol header in the same way as described in the		transport protocol header in the same way as described in the context
	context of IP options earlier. If the RSVP message with the Quick-		of IP options earlier. If the RSVP message with the Quick-Start
	Start Request object was dropped along the path, the transport		Request object was dropped along the path, the transport sender would
	sender would simply proceed with the normal congestion control		simply proceed with the normal congestion control procedures.
	procedures.
	Much of the discussion about benefits and drawbacks of using ICMP		Much of the discussion about benefits and drawbacks of using ICMP for
	for making the Quick-Start Request also applies to the RSVP case. If		making the Quick-Start Request also applies to the RSVP case. If the
	the Quick-Start Request was transmitted in a separate packet instead		Quick-Start Request was transmitted in a separate packet instead of
	of as an IP option, the transport protocol packet delivery would not		as an IP option, the transport protocol packet delivery would not be
	be delayed due to IP option processing at the routers, and the		delayed due to IP option processing at the routers, and the initial
	initial transport packets would reach their destination more		transport packets would reach their destination more reliably. The
	reliably. The possible disadvantages of using ICMP and RSVP are also		possible disadvantages of using ICMP and RSVP are also expected to be
	expected to be similar: middleboxes in the network may not be able		similar: middleboxes in the network may not be able to forward the
	to forward the Quick-Start Request messages, and the IP tunnels		Quick-Start Request messages, and the IP tunnels might cause problems
	might cause problems for processing the Quick-Start Requests.		for processing the Quick-Start Requests.
	B.2. Alternate Encoding Functions		B.2. Alternate Encoding Functions
	In this section we look at alternate encoding functions for the Rate		In this section, we look at alternate encoding functions for the Rate
	Request field in the Quick-Start Request. The main requirements for		Request field in the Quick-Start Request. The main requirements for
	this function is that it should have a sufficiently wide range for		this function is that it should have a sufficiently wide range for
	the requested rate. There is no need for overly-fine-grained		the requested rate. There is no need for overly fine-grained
	precision in the requested rate. Similarly, while it would be		precision in the requested rate. Similarly, while it would be
	attractive for the encoding function to be easily computable, it is		attractive for the encoding function to be easily computable, it is
	also possible for end-nodes and routers to simply store the table		also possible for end-nodes and routers to simply store the table
	giving the mapping between the value N in the Rate Request field,		giving the mapping between the value N in the Rate Request field, and
	and the actual rate request f(N). In this section we consider		the actual rate request f(N). In this section, we consider possible
	possible encoding methods for Rate Request fields of different		encoding methods for Rate Request fields of different sizes,
	sizes, including four-bit, eight-bit, and larger Rate Request		including four-bit, eight-bit, and larger Rate Request fields.
	fields.
	Linear functions:		Linear functions:
	One possible proposal would be for the Rate Request field to be		One possible proposal would be for the Rate Request field to be
	formatted in bits per second, scaled so that one unit equals M Kbps,		formatted in bits per second, scaled so that one unit equals M Kbps,
	for some fixed value of M. Thus, for the value N in the Rate		for some fixed value of M. Thus, for the value N in the Rate Request
	Request field, the requested rate would be M*N Kbps.		field, the requested rate would be M*N Kbps.
	Powers of two:		Powers of two:
	If a granularity of factors of two is sufficient for the Rate		If a granularity of factors of two is sufficient for the Rate
	Request, then the encoding function with the most range would be for		Request, then the encoding function with the most range would be for
	the requested rate to be K*2^N, for N the value in the Rate Request		the requested rate to be K*2^N; for N, the value in the Rate Request
	field, and for K some constant. For N=0, the rate request would be		field; and for K, some constant. For N=0, the rate request would be
	set to zero, regardless of the encoding function. For example, for		set to zero, regardless of the encoding function. For example, for
	K=40,000 and an eight-bit Rate Request field, the request range		K=40,000 and an eight-bit Rate Request field, the request range would
	would be from 80 Kbps to 40*2^255 Kbps. This clearly would be an		be from 80 Kbps to 40*2^255 Kbps. This clearly would be an
	unnecessarily large request range.		unnecessarily large request range.
	For a four-bit Rate Request field, the upper limit on the rate		For a four-bit Rate Request field, the upper limit on the rate
	request is 1.3 Gbps. It seems to us that an upper limit of 1.3 Gbps		request is 1.3 Gbps. It seems to us that an upper limit of 1.3 Gbps
	would be fine for the Quick-Start rate request, and that connections		would be fine for the Quick-Start rate request, and that connections
	wishing to start up with a higher initial sending rate should be		wishing to start up with a higher initial sending rate should be
	encouraged to use other mechanisms, such as the explicit reservation		encouraged to use other mechanisms, such as the explicit reservation
	of bandwidth. If an upper limit of 1.3 Gbps was not acceptable,		of bandwidth. If an upper limit of 1.3 Gbps was not acceptable, then
	then five or six bits could be used for the Rate Request field.		five or six bits could be used for the Rate Request field.
	The lower limit of 80 Kbps could be useful for flows with round-trip		The lower limit of 80 Kbps could be useful for flows with round-trip
	times of a second or more. For a flow with a round-trip time of one		times of a second or more. For a flow with a round-trip time of one
	second, as is typical in some wireless networks, the TCP initial		second, as is typical in some wireless networks, the TCP initial
	window of 4380 bytes allowed by [RFC3390] (given appropriate packet		window of 4380 bytes allowed by [RFC3390] (given appropriate packet
	sizes) would translate to an initial sending rate of 35 Kbps. Thus,		sizes) would translate to an initial sending rate of 35 Kbps. Thus,
	for TCP flows, a rate request of 80 Kbps could be useful for some		for TCP flows, a rate request of 80 Kbps could be useful for some
	flows with large round-trip times.		flows with large round-trip times.
	The lower limit of 80 Kbps could also be useful for some non-TCP		The lower limit of 80 Kbps could also be useful for some non-TCP
	flows that send small packets, with at most one small packet every		flows that send small packets, with at most one small packet every 10
	10 ms. A rate request of 80 Kbps would translate to a rate of a		ms. A rate request of 80 Kbps would translate to a rate of a hundred
	hundred 100-byte packets per second (including packet headers).		100-byte packets per second (including packet headers). While some
	While some small-packet flows with large round-trip times might find		small-packet flows with large round-trip times might find a smaller
	a smaller rate request of 40 Kbps to be useful, our assumption is		rate request of 40 Kbps to be useful, our assumption is that a lower
	that a lower limit of 80 Kbps on the rate request will be generally		limit of 80 Kbps on the rate request will be generally sufficient.
	sufficient. Again, if the lower limit of 80 kbps was not		Again, if the lower limit of 80 kbps was not acceptable, then extra
	acceptable, then extra bits could be used for the Rate Request		bits could be used for the Rate Request field.
	field.
	If the granularity of factors of two was too coarse, then the		If the granularity of factors of two was too coarse, then the
	encoding function could use a base less than two. An alternate form		encoding function could use a base less than two. An alternate form
	for the encoding function would be to use a hybrid of linear and		for the encoding function would be to use a hybrid of linear and
	exponential functions.		exponential functions.
	A mantissa and exponent representation:		A mantissa and exponent representation:
	Section 4.4 of [B05] suggests a mantissa and exponent representation		Section 4.4 of [B05] suggests a mantissa and exponent representation
	for the Quick-Start encoding function. With e and f as the binary		for the Quick-Start encoding function. With e and f as the binary
	numbers in the exponent and mantissa fields, and with 0 <= f < 1,		numbers in the exponent and mantissa fields, and with 0 <= f < 1,
	this would represent the rate (1+f)*2^e. [B05] suggests a mantissa		this would represent the rate (1+f)*2^e. [B05] suggests a mantissa
	field for f of 8, 16, or 24 bits, with an exponent field for e of 8		field for f of 8, 16, or 24 bits, with an exponent field for e of 8
	bits. This representation would allow larger rate requests, with an		bits. This representation would allow larger rate requests, with an
	encoding that is less coarse than the powers-of-two encoding used in		encoding that is less coarse than the powers-of-two encoding used in
	this document.		this document.
	Constraints of the transport protocol:		Constraints of the transport protocol:
	We note that the Rate Request is also constrained by the abilities		We note that the Rate Request is also constrained by the abilities of
	of the transport protocol. For example, for TCP with Window		the transport protocol. For example, for TCP with Window Scaling,
	Scaling, the maximum window is at most 2**30 bytes. For a TCP		the maximum window is at most 2**30 bytes. For a TCP connection with
	connection with a long, 1 second round-trip time, this would give a		a long, 1 second round-trip time, this would give a maximum sending
	maximum sending rate of 1.07 Gbps.		rate of 1.07 Gbps.
	B.3. The Quick-Start Request: Packets or Bytes?		B.3. The Quick-Start Request: Packets or Bytes?
	One of the design questions is whether the Rate Request field should		One of the design questions is whether the Rate Request field should
	be in bytes per second or in packets per second. We discuss this		be in bytes per second or in packets per second. We discuss this
	separately from the perspective of the transport, and from the		separately from the perspective of the transport, and from the
	perspective of the router.		perspective of the router.
	For TCP, the results from the Quick-Start Request are translated		For TCP, the results from the Quick-Start Request are translated into
	into a congestion window in bytes, using the measured round-trip		a congestion window in bytes, using the measured round-trip time and
	time and the MSS. This window applies only to the bytes of data		the MSS. This window applies only to the bytes of data payload, and
	payload, and does not include the bytes in the TCP or IP packet		does not include the bytes in the TCP or IP packet headers. Other
	headers. Other transport protocols would conceivably use the Quick-		transport protocols would conceivably use the Quick-Start Request
	Start Request directly in packets per second, or could translate the		directly in packets per second, or could translate the Quick-Start
	Quick-Start Request to a congestion window in packets.		Request to a congestion window in packets.
	The assumption of this draft is that the router only approves the		The assumption of this document is that the router only approves the
	Quick-Start Request when the output link is significantly		Quick-Start Request when the output link is significantly
	underutilized. For this, the router could measure the available		underutilized. For this, the router could measure the available
	bandwidth in bytes per second, or could convert between packets and		bandwidth in bytes per second, or could convert between packets and
	bytes by some mechanism.		bytes by some mechanism.
	If the Quick-Start Request was in bytes per second, and applied only		If the Quick-Start Request was in bytes per second, and applied only
	to the data payload, then the router would have to convert from		to the data payload, then the router would have to convert from bytes
	bytes per second of data payload, to bytes per second of packets on		per second of data payload, to bytes per second of packets on the
	the wire. If the Rate Request field was in bytes per second and the		wire. If the Rate Request field was in bytes per second, and the
	sender ended up using very small packets, this could translate to a		sender ended up using very small packets, this could translate to a
	significantly larger number in terms of bytes per second on the		significantly larger number in terms of bytes per second on the wire.
	wire. Therefore, for a Quick-Start Request in bytes per second, it		Therefore, for a Quick-Start Request in bytes per second, it makes
	makes most sense for this to include the transport and IP headers as		most sense for this to include the transport and IP headers as well
	well as the data payload. Of course, this will be at best a rough		as the data payload. Of course, this will be, at best, a rough
	approximation on the part of the sender; the transport-level sender		approximation on the part of the sender; the transport-level sender
	might not know the size of the transport and IP headers in bytes,		might not know the size of the transport and IP headers in bytes, and
	and might know nothing at all about the separate headers added in IP		might know nothing at all about the separate headers added in IP
	tunnels downstream. This rough estimate seems sufficient, however,		tunnels downstream. This rough estimate seems sufficient, however,
	given the overall lack of fine precision in Quick-Start		given the overall lack of fine precision in Quick-Start
	functionality.		functionality.
	It has been suggested that the router could possibly use information		It has been suggested that the router could possibly use information
	from the MSS option in the TCP packet header of the SYN packet to		from the MSS option in the TCP packet header of the SYN packet to
	convert the Quick-Start Request from packets per second to bytes per		convert the Quick-Start Request from packets per second to bytes per
	second, or vice versa. This would be problematic for several		second, or vice versa. This would be problematic for several
	reasons. First, if IPsec is used, the TCP header will be encrypted.		reasons. First, if IPsec is used, the TCP header will be encrypted.
	Second, the MSS option is defined as the maximum MSS that the TCP		Second, the MSS option is defined as the maximum MSS that the TCP
	sender expects to receive, not the maximum MSS that the TCP sender		sender expects to receive, not the maximum MSS that the TCP sender
	plans to send [RFC793]. However, it is probably often the case that		plans to send [RFC793]. However, it is probably often the case that
	this MSS also applies as an upper bound on the MSS used by the TCP		this MSS also applies as an upper bound on the MSS used by the TCP
	sender in sending.		sender in sending.
	We note that the sender does not necessarily know the Path MTU when		We note that the sender does not necessarily know the Path MTU when
	the Quick-Start Request is sent, or when the initial window of data		the Quick-Start Request is sent, or when the initial window of data
	is sent. Thus, with IPv4, packets from the initial window could end		is sent. Thus, with IPv4, packets from the initial window could end
	up being fragmented in the network if the "Don't Fragment" (DF) bit		up being fragmented in the network if the "Don't Fragment" (DF) bit
	skipping to change at page 72, line 16		skipping to change at page 64, line 10
	sender expects to receive, not the maximum MSS that the TCP sender		sender expects to receive, not the maximum MSS that the TCP sender
	plans to send [RFC793]. However, it is probably often the case that		plans to send [RFC793]. However, it is probably often the case that
	this MSS also applies as an upper bound on the MSS used by the TCP		this MSS also applies as an upper bound on the MSS used by the TCP
	sender in sending.		sender in sending.
	We note that the sender does not necessarily know the Path MTU when		We note that the sender does not necessarily know the Path MTU when
	the Quick-Start Request is sent, or when the initial window of data		the Quick-Start Request is sent, or when the initial window of data
	is sent. Thus, with IPv4, packets from the initial window could end		is sent. Thus, with IPv4, packets from the initial window could end
	up being fragmented in the network if the "Don't Fragment" (DF) bit		up being fragmented in the network if the "Don't Fragment" (DF) bit
	is not set [RFC1191]. A Rate Request in bytes per second is		is not set [RFC1191]. A Rate Request in bytes per second is
	reasonably robust to fragmentation. Clearly a Rate Request in		reasonably robust to fragmentation. Clearly, a Rate Request in
	packets per second is less robust in the presence of fragmentation.		packets per second is less robust in the presence of fragmentation.
	Interactions between larger initial windows and Path MTU Discovery		Interactions between larger initial windows and Path MTU Discovery
	are discussed in more detail in RFC 3390 [RFC3390].		are discussed in more detail in RFC 3390 [RFC3390].
	For a Quick-Start Request in bytes per second, the transport senders		For a Quick-Start Request in bytes per second, the transport senders
	would have the additional complication of estimating the bandwidth		would have the additional complication of estimating the bandwidth
	usage added by the packet headers.		usage added by the packet headers.
	We have chosen a Rate Request field in bytes per second rather than		We have chosen a Rate Request field in bytes per second rather than
	in packets per second because it seems somewhat more robust,		in packets per second because it seems somewhat more robust,
	skipping to change at page 72, line 38		skipping to change at page 64, line 32
	B.4. Quick-Start Semantics: Total Rate or Additional Rate?		B.4. Quick-Start Semantics: Total Rate or Additional Rate?
	For a Quick-Start Request sent in the middle of a connection, there		For a Quick-Start Request sent in the middle of a connection, there
	are two possible semantics for the Rate Request field, as follows:		are two possible semantics for the Rate Request field, as follows:
	(1) Total Rate: The requested Rate Request is the requested total		(1) Total Rate: The requested Rate Request is the requested total
	rate for the connection, including the current rate; or		rate for the connection, including the current rate; or
	(2) Additional Rate: The requested Rate Request is the requested		(2) Additional Rate: The requested Rate Request is the requested
	increase in the total rate for that connection, over and above the		increase in the total rate for that connection, over and above
	current sending rate.		the current sending rate.
	When the Quick-Start Request is sent after an idle period, the		When the Quick-Start Request is sent after an idle period, the
	current sending rate is zero, and there is no difference between (1)		current sending rate is zero, and there is no difference between (1)
	and (2) above. However, a Quick-Start Request can also be sent in		and (2) above. However, a Quick-Start Request can also be sent in
	the middle of a connection that has not been idle, e.g., after a		the middle of a connection that has not been idle, e.g., after a
	mobility event, or after an application-limited period when the		mobility event, or after an application-limited period when the
	sender is suddenly ready to send at a much higher rate. In this		sender is suddenly ready to send at a much higher rate. In this
	case, there can be a significant difference between (1) and (2)		case, there can be a significant difference between (1) and (2)
	above. In this section we consider briefly the tradeoffs between		above. In this section, we consider briefly the tradeoffs between
	these two options, and explain why we have chosen the `Total Rate'		these two options, and explain why we have chosen the `Total Rate'
	semantics.		semantics.
	The Total Rate semantics makes it easier for routers to ``allocate''		The Total Rate semantics makes it easier for routers to "allocate"
	the same rate to all connections. This lends itself to fairness,		the same rate to all connections. This lends itself to fairness, and
	and improves convergence times between old and new connections.		improves convergence times between old and new connections. With the
	With the Additional Rate semantics, the router would not necessarily		Additional Rate semantics, the router would not necessarily know the
	know the current sending rates of the flows requesting additional		current sending rates of the flows requesting additional rates, and
	rates, and therefore would not have sufficient information to use		therefore would not have sufficient information to use fairness as a
	fairness as a metric in granting rate requests. With the Total Rate		metric in granting rate requests. With the Total Rate semantics, the
	semantics, the fairness is automatic; the router is not granting		fairness is automatic; the router is not granting rate requests for
	rate requests for *additional* bandwidth without knowing the current		*additional* bandwidth without knowing the current sending rates of
	sending rates of the different flows.		the different flows.
	The Additional Rate semantics also lends itself to gaming by the		The Additional Rate semantics also lends itself to gaming by the
	connection, with senders sending frequent Quick-Start Requests in		connection, with senders sending frequent Quick-Start Requests in the
	the hope of gaining a higher rate. If the router is granting the		hope of gaining a higher rate. If the router is granting the same
	same maximum rate for all rate requests, then there is little		maximum rate for all rate requests, then there is little benefit to a
	benefit to a connection of sending a rate request over and over		connection of sending a rate request over and over again. However,
	again. However, if the router is granting an *additional* rate with		if the router is granting an *additional* rate with each rate
	each rate request, over and above the current sending rate, then it		request, over and above the current sending rate, then it is in a
	is in a connection's interest to send as many rate requests as		connection's interest to send as many rate requests as possible, even
	possible, even if very few of them are in fact granted.		if very few of them are, in fact, granted.
	Appendix E discusses a Report of Current Sending Rate as one		Appendix E discusses a Report of Current Sending Rate as one possible
	possible function in the Quick-Start Option. However, we have not		function in the Quick-Start Option. However, we have not
	standardized this possible use at this time.		standardized this possible use at this time.
	B.5. Alternate Responses to the Loss of a Quick-Start Packet		B.5. Alternate Responses to the Loss of a Quick-Start Packet
	Section 4.6 discusses TCP's response to the loss of a Quick-Start		Section 4.6 discusses TCP's response to the loss of a Quick-Start
	packet in the initial window. This section discusses several		packet in the initial window. This section discusses several
	alternate responses.		alternate responses.
	One possible alternative to reverting to the default slow-start		One possible alternative to reverting to the default Slow-Start after
	after the loss of a Quick-Start packet from the initial window would		the loss of a Quick-Start packet from the initial window would have
	have been to halve the congestion window and continue in congestion		been to halve the congestion window and continue in congestion
	avoidance. However, we note that this would not have been a		avoidance. However, we note that this would not have been a
	desirable response for either the connection or for the network as a		desirable response for either the connection or for the network as a
	whole. The packet loss in the initial window indicates that Quick-		whole. The packet loss in the initial window indicates that Quick-
	Start failed in finding an appropriate congestion window, meaning		Start failed in finding an appropriate congestion window, meaning
	that the congestion window after halving may easily also be wrong.		that the congestion window after halving may easily also be wrong.
	A more moderate alternate would be to continue in congestion		A more moderate alternate would be to continue in congestion
	avoidance from a window of (W-D)/2, where W is the Quick-Start		avoidance from a window of (W-D)/2, where W is the Quick-Start
	congestion window, and D is the number of packets dropped or marked		congestion window, and D is the number of packets dropped or marked
	from that window. However, such an approach would implicitly assume		from that window. However, such an approach would implicitly assume
	that the number of Quick-Start packets delivered is a good		that the number of Quick-Start packets delivered is a good indication
	indication of the appropriate available bandwidth for that flow,		of the appropriate available bandwidth for that flow, even though
	even though other packets from that window were dropped in the		other packets from that window were dropped in the network. And,
	network. And, further, that using half the number of segments that		further, that using half the number of segments that were
	were successfully transmitted is conservative enough to account for		successfully transmitted is conservative enough to account for the
	the possibly inaccurate congestion window indication. We believe		possibly inaccurate congestion window indication. We believe that
	that such an assumption would require more analysis at this point,		such an assumption would require more analysis at this point,
	particularly in a network with a range of packet dropping mechanisms		particularly in a network with a range of packet dropping mechanisms
	at the router, and we cannot recommend it at this time.		at the router, and we cannot recommend it at this time.
	Another drawback of approaches that don't revert back to slow-start		Another drawback of approaches that don't revert back to slow-start
	when a Quick-Start packet in the initial window is dropped is that		when a Quick-Start packet in the initial window is dropped is that
	such approaches could give the TCP receiver a greater incentive to		such approaches could give the TCP receiver a greater incentive to
	lie about the Quick-Start request. If the sender reverts to slow-		lie about the Quick-Start Request. If the sender reverts to slow-
	start when a Quick-Start packet in the initial window is dropped,		start when a Quick-Start packet in the initial window is dropped,
	this diminishes the benefit a receiver would get from a Quick-Start		this diminishes the benefit a receiver would get from a Quick-Start
	request that resulted in a dropped or ECN-marked packet.		request that resulted in a dropped or ECN-marked packet.
	B.6. Why Not Include More Functionality?		B.6. Why Not Include More Functionality?
	This proposal for Quick-Start is a rather coarse-grained mechanism		This proposal for Quick-Start is a rather coarse-grained mechanism
	that would allow a connection to use a higher sending rate along		that would allow a connection to use a higher sending rate along
	underutilized paths, but that does not attempt to provide a next-		underutilized paths, but that does not attempt to provide a next-
	generation transport protocol or congestion control mechanism, and		generation transport protocol or congestion control mechanism, and
	does not attempt the goal of providing very high throughput with		does not attempt the goal of providing very high throughput with very
	very low delay. As Section A.4 discusses, there are a number of		low delay. Appendix A.4 discusses a number of proposals (such as
	proposals such as XCP, MaxNet, and AntiECN for more fine-grained		XCP, MaxNet, and AntiECN) that provide more fine-grained per-packet
	per-packet feedback from routers than the current congestion control		feedback from routers than the current congestion control mechanisms
	mechanisms, that do attempt these more ambitious goals.		and that attempt these more ambitious goals.
	Compared to proposals such as XCP and AntiECN, Quick-Start offers		Compared to proposals such as XCP and AntiECN, Quick-Start offers
	much less control. Quick-Start does not attempt to provide a new		much less control. Quick-Start does not attempt to provide a new
	congestion control mechanism, but simply to get permission from		congestion control mechanism, but simply to get permission from
	routers for a higher sending rate at start-up, or after an idle		routers for a higher sending rate at start-up, or after an idle
	period. Quick-Start can be thought of as an "anti-congestion-		period. Quick-Start can be thought of as an "anti-congestion-
	control" mechanism, that is only of any use when all of the routers		control" mechanism that is only of any use when all the routers along
	along the path are significantly under-utilized. Thus, Quick-Start		the path are significantly underutilized. Thus, Quick-Start is of no
	is of no use towards a target of high link utilization, or fairness		use towards a target of high link utilization, or fairness in a
	in a high-utilization scenario, or controlling queueing delay during		high-utilization scenario, or controlling queueing delay during high
	high-utilization, or anything of the like.		utilization, or anything of the like.
	At the same time, Quick-Start would allow larger initial windows		At the same time, Quick-Start would allow larger initial windows than
	than would proposals such as AntiECN, requires less input to routers		would proposals such as AntiECN, requires less input to routers than
	than XCP (e.g., XCP's cwnd and RTT fields), and would require less		XCP (e.g., XCP's cwnd and RTT fields), and would require less
	frequent feedback from routers than any new congestion control		frequent feedback from routers than any new congestion control
	mechanism. Thus, Quick-Start is significantly less powerful than		mechanism. Thus, Quick-Start is significantly less powerful than
	proposals for new congestion control mechanisms such as XCP and		proposals for new congestion control mechanisms, such as XCP and
	AntiECN, but as powerful or more powerful in terms of the specific		AntiECN, but as powerful or more powerful in terms of the specific
	issue of allowing larger initial windows, and (we think) more		issue of allowing larger initial windows. Also, (we think) it is
	amenable to incremental deployment in the current Internet.		more amenable to incremental deployment in the current Internet.
	We do not discuss proposals such as XCP in detail, but simply note		We do not discuss proposals such as XCP in detail, but simply note
	that there are a number of open questions. One question concerns		that there are a number of open questions. One question concerns
	whether there is a pressing need for more sophisticated congestion		whether there is a pressing need for more sophisticated congestion
	control mechanisms such as XCP in the Internet. Quick-Start is		control mechanisms, such as XCP, in the Internet. Quick-Start is
	inherently a rather crude tool that does not deliver assurances		inherently a rather crude tool that does not deliver assurances about
	about maintaining high link utilization and low queueing delay;		maintaining high link utilization and low queueing delay; Quick-Start
	Quick-Start is designed for use in environments that are		is designed for use in environments that are significantly
	significantly underutilized, and addresses the single question of		underutilized, and addresses the single question of whether a higher
	whether a higher sending rate is allowed. New congestion control		sending rate is allowed. New congestion control mechanisms with more
	mechanisms with more fine-grained feedback from routers could allow		fine-grained feedback from routers could allow faster start-ups even
	faster startups even in environments with rather high link		in environments with rather high link utilization. Is this a
	utilization. Is this a pressing requirement? Are the other		pressing requirement? Are the other benefits of more fine-grained
	benefits of more fine-grained congestion control feedback from		congestion control feedback from routers a pressing requirement?
	routers a pressing requirement?
	We would argue that even if more fine-grained per-packet feedback		We would argue that even if more fine-grained per-packet feedback
	from routers was implemented, it is reasonable to have a separate		from routers was implemented, it is reasonable to have a separate
	mechanism such as Quick-Start for indicating an allowed initial		mechanism, such as Quick-Start, for indicating an allowed initial
	sending rate, or an allowed total sending rate after an idle or		sending rate, or an allowed total sending rate after an idle or
	underutilized period.		underutilized period.
	One difference between Quick-Start and current proposals for fine-		One difference between Quick-Start and current proposals for fine-
	grained per-packet feedback such as XCP is that XCP is designed to		grained per-packet feedback, such as XCP, is that XCP is designed to
	give robust performance even in the case where different packets		give robust performance even in the case where different packets
	within a connection routinely follow different paths. XCP achieves		within a connection routinely follow different paths. XCP achieves
	relatively robust performance in the presence of multipath routing		relatively robust performance in the presence of multipath routing by
	by using per-packet feedback, where the feedback carried in a single		using per-packet feedback, where the feedback carried in a single
	packet is about the relative increase or decrease in the rate or		packet is about the relative increase or decrease in the rate or
	window to take effect when that particular packet is acknowledged,		window to take effect when that particular packet is acknowledged,
	not about the allowed sending rate for the connection as a whole.		not about the allowed sending rate for the connection as a whole.
	In contrast, Quick-Start sends a single Quick-Start request, and the		In contrast, Quick-Start sends a single Quick-Start Request, and the
	answer to that request gives the allowed sending rate for an entire		answer to that request gives the allowed sending rate for an entire
	window of data. As a result, Quick-Start could be problematic in an		window of data. As a result, Quick-Start could be problematic in an
	environment where some fraction of the packets in a window of data		environment where some fraction of the packets in a window of data
	take path A, and the rest of the packets take path B; for example,		take path A, and the rest of the packets take path B; for example,
	the Quick-Start Request could have travelled on path A, while half		the Quick-Start Request could have traveled on path A, while half the
	of the Quick-Start packets sent in the succeeding round-trip time		Quick-Start packets sent in the succeeding round-trip time are routed
	are routed on path B. We note that [ZDPS01] shows Internet paths to		on path B. We note that [ZDPS01] shows Internet paths to be stable
	be stable on the order of RTTs.		on the order of RTTs.
	There are also differences between Quick-Start and some of the		There are also differences between Quick-Start and some of the
	proposals for per-packet feedback in terms of the number of bits of		proposals for per-packet feedback in terms of the number of bits of
	feedback required from the routers to the end-nodes. Quick-Start		feedback required from the routers to the end-nodes. Quick-Start
	uses four bits of feedback in the rate request field to indicate the		uses four bits of feedback in the rate request field to indicate the
	allowed sending rate. XCP allocates a byte for per-packet feedback,		allowed sending rate. XCP allocates a byte for per-packet feedback,
	though there has been discussion of variants of XCP with less per-		though there has been discussion of variants of XCP with less per-
	packet feedback. This would be more like other proposals such as		packet feedback. This would be more like other proposals, such as
	anti-ECN that use a single bit of feedback from routers to indicate		anti-ECN, that use a single bit of feedback from routers to indicate
	that the sender can increase as fast as slow-starting, in response		that the sender can increase as fast as slow-starting, in response to
	to this particular packet acknowledgement. In general, there is		this particular packet acknowledgement. In general, there is
	probably considerable power in fine-grained proposals with only two		probably considerable power in fine-grained proposals with only two
	bits of feedback, indicating that the sender should decrease,		bits of feedback, indicating that the sender should decrease,
	maintain, or increase the sending rate or window when this packet is		maintain, or increase the sending rate or window when this packet is
	acknowledged. However, the power of Quick-Start would be		acknowledged. However, the power of Quick-Start would be
	considerably limited if it was restricted to only two bits of		considerably limited if it was restricted to only two bits of
	feedback; it seems likely that determining the initial sending rate		feedback; it seems likely that determining the initial sending rate
	fundamentally requires more bits of feedback from routers than does		fundamentally requires more bits of feedback from routers than does
	the steady-state, per-packet feedback to increase or decrease the		the steady-state, per-packet feedback to increase or decrease the
	sending rate.		sending rate.
	On a more practical level, one difference between Quick-Start and		On a more practical level, one difference between Quick-Start and
	proposals for per-packet feedback is that there are fewer open		proposals for per-packet feedback is that there are fewer open issues
	issues with Quick-Start than there would be with a new congestion		with Quick-Start than there would be with a new congestion control
	control mechanism. Because Quick-Start is a mechanism for		mechanism. Because Quick-Start is a mechanism for requesting an
	requesting an initial sending rate in an underutilized environment,		initial sending rate in an underutilized environment, its fairness
	its fairness issues are less severe than those of a general		issues are less severe than those of a general congestion control
	congestion control mechanism. With Quick-Start, there is no need		mechanism. With Quick-Start, there is no need for the end nodes to
	for the end nodes to tell the routers the round-trip time and		tell the routers the round-trip time and congestion window, as is
	congestion window, as is done in XCP; all that is needed is for the		done in XCP; all that is needed is for the end nodes to report the
	end nodes to report the requested sending rate.		requested sending rate.
	Table 3 provides a summary of the differences between Quick-Start		Table 3 provides a summary of the differences between Quick-Start and
	and proposals for per-packet congestion control feedback.		proposals for per-packet congestion control feedback.
	Proposals for		Proposals for
	Quick-Start Per-Packet Feedback		Quick-Start Per-Packet Feedback
	+------------------+----------------------+----------------------+		+------------------+----------------------+----------------------+
	Semantics: | Allowed sending rate | Change in rate/window,		Semantics: | Allowed sending rate | Change in rate/window,
	| per connection. | per-packet.		| per connection. | per-packet.
	+------------------+----------------------+----------------------+		+------------------+----------------------+----------------------+
	Relationship to | In addition. | Replacement.		Relationship to | In addition. | Replacement.
	congestion ctrl: | |		congestion ctrl: | |
	+------------------+----------------------+----------------------+		+------------------+----------------------+----------------------+
	skipping to change at page 77, line 30		skipping to change at page 68, line 48
	Input to routers: | Rate request. |RTT, cwnd, request (XCP)		Input to routers: | Rate request. |RTT, cwnd, request (XCP)
	| | None (Anti-ECN).		| | None (Anti-ECN).
	+------------------+----------------------+----------------------+		+------------------+----------------------+----------------------+
	Bits of feedback: | Four bits for | A few bits would		Bits of feedback: | Four bits for | A few bits would
	| rate request. | suffice?		| rate request. | suffice?
	+------------------+----------------------+----------------------+		+------------------+----------------------+----------------------+
	Table 3: Differences between Quick-Start and Proposals for		Table 3: Differences between Quick-Start and Proposals for
	Fine-Grained Per-Packet Feedback.		Fine-Grained Per-Packet Feedback.
	A separate question concerns whether mechanisms such as Quick-Start,		A separate question concerns whether mechanisms, such as Quick-Start,
	in combination with HighSpeed TCP and other changes in progress,		in combination with HighSpeed TCP and other changes in progress,
	would make a significant contribution towards meeting some of these		would make a significant contribution towards meeting some of these
	needs for new congestion control mechanisms. This could be viewed		needs for new congestion control mechanisms. This could be viewed as
	as a positive step towards meeting some of the more pressing current		a positive step towards meeting some of the more pressing current
	needs with a simple and reasonably deployable mechanism, or		needs with a simple and reasonably deployable mechanism, or
	alternately, as a negative step of unnecessarily delaying more		alternately, as a negative step of unnecessarily delaying more
	fundamental changes. Without answering this question, we would note		fundamental changes. Without answering this question, we would note
	that our own approach tends to favor the incremental deployment of		that our own approach tends to favor the incremental deployment of
	relatively simple mechanisms, as long as the simple mechanisms are		relatively simple mechanisms, as long as the simple mechanisms are
	not short-term hacks but mechanisms that lead the overall		not short-term hacks, but mechanisms that lead the overall
	architecture in the fundamentally correct direction.		architecture in the fundamentally correct direction.
	B.7. Alternate Implementations for a Quick-Start Nonce		B.7. Alternate Implementations for a Quick-Start Nonce
	B.7.1. An Alternate Proposal for the Quick-Start Nonce		B.7.1. An Alternate Proposal for the Quick-Start Nonce
	An alternate proposal for the Quick-Start Nonce from [B05] would be		An alternate proposal for the Quick-Start Nonce from [B05] would be
	for an n-bit field for the QS Nonce, with the sender generating a		for an n-bit field for the QS Nonce, with the sender generating a
	random nonce when it generates a Quick-Start Request. Each router		random nonce when it generates a Quick-Start Request. Each router
	that reduces the Rate Request by r would hash the QS nonce r times,		that reduces the Rate Request by r would hash the QS nonce r times,
	using a one-way hash function such as MD5 [RFC1321] or the secure		using a one-way hash function such as MD5 [RFC1321] or the secure
	hash 1 [SHA1]. The receiver returns the QS nonce to the sender.		hash 1 [SHA1]. The receiver returns the QS nonce to the sender.
	Because the sender knows the original value for the nonce, and the		Because the sender knows the original value for the nonce, and the
	original rate request, the sender knows the total number of steps s		original rate request, the sender knows the total number of steps s
	that the rate has been reduced. The sender then hashes the original		that the rate has been reduced. The sender then hashes the original
	nonce s times, to check whether the result is the same as the nonce		nonce s times to check whether the result is the same as the nonce
	returned by the receiver.		returned by the receiver.
	This alternate proposal for the nonce would be considerably more		This alternate proposal for the nonce would be considerably more
	powerful than the QS nonce described in Section 3.4, but it would		powerful than the QS nonce described in Section 3.4, but it would
	also require more CPU cycles from the routers when they reduce a		also require more CPU cycles from the routers when they reduce a
	Quick-Start request, and from the sender in verifying the nonce		Quick-Start Request, and from the sender in verifying the nonce
	returned by the receiver. As reported in [B05], routers could		returned by the receiver. As reported in [B05], routers could
	protect themselves from processor exhaustion attacks by limiting the		protect themselves from processor exhaustion attacks by limiting the
	rate at which they will approve reductions of Quick-Start requests.		rate at which they will approve reductions of Quick-Start Requests.
	Both the Function field and the Reserved field in the Quick-Start		Both the Function field and the Reserved field in the Quick-Start
	Option would allow the extension of Quick-Start to use Quick-Start		Option would allow the extension of Quick-Start to use Quick-Start
	requests with the alternate proposal for the Quick-Start Nonce, if		requests with the alternate proposal for the Quick-Start Nonce, if it
	it was ever desired.		was ever desired.
	B.7.2. The Earlier Request-Approved Quick-Start Nonce		B.7.2. The Earlier Request-Approved Quick-Start Nonce
	An earlier version of this document included a Request-Approved		An earlier version of this document included a Request-Approved
	Quick-Start Nonce (QS Nonce) that was initialized by the sender to a		Quick-Start Nonce (QS Nonce) that was initialized by the sender to a
	non-zero, `random' eight-bit number, along with a QS TTL that was		non-zero, `random' eight-bit number, along with a QS TTL that was
	initialized to the same value as the TTL in the IP header. The		initialized to the same value as the TTL in the IP header. The
	Request-Approved Quick-Start Nonce would have been returned by the		Request-Approved Quick-Start Nonce would have been returned by the
	transport receiver to the transport sender in the Quick-Start		transport receiver to the transport sender in the Quick-Start
	Response. A router could deny the Quick-Start request by failing to		Response. A router could deny the Quick-Start Request by failing to
	decrement the QS TTL field, by zeroing the QS Nonce field, or by		decrement the QS TTL field, by zeroing the QS Nonce field, or by
	deleting the Quick-Start Request from the packet header. The QS		deleting the Quick-Start Request from the packet header. The QS
	Nonce was included to provide some protection against broken		Nonce was included to provide some protection against broken
	downstream routers, or against misbehaving TCP receivers that might		downstream routers, or against misbehaving TCP receivers that might
	be inclined to lie about whether the Rate Request was approved.		be inclined to lie about whether the Rate Request was approved. This
	This protection is now provided by the QS Nonce, by the use of a		protection is now provided by the QS Nonce, by the use of a random
	random initial value for the QS TTL field, and by Quick-Start-		initial value for the QS TTL field, and by Quick-Start-capable
	capable routers hopefully either deleting the Quick-Start Option or		routers hopefully either deleting the Quick-Start Option or zeroing
	zeroing the QS TTL and QS Nonce fields when they deny a request.		the QS TTL and QS Nonce fields when they deny a request.
	With the old Request-Approved Quick-Start Nonce, along with the QS		With the old Request-Approved Quick-Start Nonce, along with the QS
	TTL field set to the same value as the TTL field in the IP header,		TTL field set to the same value as the TTL field in the IP header,
	the Quick-Start Request mechanism would have been self-terminating;		the Quick-Start Request mechanism would have been self-terminating;
	the Quick-Start Request would terminate at the first participating		the Quick-Start Request would terminate at the first participating
	router after a non-participating router had been encountered on the		router after a non-participating router had been encountered on the
	path. This minimizes unnecessary overhead incurred by routers		path. This minimizes unnecessary overhead incurred by routers
	because of option processing for the Quick-Start Request. In the		because of option processing for the Quick-Start Request. In the
	current specification, this "self-terminating" property is provided		current specification, this "self-terminating" property is provided
	by Quick-Start-capable routers hopefully either deleting the Quick-		by Quick-Start-capable routers hopefully either deleting the Quick-
	Start Option or zeroing the Rate Request field when they deny a		Start Option or zeroing the Rate Request field when they deny a
	request. Because the current specification uses a random initial		request. Because the current specification uses a random initial
	value for the QS TTL, Quick-Start-capable routers can't tell if the		value for the QS TTL, Quick-Start-capable routers can't tell if the
	Quick-Start Request is invalid because of non-Quick-Start-capable		Quick-Start Request is invalid because of non-Quick-Start-capable
	routers upstream. This is the cost of using a design that makes it		routers upstream. This is the cost of using a design that makes it
	difficult for the receiver to cheat about the value of the QS TTL.		difficult for the receiver to cheat about the value of the QS TTL.
	C. Quick-Start with DCCP		Appendix C. Quick-Start with DCCP
	DCCP is a new transport protocol for congestion-controlled,		DCCP is a new transport protocol for congestion-controlled,
	unreliable datagrams, intended for applications such as streaming		unreliable datagrams, intended for applications such as streaming
	media, Internet telephony, and on-line games. In DCCP, the		media, Internet telephony, and online games. In DCCP, the
	application has a choice of congestion control mechanisms, with the		application has a choice of congestion control mechanisms, with the
	currently-specified Congestion Control Identifiers (CCIDs) being		currently-specified Congestion Control Identifiers (CCIDs) being CCID
	CCID 2 for TCP-like congestion control, and CCID 3 for TFRC, an		2 for TCP-like congestion control, and CCID 3 for TCP Friendly Rate
	equation-based form of congestion control. We refer the reader to		Control (TFRC), an equation-based form of congestion control. We
	[RFC4340] for a more detailed description of DCCP, and of the		refer the reader to [RFC4340] for a more detailed description of DCCP
	congestion control mechanisms.		and congestion control mechanisms.
	Because CCID 3 uses a rate-based congestion control mechanism, it		Because CCID 3 uses a rate-based congestion control mechanism, it
	raises some new issues about the use of Quick-Start with transport		raises some new issues about the use of Quick-Start with transport
	protocols. In this document we don't attempt to specify the use of		protocols. In this document, we don't attempt to specify the use of
	Quick-Start with DCCP. However, we do discuss some of the issues		Quick-Start with DCCP. However, we do discuss some of the issues
	that might arise.		that might arise.
	In considering the use of Quick-Start with CCID 3 for requesting a		In considering the use of Quick-Start with CCID 3 for requesting a
	higher initial sending rate, the following questions arise:		higher initial sending rate, the following questions arise:
	(1) How does the sender respond if a Quick-Start packet is dropped?		(1) How does the sender respond if a Quick-Start packet is dropped?
	As in TCP, if an initial Quick-Start packet is dropped, the CCID 3
	sender should revert to the congestion control mechanisms it would		As in TCP, if an initial Quick-Start packet is dropped, the CCID
	have used if the Quick-Start request had not been approved.		3 sender should revert to the congestion control mechanisms it
			would have used if the Quick-Start Request had not been approved.
	(2) When does the sender decide there has been no feedback from the		(2) When does the sender decide there has been no feedback from the
	receiver?		receiver?
	Unlike TCP, CCID 3 does not use acknowledgements for every packet,
	or for every other packet. In contrast, the CCID 3 receiver sends		Unlike TCP, CCID 3 does not use acknowledgements for every
	feedback to the sender roughly once per round-trip time. In CCID 3,		packet, or for every other packet. In contrast, the CCID 3
	the allowed sending rate is halved if no feedback is received from		receiver sends feedback to the sender roughly once per round-trip
	the receiver in at least four round-trip times (when the sender is		time. In CCID 3, the allowed sending rate is halved if no
	sending at least one packet every two round-trip times). When a		feedback is received from the receiver in at least four round-
	Quick-Start request is used, it would seem necessary to use a		trip times (when the sender is sending at least one packet every
	smaller time interval, e.g., to reduce the sending rate if no		two round-trip times). When a Quick-Start Request is used, it
	feedback arrives from the receiver in at least two round-trip times.		would seem necessary to use a smaller time interval, e.g., to
			reduce the sending rate if no feedback arrives from the receiver
			in at least two round-trip times.
	The question also arises of how the sending rate should be reduced		The question also arises of how the sending rate should be reduced
	after a period of no feedback from the receiver. As with TCP, the		after a period of no feedback from the receiver. As with TCP, the
	default CCID 3 response of halving the sending rate is not		default CCID 3 response of halving the sending rate is not
	necessarily a sufficient response to the absence of feedback; an		necessarily a sufficient response to the absence of feedback; an
	alternative is to reduce the sending rate to the sending rate that		alternative is to reduce the sending rate to the sending rate that
	would have been used if no Quick-Start request had been approved.		would have been used if no Quick-Start Request had been approved.
	That is, if a CCID 3 sender uses a Quick-Start request, special		That is, if a CCID 3 sender uses a Quick-Start Request, special rules
	rules might be required to handle the sender's response to a period		might be required to handle the sender's response to a period of no
	of no feedback from the receiver regarding the Quick-Start packets.		feedback from the receiver regarding the Quick-Start packets.
	Similarly, in considering the use of Quick-Start with CCID 3 for		Similarly, in considering the use of Quick-Start with CCID 3 for
	requesting a higher sending rate after an idle period, the following		requesting a higher sending rate after an idle period, the following
	questions arise:		questions arise:
	(1) What rate does the sender request?		(1) What rate does the sender request?
	As in TCP, there is a straightforward answer to the rate request		As in TCP, there is a straightforward answer to the rate request
	that the CCID 3 sender should use in requesting a higher sending		that the CCID 3 sender should use in requesting a higher sending
	rate after an idle period. The sender knows the current loss event		rate after an idle period. The sender knows the current loss
	rate, either from its own calculations or from feedback from the		event rate, either from its own calculations or from feedback
	receiver, and can determine the sending rate allowed by that loss		from the receiver, and can determine the sending rate allowed by
	event rate. This is the upper bound on the sending rate that should		that loss event rate. This is the upper bound on the sending
	be requested by the CCID 3 sender. A Quick-Start request is useful		rate that should be requested by the CCID 3 sender. A Quick-
	with CCID 3 when the sender is coming out of an idle or		Start Request is useful with CCID 3 when the sender is coming out
	underutilized period, because in standard operation CCID 3 does not		of an idle or underutilized period, because in standard
	allow the sender to send more than twice as fast as the receiver has		operation, CCID 3 does not allow the sender to send more than
	reported received in the most recent feedback message.		twice as fast as the receiver has reported received in the most
			recent feedback message.
	(2) What is the response to loss?		(2) What is the response to loss?
	The response to the loss of Quick-Start packets should be to return
	to the sending rate that would have been used if Quick-Start had not		The response to the loss of Quick-Start packets should be to
	been requested.		return to the 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		(3) When does the sender decide there has been no feedback from the
	receiver?		receiver?
	As in the case of the initial sending rate, it would seem prudent to
	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, the sending rate should be reduced to the sending rate that
	would have been used if no Quick-Start request had been approved.
	D. Possible Router Algorithm		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, the sending rate should be reduced to the sending
			rate that would have been used if no Quick-Start Request had been
			approved.
			Appendix D. Possible Router Algorithm
	This specification does not tightly define the algorithm a router		This specification does not tightly define the algorithm a router
	uses when deciding whether to approve a Quick-Start Rate Request or		uses when deciding whether to approve a Quick-Start Rate Request or
	whether and how to reduce a Rate Request. A range of algorithms is		whether and how to reduce a Rate Request. A range of algorithms is
	likely useful in this space and we consider the algorithm a		likely useful in this space and we consider the algorithm a
	particular router uses to be a local policy decision. In addition,		particular router uses to be a local policy decision. In addition,
	we believe that additional experimentation with router algorithms is		we believe that additional experimentation with router algorithms is
	necessary to have a solid understanding of the dynamics various		necessary to have a solid understanding of the dynamics various
	algorithms impose. However, we provide one particular algorithm in		algorithms impose. However, we provide one particular algorithm in
	this appendix as an example and as a framework for thinking about		this appendix as an example and as a framework for thinking about
	additional mechanisms.		additional mechanisms.
	[SAF06] provides several algorithms routers can use to consider		[SAF06] provides several algorithms routers can use to consider
	incoming Rate Requests. The decision process involves two		incoming Rate Requests. The decision process involves two
	algorithms. First, the router needs to track the link utilization		algorithms. First, the router needs to track the link utilization
	over the recent past. Second, this utilization needs to be updated		over the recent past. Second, this utilization needs to be updated
	by the potential new bandwidth from recent Quick-Start approvals,		by the potential new bandwidth from recent Quick-Start approvals, and
	and then compared with the router's notion of when it is		then compared with the router's notion of when it is underutilized
	underutilized enough to approve Quick-Start requests (of some size).		enough to approve Quick-Start Requests (of some size).
	First, we define the "peak utilization" estimation technique (from		First, we define the "peak utilization" estimation technique (from
	[SAF06]). This mechanism records the utilization of the link every		[SAF06]). This mechanism records the utilization of the link every S
	S seconds and stores the most recent N of these measurements. The		seconds and stores the most recent N of these measurements. The
	utilization is then taken as the highest utilization of the N		utilization is then taken as the highest utilization of the N
	samples. This method, therefore, keeps N*S seconds of history.		samples. This method, therefore, keeps N*S seconds of history. This
	This algorithm reacts rapidly to increases in the link utilization.		algorithm reacts rapidly to increases in the link utilization. In
	In [SAF06] S is set to 0.15 seconds, and experiments use values for		[SAF06], S is set to 0.15 seconds, and experiments use values for N
	N ranging from 3 to 20.		ranging from 3 to 20.
	Second, we define the "target" algorithm for processing incoming		Second, we define the "target" algorithm for processing incoming
	Quick-Start Rate Requests (also from [SAF06]). The algorithm relies		Quick-Start Rate Requests (also from [SAF06]). The algorithm relies
	on knowing the bandwidth of the outgoing link (which in many cases		on knowing the bandwidth of the outgoing link (which, in many cases,
	can be easily configured), the utilization of the outgoing link		can be easily configured), the utilization of the outgoing link (from
	(from an estimation technique such as given above) and an estimate		an estimation technique such as given above), and an estimate of the
	of the potential bandwidth from recent Quick-Start approvals.		potential bandwidth from recent Quick-Start approvals.
	Tracking the potential bandwidth from recent Quick-Start approvals		Tracking the potential bandwidth from recent Quick-Start approvals is
	is another case where local policy dictates how it should be done.		another case where local policy dictates how it should be done. The
	The simplest method, outlined in Section 8.2, is for the router to		simplest method, outlined in Section 8.2, is for the router to keep
	keep track of the aggregate Quick-Start rate requests approved in		track of the aggregate Quick-Start rate requests approved in the most
	the most recent two or more time intervals, including the current		recent two or more time intervals, including the current time
	time interval, and to use the sum of the aggregate rate requests		interval, and to use the sum of the aggregate rate requests over
	over these time intervals as the estimate of the approved Rate		these time intervals as the estimate of the approved Rate Requests.
	Requests. The experiments in [SAF06] keep track of the aggregate		The experiments in [SAF06] keep track of the aggregate approved Rate
	approved Rate Requests over the most recent two time intervals, for		Requests over the most recent two time intervals, for intervals of
	intervals of 150~msec.		150 msec.
	The target algorithm also depends on a threshold (qs_thresh) that is		The target algorithm also depends on a threshold (qs_thresh) that is
	the fraction of the outgoing link bandwidth that represents the		the fraction of the outgoing link bandwidth that represents the
	router's notion of "significantly underutilized". If the		router's notion of "significantly underutilized". If the
	utilization, augmented by the potential bandwidth from recent Quick-		utilization, augmented by the potential bandwidth from recent Quick-
	Start approvals, is above this threshold then no Quick-Start Rate		Start approvals, is above this threshold, then no Quick-Start Rate
	Requests will be approved. If the utilization, again augmented by		Requests will be approved. If the utilization, again augmented by
	the potential bandwidth from recent Quick-Start approvals, is less		the potential bandwidth from recent Quick-Start approvals, is less
	than the threshold then Rate Requests can be approved. The Rate		than the threshold, then Rate Requests can be approved. The Rate
	Requests will be reduced such that the bandwidth allocated would not		Requests will be reduced such that the bandwidth allocated would not
	drive the utilization to more than the given threshold. The		drive the utilization to more than the given threshold. The
	algorithm is:		algorithm is:
	util_bw = bandwidth * utilization;		util_bw = bandwidth * utilization;
	util_bw = util_bw + recent_qs_approvals;		util_bw = util_bw + recent_qs_approvals;
	if (util_bw < (qs_thresh * bandwidth))		if (util_bw < (qs_thresh * bandwidth))
	{		{
	approved = (qs_thresh * bandwidth) - util_bw;		approved = (qs_thresh * bandwidth) - util_bw;
	if (rate_request < approved)		if (rate_request < approved)
	approved = rate_request;		approved = rate_request;
	approved = round_down (approved);		approved = round_down (approved);
	recent_qs_approvals += approved;		recent_qs_approvals += approved;
	}		}
	Also note that given that Rate Requests are fairly coarse, the		Also note that, given that Rate Requests are fairly coarse, the
	approved rate should be rounded down when it does not fall exactly		approved rate should be rounded down when it does not fall exactly on
	on one of the rates allowed by the encoding scheme.		one of the rates allowed by the encoding scheme.
	Routers that wish to keep close track of the allocated Quick-Start		Routers that wish to keep close track of the allocated Quick-Start
	bandwidth could use Approved Rate reports to learn when rate		bandwidth could use Approved Rate reports to learn when rate requests
	requests had been decremented downstream in the network, and also to		had been decremented downstream in the network, and also to learn
	learn when a sender begins to use the approved Quick-Start request.		when a sender begins to use the approved Quick-Start Request.
	E. Possible Additional Uses for the Quick-Start Option		Appendix E. Possible Additional Uses for the Quick-Start Option
	The Quick-Start Option contains a four-bit Function field in the		The Quick-Start Option contains a four-bit Function field in the
	third byte, enabling additional uses to be defined for the Quick-		third byte, enabling additional uses to be defined for the Quick-
	Start Option. In this section we discuss some of the possible		Start Option. In this section, we discuss some of the possible
	additional uses that have been discussed for Quick-Start. The		additional uses that have been discussed for Quick-Start. The
	Function field makes it easy to add new functions for the Quick-		Function field makes it easy to add new functions for the Quick-
	Start Option.		Start Option.
	Report of Current Sending Rate: A Quick-Start Request with the		Report of Current Sending Rate: A Quick-Start Request with the
	`Report of Current Sending Rate' codepoint set in the Function field		`Report of Current Sending Rate' codepoint set in the Function field
	would be using the Rate Request field to report the current		would be using the Rate Request field to report the current estimated
	estimated sending rate for that connection. This could accompany a		sending rate for that connection. This could accompany a second
	second Quick-Start Request in the same packet containing a standard		Quick-Start Request in the same packet containing a standard rate
	rate request, for a connection that is using Quick-Start to increase		request, for a connection that is using Quick-Start to increase its
	its current sending rate.		current sending rate.
	Request to Increase Sending Rate: A codepoint for `Request to		Request to Increase Sending Rate: A codepoint for `Request to
	Increase Sending Rate' in the Function field would indicate that the		Increase Sending Rate' in the Function field would indicate that the
	connection is not idle or just starting up, but is attempting to use		connection is not idle or just starting up, but is attempting to use
	Quick-Start to increase its current sending rate. This codepoint		Quick-Start to increase its current sending rate. This codepoint
	would not change the semantics of the Rate Request field.		would not change the semantics of the Rate Request field.
	RTT Estimate: If a codepoint for `RTT Estimate' was used, a field		RTT Estimate: If a codepoint for `RTT Estimate' was used, a field for
	for the RTT Estimate would contain one or more bits giving the		the RTT Estimate would contain one or more bits giving the sender's
	sender's rough estimate of the round-trip time, if known. E.g., the		rough estimate of the round-trip time, if known. E.g., the sender
	sender could estimate whether the RTT was greater or less than 200		could estimate whether the RTT was greater or less than 200 ms.
	ms. Alternately, if the sender had an estimate of the RTT when it		Alternately, if the sender had an estimate of the RTT when it sends
	sends the Rate Request, the two-bit Reserved field at the end of the		the Rate Request, the two-bit Reserved field at the end of the
	Quick-Start Option could be used for a coarse-grained encoding of		Quick-Start Option could be used for a coarse-grained encoding of the
	the RTT.		RTT.
	Informational Request: An Informational Request codepoint in the		Informational Request: An Informational Request codepoint in the
	Function field would indicate that a request is purely		Function field would indicate that a request is purely informational,
	informational, for the sender to find out if a rate request would be		for the sender to find out if a rate request would be approved, and
	approved, and what size rate request would be approved, when the		what size rate request would be approved when the Informational
	Informational Request is sent. For example, an Informational		Request is sent. For example, an Informational Request could be
	Request could be followed one round-trip time later by a standard		followed one round-trip time later by a standard Quick-Start Request.
	Quick-Start Request. A router approving an Informational Request		A router approving an Informational Request would not consider this
	would not consider this as an approval for Quick-Start bandwidth to		as an approval for Quick-Start bandwidth to be used, and would not be
	be used, and would not be under any obligation to approve a similar		under any obligation to approve a similar standard Quick-Start
	standard Quick-Start Request one round-trip time later. An		Request one round-trip time later. An Informational Request with a
	Informational Request with a rate request of zero could be used by		rate request of zero could be used by the sender to find out if all
	the sender to find out if all of the routers along the path		of the routers along the path supported Quick-Start.
	supported Quick-Start.
	Use Format X for the Rate Request Field: A Quick-Start codepoint for		Use Format X for the Rate Request Field: A Quick-Start codepoint for
	`Use Format X for the Rate Request Field' would indicate that an		`Use Format X for the Rate Request Field' would indicate that an
	alternate format was being used for the Rate Request field.		alternate format was being used for the Rate Request field.
	Do Not Decrement: A Do Not Decrement codepoint could be used for a		Do Not Decrement: A Do Not Decrement codepoint could be used for a
	Quick-Start request where the sender would rather have the request		Quick-Start Request where the sender would rather have the request
	denied than to have the rate request decremented in the network.		denied than to have the rate request decremented in the network.
	This could be used if the sender was only interested in using Quick-		This could be used if the sender was only interested in using Quick-
	Start if the original rate request was approved.		Start if the original rate request was approved.
	Temporary Bandwidth Use: A Temporary codepoint has been proposed to		Temporary Bandwidth Use: A Temporary codepoint has been proposed to
	indicate that a connection would only use the requested bandwidth		indicate that a connection would only use the requested bandwidth for
	for a single time interval.		a single time interval.
	Normative References		Normative References
	[RFC793] J. Postel, Transmission Control Protocol, RFC 793,		[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
	September 1981.		793, September 1981.
	[RFC1191] Mogul, J. and S. Deering, Path MTU Discovery, RFC 1191,		[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
	November 1990.		November 1990.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2460] S. Deering and R. Hinden. Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification. RFC 2460, December 1998.		(IPv6) Specification", RFC 2460, December 1998.
	[RFC2581] M. Allman, V. Paxson, and W. Stevens. TCP Congestion		[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
	Control. RFC 2581. April 1999.		Control", RFC 2581, April 1999.
	[RFC3168] Ramakrishnan, K.K., Floyd, S., and Black, D. The Addition		[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
	of Explicit Congestion Notification (ECN) to IP. RFC 3168, Proposed		Explicit Congestion Notification (ECN) to IP", RFC 3168,
	Standard, September 2001.		September 2001.
	[RFC3390] M. Allman, S. Floyd, and C. Partridge. Increasing TCP's		[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's
	Initial Window. RFC 3390, October 2002.		Initial Window", RFC 3390, October 2002.
	[RFC3742] Floyd, S., Limited Slow-Start for TCP with Large		[RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large
	Congestion Windows, RFC 3742, Experimental, March 2004.		Congestion Windows", RFC 3742, March 2004.
	Informative References		Informative References
	[RFC792] J. Postel. Internet Control Message Protocol. RFC 792,		[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC
	September 1981.		792, September 1981.
	[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,		[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
	April 1992.		April 1992.
	[RFC1812] F. Baker (ed.). Requirements for IP Version 4 Routers. RFC		[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
	1812, June 1995.		RFC 1812, June 1995.
	[RFC2003] Perkins, C., IP Encapsulation within IP, RFC 2003,		[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
	October 1996.		October 1996.
	[RFC2113] D. Katz. P Router Alert Option. RFC 2113, February 1997.		[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February
			1997.
	[RFC2140] J. Touch. TCP Control Block Interdependence. RFC 2140.		[RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140,
	April 1997.		April 1997.
	[RFC2205] R. Braden, et al. Resource ReSerVation Protocol (RSVP) --		[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
	Version 1 Functional Specification. RFC 2205, September 1997.		Jamin, "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.
	[RFC2415] K. Poduri and K. Nichols. Simulation Studies of Increased		[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
	Initial TCP Window Size. RFC 2415. September 1998.		(IKE)", RFC 2409, November 1998.
	[RFC2463] A. Conta and S. Deering. Internet Control Message Protocol		[RFC2415] Poduri, K. and K. Nichols, "Simulation Studies of Increased
	(ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification.		Initial TCP Window Size", RFC 2415, September 1998.
	RFC 2463, December 1998.
	[RFC2488] M. Allman, D. Glover, and L. Sanchez. Enhancing TCP Over		[RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP Over
	Satellite Channels using Standard Mechanisms. RFC 2488. January		Satellite Channels using Standard Mechanisms", BCP 28, RFC
	1999.		2488, January 1999.
	[RFC2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, and		[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.,
	B. Palter, Layer Two Tunneling Protocol "L2TP", RFC 2661, August		and B. Palter, "Layer Two Tunneling Protocol 'L2TP'", RFC
	1999.		2661, August 1999.
	[RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer, and P. Traina,		[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina,
	Generic Routing Encapsulation (GRE), RFC 2784, March 2000.		"Generic Routing Encapsulation (GRE)", RFC 2784, March
			2000.
	[RFC2960] R. Stewart, et al. Stream Control Transmission Protocol.		[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
			Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang,
			L., and V. Paxson, "Stream Control Transmission Protocol",
	RFC 2960, October 2000.		RFC 2960, October 2000.
	[RFC3031] E. Rosen, A. Viswanathan, and R. Callon. Multiprotocol		[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
	Label Switching Architecture. RFC 3031. January 2001.		Label Switching Architecture", RFC 3031, January 2001.
	[RFC3124] H. Balakrishnan and S. Seshan. The Congestion Manager. RFC		[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager",
	3124. June 2001.		RFC 3124, June 2001.
	[RFC3234] B. Carpenter and S. Brim, Middleboxes: Taxonomy and		[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
	Issues, RFC 3234, February 2002.		Issues", RFC 3234, February 2002.
	[RFC3344] C. Perkins (ed.). IP Mobility Support for IPv4. RFC 3344,		[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344,
	August 2002.		August 2002.
	[RFC3360] S. Floyd. Inappropriate TCP Resets Considered Harmful.		[RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful",
	RFC 3360, August 2002.		BCP 60, RFC 3360, August 2002.
	[RFC3649] Floyd, S., HighSpeed TCP for Large Congestion Windows, RFC		[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows",
	3649, December 2003.		RFC 3649, December 2003.
	[RFC3662] R. Bless, K. Nichols, and K. Wehrle. A Lower Effort Per-		[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
	Domain Behavior (PDB) for Differentiated Services. RFC 3662,		Per-Domain Behavior (PDB) for Differentiated Services", RFC
	December 2003.		3662, December 2003.
	[RFC3697] J. Rajahalme, A. Conta, B. Carpenter, and S. Deering. IPv6		[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
	Flow Label Specification. RFC 3697, March 2004.		"IPv6 Flow Label Specification", RFC 3697, March 2004.
	[RFC3775] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in		[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
	IPv6. RFC 3775, June 2004.		in IPv6", RFC 3775, June 2004.
	[RFC3819] P. Karn et al., "Advice for Internet Subnetwork		[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig,
	Designers", July 2004.		R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood,
			"Advice for Internet Subnetwork Designers", BCP 89, RFC
			3819, July 2004.
	[RFC3948] A. Huttunen, B. Swander, V. Volpe, L. DiBurro, and M.		[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
	Stenberg, UDP Encapsulation of IPsec ESP Packets, RFC 3948, January		Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC
	2005.		3948, January 2005.
	[RFC4301] S. Kent and K. Seo, Security Architecture for the Internet		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Protocol, RFC 4301, December 2005.		Internet Protocol", RFC 4301, December 2005.
	[RFC4302] S. Kent, IP Authentication Header, RFC 4302, December		[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
	2005.		2005.
	[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC		[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
	4306, December 2005.		4306, December 2005.
	[RFC4340] E. Kohler, M. Handley, and S. Floyd, Datagram Congestion		[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion
	Control Protocol (DCCP), RFC 4340, March 2006.		Control Protocol (DCCP)", RFC 4340, March 2006.
	[RFC4341] S. Floyd and E. Kohler, Profile for Datagram Congestion		[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion
	Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion		Control Protocol (DCCP) Congestion Control ID 2: TCP-like
	Control, RFC 4341, March 2006.		Congestion Control", RFC 4341, March 2006.
	[AHO98] M. Allman, C. Hayes and S. Ostermann. An evaluation of TCP		[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
	with Larger Initial Windows. ACM Computer Communication Review, July		Message Protocol (ICMPv6) for the Internet Protocol Version
	1998.		6 (IPv6) Specification", RFC 4443, March 2006.
	[B05] B. Briscoe, Review: Quick-Start for TCP and IP, internet-draft		[AHO98] M. Allman, C. Hayes and S. Ostermann. An evaluation of TCP
	draft-briscoe-tsvwg-quickstart-rvw-00, work-in-progress, URL		with Larger Initial Windows. ACM Computer Communication
	"http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html", November 2005.		Review, July 1998.
	[BJCG+05] Briscoe, B., Jacquet, A., Di Cairano-Gilfedder, C.,		[B05] Briscoe, B., "Review: Quick-Start for TCP and IP",
	Salvatori, A., Soppera, A., and M. Koyabe, "Policing Congestion		<http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html>,
	Response in an Internetwork Using Re-Feedback", SIGCOMM, August		November 2005.
	2005.
	[BW97] G. Brasche and B. Walke. Concepts, Services and Protocols of		[BW97] G. Brasche and B. Walke. Concepts, Services and Protocols
	the new GSM Phase 2+ General Packet Radio Service. IEEE		of the new GSM Phase 2+ General Packet Radio Service. IEEE
	Communications Magazine, pages 94--104, August 1997.		Communications Magazine, pages 94--104, August 1997.
	[GPAR02] A. Gurtov, M. Passoja, O. Aalto, and M. Raitola. Multi-		[GPAR02] A. Gurtov, M. Passoja, O. Aalto, and M. Raitola. Multi-
	Layer Protocol Tracing in a GPRS Network. In Proceedings of the IEEE		Layer Protocol Tracing in a GPRS Network. In Proceedings of
	Vehicular Technology Conference (Fall VTC2002), Vancouver, Canada,		the IEEE Vehicular Technology Conference (Fall VTC2002),
	September 2002.		Vancouver, Canada, September 2002.
	[H05] P. Hoffman, email, October 2005. Citation for acknowledgement		[H05] P. Hoffman, email, October 2005. Citation for
	purposes only.		acknowledgement purposes only.
	[HKP01] M. Handley, C. Kreibich and V. Paxson, Network Intrusion		[HKP01] M. Handley, C. Kreibich and V. Paxson, Network Intrusion
	Detection: Evasion, Traffic Normalization, and End-to-End Protocol		Detection: Evasion, Traffic Normalization, and End-to-End
	Semantics, Proc. USENIX Security Symposium 2001.		Protocol Semantics, Proc. USENIX Security Symposium 2001.
	[Jac88] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM		[Jac88] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM.
	[JD02] Manish Jain, Constantinos Dovrolis, End-to-End Available		[JD02] Manish Jain, Constantinos Dovrolis, End-to-End Available
	Bandwidth: Measurement Methodology, Dynamics, and Relation with TCP		Bandwidth: Measurement Methodology, Dynamics, and Relation
	Throughput, SIGCOMM 2002.		with TCP Throughput, SIGCOMM 2002.
	[K03] S. Kunniyur, "AntiECN Marking: A Marking Scheme for High		[K03] S. Kunniyur, "AntiECN Marking: A Marking Scheme for High
	Bandwidth Delay Connections", Proceedings, IEEE ICC '03, May 2003.		Bandwidth Delay Connections", Proceedings, IEEE ICC '03,
	URL "http://www.seas.upenn.edu/~kunniyur/".		May 2003. <http://www.seas.upenn.edu/~kunniyur/>.
	[KAPS02] Rajesh Krishnan, Mark Allman, Craig Partridge, James P.G.		[KAPS02] Rajesh Krishnan, Mark Allman, Craig Partridge, James P.G.
	Sterbenz. Explicit Transport Error Notification (ETEN) for Error-		Sterbenz. Explicit Transport Error Notification (ETEN) for
	Prone Wireless and Satellite Networks. Technical Report No. 8333,		Error-Prone Wireless and Satellite Networks. Technical
	BBN Technologies, March 2002. URL		Report No. 8333, BBN Technologies, March 2002.
	"http://www.icir.org/mallman/papers/".		<http://www.icir.org/mallman/papers/>.
	[KHR02] Dina Katabi, Mark Handley, and Charles Rohrs, Internet		[KHR02] Dina Katabi, Mark Handley, and Charles Rohrs, Internet
	Congestion Control for Future High Bandwidth-Delay Product		Congestion Control for Future High Bandwidth-Delay Product
	Environments. ACM Sigcomm 2002, August 2002. URL		Environments. ACM Sigcomm 2002, August 2002.