Re: Implementation Notes on Server Push

Roberto Peon <grmocg@gmail.com> Wed, 15 May 2013 00:09 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 5DDA221F8F38 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 14 May 2013 17:09:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 P4HS4O5X+Qnh for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 14 May 2013 17:09:42 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0532821F8F28 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 14 May 2013 17:09:42 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UcPHF-0002Pt-BZ for ietf-http-wg-dist@listhub.w3.org; Wed, 15 May 2013 00:09:05 +0000
Resent-Date: Wed, 15 May 2013 00:09:05 +0000
Resent-Message-Id: <E1UcPHF-0002Pt-BZ@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UcPH3-0002LF-KJ for ietf-http-wg@listhub.w3.org; Wed, 15 May 2013 00:08:53 +0000
Received: from mail-bk0-f54.google.com ([209.85.214.54]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UcPGn-0006NO-2j for ietf-http-wg@w3.org; Wed, 15 May 2013 00:08:53 +0000
Received: by mail-bk0-f54.google.com with SMTP id it19so51679bkc.13 for <ietf-http-wg@w3.org>; Tue, 14 May 2013 17:08:10 -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=GU3Rumxn23dy9euVKETzkWWh3lZ4OVdlLZgFFUfgw74=; b=VLCUJU1NgvQ0UmgTPsQKTecQ/0hbrdaVqt8u6L2v7SSVOXrKBgKsOqCFo3/PBXw3sk UVrwn6j3b3DUsn87h7KnZstIJ/SqYdFOXo+683mBIZ0MuVq6t/n18uPPRd85lzr9zKxI qn/PS9w0sEuhEGqIDypiISAyvSfPne5V1h8ZqrMymybmPuny8CZLYWDQ4d/zKvbZTKJp z1OeZQEWFeWrsiWuwa2d4kGbfzZFi/hBjob/4M4iW1YrxmQtuPDdVwiCSVUjZthMekD0 hf5bm6flpF4zclfzdwK2KkYHm9NCKpwWfFGEKtDZ+HG21/OvKalGJnH14jZQADjCWmMF FNFw==
MIME-Version: 1.0
X-Received: by 10.205.41.68 with SMTP id tt4mr61041bkb.118.1368576490662; Tue, 14 May 2013 17:08:10 -0700 (PDT)
Received: by 10.205.116.133 with HTTP; Tue, 14 May 2013 17:08:10 -0700 (PDT)
In-Reply-To: <CABkgnnURhLU3RJnMDxwErELedAmGKWcVgkE+B+Pn6vR3oYjJ6A@mail.gmail.com>
References: <CAOdDvNqXhG7+xbvBwctQCR4tZePKByw75SR5oBamXTymZa7myA@mail.gmail.com> <CABkgnnURhLU3RJnMDxwErELedAmGKWcVgkE+B+Pn6vR3oYjJ6A@mail.gmail.com>
Date: Tue, 14 May 2013 17:08:10 -0700
Message-ID: <CAP+FsNcdAiK=Ddd1HTaYSuaTCj6OdKyQRCskuH2OZQ7um9TU6Q@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Patrick McManus <pmcmanus@mozilla.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="bcaec5299639932ae004dcb68bb0"
Received-SPF: pass client-ip=209.85.214.54; envelope-from=grmocg@gmail.com; helo=mail-bk0-f54.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.689, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UcPGn-0006NO-2j 2b8d0110a2487baf9aa6da5850e6bce6
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Implementation Notes on Server Push
Archived-At: <http://www.w3.org/mid/CAP+FsNcdAiK=Ddd1HTaYSuaTCj6OdKyQRCskuH2OZQ7um9TU6Q@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17996
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>

inline


On Tue, May 14, 2013 at 4:57 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> 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 agree it should be removed. If we need a mechanism to close many streams,
we can add a new opcode type instead of some implicit requirement.


>
> > 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?
>
>
As usual: It depends (TM), but so long as the max frame size, etc. is small
enough that the mechanisms to deal with it exist, changing it becomes as
painless as changing a constant or config param.


-=R