draft-ietf-masque-h3-datagram-06.txt		draft-ietf-masque-h3-datagram-07.txt
	MASQUE D. Schinazi		MASQUE D. Schinazi
	Internet-Draft Google LLC		Internet-Draft Google LLC
	Intended status: Standards Track L. Pardue		Intended status: Standards Track L. Pardue
	Expires: 5 September 2022 Cloudflare		Expires: 22 September 2022 Cloudflare
	4 March 2022		21 March 2022
	Using Datagrams with HTTP		Using Datagrams with HTTP
	draft-ietf-masque-h3-datagram-06		draft-ietf-masque-h3-datagram-07
	Abstract		Abstract
	The QUIC DATAGRAM extension provides application protocols running		The QUIC DATAGRAM extension provides application protocols running
	over QUIC with a mechanism to send unreliable data while leveraging		over QUIC with a mechanism to send unreliable data while leveraging
	the security and congestion-control properties of QUIC. However,		the security and congestion-control properties of QUIC. However,
	QUIC DATAGRAM frames do not provide a means to demultiplex		QUIC DATAGRAM frames do not provide a means to demultiplex
	application contexts. This document describes how to use QUIC		application contexts. This document describes how to use QUIC
	DATAGRAM frames with HTTP/3 by association with HTTP requests.		DATAGRAM frames with HTTP/3 by association with HTTP requests.
	Additionally, this document defines the Capsule Protocol that can		Additionally, this document defines the Capsule Protocol that can
	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 5 September 2022.		This Internet-Draft will expire on 22 September 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
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3		1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3
	2. Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. HTTP/3 Datagram Format . . . . . . . . . . . . . . . . . . . 4		3. HTTP/3 Datagram Format . . . . . . . . . . . . . . . . . . . 3
	3.1. The H3_DATAGRAM HTTP/3 SETTINGS Parameter . . . . . . . . 5		3.1. The H3_DATAGRAM HTTP/3 SETTINGS Parameter . . . . . . . . 5
	3.1.1. Note About Draft Versions . . . . . . . . . . . . . . 6		3.1.1. Note About Draft Versions . . . . . . . . . . . . . . 5
	4. Capsules . . . . . . . . . . . . . . . . . . . . . . . . . . 6		4. Capsules . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1. Capsule Protocol . . . . . . . . . . . . . . . . . . . . 7		4.1. Capsule Protocol . . . . . . . . . . . . . . . . . . . . 7
	4.2. Error Handling . . . . . . . . . . . . . . . . . . . . . 8		4.2. Error Handling . . . . . . . . . . . . . . . . . . . . . 8
	4.3. The Capsule-Protocol Header Field . . . . . . . . . . . . 8		4.3. The Capsule-Protocol Header Field . . . . . . . . . . . . 8
	4.4. The DATAGRAM Capsule . . . . . . . . . . . . . . . . . . 9		4.4. The DATAGRAM Capsule . . . . . . . . . . . . . . . . . . 9
	5. Prioritization . . . . . . . . . . . . . . . . . . . . . . . 10		5. Prioritization . . . . . . . . . . . . . . . . . . . . . . . 10
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 11		6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	7.1. HTTP/3 SETTINGS Parameter . . . . . . . . . . . . . . . . 11		7.1. HTTP/3 SETTINGS Parameter . . . . . . . . . . . . . . . . 11
	7.2. HTTP/3 Error Code . . . . . . . . . . . . . . . . . . . . 11		7.2. HTTP/3 Error Code . . . . . . . . . . . . . . . . . . . . 11
	7.3. HTTP Header Field Name . . . . . . . . . . . . . . . . . 12		7.3. HTTP Header Field Name . . . . . . . . . . . . . . . . . 11
	7.4. Capsule Types . . . . . . . . . . . . . . . . . . . . . . 12		7.4. Capsule Types . . . . . . . . . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8.1. Normative References . . . . . . . . . . . . . . . . . . 13		8.1. Normative References . . . . . . . . . . . . . . . . . . 12
	8.2. Informative References . . . . . . . . . . . . . . . . . 14		8.2. Informative References . . . . . . . . . . . . . . . . . 14
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
	A.1. CONNECT-UDP . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	A.2. WebTransport . . . . . . . . . . . . . . . . . . . . . . 15
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	The QUIC DATAGRAM extension [DGRAM] provides application protocols		The QUIC DATAGRAM extension [DGRAM] provides application protocols
	running over QUIC [QUIC] with a mechanism to send unreliable data		running over QUIC [QUIC] with a mechanism to send unreliable data
	while leveraging the security and congestion-control properties of		while leveraging the security and congestion-control properties of
	QUIC. However, QUIC DATAGRAM frames do not provide a means to		QUIC. However, QUIC DATAGRAM frames do not provide a means to
	demultiplex application contexts. This document describes how to use		demultiplex application contexts. This document describes how to use
	QUIC DATAGRAM frames with HTTP/3 [H3] by association with HTTP		QUIC DATAGRAM frames with HTTP/3 [H3] by association with HTTP
	requests. Additionally, this document defines the Capsule Protocol		requests. Additionally, this document defines the Capsule Protocol
	skipping to change at page 10, line 31 ¶		skipping to change at page 10, line 21 ¶
	on that connection is too low), the intermediary SHOULD drop the HTTP		on that connection is too low), the intermediary SHOULD drop the HTTP
	Datagram instead of converting it to a DATAGRAM capsule. This		Datagram instead of converting it to a DATAGRAM capsule. This
	preserves the end-to-end unreliability characteristic that methods		preserves the end-to-end unreliability characteristic that methods
	such as Datagram Packetization Layer Path MTU Discovery (DPLPMTUD)		such as Datagram Packetization Layer Path MTU Discovery (DPLPMTUD)
	depend on [DPLPMTUD]. An intermediary that converts QUIC DATAGRAM		depend on [DPLPMTUD]. An intermediary that converts QUIC DATAGRAM
	frames to DATAGRAM capsules allows HTTP Datagrams to be arbitrarily		frames to DATAGRAM capsules allows HTTP Datagrams to be arbitrarily
	large without suffering any loss; this can misrepresent the true path		large without suffering any loss; this can misrepresent the true path
	properties, defeating methods such as DPLPMTUD.		properties, defeating methods such as DPLPMTUD.
	While DATAGRAM capsules can theoretically carry a payload of length		While DATAGRAM capsules can theoretically carry a payload of length
	2^62-1, most applications will have their own limits on what datagran		2^62-1, most applications will have their own limits on what datagram
	payload sizes are practical. Implementations SHOULD take those		payload sizes are practical. Implementations SHOULD take those
	limits into account when parsing DATAGRAM capsules: if an incoming		limits into account when parsing DATAGRAM capsules: if an incoming
	DATAGRAM capsule has a length that is known to be so large as to not		DATAGRAM capsule has a length that is known to be so large as to not
	be usable, the implementation SHOULD discard the capsule without		be usable, the implementation SHOULD discard the capsule without
	buffering its contents into memory.		buffering its contents into memory.
	5. Prioritization		5. Prioritization
	Data streams (see Section 4.1) can be prioritized using any means		Data streams (see Section 4.1) can be prioritized using any means
	suited to stream or request prioritization. For example, see		suited to stream or request prioritization. For example, see
	skipping to change at page 13, line 5 ¶		skipping to change at page 12, line 32 ¶
	Reference: An optional reference to a specification for the type.		Reference: An optional reference to a specification for the type.
	This field MAY be empty.		This field MAY be empty.
	Registrations follow the "First Come First Served" policy (see		Registrations follow the "First Come First Served" policy (see
	Section 4.4 of [IANA-POLICY]) where two registrations MUST NOT have		Section 4.4 of [IANA-POLICY]) where two registrations MUST NOT have
	the same Type.		the same Type.
	This registry initially contains the following entry:		This registry initially contains the following entry:
	+==============+==========+===============+		Capsule Type: DATAGRAM
	| Capsule Type | Value | Specification |
	+==============+==========+===============+
	| DATAGRAM | 0xff37a5 | This Document |
	+--------------+----------+---------------+
	Table 1: Initial Capsule Types Registry		Value: 0xff37a5 (note that this will switch to a lower value before
			publication)
			Reference: This document
	Capsule types with a value of the form 41 * N + 23 for integer values		Capsule types with a value of the form 41 * N + 23 for integer values
	of N are reserved to exercise the requirement that unknown capsule		of N are reserved to exercise the requirement that unknown capsule
	types be ignored. These capsules have no semantics and can carry		types be ignored. These capsules have no semantics and can carry
	arbitrary values. These values MUST NOT be assigned by IANA and MUST		arbitrary values. These values MUST NOT be assigned by IANA and MUST
	NOT appear in the listing of assigned values.		NOT appear in the listing of assigned values.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	skipping to change at page 14, line 43 ¶		skipping to change at page 14, line 23 ¶
	Völker, "Packetization Layer Path MTU Discovery for		Völker, "Packetization Layer Path MTU Discovery for
	Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,		Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
	September 2020, <https://www.rfc-editor.org/rfc/rfc8899>.		September 2020, <https://www.rfc-editor.org/rfc/rfc8899>.
	[PRIORITY] Oku, K. and L. Pardue, "Extensible Prioritization Scheme		[PRIORITY] Oku, K. and L. Pardue, "Extensible Prioritization Scheme
	for HTTP", Work in Progress, Internet-Draft, draft-ietf-		for HTTP", Work in Progress, Internet-Draft, draft-ietf-
	httpbis-priority-12, 17 January 2022,		httpbis-priority-12, 17 January 2022,
	<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-		<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
	priority-12>.		priority-12>.
	Appendix A. Examples
	[[RFC editor: please remove this appendix before publication.]]
	A.1. CONNECT-UDP
	Client Server
	STREAM(44): HEADERS -------->
	:method = CONNECT
	:protocol = connect-udp
	:scheme = https
	:path = /target.example.org/443/
	:authority = proxy.example.org:443
	capsule-protocol = ?1
	DATAGRAM -------->
	Quarter Stream ID = 11
	Payload = Encapsulated UDP Payload
	<-------- STREAM(44): HEADERS
	:status = 200
	capsule-protocol = ?1
	/* Wait for target server to respond to UDP packet. */
	<-------- DATAGRAM
	Quarter Stream ID = 11
	Payload = Encapsulated UDP Payload
	A.2. WebTransport
	Client Server
	STREAM(44): HEADERS -------->
	:method = CONNECT
	:scheme = https
	:protocol = webtransport
	:path = /hello
	:authority = webtransport.example.org:443
	origin = https://www.example.org:443
	<-------- STREAM(44): HEADERS
	:status = 200
	/* Both endpoints can now send WebTransport datagrams. */
	Acknowledgments		Acknowledgments
	Portions of this document were previously part of the QUIC DATAGRAM		Portions of this document were previously part of the QUIC DATAGRAM
	frame definition itself, the authors would like to acknowledge the		frame definition itself, the authors would like to acknowledge the
	authors of that document and the members of the IETF MASQUE working		authors of that document and the members of the IETF MASQUE working
	group for their suggestions. Additionally, the authors would like to		group for their suggestions. Additionally, the authors would like to
	thank Martin Thomson for suggesting the use of an HTTP/3 SETTINGS		thank Martin Thomson for suggesting the use of an HTTP/3 SETTINGS
	parameter. Furthermore, the authors would like to thank Ben Schwartz		parameter. Furthermore, the authors would like to thank Ben Schwartz
	for writing the first proposal that used two layers of indirection.		for writing the first proposal that used two layers of indirection.
	The final design in this document came out of the HTTP Datagrams		The final design in this document came out of the HTTP Datagrams
End of changes. 14 change blocks.
	69 lines changed or deleted		19 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/