[Webtransport] QuicTransport vs Http3Transport

[Luke Curley <[e-mail]>]

Hey folks, I'm Luke and I'm a tech lead at Twitch/Amazon. Apologies for
creating a new thread... I have no idea how to reply to an existing thread
after recently subscribing.

I'm not able to delve into specifics until it's announced/released in a few
months, but I've been working on a new technology that leverages
QuicTransport in a big way. I'm now in a position to be proactive about
standards and we may even release and attempt to standardize what I've been
working on!


I do agree that standardizing and implementing all of the transports is
excessive. It's good to accommodate future transports, but we don't want a
fragmented standard either.


*Http2Transport*
Let's start with the easy one. Http2Transport is not an option for
Twitch as we're using QUIC to avoid head-of-line blocking (just like
HTTP/3). There's very few reasons to use Http2Transport when compared to
WebSockets, so it's difficult to justify it as a new standard.


*QuicTransport *
My favorite part of the HTTP/3 specification is that QUIC is a stand-alone
network protocol. QUIC is astonishingly better than TCP+TLS when an
application or protocol is designed around the relatively simple API. I
absolutely believe that QUIC will gain widespread usage outside of HTTP/3
and I'm already doing my part. If that's the case, then exposing the QUIC
API via QuicTransport will enable developers to leverage QUIC-based
protocols in a web environment.

I agree that the path/origin handshake is primarily designed for HTTP, but
alone it's not a compelling reason to pull in the entire HTTP/3 stack.
Also, an origin mismatch should return a custom "wrong origin" error code
when closing the connection. I would possibly even put the path/origin into
the TLS transport parameters, so the connection can be rejected early and
the application no longer has to buffer waiting to process the handshake
stream.

The other issue mentioned is not being able to support multiple
QuicTransport sessions on a single connection. Connection reuse was
definitely a problem with TCP, as you needed multiple connections to avoid
head-of-line blocking and it took 3/4 RTTs for each connection (depending
on the TLS version). However with QUIC, there's really no excuse to make a
new HTTP/3 or QuicTransport connection (requests/streams are multiplexed)
and even then, it only takes 0/1 RTTs to establish a new connection.


*Http3Transport*
I think it's cool that Http3Transport follows in the successful footsteps
of WebSockets. The ability to downgrade a HTTP/1.1 connection to TCP is
very clever and relatively simple to implement. However, WebSockets became
more convoluted with HTTP/2's multiplexing and have still not yet been
implemented. WebTransport is even more complicated due to the additional
support of unidirectional streams and datagrams. It's no longer a
"downgrade" like HTTP/1.1 to WebSocket but a complex mapping from HTTP/3 to
QUIC.

And ironically, the issues I see with Http3Transport are primarily due to
supporting multiple protocols and sessions on a single connection. Here's a
few quick concerns I have after reading the RFC:

   1. The HTTP/3 layer needs to be modified in subtle and non-backwards
   compatible ways. This will primarily break load balancers unless they are
   WebTransport aware.
   2. STREAM frames cannot be associated with a protocol or session until
   the first bytes have arrived for all prior stream IDs. This makes
   per-application and per-session flow control difficult, and would prevent
   Http3Transport from creating or accepting streams in order.
   3. RESET_STREAM frames cannot be mapped to a protocol or session for a
   stream ID unless the first bytes have been received. This prevents empty
   streams from being closed until the first HTTP/3 frame has been
   acknowledged.

Finally, there's an argument that people are going to run HTTP/3 servers,
so we should just use Http3Transport. it's actually significantly easier
for a HTTP/3 to accept a QuicTransport connection (switch based on ALPN)
than it is to support Http3Transport (custom frames and session mapping).


*Conclusion*
So yeah, I think that we absolutely support the simple-yet-powerful
QuicTransport. If there's a compelling reason to support multiple
transports on a single connection, then Http3Transport (or a
QUIC extension) is an option. And finally, I don't see any reason for
Http2Transport to exist.