Subject: [Webtransport] Use of HTTP priorities in WebTransport

From: Ian Swett <[email-masked]>
Date: Thu, 1 Apr 2021 13:00:00 -0400

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?

Ian

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 2 Apr 2021 00:40:08 +0100

Hey Ian,

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

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

---

From: Luke Curley <[email-masked]>
Date: Mon, 5 Apr 2021 12:47:26 -0700

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 <[email-masked]>
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(
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webtransport
>

---

From: Ian Swett <[email-masked]>
Date: Fri, 23 Apr 2021 17:02:32 -0400

(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

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 23 Apr 2021 18:31:11 -0700

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=
[email-masked]> wrote:

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

---

From: Kinuko Yasuda <[email-masked]>
Date: Mon, 26 Apr 2021 11:48:55 +0900

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 <[email-masked]>
wrote:

> Ian said:
>
> "I agree this is potentially more of a W3C issue to standardize an API
> than an IETF issue."
>
> <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?
>
>> I agree this is potentially more of a W3C issue to standardize an API
>> than an IETF issue.
>>