The blocking risk of Priority header when used a signal to the local stack

Hello all,

Following the WG session during IETF106 I wanted to pick up on a strand of
thought that I think Martin Thomson made at the microphone. I'm happy to
have a wrong interpretation, hence replaying it to the list for correction
or affirmation.

One of the ideas presented by the design team is that the Priority header
can be a stack-local control message that could cause the generation of a
version specific frame. This frame has certain requirements on ordering, it
must be issued before the request e.g. PRIORITY before HEADERS.

IIUC Martin identified a risk that delays in the stack-local signal could
cause delays in issuing the request e.g. HEADERS transmission is blocked
until the local stack can determine how to populate PRIORITY.

For many cases I'm sure this risk is low due to information locality and
APIs that use complete Request structures. However, a header streaming
example was mentioned and I wonder if this is a hypothetical case, or
something that can happen today.

One possible way this risk manifests could affect the ordering of request
transmission; high priority requests that somehow have their stack-local
signal delayed could get issued later than lower priority requests.  And it
is easy to imagine this being quite an opaque problem for developers to
debug.

There is also an anti-pattern mitigation to such a blocking problem.
Satisfy the requirement to always send PRIORITY first by applying a default
of either: the implementation's choice, or the default urgency/progressive
values by simply sending an empty PRIORITY. Then, reprioiritize the request
later based on more information. This is bad on many levels.

In contrast, expressing the initial priority as a header keeps it inline
with the request object for which it is signaling intent. This has some
advantages. But apply the above ordering problem in reverse, a server
processing requests only gains understanding of their priority when it
consumes the header. Should it block until that becomes available (or could
it even assume a default?). A partial design mitigation to this would be to
define priority as a pseudo-header, which forces the early emission and
processing of such information, and rules out trailers completely.

In summary, is blocking such as this a problem and should a solution try to
design around it?

Lucas