Re: Implementation Notes on Server Push

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.

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.