Re: Extensible Priorities and Reprioritization

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 <https://github.com/httpwg/http-extensions/issues/1021>
> [2] - https://github.com/httpwg/wg-materials/blob/gh-pages/interim-20-05/minutes.md#priorities <https://github.com/httpwg/wg-materials/blob/gh-pages/interim-20-05/minutes.md#priorities>