Re: [Webtransport] Use of HTTP priorities in WebTransport

[Lucas Pardue <[e-mail]>]

Hey Ian,


On Thu, Apr 1, 2021 at 6:01 PM Ian Swett <ianswett=
[e-mail]> wrote:

> Now that WebTransport is targeted at HTTP/3 and not QUIC, it seems logical
> to build on the prioritization work in the HTTP priorities draft(
> draft-ietf-httpbis-priority
> <https://tools.ietf.org/html/draft-ietf-httpbis-priority-03>).  This
> could be particularly important when pooling HTTP/3 with WebTransport, but
> I think that priority model is a good one for WebTransport by itself as
> well.
>
> Except for bidi streams, most of this priority information wouldn't need
> to be sent on the wire, but it could be used by local schedulers.
>
> Thoughts?
>

The HTTP priorities draft is very specific in that it defines an asymmetric
signal from client to server. So I'm curious how you picture it applying to
WebTransport. You're right, the general prioritization scheme might be a
good fit but I'd like to understand the requirements better. Is it only a
local priority configuration from the send side? In which case, this seems
like a W3C API issue. Or is the requirement to support sending priority
signals that instruct the peer to do something too? The hardest case to
solve is a server-initiated bidi stream that wants to signal a priority to
the client. Since WebTransport over HTTP/3 is an extension, you might get
away with changing the rules for PRIORITY_UPDATE. You could define a new
frame that carries the same information, or include it in the WebTransport
stream itself somehow.

Cheers,
Lucas