Markdown Version | Session Recording
Session Date/Time: 14 Feb 2022 17:00
MASQUE
Summary
This interim meeting focused on reviewing the proposed design for HTTP Datagrams and Connect-UDP, which resulted from the HTTP/3 Datagram Design Team's work over the past several months. The design team's output simplifies the HTTP Datagrams specification while providing extensible mechanisms for Connect-UDP. A show of hands indicated strong support for the proposed design direction, which will now be taken to the mailing list for formal working group consensus.
Key Discussion Points
- Housekeeping: The session was recorded. Attendees were requested to add their names and affiliations to the notes document, available via a link in the chat. The IETF Note Well and Code of Conduct were noted.
- Agenda Focus: The meeting's primary objective was to review and discuss the output from the HTTP/3 Datagram Design Team, aiming to finalize the design before IETF 113.
- Background on Design Team:
- MASQUE Working Group's core focus is Connect-UDP.
- The initial
h3-datagramsdraft was split intohttp-datagrams(a generic datagram transport over HTTP) andconnect-udp(building onhttp-datagrams). - After multiple iterations and realizing a circular design process at IETF 112, a design team was formed to achieve consensus.
- The design team's mandate was to reach rough consensus on the overall design for HTTP Datagrams and provide recommendations as GitHub pull requests to the working group.
- Thanks were extended to all design team participants for their work in reaching a consensus proposal.
- Design Team Output: The output consists of two pull requests: one for
http-datagramsand one forconnect-udp. - Capsule Protocol:
- The
http-datagramsdocument defines the Capsule Protocol, a sequence of Type-Length-Value (TLV) frames sent on an HTTP data stream. - Wire encoding uses QUIC-style variable-length integers (RFC 9000).
- A IANA registry for capsule types will be maintained.
- New HTTP methods or upgrade tokens (e.g., Connect-UDP, WebTransport) can declare their use of the Capsule Protocol.
- A new
Capsule-ProtocolHTTP header is introduced to inform intermediaries that the Capsule Protocol is in use, allowing for translation between different HTTP versions (e.g., HTTP/3 client-to-frontend, HTTP/2 frontend-to-backend).
- The
- HTTP Datagrams Association:
- HTTP Datagrams are strongly associated with a currently open HTTP request stream (e.g., a Connect-UDP request). They cannot be sent on a plain QUIC connection without associated HTTP semantics.
- Datagrams should not be sent once the associated stream is closed.
- Ways of Sending HTTP Datagrams:
- QUIC Datagram Frame:
- Utilizes the
draft-ietf-quic-datagramextension (recently approved by IESG). - The payload of the QUIC Datagram frame includes a
Quart-Stream-ID(client-initiated bidirectional stream ID divided by four to save bits) to associate the datagram with an HTTP request stream, followed by the HTTP Datagram Payload.
- Utilizes the
- New
DATAGRAMCapsule:- A new capsule type (
DATAGRAM) is introduced. It consists of the capsule type, length, and the HTTP Datagram Payload. - This capsule is sent within an HTTP request stream, so no explicit
Quart-Stream-IDis needed as the stream context is inherent. - This mechanism allows HTTP Datagrams to be sent over any version of HTTP, including scenarios where QUIC or UDP might be blocked.
- A new capsule type (
- QUIC Datagram Frame:
- Extensibility and Demultiplexing:
- The
Context-IDconcept, previously inhttp-datagrams, has been removed from that document. WebTransport, for example, does not require its own demultiplexing mechanism. Context-IDhas been moved to theconnect-udpdraft.
- The
- Connect-UDP Details:
Connect-UDPuses the Capsule Protocol and is defined as an HTTP upgrade token (not a new HTTP method).- It uses the
CONNECTmethod with a:protocolpseudo-header set toconnect-udp. This relies ondraft-hamilton-httpbis-websocket-over-h3(for H3) or RFC 8441 (for H2). Context-IDprovides demultiplexing within Connect-UDP:- A
Context-IDof 0 indicates a raw UDP payload to be proxied to the destination specified in the request. - In the QUIC Datagram frame,
Context-IDfollowsQuart-Stream-ID. In a capsule, it follows the Length. - Other
Context-IDvalues are dynamically allocated per request for extensibility. Even numbers are client-allocated, odd numbers are server-allocated, similar to QUIC stream IDs.
- A
- Context-ID Registration:
- Mechanisms for peers to communicate the semantics of
Context-IDs are needed. - Two methods are foreseen: HTTP headers (for initial registration) and capsules (for stateful registration during the request's lifetime).
- The current draft does not define a generic registration mechanism, deferring this to individual extensions.
- Open Question: The working group needs to decide whether to define a standardized registration method within the document or continue to leave it to extensions. This is deferred to future WG discussion, potentially at IETF 113.
- Mechanisms for peers to communicate the semantics of
- Extension Composition:
- Open Question: How multiple extensions should compose (e.g., adding a timestamp then an ECN marker) is an open question deferred to future WG discussion.
- Q&A:
- Test Implementations: A participant requested information on existing test stacks. Implementations exist in C++ (David K.'s team), Rust (Cloudflare, needing updates), and AIO-QUIC (Ericsson, open-source status unclear). A request was made to share information about test stacks on the mailing list.
- Comparison to Previous Design: The major change from previous designs is significant simplification. The prior design had more complex concepts like
datagram_format_typeand optional context extensibility mechanisms with headers, which have now been removed or simplified, improving both specification and implementation. - WebTransport Demultiplexing: WebTransport does not require the same extensibility or demultiplexing mechanisms as Connect-UDP/IP; it has a direct API for datagrams. This decision avoids unnecessary complexity in
http-datagramsfor protocols that do not need it, prioritizing composition over inheritance.
Decisions and Action Items
- Decision: A show of hands was conducted to gauge the room's sentiment on the design team's output. 21 participants raised their hands indicating agreement with the design direction, and 0 did not. This strong support confirms the proposed direction.
- Action Item: The working group chairs will bring the design team's output to the MASQUE mailing list for formal working group consensus.
- Action Item: Implementers of the drafts are encouraged to share information about their test stacks on the MASQUE mailing list to facilitate broader adoption and testing.
Next Steps
- The design team's output will be presented to the MASQUE mailing list for formal working group consensus.
- Discussion on the need for a standardized
Context-IDregistration mechanism and how extensions should compose will be deferred to future working group meetings, possibly at IETF 113.