Re: Experiences with HTTP/2 server push

Tom Bergan <> Fri, 05 August 2016 16:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 42BB012D872 for <>; Fri, 5 Aug 2016 09:31:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.307
X-Spam-Status: No, score=-8.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ePZtNMjP6JnF for <>; Fri, 5 Aug 2016 09:31:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F394212D743 for <>; Fri, 5 Aug 2016 09:31:46 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bVhxx-0006NJ-AT for; Fri, 05 Aug 2016 16:27:21 +0000
Resent-Date: Fri, 05 Aug 2016 16:27:21 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bVhxq-0006Lx-Ri for; Fri, 05 Aug 2016 16:27:14 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bVhxk-0005Pq-Jg for; Fri, 05 Aug 2016 16:27:13 +0000
Received: by with SMTP id 38so304557530iol.0 for <>; Fri, 05 Aug 2016 09:26:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0qP/q4nSaqnz/uH65ZZjFyqTjBm4OAoekrq75rozpk8=; b=ZOBMIbDHnXbcBTAjgqXutruaMXMnd2Q9U32uLJQT/yWyvawOaoOFTwhMO0H4cfVcuE pNAfLkgj0sWL2/Y/OJap3pv1lxdINynF1vw2EqqpeEtg5OSKS6kBCwmuKzT7CHLcqr2a /4hVdvih0dUvKrUHfgPH7OUUzPO/jogKLenaY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0qP/q4nSaqnz/uH65ZZjFyqTjBm4OAoekrq75rozpk8=; b=ETcRqPvLPf0jqfmM5zGGMaq+MRVwMMEvLPrsDdK0aMFRiHG9w4EVETs+nKUPEGH4w0 YZ8/dv7LewAZcAWAGDfGneivdVtRrSIAL28uy0GPUIh0ev+AU2JNzoL4DOy8FYktIIk9 +58v78Bc5anAo2NioMxJZReLiEXPC6uAie2Kt0P1PcJV8KYxPqY2COoFn5EEkKAq8rlU zRKeg+/aTRhFXQRxBVu6mDRHG6ops5CTu6TKhFrKqfPRIMy3+MV9e6M+ZSdpTGjVcSDh M3P+qf8uM9YaT8lqQVXZbGZbDbVjGEUbZl9FHDgrl81mGba6736SBQwiJgvXhyYN4/wB Eesg==
X-Gm-Message-State: AEkoous2pP4pmuyC8fxzVRX+RGHSEihtfVZdEJx89984EXt4oLmMZsj2LvfHaBNggTrIs8Qw
X-Received: by with SMTP id 26mr77399276ios.85.1470410437830; Fri, 05 Aug 2016 08:20:37 -0700 (PDT)
Received: from ( []) by with ESMTPSA id f9sm4011065itc.10.2016. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Aug 2016 08:20:37 -0700 (PDT)
Received: by with SMTP id u186so24507050ita.0 for <>; Fri, 05 Aug 2016 08:20:36 -0700 (PDT)
X-Received: by with SMTP id w63mr5047180itc.56.1470410436237; Fri, 05 Aug 2016 08:20:36 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 5 Aug 2016 08:20:35 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Tom Bergan <>
Date: Fri, 05 Aug 2016 08:20:35 -0700
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Martin Thomson <>
Cc: HTTP Working Group <>
Content-Type: multipart/alternative; boundary="001a114a92a4ba5c7b0539549bfd"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.7
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1bVhxk-0005Pq-Jg c6bd97c96c1769b84dc49680d0f09139
Subject: Re: Experiences with HTTP/2 server push
Archived-At: <>
X-Mailing-List: <> archive/latest/32197
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Fri, Aug 5, 2016 at 5:28 AM, Martin Thomson <>

> 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
We are aware of a few servers that update the priority tree like this,
e.g., see Apache's h2_session_set_prio

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