Re: Implementation Notes on Server Push

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:

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