Subject: Re: Extensible Priorities and Reprioritization

From: Patrick Meenan <[email-masked]>
Date: Mon, 6 Jul 2020 16:19:15 -0400

Sorry about the delay, just gathered the results.  The full raw results are
here
<https://docs.google.com/spreadsheets/d/14iyeO--I-K-l7er1kGuW-iTKogsgXFz4Z3M-aowSUdI/edit?usp=sharing>.
It looks like the impact dropped quite a bit across the full 25k URLs but
looking at individual tests the impact is quite dramatic when it does
impact (and it does exactly what we'd expect it to do for those outlier
cases).

The 95th percentile numbers tend to be the more interesting ones and in the
data set, reprioritization enabled is the control and disabled is the
experiment so positive changes means disabling reprioritization is that
much slower.

Largest Contentful Paint: 4% slower without reprioritization
Speed Index: 2.75% slower without reprioritization
Dom Content Loaded: 1.3% faster without reprioritization

This is pretty much (directionally) what we'd expect since reprioritization
boosts the priority of visible images (LPC/Speed Index) above late-body
scripts (DCL). It's particularly dramatic for pages that use background
images for any part of the page because they are discovered after all other
resources and would normally be scheduled after all other scripts and
inline images but if they are visible in the viewport the reprioritization
helps them load much sooner.

Looking at a few examples of the extreme cases:

https://www.thehelm.co/ - (Filmstrip
<https://www.webpagetest.org/video/compare.php?tests=200625_MT_32af039543326a2bdb5d87e2adb95fe7-r%3A3-l%3AStock%2C200701_HY_6bb4d26adff32186e991c5b96ffaecea-r%3A1-l%3ADisabled%2C&thumbSize=200&ival=5000&end=full>)
-
The main background image in the interstitial loads at < 10s vs 90s without
reprioritization
https://blog.nerdfactory.ai/ - (Filmstrip
<https://www.webpagetest.org/video/compare.php?tests=200616_KZ_496553703935231e5725c252844918db-r%3A1-l%3AStock%2C200616_BJ_798e2417374c03dfa3995586b01444a3-r%3A3-l%3ADisabled%2C&thumbSize=200&ival=5000&end=full>)
- The background image for the main content loads at <5s vs 70s without
reprioritization. No cost to DCL, just prioritized ahead of not-visible
images.
https://events.nuix.com/ - (Filmstrip
<https://www.webpagetest.org/video/compare.php?tests=200628_1A_0e61aa9f59e08f3bbb8e5d9690fe64fb-r%3A3-l%3AStock%2C200628_Q2_1793a50022566cedd6ab48dd871d5c7e-r%3A3-l%3ADisabled%2C&thumbSize=200&ival=5000&end=full>)
- Another hero background image (detecting a theme?) loads at 10s vs 60s

Looking at a few of the bigger DCL regressions:

https://oaklandcitychurch.org/ - (Filmstrip
<https://www.webpagetest.org/video/compare.php?tests=200627_XR_fae3bd7aa57238591cb122c9fe634cb7-r%3A2-l%3AStock%2C200627_R9_26ad61b65965e7bf89a8aa27a7d78ff1-r%3A2-l%3ADisabled%2C&thumbSize=200&ival=5000&end=full>)
- DCL got much slower (11s -> 33s) as a direct result of the background
image moving from 30s to 10s (the pop-up interstitial was delayed along
with the scripts that control it).

For the specific case that most of these tests exposed (background image
discovered late by CSS) it is theoretically possible for Chrome to detect
the position before making the initial request (since it is only discovered
at layout anyway) but that wouldn't help any of the more dynamic cases like
when a user scrolls a page or a carousel rotates and what is on screen
changes dynamically.

I'm still of the pretty strong opinion that we need reprioritization but
the web won't necessarily break without it and sites (and browsers) may be
able to minimize the impact of not being able to reprioritize (though that
might involve holding back requests and prioritizing locally like Chrome
does for slow HTTP/2 connections).

