]> Fastly

kazuhooku@gmail.com

Cloudflare

lucas@lucaspardue.com

Netflix

jri.ietf@gmail.com

Apple

ekinnear@apple.com

QUIC internet-draft This document specifies a polyfill of QUIC version 1 that runs on top of bi-directional streams such as TLS. 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 .

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 . QUIC frames are sent directly on top of the transport. The frames are not encrypted. It is the task of the transport (e.g., TLS) to provide confidentially 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.

Confidentially and Integrity:

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

TLS over TCP provides all these capabilities. UNIX sockets are an example that provides only the first two. 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.

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 . Use of other frames defined in QUIC version 1 is prohibited for various reasons. ACK frames are not used because the underlying transport guarantees delivery. 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. 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.

STREAM Frames While the frame format remains unchanged, there are two differences in the handling of STREAM frames between QUIC version 1 and QMux.

STREAM Frames without the Length Field In QMux, when a STREAM frame that omits the Length field is used, the size of that STREAM frame is determined by the maximum frame size, as regulated by the max_frame_size Transport Parameter (). This behavior contrasts with that of QUIC version 1, where the absence of the Length field implies that the STREAM frame extends to the end of the QUIC packet payload. This variation arises due to the characteristics of the underlying transports of QMux, which may not have, or provide visibility into, the packet boundaries.

Ordering of STREAM frames For each stream being sent, senders MUST send stream payload in order. 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 connection with an error of type PROTOCOL_VIOLATION_ERROR. This change from QUIC version 1 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. 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. Endpoints MUST send the QX_TRANSPORT_PARAMETERS frame as soon as the underlying transport becomes available. Note 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 (). If the first frame being received by an endpoint is not a QX_TRANSPORT_PARAMETERS frame, the endpoint MUST close the connection with an error of type TRANSPORT_PARAMETER_ERROR. 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 0xTBD is used for sending a ping (i.e., request the peer to respond). Type 0xTBD+1 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 0xTBD, endpoints MUST send monotonically 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 0xTBD+1 in response, endpoints MUST echo the Sequence Number that they received. When receiving multiple QX_PING frames of type 0xTBD before having the chance to respond, an endpoint MAY only respond with one QX_PING frame of type 0xTBD+1 carrying the largest Sequence Number that the endpoint has received.

Transport Parameters QMux uses a subset of Transport Parameters defined in QUIC version 1. Also, one new Transport Parameter specific to QMux is defined.

Permitted and Forbidden Transport Parameters In QMux, 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 definition of these Transport Parameters are unchanged. Use of other Transport Parameters defined in QUIC version 1 is prohibited. When an endpoint receives one of the prohibited Transport Parameters, the endpoint MUST close the connection with an error of type TRANSPORT_PARAMETER_ERROR. Endpoints MUST NOT send Transport Parameters that extend QUIC version 1, unless they are specified to be compatible with QMux. When receiving Transport Parameters not defined in QUIC version 1, receivers MUST ignore them unless they are specified to be usable on QMux.

max_frame_size Transport Parameter The max_frame_size Transport Parameter (0xTBD) is a variable-length integer specifying the maximum size of the QUIC frame that the peer can send, in the unit of bytes. The initial value of the max_frame_size Transport Parameter is 16384. By sending the Transport Parameter, the maximum frame size can only be increased. When receiving a value below the initial value, receivers MUST close the connection with an error of type TRANSPORT_PARAMETER_ERROR. Endpoints MUST NOT send QUIC frames that exceed the maximum declared by the peer. When receiving QUIC frames that exceed the declared maximum, receivers MUST close the connection with an error of type FRAME_ENCODING_ERROR.

Closing the Connection As is with QUIC version 1, a connection can be closed either by a CONNECTION_CLOSE frame or by an idle timeout. Unlike QUIC version 1, there is no draining period; once an endpoint sends or receives the CONNECTION_CLOSE frame or reaches the idle timeout, all the resources allocated for the Service are freed and the underlying transport is closed immediately.

Using 0-RTT TLS 1.3 introduced the concept of early data (also knows as 0-RTT data). When using QMux on top of 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, the servers MUST send Transport Parameters that obey to the restrictions defined in .

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 Unreliable Datagram Extension.

Unreliable Datagram Extension The use of the Unreliable Datagram Extension is permitted, with one modification: Similar to STREAM frames, when employing DATAGRAM frames of type 0x30 (i.e., DATAGRAM frames without the Length field), their size is determined by the max_frame_size Transport Parameter (). Apart from this, the encoding and semantics of the Unreliable Datagram Extension remain unchanged. The use of the extension is negotiated via the Transport Parameters. As discussed in , senders can drop DATAGRAM frames if the transport is blocked by flow or congestion control.

Version Agility Unlike QUIC, QMux does not define a mechanism for version negotiation. In large-scale deployments requiring service and protocol version discovery, QMux can and is likely to be implemented over TLS. The Application-Layer Protocol Negotiation Extension of TLS is the favored mechanism to negotiate between an application protocol based on this specification and others. When ALPN is unavailable, first 8 bytes exchanged on the transport (i.e., the type field of the QX_TRANSPORT_PARAMETERS frame in the encoded form) can be used to identify if QMux is in use.

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 TODO Security

IANA Considerations TODO

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 defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection. Informative References 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 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 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.