Re: [Webtransport] HTTP/3 Downgrade

[Bernard Aboba <[e-mail]>]

Luke said:

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

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

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.

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

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

[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 <[e-mail]> wrote:

> @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 <[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.
>>
>> 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]
>>
>> On Wed, Nov 11, 2020 at 1:52 PM Victor Vasiliev <vasilvv=
>> [e-mail]> wrote:
>>
>>> 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.
>>>
>>> On Wed, Nov 11, 2020 at 4:43 PM Luke Curley <[e-mail]> 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?
>>>>
>>>> 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.
>>>> --
>>>> Webtransport mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/webtransport
>>>>
>>> --
>>> Webtransport mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/webtransport
>>>
>>