Re: Extensible Priorities and Reprioritization

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
>