]> Fastly

kazuhooku@gmail.com

Cloudflare

lucas@lucaspardue.com

Netflix

jri.ietf@gmail.com

Apple

ekinnear@apple.com

QUIC internet-draft 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 Discussion of this document takes place on the QUIC Working Group mailing list (quic@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction QUIC version 1 is a bi-directional, authenticated transport-layer protocol built on top of UDP . The protocol provides multiplexed flow-controlled streams without head-of-line blocking as a core service. It also offers low-latency connection establishment and efficient loss recovery. However, there are downsides to QUIC. One downside is that QUIC, being based on UDP, is not as universally accessible as TCP , due to occasionally being blocked by middleboxes. Another downside is that QUIC is computationally more expensive compared to TLS over TCP. This increased cost is partly because QUIC encrypts each packet, which is smaller than the encryption unit of TLS, leading to more overhead, and partly because UDP is less optimized within computing infrastructures. Due to these limitations, applications are often served using both QUIC and TCP. QUIC is employed to provide the optimal user experience, while TCP acts as a fallback for ensuring network reachability and computational efficiency as needed. One such example is HTTP, which has different bindings for QUIC (HTTP/3 ) and TCP (HTTP/2 ). Recently, security concerns have prompted proposals to revise HTTP/2 (), which has sparked discussions about the costs of maintaining multiple HTTP versions. Another example is WebTransport, a superset of HTTP. Because HTTP has different bindings for QUIC and TCP, WebTransport defines its own extensions for the two HTTP variants (, ). To reduce or eliminate the costs associated with duplicated efforts in providing services on top of both transport protocols, this document specifies a polyfill that allows application protocols built on QUIC to run on transport protocols that provide single bi-directional, byte-oriented stream such as TCP or TLS. The specified polyfill provides a compatibility layer for the set of operations (i.e., API) required by QUIC, as specified in Section and Section of .

Trade-offs Between QMux and QUIC Version 1 QMux runs QUIC's stream and datagram operations over a single ordered, reliable byte stream. This leads to the following differences from QUIC version 1, which applications need to account for when choosing between the two.

Head-of-line blocking:

In QUIC, streams are delivered independently (), so loss affecting one stream does not delay the delivery of others. Any head-of-line blocking is confined to the individual stream that lost data, rather than affecting the whole connection. QMux carries all streams and datagrams over a single ordered byte stream and cannot provide this isolation. The loss of one segment on that transport delays every byte behind it, so a single loss can stall all QMux streams, datagrams, and control frames until the transport repairs the loss.

No unreliable datagram delivery:

In QUIC, DATAGRAM frames are delivered unreliably. They can be reordered or dropped, and they are never retransmitted. In QMux, a DATAGRAM frame written to the underlying transport is delivered reliably and in order, like any other data, and is subject to the same head-of-line blocking. A sender can still choose not to send a datagram, but a datagram cannot be dropped once sent. Applications that rely on QUIC's unreliable datagram semantics need to account for this difference.

No connection migration or multipath:

A QMux connection is tied to the connection of the underlying transport, such as a TCP four-tuple. Unlike QUIC, it cannot migrate to a new path or survive a change in the client's address ().

Connection establishment latency:

QMux uses the underlying transport for connection establishment rather than QUIC's combined transport and cryptographic handshake. Establishment latency is therefore bounded by that of the underlying transport, for example a TCP handshake followed by a TLS handshake. Early data on resumption is limited to what the underlying transport offers, such as TLS 1.3 0-RTT.

Dependence on the underlying transport:

QMux provides no confidentiality, integrity, or peer authentication of its own, and relies on the underlying transport for these properties and for application protocol negotiation (see and ).

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.

The Protocol QMux can be used on any transport that provides a bi-directional, byte-oriented stream that is ordered and reliable; for details, see . QMux transfers one or more QUIC frames within a QMux record; see . Neither QUIC frames nor QMux records are encrypted in this protocol; it is the task of the transport (e.g., TLS) to provide confidentiality and integrity. QUIC packet headers are not used. For exchanging the transport parameters, a new frame called QX_TRANSPORT_PARAMETERS frame is defined.

Properties of Underlying Transport QMux is designed to work on top of transport layer protocols that provide the following capabilities:

In-order delivery of bytes in both direction:

Underlying transport provides a byte-oriented and bi-directional stream that deliver the bytes in order; i.e., bytes that were sent in one order become available to the receiving side in the same order.

Guaranteed delivery:

If the transport runs on top of a lossy network, that transport recovers the bytes lost; e.g., by retransmitting them. This requires buffering and reassembly, in order to achieve the first bullet point (in-order delivery).

Congestion control:

When used on a shared network, the transport is congestion controlled. Implementations of QMux simply write outgoing frames to the transport when that transport permits.

Authentication, confidentiality, and integrity protection:

Unless used upon endpoints between which tampering or monitoring is a non-concern, the transport provides peer authentication, confidentially, and integrity protection.

Application Protocol Negotiation:

To avoid cross-protocol confusion, the underlying transport provides a mechanism for endpoints to agree on the protocols in use. Without such a mechanism, QMux and application protocols built on top of QMux can only be used between endpoints that have out-of-band agreement on those protocols.

TLS over TCP, combined with the Application-Layer Protocol Negotiation extension (ALPN) , provides all these capabilities. UNIX sockets are an example that provide in-order and guaranteed delivery only. Congestion control is not employed, as UNIX sockets do not face a shared bottleneck. Confidentiality and integrity protection are deemed unnecessary in environments where the operating system is trusted. Agreement on the application protocol can be achieved by using different listening sockets.

QMux Records QMux Records are formatted as shown in .

QMux Record Format

QMux Records contain the following fields:

Size:

A variable-length integer specifying the length in bytes of the Frames field. Note that this length does not include the Size field itself.

Frames:

A byte sequence that contains one or more QUIC frames.

Each QMux Record is self-delimiting. On a byte stream transport, endpoints parse QMux Records by first parsing Size and then reading exactly that many bytes as Frames. The bytes in Frames are interpreted as a contiguous series of QUIC frames encoded using QUIC version 1 framing. As with QUIC packet payloads (), frames are complete units: a frame MUST fit entirely within a single QMux Record and MUST NOT span multiple QMux Records. Senders can choose record boundaries freely, subject to the max_record_size transport parameter (). Receivers process frames within each record, using the record boundary as the payload boundary for frames that omit an explicit length. If the end of the Frames field is not aligned to a frame boundary (that is, if the final frame in the record is truncated), the receiver MUST close the connection with an error of type FRAME_ENCODING_ERROR.

QUIC Frames In QMux, the following QUIC frames can be used, as if they were sent or received in the application packet number space:

• PADDING
• RESET_STREAM
• STOP_SENDING
• STREAM
• MAX_DATA
• MAX_STREAM_DATA
• MAX_STREAMS
• DATA_BLOCKED
• STREAM_DATA_BLOCKED
• STREAMS_BLOCKED
• CONNECTION_CLOSE

The frame formats are identical to those in QUIC version 1. Likewise, the meaning and requirements for the use of these frames are consistent with QUIC version 1, with the exception to the specific changes made to the STREAM frames, as detailed in . QMux keeps the QUIC version 1 frame formats even where the ordered transport makes a field redundant, such as the Offset field of STREAM frames. This lets an implementation reuse a QUIC version 1 stack with minimal changes, and removing such fields would provide minimal benefit while increasing the divergence between QMux and QUIC version 1 implementations. Use of other frames defined in QUIC version 1 is prohibited for various reasons. Frames related to the cryptographic handshake are not used because an underlying security layer can provide equivalent features. Use of frames that communicate Connection IDs and those related to path migration is forbidden. QMux relies on the underlying transport for reliable delivery and therefore does not use ACK frames. QMux stacks do not track delivery or retransmit lost data or frames. For the stream state machinery defined in , references to acknowledgment are interpreted as though acknowledgments occurs as soon as data is passed to the underlying transport. As in QUIC version 1, applications cannot assume that the peer application has consumed data based solely on transport events. The full list of prohibited frames is:

• PING
• ACK
• CRYPTO
• NEW_TOKEN
• NEW_CONNECTION_ID
• RETIRE_CONNECTION_ID
• PATH_CHALLENGE
• PATH_REPONSE
• HANDSHAKE_DONE

Endpoints MUST NOT send prohibited frames. If an endpoint receives one it MUST close the connection with an error of type FRAME_ENCODING_ERROR.

Ordering of STREAM Frames In QUIC version 1, the order in which STREAM frames are sent or received is not guaranteed, because packets can be lost and frames can be retransmitted in different packets. In contrast, QMux, which runs over an ordered and reliable byte stream transport, requires STREAM frames for each QUIC stream to be sent in order: i.e., for each QUIC stream being sent, senders MUST send the stream payload in order. This change eliminates the need for implementations to buffer and reassemble the stream payload. As a result, the payload being received can be directly passed to the application as it is read from the transport. This efficiency is due to the underlying transport's guarantee of in-order delivery. When receiving a STREAM frame that carries a payload not immediately following the payload of the previous STREAM frame for the same Stream ID, receivers MUST close the connection with an error of type PROTOCOL_VIOLATION. These changes do not impact the senders' capability to interleave STREAM frames from multiple streams.

QX_TRANSPORT_PARAMETERS Frames In QMux, transport parameters are exchanged as frames. QX_TRANSPORT_PARAMETERS frames are formatted as shown in .

QX_TRANSPORT_PARAMETERS Frame Format

QX_TRANSPORT_PARAMETERS frames contain the following fields:

Length:

A variable-length integer specifying the length of the transport parameters field in this QX_TRANSPORT_PARAMETERS frame.

Transport Parameters:

The transport parameters. The encoding of the payload is as defined in .

The QX_TRANSPORT_PARAMETERS frame is the first frame sent by endpoints. To allow peers to open streams and start sending data as early as possible, endpoints MUST send the QX_TRANSPORT_PARAMETERS frame as soon as the underlying transport becomes available for sending. Neither endpoint needs to wait for the peer's transport parameters before sending its own, as transport parameters are a unilateral declaration of an endpoint's capabilities (). Except when sending 0-RTT data using remembered transport parameters as described in , endpoints MUST NOT send frames whose use depends on peer transport parameters until the peer's QX_TRANSPORT_PARAMETERS frame has been received and processed. This can delay use of peer-advertised flow control credit and can therefore block sending stream data before peer transport parameters arrive. When QMux runs over TLS 1.3, this does not necessarily add a full round trip for clients on a full handshake. Servers can send the QX_TRANSPORT_PARAMETERS frame immediately after the server's Finished message, and clients can receive and process the transport parameters as soon as they obtain the keys needed to process application data. The QX_TRANSPORT_PARAMETERS frame MUST only be sent as the first frame. If the first frame being received by an endpoint is not a QX_TRANSPORT_PARAMETERS frame, or if a QX_TRANSPORT_PARAMETERS frame is received other than as the first frame, the endpoint MUST close the connection with an error of type PROTOCOL_VIOLATION. The frame type (0x3f5153300d0a0d0a; "\xffQMX\r\n\r\n" on wire) has been chosen so that it can be used to disambiguate QMux from HTTP/1.1 and HTTP/2.

QX_PING Frames In QMux, QX_PING frames allow endpoints to test peer reachability above the underlying transport. QX_PING frames are formatted as shown in .

QX_PING Frame Format

Type 0x348c67529ef8c7bd is used for sending a ping (i.e., request the peer to respond). Type 0x348c67529ef8c7be is used in response. QX_PING frames contain the following fields:

Sequence Number:

A variable-length integer used to identify the ping.

When sending QX_PING frames of type 0x348c67529ef8c7bd, endpoints MUST send strictly increasing values in the Sequence Number field, since that allows the endpoints to identify to which ping the peer has responded. When sending QX_PING frames of type 0x348c67529ef8c7be in response, endpoints MUST echo the Sequence Number that they received. When receiving multiple QX_PING frames of type 0x348c67529ef8c7bd before having the chance to respond, an endpoint MAY only respond with one QX_PING frame of type 0x348c67529ef8c7be carrying the largest Sequence Number that the endpoint has received. If an endpoint receives a QX_PING frame of type 0x348c67529ef8c7be with a sequence number greater than the greatest sequence number that it sent in a QX_PING frame of type 0x348c67529ef8c7bd, the endpoint MUST close the connection with an error of type PROTOCOL_VIOLATION. Similarly, an endpoint MAY detect a sequence number that it did not send and close the connection with the same error. If an endpoint receives a QX_PING frame of type 0x348c67529ef8c7bd with a sequence number less than or equal to the previous sequence number received in a frame of the same type, the endpoint MUST close the connection with an error of type PROTOCOL_VIOLATION.

Transport Parameters As in QUIC, QMux exchanges transport parameters following the rules established in , with the modifications described in the subsections below. Transport parameters are also carried differently, in a frame rather than a TLS extension; see .

Permitted and Forbidden Transport Parameters Among the transport parameters defined in , use of the following transport parameters is allowed:

• max_idle_timeout
• initial_max_data
• initial_max_stream_data_bidi_local
• initial_max_stream_data_bidi_remote
• initial_max_stream_data_uni
• initial_max_streams_bidi
• initial_max_streams_uni

The definitions of these transport parameters are unchanged. Although an endpoint could convey connection-level limits using MAX_DATA and MAX_STREAMS frames in its first flight, the initial flow-control transport parameters from QUIC version 1 are used. The initial_max_stream_data_bidi_local, initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni parameters set the flow-control credit available on a stream as soon as it is opened, including streams opened later in the connection. Using these transport parameters also lets a client send 0-RTT data within remembered limits on a resumed connection, before the peer's frames are received (see ), and preserves the flow-control model of QUIC version 1 so that existing implementations can be reused without modification. Use of all other transport parameters defined in is prohibited, namely the following:

• original_destination_connection_id
• stateless_reset_token
• max_udp_payload_size
• ack_delay_exponent
• max_ack_delay
• disable_active_migration
• preferred_address
• active_connection_id_limit
• initial_source_connection_id
• retry_source_connection_id

When an endpoint receives one of the prohibited transport parameters, the endpoint MUST close the connection with an error of type TRANSPORT_PARAMETER_ERROR. QUIC defines a reserved range of transport parameters for the purpose of exercising a peer's ability to ignore unknown transport parameters (). The use of these transport parameters in QMux for the same purpose is allowed. Endpoints MUST NOT send transport parameters defined outside of unless they are specified to be usable with QMux. Similarly, endpoints MUST ignore transport parameters defined outside of unless they are specified to be usable with QMux; see .

max_record_size Transport Parameter The max_record_size transport parameter (0x0571c59429cd0845) is a variable-length integer specifying the maximum value of the Size field of a QMux Record () that the peer can send, in the unit of bytes. As required by , if the max_record_size transport parameter is absent, a default value applies. The default value of the max_record_size transport parameter is 16382. This value allows a sender to construct a 16KB QMux Record by using a 2-byte Size field and a 16382-byte Frames field, aligning with the default capacity of a full-sized TLS record; see . When the max_record_size transport parameter is sent, the value MUST be equal to or greater than the default value. When receiving a value less than the default value, receivers MUST close the connection with an error of type TRANSPORT_PARAMETER_ERROR. Endpoints MUST NOT send QMux Records with a Frames field that exceeds the maximum declared by the peer. When receiving a QMux Record with a Frames field that exceeds the declared maximum, receivers MUST close the connection with an error of type FRAME_ENCODING_ERROR. This document does not specify the use of the max_record_size transport parameter with QUIC version 1. Absent such a specification, the max_record_size transport parameter is ignored by QUIC version 1 endpoints as an unknown transport parameter, as defined in ().

Forward Progress and Flow Control To avoid deadlock due to flow control in the underlying transport, endpoints MUST continue reading from the underlying transport even when delivery of STREAM data to the application is temporarily blocked. Endpoints MUST NOT couple reads from the underlying transport to application reads on any single QUIC stream, as doing so can prevent processing of frames required for connection progress. Continuing to read does not imply unbounded buffering of STREAM data, as the amount of stream data a peer can send is limited by flow control (). For DATAGRAM frames, endpoints MAY drop received datagrams when they cannot be promptly delivered to the application.

Connection Termination A QMux connection can be terminated by an idle timeout, by a CONNECTION_CLOSE frame, or by observing a closure of the underlying transport.

Idle Timeout In QUIC version 1, the idle timer is reset whenever a packet is received and processed successfully, including acknowledgment-only packets. It also raises the idle timeout using PTO, a value derived from when acknowledgments are received. QMux cannot adopt this approach as-is since acknowledgments are not processed by QMux stacks; they are processed by the underlying transport instead. As a consequence, the idle timeout of QMux is defined as follows:

• As in QUIC version 1, endpoints negotiate an idle timeout using the max_idle_timeout transport parameter.
• As in QUIC version 1, endpoints reset the idle timer each time a QMux record is completely received.
• Endpoints also reset the idle timer each time a QMux record is completely sent. Since acknowledgments are not directly visible to QMux endpoints, QMux does not reset the idle timer on acknowledgements. Instead, endpoints observe the side effect of acknowledgments: bytes drained from the send buffer, opening up space to send more.
• Activity on the underlying transport - such as acknowledgments, TCP keepalives, or TLS key updates - does not reset the idle timer.
• QMux endpoints do not increase their idle timeouts relative to the current Probe Timeout (PTO).

While idle, a QMux connection may also be disrupted by inactivity timers outside of QMux; e.g., a Network Address Translator that discards its mapping. QX_PING frames can be used to elicit a peer response, which could keep inactivity timers at lower transport layers and intermediaries from causing premature connection termination.

Initiating a Connection Close When the idle timeout expires, an endpoint gracefully shuts down its sending side of the underlying transport. The endpoint does not send any QMux frames, though it might send messages at lower layers, such as a TLS close_notify alert. Separately, as in QUIC version 1, an endpoint can initiate closing of a QMux connection by sending a CONNECTION_CLOSE frame and then gracefully shutting down its sending side of the underlying transport. In either case, after shutting down the sending side, the endpoint SHOULD wait for the peer to gracefully shut down the peer's sending side. The use of graceful shutdown mitigates the risk of undelivered records and frames becoming lost due to abrupt termination of the underlying transport. While waiting for the peer to gracefully shut down, QMux endpoints SHOULD discard any data they receive without processing it, similarly to QUIC version 1 endpoints discarding packets received during the draining period ().

Responding to a Connection Close When receiving a CONNECTION_CLOSE frame or observing the peer shut down the peer's sending side, the receiving endpoint SHOULD gracefully shut down its sending side, either without sending any frames or after sending a single CONNECTION_CLOSE frame.

Handling Resets When the underlying transport becomes unavailable (e.g., due to a TCP reset or a TLS fatal alert), the QMux connection is terminated immediately.

Using TLS When QMux is used over TLS, TLS provides capabilities in addition to confidentiality and integrity protection.

Protocol Negotiation As in QUIC , when running an application protocol over QMux over TLS, endpoints MUST use ALPN to agree on an application protocol, unless another mechanism is used for agreeing on an application protocol. ALPN protocol identifiers identify the application protocol in use. Application protocols that use QMux over TLS MUST designate their ALPN identifier and specify that they use QMux version 1. The identifier for a mapping to QMux MUST be different from the mapping of the same protocol to QUIC, to retain compatibility with Service Binding and Parameter Specification via the DNS . When using ALPN, endpoints MUST abort the TLS handshake with a no_application_protocol TLS alert () if an application protocol is not negotiated. While ALPN only requires that servers use this alert, QMux clients MUST also abort the handshake when ALPN negotiation fails. QMux is not itself an application protocol and does not have an ALPN identifier. TO BE REMOVED BEFORE PUBLICATION: During the development of QMux, its wire format might change. Therefore, when testing interoperability of application protocols using a draft version of QMux, applications should specify, for each ALPN identifier they define, which draft version of QMux is used. As an example, an ALPN identifier "myapp-12qx" could identify version 12 of "myapp" over TCP and QMux, identifying the use of a specific QMux draft version in its specification. the use of QMux draft-05.

Using 0-RTT TLS 1.3 introduced the concept of early data (also known as 0-RTT data). When using QMux over TLS that supports early data, clients MAY use early data when resuming a connection, by reusing certain transport parameters as defined in . Similarly, when accepting early data, servers MUST send transport parameters that comply with the restrictions in . This preserves QUIC's 0-RTT compatibility model and avoids requiring an additional round trip to learn peer transport parameters on resumed connections.

Extensions Not all the extensions of QUIC version 1 can be used. Each extension have to define its mapping for QMux, or explicitly allow the use; see . As is the case with QUIC version 1, use of extension frames have to be negotiated before use; see . This specification defines the mapping of the following extensions.

Unreliable Datagram Extension The use of the Unreliable Datagram Extension is permitted. The encoding and semantics of the Unreliable Datagram Extension remain unchanged, and the use of the extension is negotiated via transport parameters. As discussed in , senders can drop DATAGRAM frames if the transport is blocked by flow or congestion control. The largest DATAGRAM frame an endpoint can send is constrained by two limits. First, as in QUIC version 1, it is bounded by the peer's max_datagram_frame_size transport parameter. Second, it is bounded by the size of the container that carries the frame: in QUIC version 1 that container is the packet (), whereas in QMux it is the QMux Record, so the bound is the peer's max_record_size transport parameter (). Where recommends advertising a max_datagram_frame_size of 65535 to accept any DATAGRAM frame that fits within a packet, the corresponding limit in QMux is max_record_size. Because these limits apply to the entire DATAGRAM frame rather than to its payload, the usable datagram payload is smaller than max_record_size. It excludes the frame's Type field, Length field when present, and any bytes used by other frames sharing the record. For example, with the default max_record_size of 16382, a DATAGRAM frame that is the only frame in a record and omits its Length field (using the record boundary as the end of the datagram, see ) can carry a payload of up to 16381 bytes: the maximum record size of 16382, reduced by the one-byte frame Type.

Stream Resets with Partial Delivery Extension The use of the Stream Resets with Partial Delivery Extension is permitted. The encoding and semantics of the RESET_STREAM_AT frame remain unchanged, and the use of the extension is negotiated via transport parameters. Because QMux runs on a reliable transport, all stream data is delivered to the receiving stack before the RESET_STREAM_AT frame. The Reliable Size indicates how much of that data the stack needs to deliver to the application before signaling the reset.

Version Agility As new versions of QUIC are specified, there may be a desire to define their reliable-byte-stream counterparts as different versions of QMux, and to provide ways of negotiating the version to be used. QUIC establishes connections using packets carrying an explicit version number. Using that field, Version-Independent Properties of QUIC defines a version negotiation mechanism that involves a retry. Compatible Version Negotiation for QUIC defines another negotiation mechanism for switching between compatible versions during connection establishment without retrying. By contrast, QMux does not establish connections by itself; the connections are set up by the underlying substrate, and QMux exchanges only the transport parameters after they are established. Due to these differences, the negotiation mechanisms used by QUIC and QMux will differ. This section explores some options that future versions of QMux might employ for version negotiation and upgrade.

Negotiation Using ALPN When a new QUIC version that provides a different interface to applications is specified, application protocols developed for that version might be assigned a new identifier for the TLS Application-Layer Protocol Negotiation (ALPN) extension . Similarly, when TLS is the underlying transport, application protocols built on top of the QMux counterparts of such QUIC versions can rely on ALPN to negotiate both the application protocol and the underlying QMux version (). When TLS is not the underlying transport, endpoints can use the first 8 bytes exchanged on the transport (i.e., the type field of the QX_TRANSPORT_PARAMETERS frame in the encoded form) to identify whether QMux is in use. [TODO: discuss how endpoints should behave when the first 8 bytes received are not QX_TRANSPORT_PARAMETERS.]

In-band Upgrade A new version of QMux might first start communication using QMux version 1 and then switch versions in-band during the session. The advantage of this approach is that, even when TLS is not in use, no additional round-trip is incurred for version negotiation. While QMux version 1 does not specify a concrete method, new versions might use the version_information transport parameter () to discover supported versions and coordinate the switch.

Implementation Considerations Similar to HTTP/3 with Extensible Priorities , application protocols using QUIC may employ stream multiplexing along with a system to tune the delivery sequence of QUIC streams. To alternate between QUIC streams of varying priorities in a timely manner, it is advisable for QMux implementations to avoid creating deep buffers holding QUIC frames. Instead, endpoints should wait for the transport layer to be ready for writing. Upon becoming writable, they should write QUIC frames according to the latest prioritization signals. Additionally, implementations may consider monitoring or adjusting the flow and congestion control parameters of the underlying transport. This approach aims to minimize data buffering within the transport layer before transmission. However, improper adjustment of these parameters could potentially lead to lower throughput.

Security Considerations QMux inherits many of the security properties and considerations laid out in . This section describes considerations specific to QMux.

Forward Progress Failure to follow the forward-progress requirements in can lead to deadlock and can be exploited for resource-exhaustion attacks.

Denial of Service As in QUIC (), valid QMux frames can be used to keep a connection alive, to consume processing resources disproportionate to useful progress, or to force an endpoint to generate responses. For example, sending large numbers of small records, PADDING frames, tiny flow control increments, or QX_PING frames can be used for such purposes. Implementations SHOULD monitor for such traffic patterns and MAY treat suspicious activity as a connection error. Unlike QUIC, where each packet is a self-contained unit, QMux records can arrive incrementally over the underlying byte stream. Implementations need to consider resources they might use to hold partially received records. Unlike QUIC, QMux does not provide protection against premature connection termination by unauthenticated on-path entities. An intermediary that can disrupt the underlying transport will be able to successfully terminate connections; see .

IANA Considerations This document defines new frame types and a transport parameter for use with QUIC. IANA is requested to register the following values in the registries under https://www.iana.org/assignments/quic. The codepoints listed below, unless otherwise stated, were selected using the deterministic method described at https://martinthomson.github.io/quic-pick/, with seeds of the form draft-ietf-quic-qmux-NN_<fieldtype>. Upon publication as an RFC, IANA is requested to replace provisional codepoints with permanent assignments from the standards-action range.

QUIC Frame Types The following entries should be added to the "QUIC Frame Types" registry.

Value	Frame Type Name	Status	Specification
0x3f5153300d0a0d0a	QX_TRANSPORT_PARAMETERS	provisional
0x348c67529ef8c7bd - 0x348c67529ef8c7be	QX_PING	provisional

The value 0x3f5153300d0a0d0a for QX_TRANSPORT_PARAMETERS was chosen deliberately to function as a protocol magic number see ().

QUIC Transport Parameters The following entry should be added to the "QUIC Transport Parameters" registry.

Value	Parameter Name	Status	Specification
0x0571c59429cd0845	max_record_size	provisional

References Normative References This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. 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. 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 describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection. Fastly QUIC defines a RESET_STREAM frame to abort sending on a stream. When a sender resets a stream, it also stops retransmitting STREAM frames for this stream in the event of packet loss. On the receiving side, there is no guarantee that any data sent on that stream is delivered. This document defines a new QUIC frame, the RESET_STREAM_AT frame, that allows resetting a stream, while guaranteeing delivery of stream data up to a certain byte offset. Informative References This document describes how Transport Layer Security (TLS) is used to secure QUIC. This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168. 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. This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFCs 7540 and 8740. Mozilla Cloudflare A variant mechanism for managing stream limits is described for HTTP/2. This scheme is based on that used in QUIC and is more robust against certain patterns of abuse. Facebook Apple Inc. Google WebTransport [OVERVIEW] is a protocol framework that enables application clients constrained by the Web security model to communicate with a remote application server using a secure multiplexed transport. This document describes a WebTransport protocol that is based on HTTP/3 [HTTP3] and provides support for unidirectional streams, bidirectional streams, and datagrams, all multiplexed within the same HTTP/3 connection. Facebook Inc. Apple Inc. Apple Inc. Mozilla Google Facebook Inc. WebTransport defines a set of low-level communications features designed for client-server interactions that are initiated by Web clients. This document describes a protocol that can provide many of the capabilities of WebTransport over HTTP/2. This protocol enables the use of WebTransport when a UDP-based protocol is not available. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns. This document obsoletes portions of RFC 7230. This document clarifies and updates several requirements of RFCs 4787, 5382, and 5508 based on operational and development experience. The focus of this document is Network Address Translation from IPv4 to IPv4 (NAT44). This document updates RFCs 4787, 5382, and 5508. This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. This document defines the properties of the QUIC transport protocol that are common to all versions of the protocol. QUIC does not provide a complete version negotiation mechanism but instead only provides a way for the server to indicate that the version the client chose is unacceptable. This document describes a version negotiation mechanism that allows a client and server to select a mutually supported version. Optionally, if the client's chosen version and the negotiated version share a compatible first flight format, the negotiation can take place without incurring an extra round trip. This document updates RFC 8999. This document describes a scheme that allows an HTTP client to communicate its preferences for how the upstream server prioritizes responses to its requests, and also allows a server to hint to a downstream intermediary how its responses should be prioritized when they are forwarded. This document defines the Priority header field for communicating the initial priority in an HTTP version-independent manner, as well as HTTP/2 and HTTP/3 frames for reprioritizing responses. These share a common format structure that is designed to provide future extensibility.

Acknowledgments TODO acknowledge.

Change Log

• Note to the RFC Editor / Editors: Delete this section before publication.

Since draft-ietf-quic-qmux-01

• max_record_size reframed with a default value; QMux-only, ignored by QUIC version 1 (#50, #54).
• QX_TRANSPORT_PARAMETERS frame misuse signaled with PROTOCOL_VIOLATION (#51).
• QX_PING Sequence Numbers now strictly increasing; invalid values defined (#52).
• Transport parameters follow RFC 9000 unless explicitly overridden (#53, #56).
• Expanded connection termination and CONNECTION_CLOSE handling (#57).
• Allowed use of the RESET_STREAM_AT frame (#58).
• Documented downsides compared to QUIC version 1 (#61).
• Clarified effective DATAGRAM frame size (#62).
• Explained why initial flow-control transport parameters are retained (#63).
• Explained why most QUIC version 1 frame formats are unchanged (#64).

Since draft-ietf-quic-qmux-00

• Frames are implicitly acknowledged by the underlying transport (#23).
• Adopted length-delimited QMux Records (#26).
• Added forward-progress requirements for flow control (#27).
• Clarified transport parameter timing and 0-RTT text (#28).
• Endpoints MUST use ALPN for application-protocol negotiation (#33).
• Renamed max_frame_size to max_record_size and updated codepoints (#38).
• QX_TRANSPORT_PARAMETERS is sent once, only as the first frame (#44).