Re: Experiences with HTTP/2 server push

Kazuho Oku <kazuhooku@gmail.com> Thu, 01 September 2016 05:03 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0027612D0A4 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 31 Aug 2016 22:03:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.569
X-Spam-Level:
X-Spam-Status: No, score=-7.569 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipTsIZ7ra_CU for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 31 Aug 2016 22:03:04 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37F9912D0D1 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 31 Aug 2016 22:03:03 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bfK4m-0000Kf-O7 for ietf-http-wg-dist@listhub.w3.org; Thu, 01 Sep 2016 04:58:08 +0000
Resent-Date: Thu, 01 Sep 2016 04:58:08 +0000
Resent-Message-Id: <E1bfK4m-0000Kf-O7@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <kazuhooku@gmail.com>) id 1bfK4b-0000JW-Iw for ietf-http-wg@listhub.w3.org; Thu, 01 Sep 2016 04:57:57 +0000
Received: from mail-wm0-f54.google.com ([74.125.82.54]) by lisa.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <kazuhooku@gmail.com>) id 1bfK4O-00017T-30 for ietf-http-wg@w3.org; Thu, 01 Sep 2016 04:57:54 +0000
Received: by mail-wm0-f54.google.com with SMTP id c133so59113784wmd.1 for <ietf-http-wg@w3.org>; Wed, 31 Aug 2016 21:57:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Y6N/gQM8SiksJM33t9Swv+RrntAOf8Zvl1dKGQ4I9LM=; b=JmYAO+kZVBjb4WAFPsnNnZm7aCcNmo5PeEZYMBMlQNkVylj7nMrT6XkP98tGUWZGd2 sQyK2kAdN6Q7L4S698M7iD6nvSFMjhYdkvUCp6eR5CsK+Txbdjyo7whaI/+iND44kst2 VDdBONgPJQ+v3SDAlezF1qMkmXI7bYgCQspd6C7MIhRT0MsF4ZrlAv9UeTZU1ha3Ae17 22gTEuHTSUoLl4w08m1LaeFEZzIEdbAlVC7ZXqXMAhcvaX4JjOiWT+0Gp3iBd6nyfINu 1f28XGTS4b8oWXWECF2GGJFF/5s4ly4ul9x2GVmWS81ryr/gygjkgKTJRTQnlbUGMM0r Fptw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Y6N/gQM8SiksJM33t9Swv+RrntAOf8Zvl1dKGQ4I9LM=; b=D7k3kwNuwsB/E1rxLhPocLewOQcV7xq0ek8COlOssu/NyAHBXWVe2q2XgeDnPpKRIF C4uxkyCIPAJFo1tmeYytXN7v7fruFm+aNIbMQZ4sLiIola25mFrb+uLrOERUfV/NVZYt Oi9PGt+vcBiI39KZEfY5CQmw7Rom/ol9bPKq6mZ7/d0aGJN9OsBf8pq+mui8lMEkD2Vf 8I5c690+EIqhj3XM+1+06DNapeJd1KWP9WG/ZWihukcz9noiNJf9GzYmhYNQvPwC37bL uF0CAtZq/ZyWElD1lQWqzp9f6RITdLW8U93ItDRm/eevNQmCW1Oal+WwDdipRG+gVLGe QmEQ==
X-Gm-Message-State: AE9vXwO/kWmn2VddnGGmrs0uknxs3wgEupErgMyae5eKqK8eM9oxBna8pFs9ebXb1tz4lbJ+9yo9TzHaAc1AKQ==
X-Received: by 10.28.212.211 with SMTP id l202mr13424391wmg.109.1472705836599; Wed, 31 Aug 2016 21:57:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.122.67 with HTTP; Wed, 31 Aug 2016 21:57:15 -0700 (PDT)
In-Reply-To: <CACZw55mUg_VjN3Q6TqPCb6udo3mQpoWQVNV5e2iYiNj=hC-2kw@mail.gmail.com>
References: <CACZw55mUg_VjN3Q6TqPCb6udo3mQpoWQVNV5e2iYiNj=hC-2kw@mail.gmail.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Thu, 1 Sep 2016 13:57:15 +0900
Message-ID: <CANatvzz0rBjkgV4yS+2hgspUj7wZ6y=NqojPyzHiPpvZVXzwEA@mail.gmail.com>
To: Tom Bergan <tombergan@chromium.org>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=74.125.82.54; envelope-from=kazuhooku@gmail.com; helo=mail-wm0-f54.google.com
X-W3C-Hub-Spam-Status: No, score=-5.0
X-W3C-Hub-Spam-Report: AWL=-1.280, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=1, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1bfK4O-00017T-30 b6b4c57b492fb3c769e393e2ff319e51
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Experiences with HTTP/2 server push
Archived-At: <http://www.w3.org/mid/CANatvzz0rBjkgV4yS+2hgspUj7wZ6y=NqojPyzHiPpvZVXzwEA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32368
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Hi,

