Re: [Webtransport] Use of HTTP priorities in WebTransport

[Kinuko Yasuda <[e-mail]>]

Fyi, reg: priority API at web layer, there's an API proposal for resource
loading prioritization that tries to give the priority info as a
"importance hint" (of low, medium, high) rather than concrete priority
value.  This approach has some benefits as UA could still affect and take
care of relative priorities, and got positive buy-ins from developers.
(This hasn't shipped yet though...) I suspect the same/similar attribute
might work here.

https://wicg.github.io/priority-hints/


On Sat, Apr 24, 2021 at 10:31 AM Bernard Aboba <[e-mail]>
wrote:

> Ian said:
>
> "I agree this is potentially more of a W3C issue to standardize an API
> than an IETF issue."
>
> [BA ]I'm aware of an example of a priority API
> <https://www.w3.org/blog/news/archives/8969>.  But implementations seem
> to be scarce.  Is there an example of a successful W3C API
> supporting priority?
>
> On Fri, Apr 23, 2021 at 2:03 PM Ian Swett <ianswett=
> [e-mail]> wrote:
>
>> (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 <[e-mail]> 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 <[e-mail]>
>>> wrote:
>>>
>>>> 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
>>>> --
>>>> Webtransport mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/webtransport
>>>>
>>> --
>> Webtransport mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/webtransport
>>
> --
> Webtransport mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webtransport
>