On Sat, Jun 20, 2020 at 10:17 AM Patrick Meenan <[email-masked]> wrote:

> An early read on Yoav's Canary test is that most metrics are neutral but
> Largest Contentful Paint degrades ~6.8% on average and 12% at the 95th
> percentile without reprioritization and Speed Index degrades 2.6% on
> average and 5.4% at the 95th percentile. This is not entirely unexpected
> because the main use case for reprioritization in Chrome right now is
> boosting the priority of visible images after layout is done.
>
> We'll see if it holds after the full test is complete. The early read is
> from 3,000 of the 25,000 URLs that we are testing (all https hosted on
> Fastly for simplicity since we know it handles HTTP/2 reprioritization
> correctly).  The tests are all run at "3G Fast" speeds with desktop pages
> to maximize the liklihood that there will be time for reprioritization to
> happen.  I'll provide the full raw data as well as summary results when the
> test is complete (at least another week, maybe 2).
>
> On Wed, Jun 17, 2020 at 5:43 AM Yoav Weiss <[email-masked]> wrote:
>
>>
>>
>> On Wed, Jun 17, 2020 at 9:55 AM Kazuho Oku <[email-masked]> wrote:
>>
>>>
>>>
>>> 2020年6月11日(木) 6:46 Kinuko Yasuda <[email-masked]>:
>>>
>>>> (Sorry, sent it too soon...)
>>>>
>>>> On Thu, Jun 11, 2020 at 6:12 AM Kinuko Yasuda <[email-masked]>
>>>> 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
>> <[email-masked]> 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 <
>>>>> [email-masked]> wrote:
>>>>>
>>>>>> On Tue, Jun 9, 2020 at 4:27 PM Patrick Meenan <[email-masked]>
>>>>>> 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
>>>
>>

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 6 Jul 2020 22:50:56 +0100

Hi Patrick,

Thanks for running this experiment and presenting the data back to the
group.

Also thanks to the Chrome folk for enabling the disabling flag.

Cheers
Lucas

On Mon, 6 Jul 2020, 21:19 Patrick Meenan, <[email-masked]> wrote:

> Sorry about the delay, just gathered the results.  The full raw results
> are here
> The 95th percentile numbers tend to be the more interesting ones and in
> the data set, reprioritization enabled is the control and disabled is the
> This is pretty much (directionally) what we'd expect since
> reprioritization boosts the priority of visible images (LPC/Speed Index)
> above late-body scripts (DCL). It's particularly dramatic for pages that
> use background images for any part of the page because they are discovered
> after all other resources and would normally be scheduled after all other
> scripts and inline images but if they are visible in the viewport the
> reprioritization helps them load much sooner.
>
> <https://www.webpagetest.org/video/compare.php?tests=200625_MT_32af039543326a2bdb5d87e2adb95fe7-r%3A3-l%3AStock%2C200701_HY_6bb4d26adff32186e991c5b96ffaecea-r%3A1-l%3ADisabled%2C&thumbSize=200&ival=5000&end=full>) -
>>>>>> For the renderer-triggered image reprioritization cases: this is a
>>>>>> bit interesting one, we recently found two things:
>>>>>>>> Implementing prioritization without reprioritization in this case
>>>>>>>> is worse than having no prioritization support at all.
>>>>>>>>
>>>>>>>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 10 Jul 2020 16:46:08 +1000

All,

Thanks to everyone for their efforts so far.

There's one other aspect that the we think it'd be helpful to get a sense of -- what the implementer intent is regarding reprioritisation.

In particular, it'd be very helpful to have an indication from each implementation -- in user agents as well as servers (including intermediaries) -- as to how likely they are to produce/consume reprioritisations if specified.

Note that's per-implementation, *not* per-person, so please coordinate if your implementation has multiple participants here.

Responding to this e-mail is fine.

Cheers,

