Re: Extensible Priorities and Reprioritization

If you're looking for a distilled test case, my HTTP/2 prioritization test
page <https://github.com/pmeenan/http2priorities/tree/master/stand-alone>
used for the https://ishttp2fastyet.com prioritization support tracking.
It loads a bunch of images "below the fold" and then after they start
loading it injects 2 images (one after the other) into the viewport.

Building a whole separate "VIEWPORT" scheme that is browser-specific feels
a bit like punting on the problem and effectively killing it, particularly
since most of the drive behind simplifying prioritization was for the
browser use case anyway.

What are the difficult points around implementing the current
reprioritization plans? Is it a sequencing problem with streams and
out-of-band changes? Would it help if the priority change was actually a
stream-level message and specifically changed just the urgency of the
requested stream (with any server-side headers overriding even the changed
urgency)?

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

> Hey Yoav,
>
> On Fri, Jun 5, 2020 at 9:14 AM Yoav Weiss <yoav@yoav.ws> wrote:
>
>>
>> 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?
>>
>
> Thanks for bringing up the challenges with H2, presenting data with this
> in mind seems important. Prioritization considerations wrt server-side TCP
> buffering [1] apply not only to reprioritization but preemption (the case I
> described as a bunch of requests where later requests are more urgent than
> earlier ones).
>
> Picking specifically on browsers, they have many options at their disposal
> to improve page load metrics. I think it would be useful to understand how
> big a role reprioritization plays in that. Maybe the WG would benefit from
> a distilled test case that can used to exercise reprioritization. For
> instance, is there a way to script and/or create a reproducible test for
> viewport changes?
>
> In terms of timeline, that's a bit tricky to answer and I assume the WG
> and chairs might have some opinions. To put the question back to you, is
> this data you have close to hand or are we talking weeks or months of
> experimental data gathering subject to engineering work or product release
> cycles?
>
> I'll close with a curveball idea: IIUC the viewport case, the dilemma is
> that when a browser makes the first set of requests, it is very unlikely to
> have the information required to know what is in-viewport vs.
> out-of-viewport. So for some types of resource you *always* want to
> promote/demote the resource's importance when discovering this, but for
> other types of resource you *never* need to. Could you make this a more
> explicit signal? I.e. rather than creating a general-purpose
> reprioritization mechanism that is applicable in a fraction of cases, one
> could create a "viewport/layout change" signal that tackles this specific
> case? For instance a frame called VIEWPORT that contains a boolean flag and
> a set of stream IDs that identify the affected requests.  Such a thing
> would suit being defined in an independent I-D.
>
> Cheers,
> Lucas
>
>
>>
>>