2016-08-04 9:21 GMT+09:00 Tom Bergan <tombergan@chromium.org>;:
> 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/1K0NykTXBbbbTlv60t5MyJvXjqKGsCVNYHyLEXIxYMv0

Sorry for the late response. I have recently had a chance to discuss
the details of the document.

It is a great summary of what the issues related to push are. On the
other hand, it makes me sad that the fifth rule states "Consider
Preload Instead of Push".

While I understand that not using push could be a short term answer on
some deployments, I think we need to discuss how we should fix the
issues (detailed as first four rules) to make the Web faster using
push in the long term.

And my take against the issues raised in the document are as follows:


"Rule 1: Push Enough to Fill Idle Network Time, and No More":

Technically, HoB caused by a low-priority stream is an issue irrelevant to push.

Consider the case where a large HTML that loads a CSS is sent over the
wire. In a typical implementation, the server will pass a block of
HTML much larger than INITCWND to the TCP stack before recognizing the
request for CSS. So the client would need to wait for multiple RTTs
before starting to receive the CSS.

It is only the case that such inversion of priority (a
lower-prioritized response blocking a higher one) might happen more
frequently when push is used.

That said, as discussed at the workshop, it is possible to implement a
HTTP/2 server that does not get affected by HoB between the different
streams (see https://github.com/HTTPWorkshop/workshop2016/blob/master/talks/tcpprog.pdf).

I would suggest that regardless of whether or not push is used, server
implementors should consider adopting such approach to minimize the
impact of HoB.

It should also be noted that with QUIC such HoB would not be an issue
since there would no longer be a send buffer within the kernel.


"Rule 2: Push Resources in the Right Order"

My take is that the issue can / should be solved by clients sending
PRIORITY frames for pushed resources when they observe how the
resources are used, and that until then servers should schedule the
pushed streams separately from the client-driven prioritization tree
(built by using the PRIORITY frames).

Please refer to the discussion in the other thread for details:
https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0453.html


"Rule 3: Don’t Push Resources the Client has Already Cached"

As the document states, the short-time solution would be for a server
to track what it has pushed to the client, and ultimately (and
hopefully) the standardization of cache-digests would solve the issue.


"Rule 4: Use the Right Cookies"

I think this is a very interesting point.

As a server implementor, I have always dreamt of cancelling a push
after sending a PUSH_PROMISE. In case a resource we want to push
exists on a dedicate cache that cannot be reached synchronously from
the HTTP/2 server, the server needs to send PUSH_PROMISE without the
guarantee that it would be able to push a valid response.

It would be great if we could have an error code that can be sent
using RST_STREAM to notify the client that it should discard the
PUSH_PROMISE being sent, and issue a request by itself.

With such an error code, it would be possible for a server to
speculatively push a resource by fetching it on behalf of the client
(without cookies etc.) and if it fails, then let the client fetch the
resource (with all the appropriate credentials / conditions).

> 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



-- 
Kazuho Oku