Re: Extensible Priorities and Reprioritization

Hey Patrick,

On Fri, Jun 5, 2020 at 3:41 PM Patrick Meenan <patmeenan@gmail.com> wrote:

> If you're looking for a distilled test case, my HTTP/2 prioritization
> test page
> <https://github.com/pmeenan/http2priorities/tree/master/stand-alone> used
> for the https://ishttp2fastyet.com prioritization support tracking.  It
> loads a bunch of images "below the fold" and then after they start loading
> it injects 2 images (one after the other) into the viewport.
>

It's a good test case but I wonder how it directly translates to
reprioritization frames. I think understanding specific wire behaviour in
H2 and mapping that into Extensible priorities is the key to figuring out
if PRIORITY_UPDATE frames are required. I suspect that in H2 and chrome,
your test case triggers an implicit tree reshuffle because the new request
is inserted somewhere with an explicit dependency.  Or maybe it triggers a
whole set of PRIORTY frames that shuffle the tree? How does the behaviour
of other implementations look on the wire?

That said, I think things play out differently in Extensible priorities.
The "below the fold" images can be requested at an urgency of N, the
injected images are requested later at a higher urgency between N-1 and 0.
A server that follows the specification's recommendations will pass your
test; no reprioritization frames are required to be sent.


> Building a whole separate "VIEWPORT" scheme that is browser-specific feels
> a bit like punting on the problem and effectively killing it, particularly
> since most of the drive behind simplifying prioritization was for the
> browser use case anyway.
>

Point taken. Although I will clarify that some of the drive toward a header
was to expose more control to web developers. We might also want to
consider how this scheme's reprioritization feature would or would not be
exposed. That might limit it's usefulness even further.

What are the difficult points around implementing the current
> reprioritization plans? Is it a sequencing problem with streams and
> out-of-band changes? Would it help if the priority change was actually a
> stream-level message and specifically changed just the urgency of the
> requested stream (with any server-side headers overriding even the changed
> urgency)?
>

The H2 request/response exchange sequence [1] requires the final frame in
the sequence to bear the END_STREAM flag, which closes the send side of the
stream and prevents any more frames being sent. Furthermore, see the thread
Mike Bishop started about H2's lack of grease and the impact on extension
points [2], support for extension frames on request streams might cause
connection failures. Since then Cloudflare has fixed a regression that
addresses this problem but I'm unsure of the status in the wider ecosystem.

For the above reasons, restricting PRIORITY_UPDATE to the control stream
(H2 stream 0) is a safe deployable approach. But it introduces cross-stream
referencing and that requires some careful consideration for
implementations, such as buffering and resource usage.

Channeling the WG discussion, I think it is reasonable to ask if clients
are interested in implementing the reprioritization feature. Because if we
don't exercise it with running code, it is hard to iron out the issues and
capture the necessary detail in the document. As evidenced by the problems
found in H2 stacks after they widely shipped.

Cheers
Lucas


[1] - https://tools.ietf.org/html/rfc7540#section-8.1
[2] - https://lists.w3.org/Archives/Public/ietf-http-wg/2019OctDec/0047.html