]>

kixelated@gmail.com

wit moq QMux is a polyfill that runs QUIC applications over an ordered, reliable byte-stream transport such as TCP with TLS. This document defines a binding for QMux over WebSocket . A WebSocket binding lets QUIC applications reach environments where UDP is blocked and where only an HTTP/WebSocket stack is available, including web browsers that lack WebTransport.

Conventions and Definitions 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. This document uses the terms QMux Record, QMux Frame, and transport parameter as defined in , and the terms WebSocket connection, message, frame, and subprotocol as defined in .

Introduction QMux lets an application written against the QUIC stream and datagram API run over an ordered, reliable byte-stream transport. It defines a binding over TCP and over TLS, but a WebSocket binding is out of scope for the QUIC working group charter. A WebSocket binding is nevertheless useful: WebSocket is available where UDP is blocked, in web browsers that lack WebTransport, and behind HTTP load balancers that cannot route raw TCP or QUIC. This document specifies how to carry QMux over WebSocket: the message framing, the subprotocol negotiation used in place of TLS ALPN, keep-alive behavior, connection close, and datagrams. All other QMux semantics (in-order STREAM frame delivery, stream identifiers, flow control, and transport parameters) apply unchanged from . This binding is application agnostic: any QUIC application that can run over QMux can run over QMux over WebSocket. Media over QUIC Transport is the motivating use case, but nothing in this document is specific to it.

WebSocket Binding Overview A QMux-over-WebSocket connection is an ordinary WebSocket connection whose binary messages carry QMux frames, taking the place of the underlying byte-stream transport in . Both the QMux Record layer and the WebSocket message layer provide self-delimiting messages over a reliable, ordered byte stream. The two layers are therefore collapsed: instead of prefixing each Record with its Size, the binding relies on the WebSocket message boundary to delimit it.

Establishing a Connection A client establishes a QMux-over-WebSocket connection by opening a WebSocket connection per (the opening handshake over HTTP/1.1) or per (the bootstrapping mechanism over HTTP/2 or HTTP/3). The ws URI scheme is used over an unencrypted transport and the wss URI scheme is used over a TLS-encrypted transport. Deployments SHOULD use wss; an application that expects a TLS transport when running natively over QUIC SHOULD require wss here. How the underlying connection is authenticated and authorized is out of scope for this document, as it is for .

Subprotocol Negotiation QMux over TCP/TLS uses TLS ALPN to agree on the application protocol. WebSocket has no ALPN exchange, so this binding uses the WebSocket subprotocol negotiation of Section 1.9 (the Sec-WebSocket-Protocol header) in its place, carrying the same application protocol identifier. The subprotocol identifier is exactly the identifier the application would use as its ALPN over native QUIC, for example moq-transport-18. It also determines the QMux wire-format version, so there is no separate QMux version negotiation (see ). A client offers one or more identifiers in the Sec-WebSocket-Protocol request header, in decreasing order of preference, one per protocol version it is willing to use. A server selects at most one, in its own order of preference, and echoes it in the response header; if it supports none of the offered identifiers, it MUST fail the handshake. A client MUST treat a response value it did not offer as a failed handshake per , and this binding additionally requires a selection: a client MUST treat the absence of a Sec-WebSocket-Protocol response header as a failed handshake too, since without one no QMux version was agreed.

Record Framing Each WebSocket binary message carries exactly one QMux Record's Frames field: one or more QMux frames concatenated, as defined in . Because the WebSocket framing layer already delimits each message, the QMux Record Size field is redundant: it MUST NOT be transmitted and MUST NOT be expected by the receiver. A QMux-over-WebSocket record is therefore:

The frames inside a message are encoded exactly as in , including the in-order STREAM frame requirement: for each QUIC stream, a sender MUST send that stream's payload in order, so a receiver can deliver payload to the application as it arrives without reassembly. An endpoint MAY place multiple frames in a single binary message and MAY split a logical sequence of frames across multiple messages, subject to the constraint that each STREAM frame's payload bytes are delivered in order. An empty binary message (zero frames) is permitted and carries no frames; a receiver MUST accept it and treat it as a no-op. The maximum size of a binary message is bounded by the max_record_size transport parameter defined in and by any WebSocket implementation limits. An endpoint MUST NOT send a binary message whose payload exceeds the peer's advertised max_record_size, and MAY treat receipt of an oversized message as a connection error.

