Re: [Moq] Exploring HTTP/3

[Luke Curley <[e-mail]>]

Yeah, I do think HTTP semantics mostly get in the way here.

One of the problems with Warp over HTTP/3 is that prioritization is best
scoped to a connection. Meanwhile HTTP semantics are agnostic to the
underlying transport and we can't enforce connection sharing.q

For example, suppose a client issues a request for segment 5 and segment 6,
asking that the newer segment is delivered first during congestion.

If the two requests share a HTTP/3 or HTTP/2 connection, then the HTTP
server can prioritize. Any available bandwidth under the congestion window
is spent on STREAM frames for segment 6 first.

If the two requests are over separate QUIC/TCP connections, then IP/flow
priorities could work, but not really. Support is limited and it gets messy
since QUIC packets are sequenced. We would need something like multi-path
to individually prioritize QUIC packets within a connection (ex. there's a
3rd request with a different priority).

If the two requests hit a server that doesn't support prioritization, then
that hop will round-robin. Head-of-line blocking may even be preferable,
but there's no way of knowing that a HTTP relay doesn't support
prioritization. That was my biggest concern with the HTTP Priority header:
it's a hop-to-hop property expressed in an end-to-end header.


One of the reasons for using WebTransport instead of HTTP/3 is that it
gives us a firm guarantee that streams share an underlying connection.
Additionally, QuicTransport used to guarantee that it was a dedicated
connection, although that went out the window when pooling "support" was
added.

We still run the risk of a generic WebTransport relay using round-robin,
but without adding priorities explicitly to WebTransport, I don't think
there's any way to avoid that.


On Thu, Feb 9, 2023, 8:36 AM Lucas Pardue <[e-mail]>
wrote:

> Hey Spencer,
>
> On Thu, 9 Feb 2023, 16:00 Spencer Dawkins at IETF, <
> [e-mail]> wrote:
>
>> Lucas,
>>
>> On Wed, Feb 8, 2023 at 4:55 PM Lucas Pardue <[e-mail]>
>> wrote:
>>
>>>
>>>> And yeah, I agree that browsers are the main obstacles when pushing
>>>> media, but that doesn't change too much with WebTransport. We still need a
>>>> way to set the priority when pushing a WebTransport stream, much like we
>>>> would need a way to set the priority when issuing a HTTP PUT. I suppose
>>>> it's easier to modify WebTransport since it's in development.
>>>>
>>>
>>> The W3C WebTransport WG has been considering the questions of
>>> prioritization and congestion control feedback for a relatively long time.
>>> And we have been making progress. It has the right people and the right
>>> charter to work on it. I'm a little pessimistic about trying to get
>>> momentum for HTTP upload changes MoQ could require, in the sorts of
>>> timeframes that MoQ would find useful. For context, fetch *does *even
>>> support preference of HTTP version, nor exposese connection pooling. But
>>> maybe I'm too conservative in this regard. Asking ourselves the questions
>>> is definitely worthwhile.
>>>
>>
>> Could this have been "fetch *does NOT* even support preference of HTTP
>> version"?
>>
>> I was guessing so, but didn't want to guess when I could ask.
>>
>
> Yes you're right. Thanks for spotting that! I always appreciate a careful
> eye.
>
> At the HTTP semantic layer, the version doesn't really matter, your
> request or response objects get transferred around. The same scheme value
> "https" works for all versions. Under the hood there's lots of differences
> and complexity of course. The Fetch API feels about the right layer of
> abstraction for most purposes.
>
> My sense so far has been that QUIC  is providing unique qualities that the
> MoQ protocol (whatever it is) wants to harness. If that's true, HTTP/3 is a
> hard requirement of an HTTP-based MoQ protocol, then we'd have work to do
> in the web platform to ensure its abstractions don't get in the way.
> Likewise, implementation details like internal stacks, layering, security
> model etc would need to be considered. This isn't an impossible task but
> nor will it just happen without investment and engagement.
>
> Cheers
> Lucas
>