]> Mozilla

mt@lowentropy.net

Apple Inc.

ekinnear@apple.com

Applications and Real-Time WebTransport next generation unicorn sparkling distributed ledger Limits to how a WebTransport session uses QUIC resources like streams or data can help reduce the effect that one WebTransport session has on other uses of the same HTTP/3 connection. This describes mechanisms for limiting the number of streams and quantity of data that can be consumed by each WebTransport session. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the WebTransport Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction WebTransport in HTTP/3 provides applications with all the functionality of QUIC streams. In the case where a single connection includes a WebTransport session that needs to coexist with other WebTransport sessions or HTTP requests, the core draft does not offer any way to place limits on stream usage. This document describes an additional layer of session-level flow control that governs the creation of streams and sets a session-level limit on the amount of data that can be exchanged in a session. This document does not define a framework for prioritizing the streams created for a WebTransport session with other streams. Note that this document is intended as input for . Although it is possible to define this as an extension to that protocol, integration of this design is simpler; see .

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.

Protocol Definition This document uses the following flow control capsules defined in :

• WT_MAX_DATA ()
• WT_MAX_STREAMS ()
• WT_DATA_BLOCKED ()
• WT_STREAMS_BLOCKED ()

These capsules are unchanged, except that where the WebTransport over HTTP/2 capsules refer to streams that flow over the HTTP/2 stream containing the entire WebTransport session, these capsules refer to separate limits as described in subsequent sections. These capsules use the codepoints allocated in .

Stream Limits The WT_MAX_STREAMS capsule establishes a limit on the number of streams within a WebTransport session. Like the QUIC MAX_STREAMS frame (), this capsule has two types that provide separate limits for unidirectional and bidirectional streams that are initiated by a peer. The session-level stream limit applies in addition to the QUIC MAX_STREAMS frame, which provides a connection-level stream limit. New streams can only be created within the session if both the stream- and the connection-level limit permit; see for details on how QUIC stream limits are applied. Unlike the WT_MAX_STREAMS capsule or the QUIC MAX_STREAMS frame, there is no simple relationship between the value in this frame and stream IDs in QUIC STREAM frames. This especially applies if there are other users of streams on the connection. The WT_STREAMS_BLOCKED capsule is sent to indicate that an endpoint was unable to create a stream due to the session-level stream limit.

Data Limits The WT_MAX_DATA capsule establishes a limit on the amount of data that can be sent within a WebTransport session. This limit counts all data that is sent on streams of the corresponding type, excluding the stream header (see Sections and of ). The stream header is excluded from this limit so that this limit does not prevent the sending of information that is essential in linking new streams to a specific WebTransport session. Implementing WT_MAX_DATA requires that the QUIC stack provide the WebTransport implementation with information about the final size of streams; see . The WT_DATA_BLOCKED capsule is sent to indicate that an endpoint was unable to send data due to a limit set by the WT_MAX_DATA capsule. Because WebTransport over HTTP/3 uses a native QUIC stream for each WebTransport stream, per-stream data limits are provided by QUIC natively. The WT_MAX_STREAM_DATA and WT_STREAM_DATA_BLOCKED capsules are not used and so are prohibited. Endpoints MUST treat receipt of a WT_MAX_STREAM_DATA or a WT_STREAM_DATA_BLOCKED capsule as a session error.

Negotiation If the use of flow control capsules are merged into the main specification , their use will be negotiated along with the use of WebTransport over HTTP/3. This is the simplest approach. Alternatively, if this remains as an optional extension, new HTTP/3 settings will be needed to negotiate the use of these features. In the abstract, we could define settings that carry initial values for the three variables that are controlled by the session-level flow control capsules defined here. The presence of any of those settings would indicate that these limits will be respected if the capsule is sent. Both peers need to indicate the setting before these capsules apply. If only one peer advertises any of these settings, that might indicate that they are willing to receive and respect session-level flow control capsules. However, such an endpoint cannot know when to start applying the limit.

Security Considerations Aside from new exposure to the usual programming errors arising from increased protocol complexity, it is believed that the introduction of these capabilities only improves security as it provides better control over endpoint resource allocation.

IANA Considerations This document has no IANA actions.

Normative References Facebook Apple Inc. Google WebTransport [OVERVIEW] is a protocol framework that enables clients constrained by the Web security model to communicate with a remote 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. 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. 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.

Acknowledgments TODO acknowledge.