Re: Extensible Priorities and Reprioritization

Hi all,

Reg: reprioritization benefit I can share some recent data for Chrome.  For
the two cases that are currently discussed I'm actually not fully sure
about its benefit.

For the renderer-triggered image reprioritization cases: this is a bit
interesting one, we recently found two things:
- Delaying to start low-prio requests could often work better (partly
because of server-side handling) than re-prioritizing while inflight
- In-lab measurements (tested with top 10k real sites, both on Mobile and
Desktop) showed that removing in-flight re-prioritization doesn't impact
page load performance a lot

I suspect this is maybe because server-side handling is not always perfect
and most of requests on the web are short-lived, and this may not be true
for the cases where long-running requests matter.  I don't have data for
whether may impact background / foreground cases (e.g. Chrome tries to
lower priorities when tabs become background)

For download cases, Chrome always starts a new download with a low priority
(even if it has started as a navigation), so reprioritization doesn't
happen.

Kinuko






On Wed, Jun 10, 2020 at 1:21 AM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

> On Tue, Jun 9, 2020 at 4:27 PM Patrick Meenan <patmeenan@gmail.com> wrote:
>
>> Eric's download example is a great one for exposing the risks that would
>> come for an implementation that supported prioritization but not
>> reprioritization.
>>
>> Take the trivial example of an anchor link that links to a download (say,
>> a 200MB installer of some kind):
>> - When the user clicks on the link, the browser assumes it is doing a
>> navigation and issues the request with the "HTML" priority (relatively
>> high, possibly non-incremental
>> - When the response starts coming back, it has the content-disposition to
>> download to a file.
>> - At this point, the 200MB download will block every other lower-priority
>> request on the same connection (or possibly navigation if it is
>> non-incremental)
>> - The user clicks on another page on the same site and gets nothing or a
>> broken experience until the 200MB download completes
>>
>> Without reprioritization the browser will effectively have to burn the
>> existing QUIC connection and issue any requests on a new connection (and
>> repeat for each new download).
>>
>> Implementing prioritization without reprioritization in this case is
>> worse than having no prioritization support at all.
>>
>
> Thanks Eric for presenting this case, and Patrick for breaking it down.
> That does seem like a pretty bad outcome.
>
> Is this a good candidate for a test case? IIUC correctly the problem might
> occur today with HTTP/2 depending on how exclusive priorities are used. I'm
> curious if browsers can share any more information about what they do
> already. How does Firefox manage such a resource with it's priority groups?
>
> Cheers
> Lucas
>
>