Re: Implementation Notes on Server Push

Martin Thomson <martin.thomson@gmail.com> Tue, 14 May 2013 23:59 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 7C39D21F8F11 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 14 May 2013 16:59:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 jxIMW4ELs8G5 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 14 May 2013 16:59:42 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id D790621F8F15 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 14 May 2013 16:59:41 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UcP6i-0005J6-Tk for ietf-http-wg-dist@listhub.w3.org; Tue, 14 May 2013 23:58:12 +0000
Resent-Date: Tue, 14 May 2013 23:58:12 +0000
Resent-Message-Id: <E1UcP6i-0005J6-Tk@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1UcP6W-0005HT-DJ for ietf-http-wg@listhub.w3.org; Tue, 14 May 2013 23:58:00 +0000
Received: from mail-we0-f177.google.com ([74.125.82.177]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1UcP6U-00061f-Dy for ietf-http-wg@w3.org; Tue, 14 May 2013 23:58:00 +0000
Received: by mail-we0-f177.google.com with SMTP id q58so1025151wes.36 for <ietf-http-wg@w3.org>; Tue, 14 May 2013 16:57:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=dcRnuZrKrt5gE7bOfzqZr96j4dbCc9BMkAunA5TNCMs=; b=VM5yjWeY22aaa1eshnQO/gTFonfWj3xBLo5wCm5gtqLfDGwJMPq1c0L1tjGFtDtDmq rpoWVdDK8rh0Ah+mwnG0Ddwj8OPpl5xjKsuYIGWCsxxEwJNgLpdm8ghOcVX6g+mRsNBe ly26I2hz9S1GvhT/4vgNQSRekqcRUNhGnd4x9KO6LNkTa657Rc3P+tMtDM17LIOHW4oH GA2tPwQDLmNNY09GvPwM2Z0qEpNOzj0BadyQb8CovqLra2Xtpha7GWcaBzHcI830f3ke 9EkuUACJ5fXHSTe0QuP+6ENooxKcRpYGbFvP9zN4WcQlspmAdZVODjRK2GQSHWvs9p+K EsVw==
MIME-Version: 1.0
X-Received: by 10.194.143.100 with SMTP id sd4mr407667wjb.54.1368575852334; Tue, 14 May 2013 16:57:32 -0700 (PDT)
Received: by 10.194.20.135 with HTTP; Tue, 14 May 2013 16:57:32 -0700 (PDT)
In-Reply-To: <CAOdDvNqXhG7+xbvBwctQCR4tZePKByw75SR5oBamXTymZa7myA@mail.gmail.com>
References: <CAOdDvNqXhG7+xbvBwctQCR4tZePKByw75SR5oBamXTymZa7myA@mail.gmail.com>
Date: Tue, 14 May 2013 16:57:32 -0700
Message-ID: <CABkgnnURhLU3RJnMDxwErELedAmGKWcVgkE+B+Pn6vR3oYjJ6A@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=UTF-8
Received-SPF: pass client-ip=74.125.82.177; envelope-from=martin.thomson@gmail.com; helo=mail-we0-f177.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.667, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UcP6U-00061f-Dy 238bb20e31c9c056c55663a24dd48b08
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Implementation Notes on Server Push
Archived-At: <http://www.w3.org/mid/CABkgnnURhLU3RJnMDxwErELedAmGKWcVgkE+B+Pn6vR3oYjJ6A@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17995
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>

Great feedback.

On 14 May 2013 12:14, Patrick McManus <pmcmanus@mozilla.com> wrote:
> 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 don't know if outright prohibition is necessary.  It might be that
a.css has changed, but index.html hasn't.  But I consider that
unlikely in the general case.  A word of caution seems appropriate.

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

I added that text, so I tend to agree. :)

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

That's interesting.  Do you believe that it would be worthwhile
splitting the initial window size setting in two?  One for streams I
initiate, one for streams you initiate?  That would save you a window
update on every new stream.

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

Small is good, but how small is small enough?