[Webtransport] Choosing the Transport

[Victor Vasiliev <[e-mail]>]

Hello everyone,

We recently adopted the overview draft
<https://tools.ietf.org/html/draft-ietf-webtrans-overview-00> that
describes the general requirements for and the model of WebTransport.
However, we haven't yet adopted any specific wire protocol proposals.
There are currently three of those presented to the working group:

   - QuicTransport
   <https://tools.ietf.org/html/draft-vvv-webtransport-quic-02>
   - Http2Transport
   <https://tools.ietf.org/html/draft-kinnear-webtransport-http2-01>
   - Http3Transport
   <https://tools.ietf.org/html/draft-vvv-webtransport-http3-02>
   - [hypothetical WebTransport over WebSocket]

Back when the original idea of WebTransport was forming, the hope was to
implement and ship all four of those, since they all fit different use
cases better.  After talking more to the people at IETF, it sounds like
four transports is a bit too much, and we should settle on two (one over
QUIC, and one over TCP).  The natural picks would be either Http3Transport
with Http2Transport as fallback (HttpTransport for short), or QuicTransport
with… *something* as a fallback.  Let’s look at the differences between
those two options.

*Differences*

The most substantial wire format difference between those two proposals is
the handshake.  QuicTransport originally did not have any handshake; we had
to add a bespoke handshake later in order to implement the Origin header,
and we also added a Path header later on.  We currently don’t have any form
of response headers, so if the server is unhappy with the origin or path
received, it has to close the connection with CONNECTION_CLOSE.  In
HttpTransport, we have regular HTTP header fields for both request and
response, meaning that the server can do things like return a 4xx/5xx for
an error.

During the connection itself, the difference is minimal: QuicTransport uses
streams and datagrams as-is, while Http3Transport prefixes everything with
an ID, since it is multiplexed with other HTTP traffic.  There might be a
question of whether prefixing can impose undesirable framing overhead; I
think if that ever becomes a serious problem, we can come up with some
extension to work this around.

If we decide that QuicTransport is a way to go, we’d have to add more
features into its handshake, since I suspect most people won’t be happy
with what’s in there right now (HTTP headers like Location or Forwarded
would be a good example of what people would end up needing in practice,
together with an ability to tag along arbitrary key-value metadata for
debugging purposes).  If we decide that HttpTransport is a way to go, we
would have to ensure that the result is easy for Web developers to use, and
that we understand the differences between it and regular HTTP.

>From the server complexity standpoint, I am not particularly worried about
either.  We’ve implemented QuicTransport in Chrome, and I wrote two servers
for it, in C++ and in Python; the Python one took about 100 lines of code.
Http2Transport has been implemented, in somewhat different forms, by both
Apple and Facebook, so we have practical experience with it too.  I was
previously concerned that having to implement HPACK/QPACK would be a burden
to the Web developers since those are more complex than what you’d
typically find in a WebSocket implementation, but now that we have a draft
to turn compression off
<https://tools.ietf.org/html/draft-vvv-httpbis-alps-00>, I’m less worried
about this.

There is a question of how much of the HTTP ecosystem we would be actually
getting by adopting HTTP.  It is true that basing WebTransport on HTTP does
not mean HTTP middleware would automatically implement it.  That said, we
do get a lot of useful features from HTTP, notably message routing and a
well-understood metadata format.  Everyone knows what a code 200 or 404 is,
and a lot of people have built their internal debugging/tracing tools based
on adding HTTP headers to things, and being able to easily port those to
WebTransport would be an asset.  I’ve seen some arguments that content
negotiation and caching might be applicable to certain classes of
WebTransport resources too (e.g. a live stream can be cached in the sense
that requesting a live stream is joining it), though those kinds of cases
would have to be content-specific and they do not generalize as nicely as
caching for regular HTTP resources.  An interesting point to note is that
WebTransport is always included programmatically (as opposed to being
navigated to or sourced via URL from HTML), thus alleviating the need for a
lot of otherwise useful HTTP headers.

*Questions*

While on the surface the question here is “which drafts should we adopt?”,
I would like to break this question down into two layers:

   1. Do we want to use the wire format in which we try to build minimally
   on top of QUIC (QuicTransport), or do we base it on HTTP?
   2. To what extent WebTransport connections act like HTTP connections?
   Do they have https URLs or a dedicated schema?  Which HTTP headers do and
   don’t work?


Regarding the first issue, I am increasingly leaning towards keeping only
the HTTP-based option. QuicTransport’s most appealing feature is its
simplicity; however, ever since we’ve had to add a header to communicate
the Web origin, there has been increasingly more and more reasons to add
new features to it, so even if we go that way, we’re probably going to end
up with something that’s a lot like HTTP.  Also, we know exactly how to do
TCP fallback in this case, so this removes a lot of design problems from
consideration.  Fixing complexity and other problems with HTTP is probably
more viable.

Regarding the second issue, I am not sure how much of it is in scope for
this working group.  While we do need to define a URL schema, and the
choice of schema will give us a lot of answer (by making WebTransport same
or different origin as HTTP), a lot of those questions have been
traditionally answered somewhere in Fetch spec, or simply not addressed in
the standards at all.  I am not quite sure what to do with those.

What do people think?