Re: Implementation Notes on Server Push

William Chan (陈智昌) <> Wed, 15 May 2013 21:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7941F11E80AD for <>; Wed, 15 May 2013 14:43:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.051
X-Spam-Status: No, score=-9.051 tagged_above=-999 required=5 tests=[AWL=0.625, 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 ycvad2DXLmeU for <>; Wed, 15 May 2013 14:43:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0F79721F84DF for <>; Wed, 15 May 2013 14:43:29 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UcjSm-00025c-Ib for; Wed, 15 May 2013 21:42:20 +0000
Resent-Date: Wed, 15 May 2013 21:42:20 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UcjSa-00024l-UT for; Wed, 15 May 2013 21:42:08 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UcjSW-0007RW-7r for; Wed, 15 May 2013 21:42:08 +0000
Received: by with SMTP id c11so691612qcv.18 for <>; Wed, 15 May 2013 14:41:38 -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=L4qlc9kuSQEPQmZ27K8eueAtdDg5dPEJc5c4xHJiruI=; b=QoS0cZQNMjgQfMPq66bzWMsE60qPssgWR1BWbr67B488P4rLi6eMpCtPqpI1yCDHhO sSsYzjtz4nlzQNgbIaWjqvfzl0JUEZBFCA6BPLtlmyDarZmdmLAWCU/6d2zVLfaqONzc pmvjhmOzYKK6EgJX66sDEsUK/ou0xzPVm0tLmyDnlsEnGa6X2ygF0/S1u1Wn5d+KacdB o8dUK2SRlZ+NarTf0wa+HYXLv4Jnd7w57buNtVHhGncAxAMBtoqXIPIhTEOhs/BdHfGs lH+WgU1teiqKsWr8mg6y6JQ051FfFrq4iqfa0YQvoqDd3Il9a31nk+1rPwmPjxWm0aBv 4cig==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=L4qlc9kuSQEPQmZ27K8eueAtdDg5dPEJc5c4xHJiruI=; b=Ws+zKdVzahJvjSzyRGIJk+dBc4omKuzZpApPRVe8tNgrSlKiH8LXco02G8120vQ/Ix OiQJIp+n2OkLcblAD6Ybc+uzSUBSklDgXRpKGiKS8/0alckO8t+f6Wb+1cG2I6rGg/22 ilYWkNFbWlcvfKoFhZDSq5cghZLHXCNglTe90=
X-Google-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 :x-gm-message-state; bh=L4qlc9kuSQEPQmZ27K8eueAtdDg5dPEJc5c4xHJiruI=; b=dJSKEOCMDH5cjn5nKqLj4KSVwPiC/XKqjn+9W84YF8vXLmw9yWiXgGfAjFmPPNzCCT Npt3sncCMPrvT88KzjNs8rIPY0sSZdYnFDTWP+ATXgZVdzrywbkYeGKo4/OkMb7amSLA KR7fGFNRZIJrO/HBwbntVsUoJCA9vsGZhRCF3keGcj5aTQL+VCDQA7QOq6fPVndNOIXz hTEh5fZItFE41VE/rb85B933KUkcq+Cspv0GxKcUGjjnFgD1d31e1Fl7b8d//sR4eXC3 rhCv821AEheucYbSIjJep5R/b73WrXe/SF/RQdgPmy1lDqUDax7z5bzEA+ydtbw1vvpC pLmg==
MIME-Version: 1.0
X-Received: by with SMTP id cc8mr29626904qab.10.1368654098220; Wed, 15 May 2013 14:41:38 -0700 (PDT)
Received: by with HTTP; Wed, 15 May 2013 14:41:38 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Wed, 15 May 2013 18:41:38 -0300
X-Google-Sender-Auth: 1JnKsNuaE7fGK_fzT4IaJtI3L-k
Message-ID: <>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <>
To: Patrick McManus <>
Cc: HTTP Working Group <>
Content-Type: multipart/alternative; boundary=20cf30363d3f5883f104dcc89dc4
X-Gm-Message-State: ALoCoQnjvu88BT4ux4Jb3vKUznhyreDBW3+JeONxhDygUq9wam1w+RBdWohcc2q7OgOt00oAXpYOjbS3l2orKPJX6MU29svK7hx3J9gcM1flSdIlx8D90n4e6a6tmPENyYNUjXRY7+FzGV8xBDXdLNswbNoMQAvqUJnu86e+WNA3eJM1Zksem6aW1c8N3MZCjXkGQlsfhU/Q
Received-SPF: pass client-ip=;;
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: 1UcjSW-0007RW-7r 7046a05663c9c11496aafbed11eeefc2
Subject: Re: Implementation Notes on Server Push
Archived-At: <>
X-Mailing-List: <> archive/latest/18010
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Terse because I'm running off to catch a bus to Mendoza.

On Wed, May 15, 2013 at 6:21 PM, Patrick McManus <>wrote;wrote:

> Hi Will,
> On Wed, May 15, 2013 at 4:48 PM, William Chan (陈智昌) <
> > wrote:
>> 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 stream.

Resource bounding SGTM.

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

When you say storage, do you mean memory or disk?

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

Yep, that's fair.

> 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.
What do you think about SETTINGS_MAX_CONCURRENT_STREAMS vs flow control
here? Also, when you say an established sink, how about the browser cache?