Re: Extensible Priorities and Reprioritization

On Fri, Jun 5, 2020 at 1:36 AM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

> Hello folks,
>
> The Extensible Priorities draft has an open issue on the topic of
> reprioritization [1] and the May 2020 HTTP Interim session [2] pivoted
> towards it. The discussion highlighted that reprioritization is something
> we need to get to the bottom of in order to unblock progressing this draft.
>
> Our definition of the reprioritization feature is purposefully narrow, but
> the frame-related mechanics cause complications for implementations. One
> option on the table is to take reprioritization out of the critical path of
> draft-ietf-httpbis-priority by extracting the text to leave a simpler
> definition of just the scheme and the Priority header signal. The extracted
> text could be put in a separate I-D, reworked, replaced, or dropped
> altogether. The choice of action is ultimately up to the WG, so that is why
> we’re sending this email.
>
> Removing reprioritization from draft-ietf-httpbis-priority sounds pretty
> drastic but in all the work that’s got us here, we’ve struggled to find
> data that backs up its efficacy.
>
> Reducing Extensible Priorities to its core, clients issue priority signals
> (U and I) based on the expectation that the server, if possible, will
> transmit responses in the order of their urgency and request order
> (inferred by stream ID). Reprioritization is a client sending a subsequent
> signal (U’ and I’) that modifies the priority of in-flight responses.
> Reprioritization is not:
>
>
>    -
>
>    Sending a batch of requests and signalling the desire for later
>    requests to be sent before earlier ones. By design, that is supported using
>    urgency.
>    -
>
>    Purposeful ordering of requests to meet a priority objective. This a
>    client implementation choice.
>    -
>
>    Aborting requests or responses that are in flight. By design, that is
>    a function provided by HTTP/2 or QUIC streams that is actioned by
>    implementation choice.
>    -
>
>    Manipulating a dependency tree through the lifetime of a connection.
>    By design, that is not required.
>    -
>
>    Any other mechanisms to adjust the server’s scheduling of response
>    data. That is out of scope.
>
>
> We’d be very interested to hear from people who support keeping
> reprioritization and can provide data, directly or indirectly, that the way
> it is applied in the extensible priority scheme provides tangible benefits.
> Data to the opposite effect is also of interest.
>

Chromium is re-prioritizing image requests. Images are sent with low
priority and in-viewport images are later re-prioritized (once
layout happens and the browser knows they are actually in the viewport).
IIRC +Bence Béky <bnc@chromium.org> implemented that re-prioritization for
H2, and may have data regarding its impact from the launch. Also CCing +Tarun
Bansal <tbansal@google.com>, as he may be aware of data to its efficacy.

Note that any such data regarding H2 would be biased by current H2
implementations and their challenges
<https://blog.cloudflare.com/better-http-2-prioritization-for-a-faster-web/>
with buffer bloat. So I'd tend to trust test cases/examples from known
good-actors more than internet-wide data that's more likely to be watered
down with other issues.

What's the timeline for us to provide supporting data and/or tests cases in
order to keep re-prioritization in?


> Cheers
>
> Kazuho and Lucas
>
> Extensible Priorities Editors
>
> [1] - https://github.com/httpwg/http-extensions/issues/1021
>
> [2] -
> https://github.com/httpwg/wg-materials/blob/gh-pages/interim-20-05/minutes.md#priorities
>