Re: Implementation Notes on Server Push

William Chan (陈智昌) <willchan@chromium.org> Wed, 15 May 2013 21:43 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 7941F11E80AD for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 15 May 2013 14:43:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.051
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycvad2DXLmeU for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 15 May 2013 14:43:30 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0F79721F84DF for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 15 May 2013 14:43:29 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UcjSm-00025c-Ib for ietf-http-wg-dist@listhub.w3.org; Wed, 15 May 2013 21:42:20 +0000
Resent-Date: Wed, 15 May 2013 21:42:20 +0000
Resent-Message-Id: <E1UcjSm-00025c-Ib@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 1UcjSa-00024l-UT for ietf-http-wg@listhub.w3.org; Wed, 15 May 2013 21:42:08 +0000
Received: from mail-qc0-f173.google.com ([209.85.216.173]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1UcjSW-0007RW-7r for ietf-http-wg@w3.org; Wed, 15 May 2013 21:42:08 +0000
Received: by mail-qc0-f173.google.com with SMTP id c11so691612qcv.18 for <ietf-http-wg@w3.org>; Wed, 15 May 2013 14:41:38 -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=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; 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=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; 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=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 10.224.182.136 with SMTP id cc8mr29626904qab.10.1368654098220; Wed, 15 May 2013 14:41:38 -0700 (PDT)
Sender: willchan@google.com
Received: by 10.229.102.161 with HTTP; Wed, 15 May 2013 14:41:38 -0700 (PDT)
In-Reply-To: <CAOdDvNoJfnrpBU9fexqty=CP0W-nDXA8iUJORqH6zaMaXqicbQ@mail.gmail.com>
References: <CAOdDvNqXhG7+xbvBwctQCR4tZePKByw75SR5oBamXTymZa7myA@mail.gmail.com> <CAA4WUYhmCdpa0pn5f4tRkbpcjsPOxUJvBunvNwkB9FSEinL41Q@mail.gmail.com> <CAOdDvNoJfnrpBU9fexqty=CP0W-nDXA8iUJORqH6zaMaXqicbQ@mail.gmail.com>
Date: Wed, 15 May 2013 18:41:38 -0300
X-Google-Sender-Auth: 1JnKsNuaE7fGK_fzT4IaJtI3L-k
Message-ID: <CAA4WUYh7+B5OvN5J-ODeDw9pwAGiJhuxzaNff6nWv6=NQwp99A@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=20cf30363d3f5883f104dcc89dc4
X-Gm-Message-State: ALoCoQnjvu88BT4ux4Jb3vKUznhyreDBW3+JeONxhDygUq9wam1w+RBdWohcc2q7OgOt00oAXpYOjbS3l2orKPJX6MU29svK7hx3J9gcM1flSdIlx8D90n4e6a6tmPENyYNUjXRY7+FzGV8xBDXdLNswbNoMQAvqUJnu86e+WNA3eJM1Zksem6aW1c8N3MZCjXkGQlsfhU/Q
Received-SPF: pass client-ip=209.85.216.173; envelope-from=willchan@google.com; helo=mail-qc0-f173.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 1UcjSW-0007RW-7r 7046a05663c9c11496aafbed11eeefc2
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Implementation Notes on Server Push
Archived-At: <http://www.w3.org/mid/CAA4WUYh7+B5OvN5J-ODeDw9pwAGiJhuxzaNff6nWv6=NQwp99A@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18010
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>

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

On Wed, May 15, 2013 at 6:21 PM, Patrick McManus <pmcmanus@mozilla.com>wrote;wrote:

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

SETTINGS_MAX_CONCURRENT_STREAMS is another option here.


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