Re: idea -- MAX_PUSH_RESOURCE_SIZE

Sorry I meant to say "without" A and B and not "with" A and B.


On Mon, Nov 4, 2013 at 2:07 PM, Peter Lepeska <bizzbyster@gmail.com> wrote:

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