Re: Experiences with HTTP/2 server push

On Fri, Aug 5, 2016 at 5:28 AM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> I didn't read through this in detail, but there is a fairly big error
> here when it comes to the description of using priorities.  You say:
>
> > One way to implement this is for the server to update its HTTP/2
> priority tree, **then send PRIORITY frames to the client that make A the
> exclusive parent of C** and C the exclusive parent of D. This is an
> attractive implementation because the server can continue using the HTTP/2
> priority tree to order requests C, D, and B.
>
> The server can't send PRIORITY frames in this way.  Or at least, that
> won't have the effect you think it does.
>
> The server can (and should) just send as it sees fit, using as input
> its own knowledge and the priority that the client has provided.  If
> the server sends PRIORITY, that is to affect client processing (hint:
> that's not going to happen here). Given that the space that you are
> examining is a problem for server-to-client transmission only, the
> server expressing priority is pointless.


Yes, we agree with you. The point of that section is that the server should
*not* send PRIORITY frames like that. Here's the next paragraph:

> However, this is fundamentally racey: if both ends (client and server)
update the priority tree concurrently, it can easily become out-of-sync.
For this reason, we advocate not mutating the priority tree on the server.

Let's say the server wants to prioritize a subset of streams differently
than the priorities specified by the client, or differently from the
default priorities. How should it actually implement this? The simplest
implementation is to mutate the H2 priority tree directly. This makes the
H2 priority tree the single prioritization data structure in the server.
It's also attractive because H2 priorities can be communicated to lower
layers like QUIC
<https://tools.ietf.org/html/draft-hamilton-early-deployment-quic-00#section-9>.
We are aware of a few servers that update the priority tree like this,
e.g., see Apache's h2_session_set_prio
<https://github.com/icing/mod_h2/blob/master/mod_http2/h2_session.c#L1245>.

However, if the server does this, it has a problem: the H2 priority tree is
a shared data structure. If it makes a change, its local copy of the data
structure can be out-of-sync relative to the client's copy. A future
PRIORITY frame from the client may have a different meaning than intended
if the server has already changed its tree locally. The sentence you quoted
describes the reactions of a naive server to this problem: Maybe I can keep
the client's tree in sync by sending a PRIORITY frame? (Sorry for not
making this more clear.) Of course, this doesn't actually solve the
problem, since the server's PRIORITY frames could race with the client's.
(Note that we're not aware of any servers that actually do this; we were
just hoping to prevent any from trying.)

RFC 7540 talks about another kind of race: removing closed streams from the
tree. The solution proposed by the RFC is to keep closed streams in the
tree as long as possible. The RFC does not discuss this other kind of race
-- reprioritizing streams on the server -- and this seems like something
servers are very interested in doing. AFAIK, no one has really studied the
impacts of this race nor provided guidance about how to avoid it. We don't
have any great solutions, either, we just wanted to raise the problem to be
sure that server implementors are aware of it.

On 4 August 2016 at 10:21, Tom Bergan <tombergan@chromium.org> wrote:
> > Hi all,
> >
> > Our team has been experimenting with H2 server push at Google for a few
> > months. We found that it takes a surprising amount of careful reasoning
> to
> > understand why your web page is or isn't seeing better performance with
> H2
> > push. We also encountered a lack of good documentation: How should one go
> > about using H2 push? What are the best practices? We tried to distill our
> > experiences into five "rules of thumb" that are described in this doc:
> > https://docs.google.com/document/d/1K0NykTXBbbbTlv60t5MyJvXj
> qKGsCVNYHyLEXIxYMv0
> >
> > The doc is a little long, but the first two pages give a decent tl;dr. I
> > suspect the ideas and conclusions will be "obvious" to many people on
> this
> > mailing list, at least in hindsight. Hopefully other folks interested in
> H2
> > server push will find this useful. Let us know if you have any comments.
> >
> > -Tom, Simon, and Michael
>