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/