Re: Implementation Notes on Server Push

William Chan (陈智昌) <willchan@chromium.org> Tue, 14 May 2013 19:51 UTC

Return-Path: <ietf-http-wg-request@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 DF7C321F84AD for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 14 May 2013 12:51:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.426
X-Spam-Level:
X-Spam-Status: No, score=-8.426 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKz4NJJvXOZy for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 14 May 2013 12:50:57 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 11A2421F8532 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 14 May 2013 12:50:57 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UcLEn-0007oH-RV for ietf-http-wg-dist@listhub.w3.org; Tue, 14 May 2013 19:50:17 +0000
Resent-Date: Tue, 14 May 2013 19:50:17 +0000
Resent-Message-Id: <E1UcLEn-0007oH-RV@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <willchan@google.com>) id 1UcLEa-0004lX-F2 for ietf-http-wg@listhub.w3.org; Tue, 14 May 2013 19:50:05 +0000
Received: from mail-qa0-f44.google.com ([209.85.216.44]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1UcKzT-0006LP-8H for ietf-http-wg@w3.org; Tue, 14 May 2013 19:34:30 +0000
Received: by mail-qa0-f44.google.com with SMTP id o13so2360659qaj.3 for <ietf-http-wg@w3.org>; Tue, 14 May 2013 12:34:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=uwp4uIaTwiG9AVaqHp+x6WCAcyau0rpSs58jkbFzMvA=; b=oVntzWCviOmdKnOVT4xdiNJJYXLOtNguVsQ7f1AvcvCG6AWIUVPmiOtJxk7WHXlxdN B71MN3q763bC/bFWwv4TEhDj2tNOZrmIVhwfc14J9r/TtXEb9QBreh4DW8zALF7i5WlJ fG4psOMzp/9+31ciL1ZMlsh0fJ82oRDy6Tem9K/6I/rBP7DCZgK282DATZacEFP1Un+/ p6jEdWNigfm2UbZxc7lD81YJEXGUoKFt5sXz2hNZ5EEOxo3x/FNLN1CtGypScPQsZ125 qA2vBVnJQq2lF3O10gtX2mYOBMlR8rzMj+ZiOG/lQA53KcN4MxnZ0mkzx7DEurhK96/u OhPQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=uwp4uIaTwiG9AVaqHp+x6WCAcyau0rpSs58jkbFzMvA=; b=ZOu7FJZT1B1WBU0cEuKh7ryz/6XBocoK6yAfJZVJ+dgZrmnxmLs0vlPExhAEafJP80 Ov2C9N3YNcAbfvD94DdVF1DCLdDt7x7Am7pykVlaNN34Lk6j9SMfoWX3wfMXtdfOc2p/ 3U5FPXswLenMUQEsGYTDjQnr3FBbU6v961kOo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=uwp4uIaTwiG9AVaqHp+x6WCAcyau0rpSs58jkbFzMvA=; b=nTTVE6Wv1/8xp2FPLoGd5ds3XmBAmOkWcceCxjJvdVwaBR+u7wizL0PYBt9m1Wbrs0 S5+nxSRQtV5sQyC6K0M89tbRkeagzywVGASq0p0ZjWCZt0nDYCQD0MV7ULmY0k4rsoWQ RAAoA09nzkPkYep3JXISNEVMEZIoteyRegHJ2/kH24Xt0xtVO3b/DfSMMn7qB7TkFvjz HEcc4zgnrIS+OQN+Q3C7DDqsBTEcJb8LJkm4XJMwQBLAq6bsrGQLR5r9zjEpUre+KD9p XEC6dfsVoh+e9VDNOX0aaNt2hhdubViRmgF/BC2W1tQ+Qft4rwozUEPxjWKilYiGwqIC 2PCg==
MIME-Version: 1.0
X-Received: by 10.229.94.70 with SMTP id y6mr1490935qcm.46.1368560041203; Tue, 14 May 2013 12:34:01 -0700 (PDT)
Sender: willchan@google.com
Received: by 10.229.61.25 with HTTP; Tue, 14 May 2013 12:34:01 -0700 (PDT)
In-Reply-To: <CAOdDvNqXhG7+xbvBwctQCR4tZePKByw75SR5oBamXTymZa7myA@mail.gmail.com>
References: <CAOdDvNqXhG7+xbvBwctQCR4tZePKByw75SR5oBamXTymZa7myA@mail.gmail.com>
Date: Tue, 14 May 2013 16:34:01 -0300
X-Google-Sender-Auth: yK5jhxoLTPQEjLytjyVB4KzV6lk
Message-ID: <CAA4WUYgU5mkHv-WZ0XoWg2NDj4oz2TVTwPOJrE18P_cHYDCmGA@mail.gmail.com>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=14dae94ee3a31c40e804dcb2b722
X-Gm-Message-State: ALoCoQloyrb27GyYCAIWkJY8A6rrFelB6IYZw1wbYLwivbw8x4VbsTqzY5/pFvrYv3S8nHm5omq5mMsgl9YsXVtpO7ljQYWRjKW0cvY9eoleu+5uWSnxbLHjMAZciIXKx3gNNmxLnnYTdvqpTrOa0DV/jHSuQgJCtAzog6yinGKUYrkBH17bx+a6v393VXG+vAU+tULVBpku
Received-SPF: pass client-ip=209.85.216.44; envelope-from=willchan@google.com; helo=mail-qa0-f44.google.com
X-W3C-Hub-Spam-Status: No, score=-3.8
X-W3C-Hub-Spam-Report: AWL=-2.418, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.629, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UcKzT-0006LP-8H af6e87443962891c7a66928ea3522d22
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Implementation Notes on Server Push
Archived-At: <http://www.w3.org/mid/CAA4WUYgU5mkHv-WZ0XoWg2NDj4oz2TVTwPOJrE18P_cHYDCmGA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17993
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>

Thanks for the feedback, this is great to hear.

On Tue, May 14, 2013 at 4:14 PM, Patrick McManus <pmcmanus@mozilla.com>wrote;wrote:

> I'm wrapping up a Firefox implementation of spdy/3 server push and wanted
> to provide some ietf level feedback because that mechanism is largely
> intact in the current http2 work in progress draft.
>
>
>    - 304's seem to be a common cause of wasted pushed streams. I would
>    see servers respond with a 304 for index.html and still push 200 responses
>    for a.css and b.js when in a non-push world that would have been either 1
>    or 3 304's. Maybe we should have a rule that you can only push to an
>    assoc-stream of 2xx ?
>
>
I'm hesitant to mandate this behavior. I think it's best to say that
servers should figure this out. Server push is an advanced feature and I
think it'll take us a little while to develop best practices around its
use. This sounds great for a best practice recommendation.


>
>    - There is language in the spec that if the client resets a stream
>    that it implicitly resets any associated streams too. That was complicated
>    to implement and pretty much broke my stream state model internally - while
>    researching it it appears that mod_spdy and chrome don't implement it at
>    all. The spec has an editorial note about removing that feature and I favor
>    that removal.
>
> The interesting thing to note is our two major server implementations of
push (mod_spdy & Jetty) both did not implement the implicit reset. But
which side bears the responsibility for explicitly resetting the stream?
Smart servers will reset the push streams still in order to save sending
unnecessary data, which is kinda what the implicit reset would suggest
they'd do, except without explicitly sending the RST_STREAM. None of our
existing implementations were that smart though (I doubt any initial server
push implementation would be very well tuned, so I'm not dinging the
implementers. I mean, our Chromium implementation admittedly sucks and we
find rough edges all the time). If the server doesn't explicitly do a
RST_STREAM, then I think smart clients will probably send RST_STREAMs when
the parent stream is canceled.

>
>    - I found flow control for pushed streams immensely helpful. It lets
>    the client bound how much data can be pushed before there is a local GET
>    matched up with that. Relatedly, I changed my default SETTINGS window size
>    from a ~infinite value to be a smaller push-apropos value and then
>    pipelined a window update with each odd SYN_STREAM to make pulled streams
>    ~infinite again while preserving the smaller limit for push and this worked
>    fine with all existing servers to my pleasant surprise. That seems to mean
>    at least the spdy/3 windowing mechanism is simple enough for people to get
>    right.
>    - As with other parts of the spec, I was faced in some implementations
>    with some very large data frames (90+KB) from servers when testing. Such
>    frames are impervious to CANCEL or any mechanism we might use to change
>    priorities driven by the client :(..  HTTP2 is doing the right thing by
>    creating a smallish max frame size.
>
> I assume you're testing against mod_spdy or Jetty. If you see this, we
should fix those implementations. I think the developers will be very
welcoming of feedback.

>
>
>
> Obviously this is implementation experience with testing and isn't real
> operational experience yet.. that will come.
>
> -P
>