Re: Extensible Priorities and Reprioritization

(Sorry, sent it too soon...)

On Thu, Jun 11, 2020 at 6:12 AM Kinuko Yasuda <kinuko@chromium.org> wrote:

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

Let me stress though that testing this with servers that can properly
handle reprioritization could change the landscape, and again this isn't
really capturing how it affects long-lived request cases, or cases where
tabs go foreground & background while loading, so for now I'm not very
motivated to remove the reprioritization feature either.


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