draft-ietf-tsvwg-quickstart-06.txt		draft-ietf-tsvwg-quickstart-07.txt
	Internet Engineering Task Force S. Floyd		Internet Engineering Task Force S. Floyd
	INTERNET-DRAFT M. Allman		INTERNET-DRAFT M. Allman
	draft-ietf-tsvwg-quickstart-06.txt ICIR		draft-ietf-tsvwg-quickstart-07.txt ICIR
	Expires: February 2007 A. Jain		Expires: April 2007 A. Jain
	F5 Networks		F5 Networks
	P. Sarolahti		P. Sarolahti
	Nokia Research Center		Nokia Research Center
	30 August 2006		9 October 2006
	Quick-Start for TCP and IP		Quick-Start for TCP and IP
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	skipping to change at page 1, line 36		skipping to change at page 1, line 36
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as		at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in progress."		reference material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on February 2007.		This Internet-Draft will expire on April 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
	skipping to change at page 3, line 7		skipping to change at page 3, line 7
	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, and as a result of the difficulties and seeming absence of		concerns, and as a result of the difficulties and seeming absence of
	motivation for routers such as core routers to deploy Quick-Start,		motivation for routers such as core routers to deploy Quick-Start,
	Quick-Start is being proposed as a mechanism that could be of use in		Quick-Start is being proposed as a mechanism that could be of use in
	controlled environments, and not as a mechanism that would be		controlled environments, and not as a mechanism that would be
	intended or appropriate for ubiquitous deployment in the global		intended or appropriate for ubiquitous deployment in the global
	Internet.		Internet.
	TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION:		TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION:
			Changes from draft-ietf-tsvwg-quickstart-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:		Changes from draft-ietf-tsvwg-quickstart-05:
	* Minor editing in response to AD feedback from		* Minor editing in response to AD feedback from
	Lars Eggert.		Lars Eggert.
	This includes changing one "should" to "SHOULD",		This includes changing one "should" to "SHOULD",
	and changing formating of the IANA Considerations		and changing formatting of the IANA Considerations
	section.		section.
	* Clarifying in the Introduction that the QS router		* Clarifying in the Introduction that the QS router
	does not give preferential treatment to QS packets.		does not give preferential treatment to QS packets.
	In response to email from Fil Dickinson.		In response to email from Fil Dickinson.
	* Added a discussion of interactions between		* Added a discussion of interactions between
	Quick-Start and draft-ietf-pmtud-method. In		Quick-Start and draft-ietf-pmtud-method. In
	response to AD Feedback from Lars Eggert.		response to AD Feedback from Lars Eggert.
	skipping to change at page 9, line 22		skipping to change at page 9, line 22
	3.1. The Quick-Start Option for IPv4. . . . . . . . . . . . . 17		3.1. The Quick-Start Option for IPv4. . . . . . . . . . . . . 17
	3.2. The Quick-Start Option for IPv6. . . . . . . . . . . . . 21		3.2. The Quick-Start Option for IPv6. . . . . . . . . . . . . 21
	3.3. Processing the Quick-Start Request at		3.3. Processing the Quick-Start Request at
	Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 22		Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	3.3.1. Processing the Report of Approved		3.3.1. Processing the Report of Approved
	Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 23		Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
	3.4. The QS Nonce . . . . . . . . . . . . . . . . . . . . . . 24		3.4. The QS Nonce . . . . . . . . . . . . . . . . . . . . . . 24
	4. The Quick-Start Mechanisms in TCP . . . . . . . . . . . . . . 26		4. The Quick-Start Mechanisms in TCP . . . . . . . . . . . . . . 26
	4.1. Sending the Quick-Start Request. . . . . . . . . . . . . 27		4.1. Sending the Quick-Start Request. . . . . . . . . . . . . 27
	4.2. The Quick-Start Response Option in the TCP		4.2. The Quick-Start Response Option in the TCP
	header. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29		header. . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	4.3. TCP: Sending the Quick-Start Response. . . . . . . . . . 30		4.3. TCP: Sending the Quick-Start Response. . . . . . . . . . 29
	4.4. TCP: Receiving and Using the Quick-Start		4.4. TCP: Receiving and Using the Quick-Start
	Response Packet . . . . . . . . . . . . . . . . . . . . . . . 30		Response Packet . . . . . . . . . . . . . . . . . . . . . . . 30
	4.5. TCP: Controlling Acknowledgement Traffic on		4.5. TCP: Controlling Acknowledgement Traffic on
	the Reverse Path . . . . . . . . . . . . . . . . . . . . . . 33		the Reverse Path . . . . . . . . . . . . . . . . . . . . . . 32
	4.6. TCP: Responding to a Loss of a Quick-Start		4.6. TCP: Responding to a Loss of a Quick-Start
	Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 34		Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
	4.7. TCP: A Quick-Start Request for a Larger Ini-		4.7. TCP: A Quick-Start Request for a Larger Ini-
	tial Window . . . . . . . . . . . . . . . . . . . . . . . . . 35		tial Window . . . . . . . . . . . . . . . . . . . . . . . . . 34
	4.7.1. Interactions with Path MTU Discovery. . . . . . . . 35		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. . . . . . . . . . . . 36		Discarded by Routers or Middleboxes. . . . . . . . . . . . 35
	4.8. TCP: A Quick-Start Request in the Middle of		4.8. TCP: A Quick-Start Request in the Middle of
	a Connection. . . . . . . . . . . . . . . . . . . . . . . . . 37		a Connection. . . . . . . . . . . . . . . . . . . . . . . . . 36
	4.9. An Example Quick-Start Scenario with TCP . . . . . . . . 38		4.9. An Example Quick-Start Scenario with TCP . . . . . . . . 37
	5. Quick-Start and IPsec AH. . . . . . . . . . . . . . . . . . . 39		5. Quick-Start and IPsec AH. . . . . . . . . . . . . . . . . . . 38
	6. Quick-Start in IP Tunnels and MPLS. . . . . . . . . . . . . . 39		6. Quick-Start in IP Tunnels and MPLS. . . . . . . . . . . . . . 39
	6.1. Simple Tunnels That Are Compatible with		6.1. Simple Tunnels That Are Compatible with
	Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 41		Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 41
	6.1.1. Simple Tunnels that are Aware of Quick-		6.1.1. Simple Tunnels that are Aware of Quick-
	Start. . . . . . . . . . . . . . . . . . . . . . . . . . . 42		Start. . . . . . . . . . . . . . . . . . . . . . . . . . . 41
	6.2. Simple Tunnels That Are Not Compatible with		6.2. Simple Tunnels That Are Not Compatible with
	Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 42		Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 42
	6.3. Tunnels That Support Quick-Start . . . . . . . . . . . . 43		6.3. Tunnels That Support Quick-Start . . . . . . . . . . . . 43
	6.4. Quick-Start and MPLS . . . . . . . . . . . . . . . . . . 44		6.4. Quick-Start and MPLS . . . . . . . . . . . . . . . . . . 44
	7. The Quick-Start Mechanism in other Transport Pro-		7. The Quick-Start Mechanism in other Transport Pro-
	tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45		tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
	8. Using Quick-Start . . . . . . . . . . . . . . . . . . . . . . 46		8. Using Quick-Start . . . . . . . . . . . . . . . . . . . . . . 45
	8.1. Determining the Rate to Request. . . . . . . . . . . . . 46		8.1. Determining the Rate to Request. . . . . . . . . . . . . 45
	8.2. Deciding the Permitted Rate Request at a		8.2. Deciding the Permitted Rate Request at a
	Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . 46		Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
	9. Evaluation of Quick-Start . . . . . . . . . . . . . . . . . . 47		9. Evaluation of Quick-Start . . . . . . . . . . . . . . . . . . 46
	9.1. Benefits of Quick-Start. . . . . . . . . . . . . . . . . 47		9.1. Benefits of Quick-Start. . . . . . . . . . . . . . . . . 46
	9.2. Costs of Quick-Start . . . . . . . . . . . . . . . . . . 48		9.2. Costs of Quick-Start . . . . . . . . . . . . . . . . . . 47
	9.3. Quick-Start with QoS-enabled Traffic . . . . . . . . . . 49		9.3. Quick-Start with QoS-enabled Traffic . . . . . . . . . . 49
	9.4. Protection against Misbehaving Nodes . . . . . . . . . . 50		9.4. Protection against Misbehaving Nodes . . . . . . . . . . 49
	9.4.1. Misbehaving Senders . . . . . . . . . . . . . . . . 50		9.4.1. Misbehaving Senders . . . . . . . . . . . . . . . . 49
	9.4.2. Receivers Lying about Whether the		9.4.2. Receivers Lying about Whether the
	Request was Approved . . . . . . . . . . . . . . . . . . . 51		Request was Approved . . . . . . . . . . . . . . . . . . . 51
	9.4.3. Receivers Lying about the Approved		9.4.3. Receivers Lying about the Approved
	Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 52		Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
	9.4.4. Collusion between Misbehaving Routers . . . . . . . 53		9.4.4. Collusion between Misbehaving Routers . . . . . . . 53
	9.5. Misbehaving Middleboxes and the IP TTL . . . . . . . . . 54		9.5. Misbehaving Middleboxes and the IP TTL . . . . . . . . . 54
	9.6. Attacks on Quick-Start . . . . . . . . . . . . . . . . . 55		9.6. Attacks on Quick-Start . . . . . . . . . . . . . . . . . 54
	9.7. Simulations with Quick-Start . . . . . . . . . . . . . . 55		9.7. Simulations with Quick-Start . . . . . . . . . . . . . . 55
	10. Implementation and Deployment Issues . . . . . . . . . . . . 56		10. Implementation and Deployment Issues . . . . . . . . . . . . 55
	10.1. Implementation Issues for Sending Quick-		10.1. Implementation Issues for Sending Quick-
	Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 56		Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 56
	10.2. Implementation Issues for Processing Quick-		10.2. Implementation Issues for Processing Quick-
	Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 57		Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 56
	10.3. Possible Deployment Scenarios . . . . . . . . . . . . . 57		10.3. Possible Deployment Scenarios . . . . . . . . . . . . . 57
	10.4. A Comparison with the Deployment Problems		10.4. A Comparison with the Deployment Problems
	of ECN. . . . . . . . . . . . . . . . . . . . . . . . . . . . 59		of ECN. . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
	11. Security Considerations. . . . . . . . . . . . . . . . . . . 59		11. Security Considerations. . . . . . . . . . . . . . . . . . . 58
	12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 60		12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 60
	12.1. IP Option . . . . . . . . . . . . . . . . . . . . . . . 60		12.1. IP Option . . . . . . . . . . . . . . . . . . . . . . . 60
	12.2. TCP Option. . . . . . . . . . . . . . . . . . . . . . . 61		12.2. TCP Option. . . . . . . . . . . . . . . . . . . . . . . 60
	13. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . 61		13. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . 61
	14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 61		14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 61
	A. Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 62		A. Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 62
	A.1. Fast Start-ups without Explicit Information		A.1. Fast Start-ups without Explicit Information
	from Routers. . . . . . . . . . . . . . . . . . . . . . . . . 63		from Routers. . . . . . . . . . . . . . . . . . . . . . . . . 62
	A.2. Optimistic Sending without Explicit Informa-		A.2. Optimistic Sending without Explicit Informa-
	tion from Routers . . . . . . . . . . . . . . . . . . . . . . 64		tion from Routers . . . . . . . . . . . . . . . . . . . . . . 64
	A.3. Fast Start-ups with other Information from		A.3. Fast Start-ups with other Information from
	Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 65		Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
	A.4. Fast Start-ups with more Fine-Grained Feed-		A.4. Fast Start-ups with more Fine-Grained Feed-
	back from Routers . . . . . . . . . . . . . . . . . . . . . . 66		back from Routers . . . . . . . . . . . . . . . . . . . . . . 65
	A.5. Fast Start-ups with Lower-Than-Best-Effort		A.5. Fast Start-ups with Lower-Than-Best-Effort
	Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 66		Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
	B. Design Decisions. . . . . . . . . . . . . . . . . . . . . . . 67		B. Design Decisions. . . . . . . . . . . . . . . . . . . . . . . 66
	B.1. Alternate Mechanisms for the Quick-Start		B.1. Alternate Mechanisms for the Quick-Start
	Request: ICMP and RSVP. . . . . . . . . . . . . . . . . . . . 67		Request: ICMP and RSVP. . . . . . . . . . . . . . . . . . . . 67
	B.1.1. ICMP. . . . . . . . . . . . . . . . . . . . . . . . 67		B.1.1. ICMP. . . . . . . . . . . . . . . . . . . . . . . . 67
	B.1.2. RSVP. . . . . . . . . . . . . . . . . . . . . . . . 69		B.1.2. RSVP. . . . . . . . . . . . . . . . . . . . . . . . 68
	B.2. Alternate Encoding Functions . . . . . . . . . . . . . . 70		B.2. Alternate Encoding Functions . . . . . . . . . . . . . . 69
	B.3. The Quick-Start Request: Packets or Bytes? . . . . . . . 71		B.3. The Quick-Start Request: Packets or Bytes? . . . . . . . 71
	B.4. Quick-Start Semantics: Total Rate or Addi-		B.4. Quick-Start Semantics: Total Rate or Addi-
	tional Rate?. . . . . . . . . . . . . . . . . . . . . . . . . 73		tional Rate?. . . . . . . . . . . . . . . . . . . . . . . . . 72
	B.5. Alternate Responses to the Loss of a Quick-		B.5. Alternate Responses to the Loss of a Quick-
	Start Packet. . . . . . . . . . . . . . . . . . . . . . . . . 74		Start Packet. . . . . . . . . . . . . . . . . . . . . . . . . 73
	B.6. Why Not Include More Functionality?. . . . . . . . . . . 74		B.6. Why Not Include More Functionality?. . . . . . . . . . . 74
	B.7. Alternate Implementations for a Quick-Start		B.7. Alternate Implementations for a Quick-Start
	Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77		Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
	B.7.1. An Alternate Proposal for the Quick-		B.7.1. An Alternate Proposal for the Quick-
	Start Nonce. . . . . . . . . . . . . . . . . . . . . . . . 78		Start Nonce. . . . . . . . . . . . . . . . . . . . . . . . 77
	B.7.2. The Earlier Request-Approved Quick-		B.7.2. The Earlier Request-Approved Quick-
	Start Nonce. . . . . . . . . . . . . . . . . . . . . . . . 78		Start Nonce. . . . . . . . . . . . . . . . . . . . . . . . 78
	C. Quick-Start with DCCP . . . . . . . . . . . . . . . . . . . . 79		C. Quick-Start with DCCP . . . . . . . . . . . . . . . . . . . . 79
	D. Possible Router Algorithm . . . . . . . . . . . . . . . . . . 81		D. Possible Router Algorithm . . . . . . . . . . . . . . . . . . 80
	E. Possible Additional Uses for the Quick-Start		E. Possible Additional Uses for the Quick-Start
	Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82		Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
	Normative References . . . . . . . . . . . . . . . . . . . . . . 84		Normative References . . . . . . . . . . . . . . . . . . . . . . 83
	Informative References . . . . . . . . . . . . . . . . . . . . . 84		Informative References . . . . . . . . . . . . . . . . . . . . . 84
	AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 89		AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 89
	Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 91		Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 90
	Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 91		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 MSS-sized
	skipping to change at page 15, line 25		skipping to change at page 15, line 25
	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. In		inform the sender of the status of the Quick-Start Request. For
			example, when TCP is used, the TCP receiver sends feedback to the
			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 a sending rate in bits per second, and a Quick-Start TTL (QS		for a sending rate in bits per second, and a Quick-Start TTL (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 is initialized by the sender to a random value. The transport		TTL 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. In		Start Nonce to the sender using transport-level mechanisms; for TCP,
	particular, the receiver computes the difference between the Quick-		the receiver sends this information in the Quick-Start Response in
	Start TTL and the IP TTL (the TTL in the IP header) of the Quick-		the TCP header. In particular, the receiver computes the difference
	Start request packet, and returns this in the Quick-Start response.		between the Quick-Start TTL and the IP TTL (the TTL in the IP
	The sender uses this information to determine if all of the routers		header) of the Quick-Start request packet, and returns this in the
	along the path decremented the Quick-Start TTL, approving the Quick-		Quick-Start response. The sender uses the TTL difference to
	Start Request.		determine if all of the routers along the path decremented the
			Quick-Start TTL, approving the Quick-Start Request.
	If the request is approved by all of the routers along the path,		If the request is approved by all of the routers along the path,
	then the TCP sender combines this allowed rate with the measurement		then the TCP sender combines this allowed rate with the measurement
	of the round-trip time, and ends up with an allowed TCP congestion		of the round-trip time, and ends up with an allowed TCP congestion
	window. This window is sent rate-paced over the next round-trip		window. This window is sent rate-paced over the next round-trip
	time, or until an ACK packet is received.		time, or until an ACK packet is received.
	Figure 1 shows a successful use of Quick-Start, with 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. In this example, Quick-Start is used by TCP to establish		Request, and the TCP receiver using the Quick-Start Response to
	the initial congestion window.		return information to the TCP sender. In this example, Quick-Start
			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>
	| <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 16, line 32		skipping to change at page 16, line 36
	| Decrement		| Decrement
	| QS TTL		| QS TTL
	| to approve		| to approve
	| request -->		| request -->
	|		|
	| <IP TTL: 60>		| <IP TTL: 60>
	| <QS TTL: 88>		| <QS TTL: 88>
	| <TTL Diff: 28>		| <TTL Diff: 28>
	| Return Quick-Start		| Return Quick-Start
	| info to sender in		| info to sender in
	| <-- TCP ACK packet.		| Quick-Start Response
			| <-- 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
	skipping to change at page 17, line 29		skipping to change at page 17, line 31
	|		|
	| Forward packet		| Forward packet
	| without modifying		| without modifying
	| Quick-Start Option. -->		| Quick-Start Option. -->
	|		|
	| <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
	| <-- TCP ACK packet.		| Quick-Start Response
			| <-- 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
	skipping to change at page 20, line 45		skipping to change at page 20, line 45
	the network. If the packet contained the Quick-Start Request is		the network. If the packet contained the Quick-Start Request is
	acknowledged, but the acknowledgement packet does not contain a		acknowledged, but the acknowledgement packet does not contain a
	Quick-Start Response, then the sender MUST assume that the Quick-		Quick-Start Response, then the sender MUST assume that the Quick-
	Start Request was denied, and set a Report of Approved Rate with a		Start Request was denied, and set a Report of Approved Rate with a
	rate of zero. 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 sent 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 total rate for the connection, including the current rate		requested total rate for the connection, including the current rate
	of the connection; the Rate Request is *not* a request for an		of the connection; the Rate Request is *not* a request for an
	additional sending rate over and above the current sending rate. If		additional sending rate over and above the current sending rate. If
	the Rate Request is denied, or lowered to a value below the		the Rate Request is denied, or lowered to a value below the
	skipping to change at page 21, line 41		skipping to change at page 21, line 41
	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 have a checksum field, and modifying the Quick-Start Request in		not have a checksum field, and modifying the Quick-Start Request in
	the IPv6 Hop-by-Hop options header does not affect the IPv6 pseudo-		the 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.
	Note that [RFC2460] specifies that when a specific flow label has		Appendix A of RFC 2460 requires that all packets with the same flow
	been assigned to packets, the contents of the Hop-by-Hop options,		label must be originated with the same hop-by-hop header contents,
	excluding the next header field, must originate with the same		which would be incompatible with Quick-Start. However, a later IPv6
	contents throughout the IP flow lifetime. However, the Quick-Start		flow label specification [RFC3697] updates the use of flow labels in
	option would be included in only a small fraction of the packets		IPv6 and removes this restriction. Therefore Quick-Start is
	during a flow lifetime. Thus, Quick-Start SHOULD NOT be used in an		compatible with the current IPv6 specifications.
	IPv6 connection that uses flow labels unless the experimental
	specification of flow labels in Appendix A of RFC 2460 is changed.
	We note that RFC 2460 states that the use of the flow label field in
	IPv6 "is, at the time of writing, still experimental and subject to
	change as the requirements for flow support in the Internet become
	clearer" [RFC2460].
	3.3. Processing the Quick-Start Request at Routers		3.3. Processing the Quick-Start Request at Routers
	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
	skipping to change at page 22, line 30		skipping to change at page 22, line 28
	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
	delete the Quick-Start Request from the IP header. This saves		either delete the Quick-Start Request from the IP header or zero the
	resources because downstream routers will have no option to process.		QS TTL, QS Nonce, and Rate Request fields. Deleting the Quick-Start
	If a Quick-Start-capable router wishes to deny the request but		Request saves resources because downstream routers will have no
	doesn't delete the Quick-Start Request from the IP header, then the		option to process, but zeroing the Rate Request field may be more
	router SHOULD zero the QS TTL, QS Nonce, and Rate Request fields.		efficient for routers to implement. As suggested in [B05], future
	Zeroing the Rate Request field may be more efficient for routers to		additions to Quick-Start could define error codes for routers to
	implement than deleting the Quick-Start option. As suggested in		insert into the QS Nonce field to report back to the sender the
	[B05], future additions to Quick-Start could define error codes for		reason that the Quick-Start request was denied, e.g., that the
	routers to insert into the QS Nonce field to report back to the		router is denying all Quick-Start requests at this time, or that
	sender the reason that the Quick-Start request was denied, e.g.,		this router as a matter of policy does not grant Quick-Start
	that the router is denying all Quick-Start requests at this time, or
	that this router as a matter of policy does not grant Quick-Start
	requests. A router that doesn't understand the Quick-Start option		requests. A router that doesn't understand the Quick-Start option
	will simply forward the packet with the Quick-Start Request		will simply forward the packet with the Quick-Start Request
	unchanged (ensuring that the TTL Diff will not match and Quick-Start		unchanged (ensuring 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).
	skipping to change at page 26, line 10		skipping to change at page 25, line 33
	Rate K". Thus, the receiver has a 1/16 chance in successfully lying		Rate K". Thus, the receiver has a 1/16 chance in successfully lying
	and saying that the received rate request was K+2 instead of K.		and saying that the received rate request was K+2 instead of K.
	We note that the protection offered by the QS Nonce is the same		We note that the protection offered by the QS Nonce is the same
	whether one router makes all of the decrements in the rate request,		whether one router makes all of the decrements in the rate request,
	or whether they are made at different routers along the path.		or whether they are made at different routers along the path.
	The requirements for randomization for the sender and routers in		The requirements for randomization for the sender and routers in
	setting `random' values in the QS Nonce are not stringent - almost		setting `random' values in the QS Nonce are not stringent - almost
	any form of pseudo-random numbers would do. The requirement is that		any form of pseudo-random numbers would do. The requirement is that
	the original value for the QS Nonce is not easily guessable by the		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 changed by a router along the path, the receiver should not be		are changed by a router along the path, the receiver should not be
	able to guess those two bits from the other 28 bits in the QS Nonce.		able 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
	skipping to change at page 33, line 40		skipping to change at page 33, line 17
	acknowledgement traffic in DCCP's CCID2 [RFC4341].		acknowledgement 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 TCP receiver could limit its sending rate for ACK packets sent		the TCP receiver could limit its sending rate for ACK packets sent
	in response to Quick-Start data packets. The following information		in response to Quick-Start data packets. The following information
	is needed by the TCP receiver:		is 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 a measurement of the round-trip time, it can use the time		have a measurement of the round-trip time, it can use the time
	between the receipt of the Quick-Start Request and the Quick-Start		between the receipt of the Quick-Start Request and the Report
	Response packets.		of Approved 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 and therefore the receiver should have an understanding
	of the packet size the sender will be using. If the receiver does		of the packet size the sender will be using. If the receiver does
	not have such an understanding or wishes to confirm the negotiated		not have such an understanding or wishes to confirm the negotiated
	MSS, the size of the first data packet can be used.		MSS, the size of the first data packet can be used.
	skipping to change at page 39, line 10		skipping to change at page 38, line 28
	congestion window appropriately, and sets up rate-based pacing to be		congestion window appropriately, and sets up rate-based pacing to be
	used with its initial window. If the Quick-Start Response is not		used with its initial window. If the Quick-Start Response is not
	valid, then Host B uses TCP's default initial window. In either		valid, then Host B uses TCP's default initial window. In either
	case, Host B sends a Report of Approved Rate.		case, Host B sends a Report of Approved Rate.
	5. Quick-Start and IPsec AH		5. Quick-Start and IPsec AH
	This section shows that Quick-Start is compatible with IPsec AH		This section shows that Quick-Start is compatible with IPsec AH
	(Authentication Header). AH uses an Integrity Check Value (ICV) in		(Authentication Header). AH uses an Integrity Check Value (ICV) in
	the IPsec Authentication Header to verify both message		the IPsec Authentication Header to verify both message
	authentication and integrity ([RFC2402], [RFC4302]). Changes to the		authentication and integrity ([RFC4302], page 85). Changes to the
	Quick-Start option in the IP header do not affect this AH ICV. The		Quick-Start option in the IP header do not affect this AH ICV. The
	tunnel considerations in Section 6 below apply to all IPsec tunnels,		tunnel 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
	2402 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 does not cause problems with existing IPsec AH implementations		route does not cause problems with existing IPsec AH implementations
	for IPv4. If the Quick-Start option is recognized, it MUST be		for IPv4. If the Quick-Start option is recognized, it MUST be
	treated as a mutable IPv4 option, and hence be completely zeroed for		treated as a mutable IPv4 option, and hence be completely zeroed for
	AH ICV calculation purposes. IPv6 option numbers explicitly		AH ICV calculation purposes. IPv6 option numbers explicitly
	indicate whether the option is mutable; the 3rd highest order bit in		indicate whether the option is mutable; the 3rd highest order bit in
	the IANA-allocated option type has the value 1 to indicate that the		the IANA-allocated option type has the value 1 to indicate that the
	Quick-Start option data can change en route. RFC 2402 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 ([RFC2401], [RFC4301]), IP in IP [RFC2003],		tunnels, including IPsec ([RFC4301]), IP in IP [RFC2003], GRE
	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 between the IP TTL and the Quick-Start TTL, mod 256.		difference between the IP TTL and the Quick-Start TTL, mod 256.
	Recall that the sender considers the Quick-Start request approved		Recall that the sender considers the Quick-Start request approved
	only if the value of TTL Diff for the packet entering the network is		only if the value of TTL Diff for the packet entering the network is
	the same as the value of TTL Diff for the packet exiting the		the same as 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
	skipping to change at page 43, line 9		skipping to change at page 42, line 29
	Quick-Start, a valid Quick-Start Request with unchanged TTL Diff		Quick-Start, a valid Quick-Start Request with unchanged TTL Diff
	traverses in the inner header, while the outer header most likely		traverses in the inner header, while the outer header most likely
	does not carry a Quick-Start Request. If the tunnel egress also		does not carry a Quick-Start Request. If the tunnel egress also
	does not support Quick-Start, it remains possible that the Quick-		does not support Quick-Start, it remains possible that the Quick-
	Start Request would be falsely approved, because the packet is		Start Request would be falsely approved, because the packet is
	decapsulated using the Quick-Start request from the inner header,		decapsulated using the Quick-Start request from the inner header,
	and the value of TTL Diff echoed to the sender remains unchanged.		and the value of TTL Diff echoed to the sender remains unchanged.
	For example, such a scenario can occur with a Bump-In-The-Stack		For example, such a scenario can occur with a Bump-In-The-Stack
	(BITS), an IPSec encryption implementation where the data encryption		(BITS), an IPSec encryption implementation where the data encryption
	occurs between the network drivers and the TCP/IP protocol stack		occurs between the network drivers and the TCP/IP protocol stack
	[RFC2401].		[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 the client and the VPN gateway is likely to contain the most		between 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 use BITS [H05], we will explore this in more detail.		to 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 the encryption occurs on an outboard processor, offloading the		where the encryption occurs on an outboard processor, offloading the
	encryption processing overhead from the host or router [RFC2401].		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 the Quick-Start request will be denied. However, if the BITW		and the Quick-Start request will be denied. However, if the BITW
	supports a host and does not have its own IP address, then the IP		supports a host and does not have its own IP address, then the IP
	TTL is not decremented before the packet is passed from the host to		TTL is not decremented before the packet is passed from the host to
	the BITW, and a false positive could occur.		the BITW, and a false positive could occur.
	Other tunnels that need to be looked at are IP tunnels over non-		Other tunnels that need to be looked at are IP tunnels over non-
	network protocols, such as IP over TCP and IP over UDP [RFC3948],		network protocols, such as IP over TCP and IP over UDP [RFC3948],
	skipping to change at page 55, line 42		skipping to change at page 55, line 16
	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-larqe 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 4KB and 128KB) in under-utilized
	environments. These studies are of file transfers, with the		environments. These studies are of file transfers, with the
	skipping to change at page 60, line 9		skipping to change at page 59, line 30
	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 a mutable IPv4 option, and hence completely zeroed for AH ICV		is 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
	2402 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 2402, 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 2402 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 is erroneously considered approved by the sender without the		Request is erroneously considered approved by the sender without the
	routers in the tunnel having individually approved the request,		routers in the tunnel having individually approved the request,
	causing a false positive.		causing a false positive.
	We note two high-order points here. First, the Quick-Start Nonce		We note two high-order points here. First, the Quick-Start Nonce
	skipping to change at page 65, line 22		skipping to change at page 64, line 40
	(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 flows
	used large initial windows, many packets were dropped from		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 senders
	in amplifying the damage done by a Distributed Denial of Service		in amplifying the damage done by a Distributed Denial of Service
	(DDoS) attack (assuming attackers use conformant congestion control		(DDoS) attack (assuming attackers use compliant congestion control
	in the hopes of "flying under the radar").		in the hopes of "flying under the radar").
	(4) Performance hits if a packet is dropped:		(4) Performance hits if a packet is dropped:
	A fourth issue would be to quantify the performance hit to the		A fourth issue would be to quantify the performance hit to the
	connection when a packet is dropped from one of the initial windows.		connection when a packet is dropped from one of the initial windows.
	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
	skipping to change at page 68, line 27		skipping to change at page 68, line 4
	One benefit of using ICMP would be that the delivery of the TCP SYN		One benefit of using ICMP would be that the delivery of the TCP SYN
	packet or other initial packet would not be delayed by IP option		packet or other initial packet would not be delayed by IP option
	processing at routers. A greater advantage is that if middleboxes		processing at routers. A greater advantage is that if middleboxes
	were blocking packets with Quick-Start Requests, using the Quick-		were blocking packets with Quick-Start Requests, using the Quick-
	Start Request in a separate ICMP packet would mean that the		Start Request in a separate ICMP packet would mean that the
	middlebox behavior would not affect the connection as a whole. (To		middlebox behavior would not affect the connection as a whole. (To
	get this robustness to middleboxes with TCP using an IP Quick-Start		get this robustness to middleboxes with TCP using an IP Quick-Start
	Option, one would have to have a TCP-level Quick-Start Request		Option, one would have to have a TCP-level Quick-Start Request
	packet that could be sent concurrently but separately from the TCP		packet that could be sent concurrently but separately from the TCP
	SYN packet.)		SYN packet.)
	However, there are a number of disadvantages to using ICMP. Some		However, there are a number of disadvantages to using ICMP. Some
	firewalls and middleboxes may not forward the ICMP Quick-Start		firewalls and middleboxes may not forward the ICMP Quick-Start
	Request packets. (If an ICMP Reply packet from a router to the		Request packets. (If an ICMP Reply packet from a router to the
	sender is dropped in the network, the sender would still know that		sender is dropped in the network, the sender would still know that
	the request was not approved, as stated earlier, so this would not		the request was not approved, as stated earlier, so this would not
	be as serious of a problem.) In addition, it would be difficult, if		be as serious of a problem.) In addition, it would be difficult, if
	not impossible, for a router in the middle of an IP tunnel to		not impossible, for a router in the middle of an IP tunnel to
	deliver an ICMP Reply packet to the actual source, for example when		deliver an ICMP Reply packet to the actual source, for example when
	the inner IP header is encrypted as in IPsec tunnel mode [RFC2401].		the inner IP header is encrypted as in IPsec ESP tunnel mode
	Again, however, the ICMP Reply packet would not be essential to the		[RFC4301]. Again, however, the ICMP Reply packet would not be
	correct operation of ICMP Quick-Start.		essential to the correct operation of ICMP Quick-Start.
	Unauthenticated out-of-band ICMP messages could enable some types of		Unauthenticated out-of-band ICMP messages could enable some types of
	attacks by third-party malicious hosts that are not possible when		attacks by third-party malicious hosts that are not possible when
	the control information is carried in-band with the IP packets that		the control information is carried in-band with the IP packets that
	can only be altered by the routers on the connection path. Finally,		can only be altered by the routers on the connection path. Finally,
	as a minor concern, using ICMP would cause a small amount of		as a minor concern, using ICMP would cause a small amount of
	additional traffic in the network, which is not the case when using		additional traffic in the network, which is not the case when using
	IP options.		IP options.
	B.1.2. RSVP		B.1.2. RSVP
	skipping to change at page 70, line 47		skipping to change at page 70, line 19
	request is 1.3 Gbps. It seems to us that an upper limit of 1.3 Gbps		request is 1.3 Gbps. It seems to us that an upper limit of 1.3 Gbps
	would be fine for the Quick-Start rate request, and that connections		would be fine for the Quick-Start rate request, and that connections
	wishing to start up with a higher initial sending rate should be		wishing to start up with a higher initial sending rate should be
	encouraged to use other mechanisms, such as the explicit reservation		encouraged to use other mechanisms, such as the explicit reservation
	of bandwidth. If an upper limit of 1.3 Gbps was not acceptable,		of bandwidth. If an upper limit of 1.3 Gbps was not acceptable,
	then five or six bits could be used for the Rate Request field.		then five or six bits could be used for the Rate Request field.
	The lower limit of 80 Kbps could be useful for flows with round-trip		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 RFC 3390 (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 ms. A rate request of 80 Kbps would translate to a rate of a		10 ms. A rate request of 80 Kbps would translate to a rate of a
	hundred 100-byte packets per second (including packet headers).		hundred 100-byte packets per second (including packet headers).
	While some small-packet flows with large round-trip times might find		While some small-packet flows with large round-trip times might find
	a smaller rate request of 40 Kbps to be useful, our assumption is		a smaller rate request of 40 Kbps to be useful, our assumption is
	skipping to change at page 72, line 30		skipping to change at page 71, line 49
	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 might know nothing at all about the separate headers added in IP		and 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. The MSS option is defined as the maximum MSS		second, or vice versa. This would be problematic for several
	that the TCP sender expects to receive, not the maximum MSS that the		reasons. First, if IPsec is used, the TCP header will be encrypted.
	TCP sender plans to send [RFC793]. However, it is probably often
	the case that this MSS also applies as an upper bound on the MSS		Second, the MSS option is defined as the maximum MSS that the TCP
	used by the TCP sender in sending.		sender expects to receive, not the maximum MSS that the TCP sender
			plans to send [RFC793]. However, it is probably often the case that
			this MSS also applies as an upper bound on the MSS used by the TCP
			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].
	skipping to change at page 81, line 44		skipping to change at page 81, line 36
	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 an estimation technique such as given above) and an estimate		(from an estimation technique such as given above) and an estimate
	of the potential bandwidth from recent Quick-Start approvals.		of the potential bandwidth from recent Quick-Start approvals.
	Tracking the potential bandwidth from recent Quick-Start approvals		Tracking the potential bandwidth from recent Quick-Start approvals
	is another case where local policy dictates how it should be done.		is another case where local policy dictates how it should be done.
	The simpliest method, outlined in Section 8.2, is for the router to		The simplest method, outlined in Section 8.2, is for the router to
	keep track of the aggregate Quick-Start rate requests approved in		keep track of the aggregate Quick-Start rate requests approved in
	the most recent two or more time intervals, including the current		the most recent two or more time intervals, including the current
	time interval, and to use the sum of the aggregate rate requests		time interval, and to use the sum of the aggregate rate requests
	over these time intervals as the estimate of the approved Rate		over these time intervals as the estimate of the approved Rate
	Requests. The experiments in [SAF06] keep track of the aggregate		Requests. The experiments in [SAF06] keep track of the aggregate
	approved Rate Requests over the most recent two time intervals, for		approved Rate Requests over the most recent two time intervals, for
	intervals of 150~msec.		intervals of 150~msec.
	The target algorithm also depends on a threshold (qs_thresh) that is		The target algorithm also depends on a threshold (qs_thresh) that is
	the fraction of the outgoing link bandwidth that represents the		the fraction of the outgoing link bandwidth that represents the
	skipping to change at page 85, line 6		skipping to change at page 84, line 43
	October 1996.		October 1996.
	[RFC2113] D. Katz. P Router Alert Option. RFC 2113, February 1997.		[RFC2113] D. Katz. P Router Alert Option. RFC 2113, February 1997.
	[RFC2140] J. Touch. TCP Control Block Interdependence. RFC 2140.		[RFC2140] J. Touch. TCP Control Block Interdependence. RFC 2140.
	April 1997.		April 1997.
	[RFC2205] R. Braden, et al. Resource ReSerVation Protocol (RSVP) --		[RFC2205] R. Braden, et al. Resource ReSerVation Protocol (RSVP) --
	Version 1 Functional Specification. RFC 2205, September 1997.		Version 1 Functional Specification. RFC 2205, September 1997.
	[RFC2401] S. Kent and R. Atkinson, Security Architecture for the
	Internet Protocol, RFC 2401, November 1998.
	[RFC2402] S. Kent and R. Atkinson. IP Authentication Header. RFC
	2402, November 1998.
	[RFC2409] D. Harkins and D. Carrel, The Internet Key Exchange (IKE),		[RFC2409] D. Harkins and D. Carrel, The Internet Key Exchange (IKE),
	RFC 2409, November 1998.		RFC 2409, November 1998.
	[RFC2415] K. Poduri and K. Nichols. Simulation Studies of Increased		[RFC2415] K. Poduri and K. Nichols. Simulation Studies of Increased
	Initial TCP Window Size. RFC 2415. September 1998.		Initial TCP Window Size. RFC 2415. September 1998.
	[RFC2463] A. Conta and S. Deering. Internet Control Message Protocol		[RFC2463] A. Conta and S. Deering. Internet Control Message Protocol
	(ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification.		(ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification.
	RFC 2463, December 1998.		RFC 2463, December 1998.
	skipping to change at page 86, line 10		skipping to change at page 85, line 41
	[RFC3360] S. Floyd. Inappropriate TCP Resets Considered Harmful.		[RFC3360] S. Floyd. Inappropriate TCP Resets Considered Harmful.
	RFC 3360, August 2002.		RFC 3360, August 2002.
	[RFC3649] Floyd, S., HighSpeed TCP for Large Congestion Windows, RFC		[RFC3649] Floyd, S., HighSpeed TCP for Large Congestion Windows, RFC
	3649, December 2003.		3649, December 2003.
	[RFC3662] R. Bless, K. Nichols, and K. Wehrle. A Lower Effort Per-		[RFC3662] R. Bless, K. Nichols, and K. Wehrle. A Lower Effort Per-
	Domain Behavior (PDB) for Differentiated Services. RFC 3662,		Domain Behavior (PDB) for Differentiated Services. RFC 3662,
	December 2003.		December 2003.
			[RFC3697] J. Rajahalme, A. Conta, B. Carpenter, and S. Deering. IPv6
			Flow Label Specification. RFC 3697, March 2004.
	[RFC3775] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in		[RFC3775] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in
	IPv6. RFC 3775, June 2004.		IPv6. RFC 3775, June 2004.
	[RFC3819] P. Karn et al., "Advice for Internet Subnetwork		[RFC3819] P. Karn et al., "Advice for Internet Subnetwork
	Designers", July 2004.		Designers", July 2004.
	[RFC3948] A. Huttunen, B. Swander, V. Volpe, L. DiBurro, and M.		[RFC3948] A. Huttunen, B. Swander, V. Volpe, L. DiBurro, and M.
	Stenberg, UDP Encapsulation of IPsec ESP Packets, RFC 3948, January		Stenberg, UDP Encapsulation of IPsec ESP Packets, RFC 3948, January
	2005.		2005.
	skipping to change at page 91, line 7		skipping to change at page 90, line 7
	Pasi Sarolahti		Pasi Sarolahti
	Nokia Research Center		Nokia Research Center
	P.O. Box 407		P.O. Box 407
	FI-00045 NOKIA GROUP		FI-00045 NOKIA GROUP
	Finland		Finland
	Phone: +358 50 4876607		Phone: +358 50 4876607
	Email: pasi.sarolahti@iki.fi		Email: pasi.sarolahti@iki.fi
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society 2006. This document is subject		Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	This document and the information contained herein are provided on		This document and the information contained herein are provided on
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
	INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR		INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
	IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
End of changes. 57 change blocks.
	112 lines changed or deleted		125 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/