Subject: [Webtransport] HTTP/3 Downgrade

From: Luke Curley <[email-masked]>
Date: Wed, 11 Nov 2020 13:42:43 -0800

It seems like connection pooling introduces a lot of technical complexity
for limited benefits. Hypothetically, what if connection pooling was
dropped as a requirement?

What if Http3Transport involved establishing a new HTTP/3 connection and
downgrading it to QUIC? It would be analogous to WebSockets for HTTP/1.1.

You could use 0-RTT to minimize latency when establishing a HTTP/3 or
Http3Transport connection to an existing host. These connections would not
share congestion control state (unfortunate), but would also not share flow
control limits (yay).

I also think this is how you could merge QuicTransport and Http3Transport.
Use HTTP/3 for the handshake, and QUIC for the data transfer.

---

From: Ian Swett <[email-masked]>
Date: Wed, 11 Nov 2020 16:48:26 -0500

Downgrading post handshake is very complex in practice, particularly
because QUIC is not head-of-line blocking. If you were to pursue this, I
would recommend downgrading as part of the handshake.

You could use a transport param instead of alpn if that was preferable.

On Wed, Nov 11, 2020 at 4:43 PM Luke Curley <[email-masked]> wrote:

> --
> Webtransport mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webtransport
>

---

From: Victor Vasiliev <[email-masked]>
Date: Wed, 11 Nov 2020 16:51:49 -0500

I'm not sure "HTTP/3 without pooling" does anything that QuicTransport
doesn't already do, especially since the latter got real header support.
So, at least as far as my understanding of this space goes, Http3Transport
without pooling doesn't make that much sense.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 11 Nov 2020 14:35:25 -0800

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.

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

On Wed, Nov 11, 2020 at 1:52 PM Victor Vasiliev <vasilvv=
[email-masked]> wrote:

>> I also think this is how you could merge QuicTransport and
>> Http3Transport. Use HTTP/3 for the handshake, and QUIC for the data
>> transfer.
>> --

---

From: Luke Curley <[email-masked]>
Date: Wed, 11 Nov 2020 17:31:39 -0800

@bernard I think that use-case boils down to a lack of HTTP functionality.
The "proper" approach would be to use HTTP server push for media, but
nobody likes that. Justin's ask is to instead to augment HTTP/3 such that
it muxes in QUIC-like connections. I do think it address HTTP's
short-comings, but it's non-trivial and will require custom HTTP/3
implementations.

My use-case is almost identical (Twitch). We're implementing a video
protocol over QuicTransport instead of trying to leverage HTTP/3. It gives
us the ability to push media while utilizing stock QUIC implementations.
All you need on top is a simple API layer, such as JSON messages over
bidirectional streams.

As for firewall traversal, QUIC connections can use the same socket and
would thus share the NAT binding... assuming middleware does not decode
QUIC initial packets. Each connection could end up on different host
depending on load balancing though.

Has somebody formulated a list of pros and cons for Http3Transport as
compared to QuicTransport?

On Wed, Nov 11, 2020 at 2:35 PM Bernard Aboba <[email-masked]>
wrote:

>>> It seems like connection pooling introduces a lot of technical
>>> complexity for limited benefits. Hypothetically, what if connection pooling
>>> was dropped as a requirement?
>>>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 12 Nov 2020 11:18:31 -0800

Luke said:

"My use-case is almost identical (Twitch). We're implementing a video

bidirectional streams."

[BA] That's a pretty straightforward way to move forward on low
latency or P2P use cases (e.g. game streaming and remote desktop).
HTTP/3 use cases tend to be situations where caching might be useful,
or where there is a desire to leverage HTTP/3 specifically. For
example, for live events you can often live with more latency (perhaps
up to a second), and CDNs are widely used today to improve
scalability. In the RIPT BOF, a desire to leverage cloud
infrastructure was mentioned, though at the time there was scepticism
as to whether that would actually be possible (and similar concerns
have been raised on this thread).

[BA] I think the concern was not NAT traversal so much as enterprise
firewalls that today often have restrictive policies (e.g. TCP-only or
HTTP-only). Not sure whether those firewalls are likely to be
QUIC-friendly or if so what we can assume about them when they are
upgraded (e.g. MASQUE support?). So may not be easy to say exactly
what the requirements will be.

[BA] There have been some slides presented with a few basic
considerations. But more detailed examination seems needed to distill
requirements and get to the bottom of what implementers need as
opposed to what might sound good at a superficial level but might not
be deployable or implementable. The need for more detailed discussion
becomes apparent when actually trying to implement some of the use
cases - and realizing that in practice there are more moving parts
than meets the eye.

There are also DevOps issues like load balancing/draining, which has
been an issue with Websockets deployment. Quite solvable but worth
articulating in terms of requirements.

"

On Wed, Nov 11, 2020 at 5:31 PM Luke Curley <[email-masked]> wrote:

>> 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:
>>>> What if Http3Transport involved establishing a new HTTP/3 connection
>>>> and downgrading it to QUIC? It would be analogous to WebSockets for
>>>> HTTP/1.1.
>>>>

---

From: Victor Vasiliev <[email-masked]>
Date: Fri, 13 Nov 2020 10:05:03 -0500

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

> https://datatracker.ietf.org/meeting/107/materials/slides-107-ript-rtc-implementation-experiences-00

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