Re: Extensible Priorities and Reprioritization

On Wed, Jun 17, 2020 at 9:55 AM Kazuho Oku <kazuhooku@gmail.com> wrote:

>
>
> 2020年6月11日(木) 6:46 Kinuko Yasuda <kinuko@chromium.org>:
>
>> (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.
>>
>
> Hi Kinuko,
>
> Thank you for sharing your data. I feel a bit sad that reprioritization
> isn't showing much benefit at the moment. I tend to agree that we are
> likely to see different results between server implementations and HTTP
> versions being used. The effectiveness of reprioritization depends on the
> depth of the send buffer (after prioritization decision is made), at least
> to certain extent.
>

FWIW, I added a flag
<https://chromium-review.googlesource.com/c/chromium/src/+/2232923> to turn
off Chromium's H2 request prioritization. I believe +Pat Meenan
<patmeenan@gmail.com> is currently running tests with and without this flag
a list of servers we estimate is likely to handle them well.


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