WebSocket Message Types This binding uses WebSocket message and control frames as follows: Binary messages carry QMux frames as defined in . Text messages MUST NOT be sent. A receiver MUST treat a text message as a connection error and close the WebSocket connection. Close frames terminate the connection as defined in . Ping and Pong frames are used for keep-alive as defined in and are otherwise handled by the WebSocket layer; they carry no QMux frames. The first QMux frame sent by each endpoint MUST be the QX_TRANSPORT_PARAMETERS frame, exactly as required by ; this binding does not change that requirement.

QMux Version The QMux version is not signaled on the wire. As with QMux over TLS, it is implied by the negotiated application protocol: each application protocol that runs over QMux specifies which QMux version each of its identifiers uses. An application protocol used with this binding MUST select a QMux version that provides the Record layer (see ), i.e. or later.

Keep-Alive and Idle Timeout A WebSocket connection has no built-in idle timeout: if the peer's host crashes without a TCP FIN, the local socket can remain "open" for hours. To detect a dead peer, an endpoint SHOULD send WebSocket Ping frames periodically and SHOULD close the connection if no WebSocket frame of any kind is received within a timeout, a small multiple of the ping interval. Reasonable defaults are a 5-second ping interval and a 30-second timeout, but the values are a local policy decision. Receipt of any WebSocket frame from the peer (binary, Ping, or Pong) resets the idle timer. This keep-alive operates at the WebSocket layer and is separate from the QMux max_idle_timeout transport parameter and QX_PING frame, either of which an endpoint MAY also use.

Datagrams QMux datagrams are supported. They are negotiated and encoded exactly as in : an endpoint advertises the datagram transport parameter and carries QMux DATAGRAM frames inside binary messages, like any other frame ().

Connection Close An endpoint terminates a QMux-over-WebSocket connection by sending a WebSocket Close frame and then closing the underlying transport. A QMux CONNECTION_CLOSE frame, if sent, conveys the QMux-level error code and reason and SHOULD be sent in a final binary message before the WebSocket Close frame. Because the WebSocket layer provides its own connection close, there is no draining period: an endpoint MAY close immediately after sending its Close frame. Receipt of a WebSocket Close frame, or loss of the underlying transport, terminates the QMux connection and all of its streams.

Security Considerations This binding inherits the security considerations of QMux , WebSocket , and, when wss is used, TLS . Carrying QMux over WebSocket does not add or remove any QMux-level security property. In particular, this binding provides no transport-layer confidentiality or integrity of its own; deployments that require those properties MUST use wss (WebSocket over TLS). The keep-alive mechanism in causes an endpoint to send periodic Ping frames. An endpoint SHOULD bound the rate at which it sends and responds to Ping/Pong frames to avoid amplification or resource-exhaustion concerns. Because a server selects the subprotocol from a client-supplied list, a server MUST validate the selected identifier against its own supported set and MUST NOT echo an arbitrary client-supplied value, as required by .

IANA Considerations This document has no IANA actions. This binding defines no subprotocol identifiers of its own: the Sec-WebSocket-Protocol value is the application protocol identifier, which is owned by the application protocol's specification (for example, ). Whether those identifiers are registered in the WebSocket Subprotocol Name Registry is therefore up to each application protocol, not this document.

Fastly Cloudflare Netflix Apple This document specifies QMux version 1. QMux version 1 provides, over bi-directional streams such as TLS, the same set of stream and datagram operations that applications rely upon in QUIC version 1. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the QUIC Working Group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Source for this draft and an issue tracker can be found at https://github.com/quicwg/qmux. The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or s and long polling). [STANDARDS-TRACK] 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. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. The mechanism for running the WebSocket Protocol over a single stream of an HTTP/2 connection is equally applicable to HTTP/3, but the HTTP-version-specific details need to be specified. This document describes how the mechanism is adapted for HTTP/3. Cisco Google Google Meta This document defines Media over QUIC Transport (MOQT), a publish/ subscribe protocol that runs over QUIC and WebTransport. MOQT leverages the features of these transports, such as streams, datagrams, priorities, and partial reliability. MOQT operates both point-to-point and through intermediate relays, enabling scalable low-latency delivery. Despite its name, MOQT is media agnostic and can be used for a wide range of use cases.

Acknowledgments QMux is the work of the QUIC working group; this document only defines a WebSocket binding for it. Thanks to the Media over QUIC working group for motivating a transport that works where UDP does not.