Re: Extensible Priorities and Reprioritization

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.


On Tue, Jun 9, 2020 at 8:16 AM Bence Béky <bnc@chromium.org> wrote:

> Hi all,
>
> I find the statement that the client often learns information that
> influences priority after the request is sent conceivable.  To me this
> implies that the additional benefit of reprioritization is comparable to
> the benefit of prioritization in the first place.  Unfortunately, however,
> I do not have any data on the effect of reprioritization on the users' page
> load experience, neither for HTTP/2 or HTTP/3.
>
> However, I can speak to the complexity part.  I have implemented the
> PRIORITY_UPDATE frame for HTTP/3 both in the client and in the server
> network stack.  I consider the complexity of server-side buffering and
> resource usage limiting minimal.  Because of this, I oppose removing
> reprioritization from the Extensible Prioritization Scheme for HTTP draft.
>
> Since Chrome renderer has already been sending reprioritization signals to
> the network stack when an image goes in or out of the current view, now
> PRIORITY_UPDATE frames should be sent upon these events when using HTTP/3.
> Since we had reprioritization in place in the renderer for the HTTP/2 case,
> this essentially came for free for HTTP/3 with the network stack change.
>
> Cheers,
>
> Bence
>
> On Tue, Jun 9, 2020 at 12:08 AM Kazuho Oku <kazuhooku@gmail.com> wrote:
>
>> Hello all,
>>
>> Thank you for all the discussion.
>>
>> To me it seems that there's sentiment that reprioritization would be
>> useful, even if it is hard to immediately prove that it is. I share that
>> sentiment.
>>
>> At the same time, as others (mostly recently Lucas in this thread) have
>> pointed out, reprioritization is more complex to implement than compared to
>> just having initial priorities. That is because the servers need to take
>> care of frames arriving out-of-order across multiple streams.
>>
>> That brings my mind back to the question that Lucas posted: even if we
>> think that reprioritization would be useful, should that be an
>> indispensable part of Extensible Priorities?
>>
>> We know that the prioritization signals sent by clients are merely
>> advices; servers might or might not honor them. What we've learned from
>> HTTP/2 is that we cannot assume that the servers do the "correct" thing, if
>> the scheme being defined is complex.
>>
>> Based on these points, my preference is starting to lean towards *not*
>> having reprioritization as an indispensable feature of Extensible
>> Priorities.
>>
>> I am totally fine (and supportive) of having reprioritization as an
>> optional feature. I do not have a strong opinion regarding if it should be
>> kept as an optional feature of the current draft, or if it should be a
>> different draft.
>>
>> What do you think? Would the user experience deteriorate if the server
>> only supports initial priorities? Would that deterioration be significant
>> to the extent that it would be a blocker for us to proceed?
>>
>>
>> 2020年6月9日(火) 9:46 Eric Kinnear <ekinnear@apple.com>:
>>
>>> Hi all,
>>>
>>> As another datapoint, Safari (and URLSession for general HTTP use
>>> outside the browser) use reprioritization to update the incremental flag.
>>>
>>> One place where we do that update is during a download in Safari: since
>>> some responses are displayed and some responses are downloaded, we don’t
>>> know upfront if we’re going to be rendering the content onscreen or putting
>>> it in the downloads list. More generally, we support the concept of “fetch
>>> the response for this request” as well “download this resource to some path
>>> on disk for me to deal with later”, and switching between them causes us to
>>> signal whether we are [no longer] interested in incremental delivery of the
>>> resource.
>>>
>>> Unfortunately, we don’t currently have any numbers to share about
>>> efficacy here, but it does seem as though the ability to update the value
>>> that we sent is key in supporting an API that allows both directions of
>>> update:
>>> - Clients can defer updates to a resource, knowing that they can
>>> “re-request” such incremental updates should their user navigate back to
>>> some particular UI that would benefit from displaying the results of
>>> incremental delivery.
>>> - Clients can always request incremental updates and know that they can
>>> defer those incremental updates once they are able to identify that the
>>> response will not be rendered onscreen.
>>>
>>> Anecdotally, we do know that offering the ability to adjust how the
>>> on-client-device data delivery behaves can significantly impact throughput
>>> itself and also power cost (mostly due to changes in batching during
>>> delivery).
>>>
>>> Thanks,
>>> Eric
>>>
>>>
>>> On Jun 4, 2020, at 4:33 PM, Lucas Pardue <lucaspardue.24.7@gmail.com>
>>> wrote:
>>>
>>> Hello folks,
>>>
>>> The Extensible Priorities draft has an open issue on the topic of
>>> reprioritization [1] and the May 2020 HTTP Interim session [2] pivoted
>>> towards it. The discussion highlighted that reprioritization is something
>>> we need to get to the bottom of in order to unblock progressing this draft.
>>>
>>> Our definition of the reprioritization feature is purposefully narrow,
>>> but the frame-related mechanics cause complications for implementations.
>>> One option on the table is to take reprioritization out of the critical
>>> path of draft-ietf-httpbis-priority by extracting the text to leave a
>>> simpler definition of just the scheme and the Priority header signal. The
>>> extracted text could be put in a separate I-D, reworked, replaced, or
>>> dropped altogether. The choice of action is ultimately up to the WG, so
>>> that is why we’re sending this email.
>>>
>>> Removing reprioritization from draft-ietf-httpbis-priority sounds pretty
>>> drastic but in all the work that’s got us here, we’ve struggled to find
>>> data that backs up its efficacy.
>>>
>>> Reducing Extensible Priorities to its core, clients issue priority
>>> signals (U and I) based on the expectation that the server, if possible,
>>> will transmit responses in the order of their urgency and request order
>>> (inferred by stream ID). Reprioritization is a client sending a subsequent
>>> signal (U’ and I’) that modifies the priority of in-flight responses.
>>> Reprioritization is not:
>>>
>>>
>>>    - Sending a batch of requests and signalling the desire for later
>>>    requests to be sent before earlier ones. By design, that is supported using
>>>    urgency.
>>>    - Purposeful ordering of requests to meet a priority objective. This
>>>    a client implementation choice.
>>>    - Aborting requests or responses that are in flight. By design, that
>>>    is a function provided by HTTP/2 or QUIC streams that is actioned by
>>>    implementation choice.
>>>    - Manipulating a dependency tree through the lifetime of a
>>>    connection. By design, that is not required.
>>>    - Any other mechanisms to adjust the server’s scheduling of response
>>>    data. That is out of scope.
>>>
>>>
>>> We’d be very interested to hear from people who support keeping
>>> reprioritization and can provide data, directly or indirectly, that the way
>>> it is applied in the extensible priority scheme provides tangible benefits.
>>> Data to the opposite effect is also of interest.
>>>
>>> Cheers
>>> Kazuho and Lucas
>>> Extensible Priorities Editors
>>>
>>> [1] - https://github.com/httpwg/http-extensions/issues/1021
>>> [2] -
>>> https://github.com/httpwg/wg-materials/blob/gh-pages/interim-20-05/minutes.md#priorities
>>>
>>>
>>>
>>
>> --
>> Kazuho Oku
>>
>