< draft-kuhn-quic-careful-resume-00.txt		draft-kuhn-quic-careful-resume-01.txt >
	Internet Engineering Task Force N. Kuhn		Internet Engineering Task Force N. Kuhn
	Internet-Draft		Internet-Draft Thales Alenia Space
	Intended status: Informational E. Stephan		Intended status: Informational E. Stephan
	Expires: 6 September 2022 Orange		Expires: 7 November 2022 Orange
	G. Fairhurst		G. Fairhurst
	T. Jones		T. Jones
	University of Aberdeen		University of Aberdeen
	C. Huitema		C. Huitema
	Private Octopus Inc.		Private Octopus Inc.
	5 March 2022		6 May 2022
	Carefully Resume QUIC Session		Carefully Resume QUIC Session
	draft-kuhn-quic-careful-resume-00		draft-kuhn-quic-careful-resume-01
	Abstract		Abstract
	This document provides a method to allow a QUIC session to carefully		This document provides a method to allow a QUIC session to carefully
	resume using a previously utilised Internet path.		resume using a previously utilised Internet path.
	The method uses a set of computed congestion control parameters that		The method uses a set of computed congestion control parameters that
	are based on the previously observed path characteristics, such as		are based on the previously observed path characteristics, such as
	the bottleneck bandwidth, available capacity, or the RTT. These		the bottleneck bandwidth, available capacity, or the RTT. These
	parameters are stored and can then used to modify the congestion		parameters are stored and can then used to modify the congestion
	skipping to change at page 1, line 49 ¶		skipping to change at page 1, line 49 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 6 September 2022.		This Internet-Draft will expire on 7 November 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 30 ¶		skipping to change at page 2, line 30 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Language, notations and terms . . . . . . . . . . . . . . . . 5		2. Language, notations and terms . . . . . . . . . . . . . . . . 5
	2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5		2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
	2.2. Notations and Terms . . . . . . . . . . . . . . . . . . . 5		2.2. Notations and Terms . . . . . . . . . . . . . . . . . . . 5
	3. Scenarios of Interest . . . . . . . . . . . . . . . . . . . . 6		3. Scenarios of Interest . . . . . . . . . . . . . . . . . . . . 6
	3.1. Large BDP Scenarios . . . . . . . . . . . . . . . . . . . 6		3.1. Large BDP Scenarios . . . . . . . . . . . . . . . . . . . 6
	3.2. Accomodating from a Known Reduction in Capacity . . . . . 6		3.2. Accomodating from a Known Reduction in Capacity . . . . . 6
	3.3. Optimizing Client Requests . . . . . . . . . . . . . . . 7		3.3. Optimizing Client Requests . . . . . . . . . . . . . . . 7
	3.4. Sharing Transport Information across Multiple		3.4. Sharing Transport Information across Multiple
	Connections . . . . . . . . . . . . . . . . . . . . . . . 7		Connections . . . . . . . . . . . . . . . . . . . . . . . 8
	3.5. Connection Establishment, Client and Server . . . . . . . 7		3.5. Connection Establishment, Client and Server . . . . . . . 8
	4. The Phases of CC . . . . . . . . . . . . . . . . . . . . . . 8		4. The Phases of CC . . . . . . . . . . . . . . . . . . . . . . 8
	5. Safe Jump . . . . . . . . . . . . . . . . . . . . . . . . . . 9		5. Safe Jump . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.1. Rationale behind the Safety Guidelines . . . . . . . . . 9		5.1. Rationale behind the Safety Guidelines . . . . . . . . . 9
	5.2. Rationale #1: Variable Network Conditions . . . . . . . . 9		5.2. Rationale #1: Variable Network Conditions . . . . . . . . 10
	5.3. Rationale #2: Malicious clients . . . . . . . . . . . . . 11		5.3. Rationale #2: Malicious clients . . . . . . . . . . . . . 11
	5.4. Trade-off between the different solutions . . . . . . . . 12		5.4. Trade-off between the different solutions . . . . . . . . 12
	5.4.1. Interoperability and Use Cases . . . . . . . . . . . 12		5.4.1. Interoperability and Use Cases . . . . . . . . . . . 12
	5.4.2. Summary . . . . . . . . . . . . . . . . . . . . . . . 12		5.4.2. Summary . . . . . . . . . . . . . . . . . . . . . . . 13
	6. Safety Guidelines . . . . . . . . . . . . . . . . . . . . . . 14		6. Safety Guidelines . . . . . . . . . . . . . . . . . . . . . . 14
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 16		9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	10.1. Normative References . . . . . . . . . . . . . . . . . . 17		10.1. Normative References . . . . . . . . . . . . . . . . . . 17
	10.2. Informative References . . . . . . . . . . . . . . . . . 17		10.2. Informative References . . . . . . . . . . . . . . . . . 18
	Appendix A. Implementation Considerations . . . . . . . . . . . 18		Appendix A. Implementation Considerations . . . . . . . . . . . 19
	A.1. Rationale behind the different implementation options . . 19		A.1. Rationale behind the different implementation options . . 19
	A.2. Independent Local Storage of Values . . . . . . . . . . . 19		A.2. Independent Local Storage of Values . . . . . . . . . . . 19
	A.3. Using NEW_TOKEN frames . . . . . . . . . . . . . . . . . 20		A.3. Using NEW_TOKEN frames . . . . . . . . . . . . . . . . . 20
	A.4. BDP Frame . . . . . . . . . . . . . . . . . . . . . . . . 20		A.4. BDP Frame . . . . . . . . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	The specification for the QUIC transport protocol [RFC9000] notes		The specification for the QUIC transport protocol [RFC9000] notes
	"Generally, implementations are advised to be cautious when using		"Generally, implementations are advised to be cautious when using
	skipping to change at page 4, line 38 ¶		skipping to change at page 4, line 38 ¶
	different areas of connectivity with a temporary change in path		different areas of connectivity with a temporary change in path
	characteristics before the user returns to the original path		characteristics before the user returns to the original path
	characteristics).		characteristics).
	In all of these cases, specific characteristics of the path may have		In all of these cases, specific characteristics of the path may have
	been learned, including CC information, such as the available		been learned, including CC information, such as the available
	capacity and RTT. This CC information might be expected to be		capacity and RTT. This CC information might be expected to be
	similar when a new connection is made between the same local and		similar when a new connection is made between the same local and
	remote endpoints.		remote endpoints.
			While the server could take optimization decisions without
			considering the client's preference, in some cases a client could
			have information that is not available at the server. A client may
			provide hints, for example: (1) information abnout how the upper
			layers expect to use a connection - such as the expected size of
			transfer; (2) an indication that the path/local interface has
			changed; (3) information related to current hardware limitations of
			the client or (4) an understanding about the capacity needs of other
			concurrent flows that would compete for shared capacity. As a
			result, a client could explicitely ask for tuning the slow start of
			the resumed connection, or to inhibit tuning. This is discussed
			further later in the document.
	There are also cases where using the parameters of a previous		There are also cases where using the parameters of a previous
	connection are not appropriate, and a need to evaluate the potential		connection are not appropriate, and a need to evaluate the potential
	malicious use of the method.		malicious use of the method.
	The remainder of this document:		The remainder of this document:
	1. discusses use-cases where carefully resuming QUIC sessions is		1. discusses use-cases where carefully resuming QUIC sessions is
	expected to have benefit;		expected to have benefit;
	2. proposes guidelines for how to carefully utilise the previously		2. proposes guidelines for how to carefully utilise the previously
	skipping to change at page 18, line 12 ¶		skipping to change at page 18, line 23 ¶
	10.2. Informative References		10.2. Informative References
	[CONEXT15] Li, Q., Dong, M., and P B. Godfrey, "Halfback: Running		[CONEXT15] Li, Q., Dong, M., and P B. Godfrey, "Halfback: Running
	Short Flows Quickly and Safely", ACM CoNEXT , 2015.		Short Flows Quickly and Safely", ACM CoNEXT , 2015.
	[I-D.cardwell-iccrg-bbr-congestion-control]		[I-D.cardwell-iccrg-bbr-congestion-control]
	Cardwell, N., Cheng, Y., Yeganeh, S. H., Swett, I., and V.		Cardwell, N., Cheng, Y., Yeganeh, S. H., Swett, I., and V.
	Jacobson, "BBR Congestion Control", Work in Progress,		Jacobson, "BBR Congestion Control", Work in Progress,
	Internet-Draft, draft-cardwell-iccrg-bbr-congestion-		Internet-Draft, draft-cardwell-iccrg-bbr-congestion-
	control-01, 7 November 2021,		control-02, 7 March 2022,
	<https://www.ietf.org/archive/id/draft-cardwell-iccrg-bbr-		<https://www.ietf.org/archive/id/draft-cardwell-iccrg-bbr-
	congestion-control-01.txt>.		congestion-control-02.txt>.
	[I-D.irtf-iccrg-sallantin-initial-spreading]		[I-D.irtf-iccrg-sallantin-initial-spreading]
	Sallantin, R., Baudoin, C., Arnal, F., Dubois, E., Chaput,		Sallantin, R., Baudoin, C., Arnal, F., Dubois, E., Chaput,
	E., and A. Beylot, "Safe increase of the TCP's Initial		E., and A. Beylot, "Safe increase of the TCP's Initial
	Window Using Initial Spreading", Work in Progress,		Window Using Initial Spreading", Work in Progress,
	Internet-Draft, draft-irtf-iccrg-sallantin-initial-		Internet-Draft, draft-irtf-iccrg-sallantin-initial-
	spreading-00, 15 January 2014,		spreading-00, 15 January 2014,
	<https://www.ietf.org/archive/id/draft-irtf-iccrg-		<https://www.ietf.org/archive/id/draft-irtf-iccrg-
	sallantin-initial-spreading-00.txt>.		sallantin-initial-spreading-00.txt>.
	skipping to change at page 20, line 31 ¶		skipping to change at page 20, line 45 ¶
	Using BDP Frames, the server could send information relating to the		Using BDP Frames, the server could send information relating to the
	path characteristics to the client. The use of the BDP Frame is		path characteristics to the client. The use of the BDP Frame is
	negotiated with the client. The client can read its content. If the		negotiated with the client. The client can read its content. If the
	client agrees with the usage of previous session parameters, it can		client agrees with the usage of previous session parameters, it can
	send the BDP Frame back to the server in an Initial packet of a later		send the BDP Frame back to the server in an Initial packet of a later
	connection.		connection.
	Authors' Addresses		Authors' Addresses
	Nicolas Kuhn		Nicolas Kuhn
			Thales Alenia Space
	Email: nicolas.kuhn.ietf@gmail.com		Email: nicolas.kuhn.ietf@gmail.com
	Emile Stephan		Emile Stephan
	Orange		Orange
	Email: emile.stephan@orange.com		Email: emile.stephan@orange.com
	Godred Fairhurst		Godred Fairhurst
	University of Aberdeen		University of Aberdeen
	Department of Engineering		Department of Engineering
	Fraser Noble Building		Fraser Noble Building
	Aberdeen		Aberdeen
	Email: gorry@erg.abdn.ac.uk		Email: gorry@erg.abdn.ac.uk
	Tom Jones		Tom Jones
	University of Aberdeen		University of Aberdeen
	Department of Engineering		Department of Engineering
End of changes. 14 change blocks.
	14 lines changed or deleted		27 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/