Extensible Priorities and Reprioritization

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