Google LLC

1600 Amphitheatre Parkway Mountain View, California 94043 United States of America dschinazi.ietf@gmail.com

Internet-Draft The QUIC DATAGRAM extension provides application protocols running over QUIC with a way to send unreliable data while leveraging the security and congestion-control properties of QUIC. However, QUIC DATAGRAM frames do not provide a means to demultiplex application contexts using them. This document defines how to use QUIC DATAGRAM frames when the application protocol running over QUIC is HTTP/3, by adding an identifier at the start of the frame payload.

The QUIC DATAGRAM extension provides application protocols running over QUIC with a way to send unreliable data while leveraging the security and congestion-control properties of QUIC. However, QUIC DATAGRAM frames do not provide a means to demultiplex application contexts using them. This document defines how to use QUIC DATAGRAM frames when the application protocol running over QUIC is HTTP/3 , by adding an identifier at the start of the frame payload. This design mimics the use of Stream Types in HTTP/3, which provide a demultiplexing identifier at the start of each unidirectional stream.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

When used with HTTP/3, the Datagram Data field of QUIC DATAGRAM frames uses the following format:

A variable-length integer indicating the Flow Identifier of the datagram (see ). The payload of the datagram, whose semantics are defined by individual applications.

Flow identifiers represent bidirectional flows of datagrams within a single QUIC connection. These are effectively equivalent to UDP ports, that allow basic demultiplexing of application data. The primary role of slow identifiers is to provide a standard mechanism for demultiplexing application data flows, which may be destined for different processing threads in the application, akin to UDP sockets. Beyond this, a sender SHOULD ensure that DATAGRAM frames within a single flow are transmitted in order relative to one another. If multiple DATAGRAM frames can be packed into a single QUIC packet, the sender SHOULD group them by Flow Identifier to promote fate-sharing within a specific flow and improve the ability to process batches of datagram messages efficiently on the receiver.

Implementations of HTTP/3 that support the DATAGRAM extension will provide a flow identifier allocation service. That service will allow applications co-located with HTTP/3 to request a unique Flow Identifier that they can subsequently use for their own purposes. The HTTP/3 implementation will then parse the Flow Identifier of incoming DATAGRAM frames and use it to deliver the frame to the appropriate application.

This document currently does not have additional security considerations on top of the ones defined in and .

This document has no IANA actions.

This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection. This document defines the core of the QUIC transport protocol. Accompanying documents describe QUIC's loss detection and congestion control and the use of TLS for key negotiation. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at <https://mailarchive.ietf.org/arch/search/?email_list=quic>. Working Group information can be found at <https://github.com/ quicwg>; source code and issues list for this draft can be found at <https://github.com/quicwg/base-drafts/labels/-transport>. The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC, and describes how HTTP/2 extensions can be ported to HTTP/3. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

The DATAGRAM frame identifier was previously part of the DATAGRAM frame definition itself, the author would like to acknowledge the authors of that document and the members of the IETF QUIC working group for their suggestions.