Re: Some thoughts on server push and client pull

Server push should exist to:
1) Allow elements which would have been inlined to be identified *and
prioritized* separately.
2) Allow content (i.e. website) creators to make some mistakes w.r.t.
resource ordering, and not have the users be severely penalized, which is
what happens with inlining today.
3) Reduce bandwidth:
  a) In cases where the client can advertise elements in the cache which
are associated with the current request, the server could not send those
resources. This would be a strict improvement over inlining.
  b) Even in cases where the client doesn't advertise elements, if the
client closes the streams before the server has sent all the bytes, there
will be a reduction in bytes sent as compared to inlining.

Note I didn't say that it reduces an RTT as compared to HTTP. Rather, it
either:
  1) where the resources were cached it can save multiple RTTs.
  2) Ignoring cache effects it is strictly equivalent to *good* inlining,
where you've put the important resources at the appropriate place in the
document.

Server push is simply better inlining, supported at the layer where it
should be :)


What is the purpose of HTTP? Answering this question seems relevant in
figuring out what the scope is...
-=R


On Thu, Jun 7, 2012 at 10:22 AM, Safruti, Ido <ido@akamai.com> wrote:

> I believe we should keep it open for now, as clearly there is some work
> done on that front, and we should wait and see initial results.
> We are also looking at this as a potential way to eliminate a roundtrip
> which is currently required in any other suggestion (where the client
> initiates the requests) - between the page and the embedded resources.
>
>
> From: "William Chan (陈智昌)" <willchan@chromium.org>
> To: Martin Thomson <martin.thomson@gmail.com>
> Cc: Mike Belshe <mike@belshe.com>, Gabriel Montenegro <
> Gabriel.Montenegro@microsoft.com>, "ietf-http-wg@w3.org" <
> ietf-http-wg@w3.org>
> Subject: Re: Some thoughts on server push and client pull
>
> On Thu, Jun 7, 2012 at 9:54 AM, Martin Thomson <martin.thomson@gmail.com>wrote:
>
>> On 7 June 2012 09:43, William Chan (陈智昌) <willchan@chromium.org> wrote:
>> > * Google is working on efforts to seriously deploy SPDY server push on
>> our
>> > properties. I can't comment further on timeline, but I hope to provide
>> data
>> > to guide our discussions, so let's not axe it just yet.
>> > * To my knowledge, Amazon is using it in their Silk browser. A proxy
>> that
>> > uses server push is a fascinating use case, and it'd be cool to get
>> data on
>> > that first.
>>
>> I'm with Mike and Gabriel on this one.
>>
>> It would be nice if HTTP/2.0 discussions could be scoped to exclude
>> discussions on new protocol semantics.  If you feel especially
>> attached to the idea of push, then my preference would be to see a new
>> draft on it.
>>
>
> Can you clarify what you mean by new protocol semantics? Does multiplexing
> count as a new protocol semantic? What's your proposed scope?
>
> I understand the desire to split out server push into a separate draft /
> extension. If we don't have data to support push, then by all means we
> should drop it. The main concern I have is with regards to treating push as
> an optional feature / extension. As many of us have stated repeatedly on
> this mailing list, many things that are optional simply become unusable in
> real, public deployments.
>
>
>> --Martin
>>
>
>