Re: [Webtransport] HTTP/3 Downgrade

[Victor Vasiliev <[e-mail]>]

On Wed, Nov 11, 2020 at 5:35 PM Bernard Aboba <[e-mail]>
wrote:

> Victor said:
>
> "Http3Transport without pooling doesn't make that much sense."
>
> [BA] Some Http3Transport use cases depend on pooling between WebTransport
> and HTTP/3 request/responses; others could just be satisfied by
> WebTransport pooling.  I would suggest that we distinguish these two
> requirements, because pooling/sharing a QUIC connection between
> WebTransport instances appears simpler than pooling/sharing a QUIC
> connection between WebTransport and HTTP/3.
>

I'm actually not sure about that.  Managing connection pools can be fairly
hard, so I would not be surprised if implementing pooled WebTransport
without HTTP required more code than just using HTTP/3.

Design-wise, almost all hard problems (things like flow control) are issues
for both.


>
> At IETF 107 RIPT BOF there was a desire expressed to enable media services
> to leverage HTTP infrastructure. Justin Uberti described a use case where
> gRPC would be sent over HTTP/3 to request that the server initiate either a
> reliable stream or flow of datagrams (see below).  This use case appears to
> require pooling of WebTransport and HTTP/3 request/responses (in order to
> simplify firewall traversal).  However, this use case is not easily
> supported using an garden variety HTTP/3 server, which probably could not
> initially be expected to support QUIC datagrams (although it would not be
> hard to support in node.js assuming that a QUIC module was available).
>
> See Slide 7 here:
> https://datatracker.ietf.org/meeting/107/materials/slides-107-ript-rtc-implementation-experiences-00
>
> [image: image.png]
>

I've been thinking about this, and I am not entirely convinced this is
specific to Http3Transport.  There are many reasons why HTTP load balancers
usually work on L7 instead of L4, but the main ones are roughly: (1) this
lets them optimize content (caching, compression, etc), (2) L7 LB can fan
out requests from a single HTTP connection to multiple backends.  The first
one doesn't really apply that much to WebTransport (since we can't do
things like caching), and the second one is just a benefit of
Http3Transport being pooled.  QuicTransport is probably perfectly fine
being load balanced at L4.

>From my perspective, the main benefit of Http3Transport is pooling support,
and pretty much everything else should work for QuicTransport too.  Another
benefit is ability to fall back to Http2Transport when UDP is blocked (I
understand that Http2Transport is not compelling for *existing* systems
that already work over TCP, but if I were to build a *completely new* thing
over WebTransport, I would want it to handle networks with no UDP for me).