Re: Extensible Priorities and Reprioritization

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