Retrospective on PRIORITY

[Mike Bishop <[e-mail]>]

I had an interesting side conversation in Chicago, where it was proposed that HTTP/QUIC pull out the H2 priority scheme and go with something simpler, or at least make all priority schemes extensions so client/server can negotiate which one they want to use.  I think efforts like that probably need to be driven out of the HTTP WG rather than the QUIC WG, but it did raise some interesting questions.

Back in this thread (https://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/0396.html), we had a proposal which permits expressing the same desired end-states, but requires the client to do the tree collapsing instead of the server.  That means clients can be as simple or as complex as they desire, and the server just needs to see the end output of whatever fancy algorithm they're using.

The argument that drove the current scheme was that when running a proxy, you need a way to be able to encapsulate the priorities declared by one client onto priorities in a back-end connection while isolating the user's declared priorities from other users' declared priorities.  Clearly you can't just do a straight pass-through, or everyone is incented to use the top end of the priority range.  The scheme that ultimately landed in H2 allows this at the proxy:

  *   Every user gets a placeholder node; weights of placeholders represent relative priorities of the users
  *   Anything the user declares depends on stream zero in their connection depends on this placeholder; weights unchanged
  *   Anything the user declares depends some other stream still depends on that stream; weights unchanged
Also, when something changes near the root of the tree, the client might be issuing a lot of PRIORITY frames to update everything as a result if all the server gets is the output of the tree.  In the video playback case, finishing the current chunk is a change near the root of the tree that's fairly common.

With any simpler scheme, the proxy either has to ignore declared priorities or do work to coalesce declared priorities across users.  And obviously, if you have tiers of proxies, the same logic can be applied multiple times and still get a sensible result at the back-end.  You could bring that idea into the proposal linked above, but you'd need groups-of-groups, and groups-of-groups-of-groups, and soon you wind up with something that looks a lot like a dependency tree again.

I think any reasonable priority scheme will work fine between client and server - it's the proxy (forward or reverse) that needs to see the uncollapsed tree so that it can merge trees between clients.  Now that H2 is deployed, I'm curious how proxy vendors are finding this to work out.  Do you find the additional richness useful, or is there more appetite for simpler priority schemes?  Are you actually using the algorithm above, or something like it?