Re: [Webtransport] Use of HTTP priorities in WebTransport

(sorry for the delay, now caught up from leave)

I agree this is potentially more of a W3C issue to standardize an API than
an IETF issue.

I agree that most of this information would not be sent on the wire, but as
we add functionality to HTTP(ie: WebTransport and MASQUE), it becomes
increasingly important to understand how prioritization might work.
Ideally no explicit signals are necessary and each endpoint knows what to
do, and we can fit WebTransport(and MASQUE) into the existing scheduler so
when multiplexed, there's no ambiguity about what implementations should
send first?

My concern is if there are no rules or APIs for prioritization, different
implementations may make different choices, and the more things which are
multiplexed on a single connection, the more important it becomes.

Ian

On Mon, Apr 5, 2021 at 3:47 PM Luke Curley <kixelated@gmail.com> wrote:

> I think stream prioritization is an important next phase for WebTransport.
> But like Lucas mentioned, I'm not sure it needs to be handled at the
> transport layer.
>
> Currently, the server can prioritize sending stream data based on any
> scheme it wants. The browser could inform the server which prioritization
> scheme to use for a given stream, but I think that use-case can be
> negotiated at the application level instead.
>
> The browser definitely needs an API for prioritizing sending stream data
> though and a simple scheme like the priorities draft would be a good
> starting point.
>
> On Thu, Apr 1, 2021 at 4:40 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
> wrote:
>
>> Hey Ian,
>>
>>
>> On Thu, Apr 1, 2021 at 6:01 PM Ian Swett <ianswett=
>> 40google.com@dmarc.ietf.org> 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
>> --
>> Webtransport mailing list
>> Webtransport@ietf.org
>> https://www.ietf.org/mailman/listinfo/webtransport
>>
>