Re: [Moq] Exploring HTTP/3

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Lucas,

On Thu, Feb 9, 2023 at 10: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.
>

I developed that skill on review teams, and on the IESG. I wonder what
skill I gave up, for that skill to fit. 🙃


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

I understand less about Web APIs than I would like to understand - that
could change, but so far, it hasn't. So, perhaps, I should be deferring to
Bernard and Victor (two of the current WebTransport specification editors),
but you know me. So I'll ask the question, and let more knowledgeable folks
explain what I really meant, or just say "Spencer doesn't understand Web
APIs".

Looking at https://www.w3.org/TR/webtransport/#protocol-concepts, it looks
like WebTransport is intended to run over HTTP/3, and in
https://www.w3.org/TR/webtransport/#web-transport-configuration,
there'sa *requireUnreliable
*WebTransportOptions boolean attribute, that says, if "set to true, the
WebTransport connection cannot be established over HTTP/2 if an HTTP/3
connection is not possible."

I understood your previous point to be that an application doesn't have a
way to say "use HTTP/3 if you can". Was I misunderstanding your point, or
the specification?

Best,

Spencer


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