Re: Extensible Priorities and Reprioritization

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


>
>