| Internet-Draft | WebTransport over QUIC over HTTP | July 2021 |
| Thomson | Expires 13 January 2022 | [Page] |
The WebTransport API provides an interface to HTTP resources that provides transport-layer capabilities. This document describes how a subset of the QUIC protocol can be used to provide these transport capabilities.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the WebTransport Working Group mailing list (webtransport@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/webtransport/.¶
Source for this draft and an issue tracker can be found at https://github.com/martinthomson/webtransport-hwtq.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 13 January 2022.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
This document is input to discussion of the design of [WTH2] and -- to a lesser extent -- [WTH3]. The author has no intent of pursuing publication of this document, it exists only to provide a more complete exploration of an alternative design.¶
This document describes a means of providing a WebTransport-capable mapping to any HTTP version, with a specific goal of providing a TCP-based design that fulfills all of the basic WebTransport requirements.¶
The proposed design transplants the design of QUIC streams [QUIC] almost directly, saving specification effort. This might also save implementation and validation effort through reuse.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The WebTransport API depends on three basic functions: bidirectional and unidirectional streams, plus datagrams. When using a QUIC transport, using native QUIC support for these capabilities ([QUIC], [QD]) provides the best performance. However, the need to provide a TCP-based protocol means finding a protocol that works with -- at a minimum -- HTTP/2.¶
This document proposes that an extended CONNECT [EXT-CONNECT] be used to establish a new connection using a new protocol identifier (with an identifier to be decided). Using CONNECT results in a bidirectional communications medium with stream characteristics between client and server.¶
Once established, this document proposes using a subset of QUIC frames to carry the control messages, stream data, and datagrams. The following frames would be permitted:¶
This set of frames is sufficient to carry data for streams of the necessary types. It also provides a complete set of resource management functions that operate within the scope of the bidirectional WebTransport communication.¶
This would use a subset of the stream states in [QUIC]. This ensures that the API is able to present a very similar interface to streams as that provided in QUIC. Implementations might be simplified slightly as some state transitions are not possible in a context where ordered delivery can be guaranteed.¶
Endpoints MUST NOT send stream data that is not contiguous or out of order. The underlying transport provides reliable, ordered delivery. Implementations will still need to buffer stream data, but the implementation of that buffering does not need to handle gaps in incoming flow.¶
It is not clear whether "connection"-level flow control (the QUIC MAX_DATA frame) is necessary in the context of this integration. TCP or HTTP/2 flow control mechanisms already exist to control the flow of information on the request and response, which makes the control redundant in some circumstances. The inclusion is justified by the potential for DATAGRAM frames and other control frames to be exchanged independent of this limit.¶
A connection close signal at the level of the WebTransport is possible. The QUIC application CONNECTION_CLOSE (0x1d) might be used for this purpose.¶
The main claim made here is that this design is comparatively simpler than the design in [WTH2]. However, there are other consequences that are worth consideration. This section attempts to document these more fully.¶
The QUIC binding in [WTH3] is complicated by the need to manage the total number of WebTransport sessions on the one connection. Furthermore, the use of shared resources at the level of the connection (streams especially) means that it is necessary to carefully manage the commitment of resources to a¶
[WTH2] has similar constraints on operation. This proposal avoids using a shared resource for its functions, avoiding that problem. The cost is that sessions are exposed to additional head-of-line blocking performance costs. As the goal of the protocol is to support TCP-based HTTP versions, the marginal impact of head-of-line blocking is expected to be minimal.¶
[WTH2] describes a design that integrates with the HTTP/2 stream state machine. This is challenging as it results in the details of the HTTP/2 stream state machine being visible in the API. In particular, the closing of send and receive parts of HTTP/2 streams are coupled, where they are independent in QUIC.¶
As a protocol extension, this difference could be addressed with adjustments to the state machine, but this results in the implementation of an entirely new state management logic, which increases implementation complexity.¶
The other way to resolve this discrepancy is to require the same sort of close-state coupling when QUIC is used so that behavior is consistent across different protocol versions.¶
Though not a hard requirement of the design, the ability to support HTTP/1.1 is an advantage of this design.¶
It is also possible to use this design with HTTP/3, albeit with worse performance characteristics than the more complete design of [WTH3]. This is offered merely as an observation.¶
This proposal adds an additional layer of framing, which increases overheads in HTTP/2. This is less efficient in terms of overheads than native use of HTTP/2 layer constructs. This is partially mitigated by the relatively good efficiency of QUIC framing and the potential to send larger frames with the HTTP/2 stream. The QUIC-derived frames this uses do not need to be limited in size in the same way as those at the HTTP/2 layer.¶
There is a small bit of redundancy in the RESET_STREAM frame. With a reliable substrate, there is no need to signal the number of bytes that were consumed by the stream in a RESET_STREAM frame. This field could be safely removed, if reuse of the QUIC encodings was deemed to be unimportant.¶
In the current design, endpoints are required to provide an accurate value for the Final Size field of RESET_STREAM frames they send and to validate the value they received.¶
Relatively few of the security considerations of QUIC apply, though a small few are relevant, such as Section 21.6 of [QUIC].¶
This document has no IANA actions. Currently. It might be necessary to work out how the framing layer might be extended in a way that can avoid collisions between frames used in QUIC and this design. A few options seem plausible:¶
Alan Frindell probably doesn't like this proposal all that much, but he at a minimum deserves some credit for it being written down.¶