Re: Concerns about HTTP/2 Priority

On 3 November 2014 14:16, Mark Nottingham <mnot@mnot.net> wrote:
> If you (or anyone else) can suggest smaller changes (i.e. ones that don’t affect the wire format or greatly change semantics) that can gain popular acclaim in a reasonable amount of time, that may be a useful way forward; I’d encourage folks to consider what can be done within that scope. Having said that, we have one remaining issue from WGLC, and it’s not going to be open much longer.

In that spirit, here's a very modest change to the spec that I'll
suggest.  But first I'll note that if you are willing to live with a
kludge, this isn't necessary to address the intermediation case (see
below for kludge details).

The change:
  Make it so that PRIORITY can be sent on a stream in ANY state.
  i.e., change so that PRIORITY is permitted in the "idle" state.

One of the concerns that Chad raised was that the current scheme does
not perfectly address the intermediation case.  And that's true, and
it has bothered me on and off.  But only because I keep forgetting
that I was happy with the kludge.  The other concerns bother me much
less.

The kludge is this: you allow a single request from each client at
your intermediary to establish a node in the dependency tree that is
subsequently used as an anchor for all their requests in place of
stream 0.  Since this node will live for some time past the lifetime
of the initial request, you can treat this as a new root for that
client.  You can periodically shift which stream you use as an anchor
if you are concerned about an old stream being garbage collected for
being too old, even though it is still in use.

That could address the intermediation case, which I think was the
important one.  Being able to prioritized unused streams would of
course make it marginally easier.

If you allow the prioritization of unused streams, you can create
nodes in the dependency tree that can be used to form pseudo-groups.
These could easily address the intermediation concern.  It doesn't
perfectly address the "all the JS before all the CSS" scenario, but
Mark's note there about the server knowing things about priority
applies.  A robust scheme that properly addressed that case would not
be as trivial a change.

Here's a second kludge that relies (a little more) on unused streams
with priority: if JS has to come before all CSS and you have three of
each, then:  Send requests for all the JS with as high a weighting as
you feel you can use.  Then, prioritize a new unused stream with the
same dependency as all the JS, but with very low weight (i.e., 1).
CSS requests can hang off that low weight stream.  Any server with any
sense will then avoid spending cycles on the CSS unless it is blocked
on the JS.

As far as I can tell, this second kludge is more difficult to get
right without the change I suggest, but it's not impossible to get
something approximating it.

On balance, I'm not sure that we're going to get much without actual
experience with any scheme we propose, so I don't think that big
changes are going to be worthwhile.  Well, unless a well-researched
and extensive study suddenly manifests itself, that is.

I'm not even sure if the tweak above is worth doing, except that it
makes the scheme slightly more flexible, making the proxy case easier
to solve.

Received on Monday, 3 November 2014 23:07:13 UTC