Generic HTTP Binding for WebTransport using QUIC

Document Type Active Internet-Draft (individual)
Author Martin Thomson 
Last updated 2021-07-11
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
WEBTRANS                                                      M. Thomson
Internet-Draft                                                   Mozilla
Intended status: Informational                              12 July 2021
Expires: 13 January 2022

            Generic HTTP Binding for WebTransport using QUIC


   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

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the WebTransport Working
   Group mailing list (, which is archived at

   Source for this draft and an issue tracker can be found at

Status of This Memo

   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

   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 Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Thomson                  Expires 13 January 2022                [Page 1]
Internet-Draft      WebTransport over QUIC over HTTP           July 2021

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (
   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Open Design Questions . . . . . . . . . . . . . . . . . .   4
   4.  Comparison to an HTTP/2-Only Design . . . . . . . . . . . . .   4
     4.1.  Session Control and Resource Management . . . . . . . . .   4
     4.2.  Stream States . . . . . . . . . . . . . . . . . . . . . .   5
     4.3.  HTTP/1.1  . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.4.  Additional Framing  . . . . . . . . . . . . . . . . . . .   5
     4.5.  RESET_STREAM Redundancies . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   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

   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.

Thomson                  Expires 13 January 2022                [Page 2]
Internet-Draft      WebTransport over QUIC over HTTP           July 2021

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "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.

3.  Overview

   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:




   *  STREAM (with the 0x02 bit set only)

   *  MAX_DATA






   *  DATAGRAM (0x31 only; from [QD])

Thomson                  Expires 13 January 2022                [Page 3]
Internet-Draft      WebTransport over QUIC over HTTP           July 2021

   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.

3.1.  Open Design Questions

   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.

4.  Comparison to an HTTP/2-Only Design

   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.

4.1.  Session Control and Resource Management

   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

Thomson                  Expires 13 January 2022                [Page 4]
Internet-Draft      WebTransport over QUIC over HTTP           July 2021

   [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.

4.2.  Stream States

   [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.

4.3.  HTTP/1.1

   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.

4.4.  Additional Framing

   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.

Thomson                  Expires 13 January 2022                [Page 5]
Internet-Draft      WebTransport over QUIC over HTTP           July 2021

4.5.  RESET_STREAM Redundancies

   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.

5.  Security Considerations

   Relatively few of the security considerations of QUIC apply, though a
   small few are relevant, such as Section 21.6 of [QUIC].

6.  IANA Considerations

   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:

   *  Register WebTransport extensions in the QUIC registry.  After all,
      there is tons of space over there.  The main cost there is
      recording what context each frame type applies to.

   *  Make a clone of the registry for WebTransport that only contains
      WebTransport frames.  This is relatively simple, but might result
      in collisions as both protocols independently evolve.

   *  Forego extensibility, at least in the short term, and require a
      revision or update to the protocol to define new frames or to add
      the use of a registry.

7.  Normative References

              McManus, P., "Bootstrapping WebSockets with HTTP/2",
              RFC 8441, DOI 10.17487/RFC8441, September 2018,

   [QD]       Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable
              Datagram Extension to QUIC", Work in Progress, Internet-
              Draft, draft-ietf-quic-datagram-02, 16 February 2021,

Thomson                  Expires 13 January 2022                [Page 6]
Internet-Draft      WebTransport over QUIC over HTTP           July 2021

   [QUIC]     Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <>.

   [WTH2]     Frindell, A., Kinnear, E., Pauly, T., Vasiliev, V., and G.
              Xie, "WebTransport using HTTP/2", Work in Progress,
              Internet-Draft, draft-ietf-webtrans-http2-00, 3 July 2021,

   [WTH3]     Vasiliev, V., "WebTransport over HTTP/3", Work in
              Progress, Internet-Draft, draft-ietf-webtrans-http3-01, 19
              May 2021, <


   Alan Frindell probably doesn't like this proposal all that much, but
   he at a minimum deserves some credit for it being written down.

Author's Address

   Martin Thomson


Thomson                  Expires 13 January 2022                [Page 7]