> On 7 Jul 2020, at 7:50 am, Lucas Pardue <[email-masked]> wrote:
> 
> Hi Patrick,
> 
> Thanks for running this experiment and presenting the data back to the group.
> 
> Sorry about the delay, just gathered the results.  The full raw results are here.  It looks like the impact dropped quite a bit across the full 25k URLs but looking at individual tests the impact is quite dramatic when it does impact (and it does exactly what we'd expect it to do for those outlier cases).
> 
> The 95th percentile numbers tend to be the more interesting ones and in the data set, reprioritization enabled is the control and disabled is the experiment so positive changes means disabling reprioritization is that much slower.
> 
> This is pretty much (directionally) what we'd expect since reprioritization boosts the priority of visible images (LPC/Speed Index) above late-body scripts (DCL). It's particularly dramatic for pages that use background images for any part of the page because they are discovered after all other resources and would normally be scheduled after all other scripts and inline images but if they are visible in the viewport the reprioritization helps them load much sooner.
> 
> https://www.thehelm.co/ - (Filmstrip) - The main background image in the interstitial loads at < 10s vs 90s without reprioritization
> https://blog.nerdfactory.ai/ - (Filmstrip) - The background image for the main content loads at <5s vs 70s without reprioritization. No cost to DCL, just prioritized ahead of not-visible images.
> https://events.nuix.com/ - (Filmstrip) - Another hero background image (detecting a theme?) loads at 10s vs 60s
> 
> https://oaklandcitychurch.org/ - (Filmstrip) - DCL got much slower (11s -> 33s) as a direct result of the background image moving from 30s to 10s (the pop-up interstitial was delayed along with the scripts that control it).
> 
> For the specific case that most of these tests exposed (background image discovered late by CSS) it is theoretically possible for Chrome to detect the position before making the initial request (since it is only discovered at layout anyway) but that wouldn't help any of the more dynamic cases like when a user scrolls a page or a carousel rotates and what is on screen changes dynamically.
> 
> I'm still of the pretty strong opinion that we need reprioritization but the web won't necessarily break without it and sites (and browsers) may be able to minimize the impact of not being able to reprioritize (though that might involve holding back requests and prioritizing locally like Chrome does for slow HTTP/2 connections).
> 
> 
> An early read on Yoav's Canary test is that most metrics are neutral but Largest Contentful Paint degrades ~6.8% on average and 12% at the 95th percentile without reprioritization and Speed Index degrades 2.6% on average and 5.4% at the 95th percentile. This is not entirely unexpected because the main use case for reprioritization in Chrome right now is boosting the priority of visible images after layout is done.
> 
> We'll see if it holds after the full test is complete. The early read is from 3,000 of the 25,000 URLs that we are testing (all https hosted on Fastly for simplicity since we know it handles HTTP/2 reprioritization correctly).  The tests are all run at "3G Fast" speeds with desktop pages to maximize the liklihood that there will be time for reprioritization to happen.  I'll provide the full raw data as well as summary results when the test is complete (at least another week, maybe 2). 
> 
> On Thu, Jun 11, 2020 at 6:12 AM Kinuko Yasuda <[email-masked]> 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 to turn off Chromium's H2 request prioritization. I believe +Pat Meenan 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 <[email-masked]> wrote:
> On Tue, Jun 9, 2020 at 4:27 PM Patrick Meenan <[email-masked]> 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

--
Mark Nottingham   https://www.mnot.net/

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 21 Jul 2020 10:55:58 -0700

Hi all, 

We (both in Safari and in URLSession for general HTTP usage on Apple platforms) are quite excited about the new priorities document and the opportunities it brings to simplify and focus on information that’s strictly necessary to communicate between the client, server, and intermediaries.

Specific to reprioritization, we have several cases where we use, and so far believe we need to continue to use, reprioritization (although ideas on workarounds are always welcome!).

First, the Web download case that’s been discussed (and thanks Patrick for running some related experiments for web traffic!), where we use reprioritization to modify the incremental bit on resources. 

Second, when streaming HLS video, we prioritize the currently playing tier above the other tiers. We may have several requests outstanding for the next several segments of video, and when we switch up/down we need to be able to reprioritize those alternate tiers. Unfortunately, so far it’s looking like not being able to reprioritize these requests would prevent our implementation of the new priority scheme. For Low-Latency HLS, we certainly will need to use reprioritization if we’re to fit within the currently proposed priority tiers.

Finally, a more generalized example. As we work to help customers and clients of the APIs we offer, we’ve found that many of our efforts to guide them towards appropriate prioritization of less important work at lower priorities is only enabled by the ability to raise that priority later when circumstances change. 

As a very contrived (but unfortunately close to real world) example, consider a case where we ask a client to de-prioritize loading of images in a list view that aren’t close to being scrolled into view by the user. If we can offer higher priority for those images once the user starts scrolling closer to having those items come into view, our clients are generally happy to initially load such images at lower priorities. However, if they’re stuck with that initial priority forever, they end up loading the entire set of images at a high priority just in case they might be eventually blocking render. A good bit of the time, that never happens, so we end up having everything at high priority when in reality we would rarely have needed to reprioritize the requests. And once everything’s at high priority, we no longer have the utility of the priority system at all.

There are all sorts of ways to dissect that particular example, but the general response we’ve seen remains: folks are much more willing to fully utilize a prioritization system in the real world if they’re able to adjust the priorities that they assigned later on when they have more information or the circumstances change.

Thanks,
Eric

Side note:

For the document as a whole, we’ve gotten some feedback internally that it would be really nice if there were some (minimal, recommendation only) guidance as to how to respond to the priority signals when received. This wouldn’t be restrictive, as we’re really excited to experiment here and see what awesome results we can achieve, but having a baseline of “implement this as written and you’ll do okay” might be worth considering to increase the likelihood that we have a large group of generally-performant implementations.

An example here would be if two requests of the same urgency arrive back-to-back, the first with the incremental bit set and the second without. What gets sent when? What do you do next if a third request arrives with the incremental bit also set before the first is complete? There are lots and lots of permutations, but a general approach of handling new items coming in is something that I think we’ve all been imagining during discussions, but we haven’t really written it down explicitly. Internally, as we discussed with some folks new to the topic, we discovered that our imaginations of what to do in cases like these didn’t actually align as well as we thought.

> On Jul 9, 2020, at 11:46 PM, Mark Nottingham <[email-masked]> wrote:
> 
> All,
>

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 21 Jul 2020 19:19:41 +0100

Hi Eric,

Just responding to your side note

On Tue, Jul 21, 2020 at 6:56 PM Eric Kinnear <[email-masked]> wrote:

>
> Side note:
>
> For the document as a whole, we’ve gotten some feedback internally that it
> would be really nice if there were some (minimal, recommendation only)
> guidance as to how to respond to the priority signals when received. This
> wouldn’t be restrictive, as we’re really excited to experiment here and see
> what awesome results we can achieve, but having a baseline of “implement
> this as written and you’ll do *okay” *might be worth considering to
> increase the likelihood that we have a large group of generally-performant
> implementations.
>
> An example here would be if two requests of the same urgency arrive
> back-to-back, the first with the incremental bit set and the second
> without. What gets sent when? What do you do next if a third request
> arrives with the incremental bit also set before the first is complete?
> There are lots and lots of permutations, but a general approach of handling
> new items coming in is something that I think we’ve all been imagining
> during discussions, but we haven’t really written it down explicitly.
> Internally, as we discussed with some folks new to the topic, we discovered
> that our imaginations of what to do in cases like these didn’t actually
> align as well as we thought.
>

Thanks for your feedback. I think this is orthogonal to the
reprioritization issue so I've created
https://github.com/httpwg/http-extensions/issues/1232 to capture your
comments. I think this might have some cross over with
https://github.com/httpwg/http-extensions/issues/1216 so if you coud take
at look at those and add anything more to them it would be appreciated.

Cheers
Lucas

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 21 Jul 2020 11:57:55 -0700

> On Jul 21, 2020, at 11:19 AM, Lucas Pardue <[email-masked]> wrote:
> 
> Hi Eric,
> 
> On Tue, Jul 21, 2020 at 6:56 PM Eric Kinnear <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Side note:
> 
> Thanks for your feedback. I think this is orthogonal to the reprioritization issue
Absolutely!

> so I've created https://github.com/httpwg/http-extensions/issues/1232 <https://github.com/httpwg/http-extensions/issues/1232> to capture your comments. I think this might have some cross over with https://github.com/httpwg/http-extensions/issues/1216 <https://github.com/httpwg/http-extensions/issues/1216> so if you coud take at look at those and add anything more to them it would be appreciated.

Sounds great, thank you! 

Much appreciated, 
Eric

---

From: Yoav Weiss <[email-masked]>
Date: Tue, 21 Jul 2020 21:06:34 +0200

+Ian Swett <[email-masked]> +Bence Béky <[email-masked]>

Google's Chrome and QUIC teams similarly intend to implement and support
reprioritization, for similar use-cases.
Upgrading images that are in or approaching the viewport as well as
downgrading the priority of large downloads both seem like important use
cases.
Video streaming use-cases where either quality-tier change or user actions
result in download changes also seem worthwhile (although I'm not sure if
cancellation can't handle some of those).

Another use-case I heard from folks is that of JS reprioritization as a
result of user-actions: scripts that large apps want to download in
low-priority can become critical as a result of a user-action that needs
them. Being able to reprioritize can significantly impact such apps'
responsiveness.

On Tue, Jul 21, 2020 at 7:59 PM Eric Kinnear <[email-masked]> wrote:

> Hi all,
>
> We (both in Safari and in URLSession for general HTTP usage on Apple
> platforms) are quite excited about the new priorities document and the
> opportunities it brings to simplify and focus on information that’s
> strictly necessary to communicate between the client, server, and
> intermediaries.
>
> Specific to reprioritization, we have several cases where we use, and so
> far believe we need to continue to use, reprioritization (although ideas on
> workarounds are always welcome!).
>
> First, the Web download case that’s been discussed (and thanks Patrick for
> running some related experiments for web traffic!), where we use
> reprioritization to modify the incremental bit on resources.
>
> Second, when streaming HLS video, we prioritize the currently playing tier
> above the other tiers. We may have several requests outstanding for the
> next several segments of video, and when we switch up/down we need to be
> able to reprioritize those alternate tiers. Unfortunately, so far it’s
> looking like not being able to reprioritize these requests would prevent
> our implementation of the new priority scheme. For Low-Latency HLS, we
> certainly will need to use reprioritization if we’re to fit within the
> currently proposed priority tiers.
>
> Finally, a more generalized example. As we work to help customers and
> clients of the APIs we offer, we’ve found that many of our efforts to guide
> them towards appropriate prioritization of less important work at lower
> priorities is only enabled by the ability to raise that priority later when
> circumstances change.
>
> As a very contrived (but unfortunately close to real world) example,
> consider a case where we ask a client to de-prioritize loading of images in
> a list view that aren’t close to being scrolled into view by the user. If
> we can offer higher priority for those images once the user starts
> scrolling closer to having those items come into view, our clients are
> generally happy to initially load such images at lower priorities. However,
> if they’re stuck with that initial priority forever, they end up loading
> the entire set of images at a high priority *just in case* they might be
> eventually blocking render. A good bit of the time, that never happens, so
> we end up having everything at high priority when in reality we would
> rarely have needed to reprioritize the requests. And once everything’s at
> high priority, we no longer have the utility of the priority system at all.
>
> There are all sorts of ways to dissect that particular example, but the
> general response we’ve seen remains: folks are much more willing to fully
> utilize a prioritization system in the real world if they’re able to adjust
> the priorities that they assigned later on when they have more information
> or the circumstances change.
>
> Thanks,
> Eric
>
>
> Side note:
>
> There's one other aspect that the we think it'd be helpful to get a sense
> of -- what the implementer intent is regarding reprioritisation.
>
> In particular, it'd be very helpful to have an indication from each
> implementation -- in user agents as well as servers (including
> intermediaries) -- as to how likely they are to produce/consume
> reprioritisations if specified.
>
> Note that's per-implementation, *not* per-person, so please coordinate if
> your implementation has multiple participants here.
>
> are here.  It looks like the impact dropped quite a bit across the full 25k
> URLs but looking at individual tests the impact is quite dramatic when it
> does impact (and it does exactly what we'd expect it to do for those
> outlier cases).
>
> https://www.thehelm.co/ - (Filmstrip) - The main background image in the
> interstitial loads at < 10s vs 90s without reprioritization
> https://blog.nerdfactory.ai/ - (Filmstrip) - The background image for the
> main content loads at <5s vs 70s without reprioritization. No cost to DCL,
> just prioritized ahead of not-visible images.
> https://oaklandcitychurch.org/ - (Filmstrip) - DCL got much slower (11s
> -> 33s) as a direct result of the background image moving from 30s to 10s
> (the pop-up interstitial was delayed along with the scripts that control
> it).
>
> 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.
>
> - 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
>
> FWIW, I added a flag to turn off Chromium's H2 request prioritization. I
> believe +Pat Meenan 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)
>
> Eric's download example is a great one for exposing the risks that would
> come for an implementation that supported prioritization but not
> reprioritization.
>
> - When the user clicks on the link, the browser assumes it is doing a
> navigation and issues the request with the "HTML" priority (relatively
> - 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
>
>
> --

---

From: Yoav Weiss <[email-masked]>
Date: Tue, 28 Jul 2020 08:42:06 +0200

I ran the above by +David Schinazi <[email-masked]>, who better
represents the Chrome networking team than me. His reply is: "Chrome will
closely follow proposals related to HTTP/3 reprioritization, and is very
likely to implement a proposal that gets consensus in the IETF QUIC Working
Group"

On Tue, Jul 21, 2020 at 9:06 PM Yoav Weiss <[email-masked]> wrote:

>> First, the Web download case that’s been discussed (and thanks Patrick
>> for running some related experiments for web traffic!), where we use
>> Second, when streaming HLS video, we prioritize the currently playing
>> tier above the other tiers. We may have several requests outstanding for
>> the next several segments of video, and when we switch up/down we need to
>> be able to reprioritize those alternate tiers. Unfortunately, so far it’s
>> For the document as a whole, we’ve gotten some feedback internally that
>> it would be really nice if there were some (minimal, recommendation only)
>> https://blog.nerdfactory.ai/ - (Filmstrip) - The background image for
>> the main content loads at <5s vs 70s without reprioritization. No cost to
>> DCL, just prioritized ahead of not-visible images.

---

From: Yoav Weiss <[email-masked]>
Date: Tue, 28 Jul 2020 10:32:21 +0200

s/QUIC Working Group/HTTP Working Group/

On Tue, Jul 28, 2020 at 8:42 AM Yoav Weiss <[email-masked]> wrote:

>> Video streaming use-cases where either quality-tier change or user
>> actions result in download changes also seem worthwhile (although I'm not
>> sure if cancellation can't handle some of those).
>>
>>> the entire set of images at a high priority *just in case* they might
>>> be eventually blocking render. A good bit of the time, that never happens,
>>> so we end up having everything at high priority when in reality we would
>>> There's one other aspect that the we think it'd be helpful to get a
>>> sense of -- what the implementer intent is regarding reprioritisation.
>>>
>>> Note that's per-implementation, *not* per-person, so please coordinate
>>> if your implementation has multiple participants here.
>>>
>>> https://www.thehelm.co/ - (Filmstrip) - The main background image in
>>> the interstitial loads at < 10s vs 90s without reprioritization