Re: Retrospective on PRIORITY

[Kazuho Oku <[e-mail]>]

Hi Mike,

Thank you for raising this interesting discussion.

2017-04-19 3:46 GMT+09:00 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?

I would argue that for a reverse proxy there is no much need to
prioritize requests sent to origin, since the majority of HTTP
requests are requests for static assets and hence are terminated at
the reverse proxy. Users of a reverse proxy that sends all requests to
origin (e.g. WAF-as-a-service) might have a different opinion, though.

OTOH, I am kind of negative about designing a new priority scheme. The
priority scheme of HTTP/2 works fairly well, and we have experiences.
Is there any reason not to reuse?

My point is that we should better not risk delaying the delivery of
QUIC by trying to replace something that might be a bit complicated
but is already known to work well.

-- 
Kazuho Oku