Re: [Webtransport] Use of HTTP priorities in WebTransport

[Bernard Aboba <[e-mail]>]

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
>