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-datagrams draft was split into http-datagrams (a generic datagram transport over HTTP) and connect-udp (building on http-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-datagrams and one for connect-udp.
Capsule Protocol:
- The http-datagrams document 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-Protocol HTTP 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).
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-datagram extension (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.
- New DATAGRAM Capsule:
  - 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-ID is 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.
Extensibility and Demultiplexing:
- The Context-ID concept, previously in http-datagrams, has been removed from that document. WebTransport, for example, does not require its own demultiplexing mechanism.
- Context-ID has been moved to the connect-udp draft.
Connect-UDP Details:
- Connect-UDP uses the Capsule Protocol and is defined as an HTTP upgrade token (not a new HTTP method).
- It uses the CONNECT method with a :protocol pseudo-header set to connect-udp. This relies on draft-hamilton-httpbis-websocket-over-h3 (for H3) or RFC 8441 (for H2).
- Context-ID provides demultiplexing within Connect-UDP:
  - A Context-ID of 0 indicates a raw UDP payload to be proxied to the destination specified in the request.
  - In the QUIC Datagram frame, Context-ID follows Quart-Stream-ID. In a capsule, it follows the Length.
  - Other Context-ID values are dynamically allocated per request for extensibility. Even numbers are client-allocated, odd numbers are server-allocated, similar to QUIC stream IDs.
- 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.
- 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_type and 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-datagrams for 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-ID registration mechanism and how extensions should compose will be deferred to future working group meetings, possibly at IETF 113.