Re: Retrospective on PRIORITY

Interesting dig up Mike, I didn't follow the discussion during  2014 and
therefore had always wondered why the priorities ended up being a tree
instead of something simpler. Do you mean that we ended up with a
tree-based priority scheme because of the assumption that most people would
be deploying HTTP/2 through proxies that collapse multiple sets of streams
from client to proxy to a single set of streams from proxy to  origin?

As of your question, I'm more on your curious-side of the matter, though I
have some opinions.

We are not proxy implementors, but we sell an HTTP/2 solution that makes
strong use of priorities. We have opted for equipping the server with ways
to set priorities between streams a-priori, without directly using the
priority frames from the browser. We collect the priority frames and
combine then with other nuggets of information (e.g. information derived
from the browser's DOM in a sandbox) to program the priorities.

One of the reasons we prefer this approach is because of the latency of the
entire browser-network-server system, even when there are no proxies in the
middle. We have noticed that is not just pure network latency we have to
deal with, but also different buffers, caches, CPU saturation on the
server, and particularly, parsing and decompression time on the browser. We
have observed the last component to be significant even on moderately
powerful laptops, the situation on mobile devices being  worse. This system
latency means that priority frames often arrive a bit too late to be
effective, even without deploying HTTP/2 Push.

Back to your question, I would expect  a proxy that just relies priority
information to make this latency higher. A proxy can of course  improve
things by being  more sophisticated ... in some way, which I can't exactly
imagine. So, from my point of view, a flat priority indication would make
more sense.





On Tue, Apr 18, 2017 at 8:46 PM, Mike Bishop <Michael.Bishop@microsoft.com>
wrote:

> 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?
>



-- 
Alcides Viamontes E.
Chief Executive Officer, Zunzun AB
(+46) 722294542
(www.shimmercat.com is a property of Zunzun AB)