Re: idea -- MAX_PUSH_RESOURCE_SIZE

Mike,

I don't think my proposal is ideal and you point out a weakness in it. Are
there other ways the server can distinguish between large cache browsers
like those on PCs and small cache browses like those on small devices with
A) slowing down the initial frame and B) sending unused data to the browser?

Peter


On Mon, Nov 4, 2013 at 2:04 PM, Mike Bishop <Michael.Bishop@microsoft.com>wrote:

>  How does it slow things down compared to your solution?  With yours, a
> large resource simply couldn’t be pushed.  With the small window approach,
> the large resource still gets pushed *if* the client doesn’t already have
> it cached, but it caps the amount of wasted data if the object is already
> in the client’s cache.  You still have savings on the parsing of the
> initial resource (i.e. the delay before the client would have requested
> it), so push remains useful for larger resources.
>
>  At the cost of an extra WINDOW_UPDATE frame on every client request, of
> course.
>
>  Sent from Windows Mail
>
>   *From:* Peter Lepeska <bizzbyster@gmail.com>
> *Sent:* ‎Monday‎, ‎November‎ ‎4‎, ‎2013 ‎1‎:‎08‎ ‎PM
> *To:* William Chan (陈智昌) <willchan@chromium.org>
> *Cc:* Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group<ietf-http-wg@w3.org>
>
>  I understand that we want to minimize the config settings but this
> alternative solution has the much worse consequence of slowing down pushed
> resources in the 99% case when we expect the browser to actually use what
> we are pushing.
>
>  If it is between no new config setting and starting with small per
> stream receive windows by default to limit the damage of unused pushed
> resources, I am fine with no new config setting.
>
>  I think the receive windows should be configured to maximize performance
> and we should be very cautious any time we tweak them to deliver other
> functionality due to the possible side effect of slower transmissions.
>
>  Isn't HTTP 2.0 supposed to primarily be about faster? We need to stick
> to that original goal!
>
>  Peter
>
>
> On Mon, Nov 4, 2013 at 10:29 AM, William Chan (陈智昌) <willchan@chromium.org
> > wrote:
>
>> Note that the FF strategy (which we've discussed Chromium side) is to
>> start with smaller per-stream receive windows by default, and upgrade them
>> immediately for normal streams, or as Pat calls them, "pull" streams. This
>> would let stuff like push streams, or as Chromium is discussing, web
>> platform prefetch/prerender/etc streams, start with smaller receive windows.
>>
>>
>> On Mon, Nov 4, 2013 at 10:14 AM, Martin Thomson <martin.thomson@gmail.com
>> > wrote:
>>
>>> On 4 November 2013 10:00, Peter Lepeska <bizzbyster@gmail.com> wrote:
>>> > As per above, the browser currently can only set max concurrent
>>> streams to
>>> > limit the amount of data pushed to it but perhaps better is to set a
>>> max
>>> > size of file that the browser is willing to accept via server push.
>>>
>>>  We are, as much as possible, attempting to limit the number of
>>> settings that we allow in the protocol.  I take that to mean that
>>> there needs to be a high bar on the addition of settings.
>>> Specifically, if there is an alternative solution to the problem, then
>>> it's not enough.
>>>
>>> In this case, if you are concerned about the size, the flow control
>>> window will allow you to control the size and give you time to
>>> generate RST_STREAM as appropriate.  ...Trade off as appropriate
>>> against your desire to maximize throughput.
>>>
>>>
>>
>