Re: Implementation Notes on Server Push

Patrick McManus <> Wed, 15 May 2013 21:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 27A0211E80D2 for <>; Wed, 15 May 2013 14:23:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.829
X-Spam-Status: No, score=-8.829 tagged_above=-999 required=5 tests=[AWL=0.847, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IG5yYWkv1nRq for <>; Wed, 15 May 2013 14:22:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 98F5B11E80E6 for <>; Wed, 15 May 2013 14:22:44 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1Ucj9O-0001kv-NC for; Wed, 15 May 2013 21:22:18 +0000
Resent-Date: Wed, 15 May 2013 21:22:18 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1Ucj9C-0001hv-Ub for; Wed, 15 May 2013 21:22:06 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1Ucj9C-0006mG-0X for; Wed, 15 May 2013 21:22:06 +0000
Received: by with SMTP id j6so2793855oag.4 for <>; Wed, 15 May 2013 14:21:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=nwEaOz22f4ucVQmoTl8BKjMe8nK3jhiuelScdNASl+M=; b=n3OCOolXQAT7jhZ+cZz3bj5c6oJ7nhnUNDFmMKHcp9wRuRiShsvJS0tHtUNQmQ82Kx U3yoBEUbZwCmmpjR781U6k1cExhhJRONwWHhN9yQyVvTWZviEyFjXNCsypLk7xKdHw/z oAdc+mE9TexnJB0tav5fOvWn/Ly4PVIelzPPmGrB1zirzlX2s+Mga6mKfqPCqpoqrjKW bGrSngx38lsaNO1m/cVw0nsDmDXxNwnF+09FahZPBfH8lnnYVEsRyOqQqyfoPnaxxrEM pX+CnNJ18SO75S5FBzLXejreq0ysCyu4PeGjsLWTiE7JGmHhlxHLkRF4l3TRE8oCE9/F lw2w==
MIME-Version: 1.0
X-Received: by with SMTP id tz3mr18500564obc.23.1368652900152; Wed, 15 May 2013 14:21:40 -0700 (PDT)
Received: by with HTTP; Wed, 15 May 2013 14:21:40 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Wed, 15 May 2013 17:21:40 -0400
X-Google-Sender-Auth: 4F8bR3b9lKni4mmeBtB8OeXWm18
Message-ID: <>
From: Patrick McManus <>
To: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <>
Cc: HTTP Working Group <>
Content-Type: multipart/alternative; boundary=001a11c2029aef414c04dcc8557b
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.3
X-W3C-Hub-Spam-Report: AWL=-2.631, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1Ucj9C-0006mG-0X cfc6432204911d7b18f14b49be29e3a1
Subject: Re: Implementation Notes on Server Push
Archived-At: <>
X-Mailing-List: <> archive/latest/18009
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Will,

On Wed, May 15, 2013 at 4:48 PM, William Chan (陈智昌)

> Given the amount of discussion here, I figured I should chime in on this
> point and ask a question. Are you doing this for memory bounding purposes?
> Or is this for prioritization purposes?
> As I've said before, I think we should not attempt to leverage flow
> control mechanisms for prioritization. The client should advise the server
> as best as possible the appropriate prioritization, and then trust the
> server to serve responses (including pushed streams) in the best ordering.

I'm doing it for resource bounding only because I anticipate we will add a
mechanism for the client to advise the server of the priority of a pushed

Its pretty obvious that there are going to be a fair number of pushed
streams that never get used.  I think there are lots of scenarios where
that's true - but we can start with things like AdBlockPlus and
GreaseMonkey scripts where the view the client has of the dom is pretty
different than the server's view. And the savings of push is really just on
the order of 1 RTT for the whole page load. So client implementations need
to draw a balance between the costs of buffering and transferring that data
and the RTT savings.

Its a particular quandary on mobile. The RTT is certainly costlier.. but
storage is costlier too and more importantly to me the data transfer can be
exceptionally expensive.

I've got mobile carriers right now (mostly emergent markets) who are asking
for ways to disable existing HTTP speculative operations (e.g. DNS or
TCP/SSL handshakes) on Firefox OS phones because their top priority is
reducing data charges. (That confuses me a bit too - I thought they were in
the business of selling data, but anyhow.)

Flow controlling push provides a nice way to participate in the push
without an open ended commitment to it... and in the end I want it on the
client for the same reason server operators want it on the other end - I
can't accept an arbitrary amount of data without an established sink to
send it to.