Subject: idea -- MAX_PUSH_RESOURCE_SIZE

From: Peter Lepeska <[email-masked]>
Date: Mon, 4 Nov 2013 10:00:05 -0800

If the client determines, for any reason, that it does not wish to
   receive the pushed resource from the server, or if the server takes
   too long to begin sending the promised resource, the client can send
   an RST_STREAM frame, using either the CANCEL or REFUSED_STREAM codes,
   and referencing the pushed stream's identifier.

   A client can use the SETTINGS_MAX_CONCURRENT_STREAMS setting to limit
   the number of resources that can be concurrently pushed by a server.
   Advertising a SETTINGS_MAX_CONCURRENT_STREAMS value of zero disables
   server push by preventing the server from creating the necessary
   streams.  This does not prohibit a server from sending PUSH_PROMISE
   frames; clients need to reset any promised streams that are not
   wanted.

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. That way a browser can adjust the amount of data pushed
to it depending on its available cache space. So, for instance, a
browser on a small device would set MAX_PUSH_RESOURCE_SIZE setting to
a value lower than a browser on a PC with lots of storage.

Thanks,

Peter

---

From: Martin Thomson <[email-masked]>
Date: Mon, 4 Nov 2013 10:14:36 -0800

On 4 November 2013 10:00, Peter Lepeska <[email-masked]> 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.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 4 Nov 2013 10:29:10 -0800

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.

---

From: Peter Lepeska <[email-masked]>
Date: Mon, 4 Nov 2013 13:07:16 -0800

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 (陈智昌)
<[email-masked]>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

---

From: Roberto Peon <[email-masked]>
Date: Mon, 4 Nov 2013 13:19:18 -0800

Server push can currently be disabled.
The amount of each resource sent can be controlled at a fine-grained level,
and so it can be throttled.

Server push currently enables cache validation/invalidation, as well as
offering a replacement for inlining.

What you propose would make it unreliable and thus un-useful for the
second. People would simply inline stead, destroying all of the potential
benefits.
It seems like a bad idea.
-=R

On Mon, Nov 4, 2013 at 1:07 PM, Peter Lepeska <[email-masked]> wrote:

> On Mon, Nov 4, 2013 at 10:29 AM, William Chan (陈智昌) <[email-masked]
> > wrote:
>
>> On Mon, Nov 4, 2013 at 10:14 AM, Martin Thomson <[email-masked]
>> > wrote:
>>
>>> streams to

---

From: Mike Bishop <[email-masked]>
Date: Mon, 4 Nov 2013 22:04:14 +0000

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<mailto:[email-masked]>
Sent: ?Monday?, ?November? ?4?, ?2013 ?1?:?08? ?PM
To: William Chan (陈智昌)<mailto:[email-masked]>
Cc: Martin Thomson<mailto:[email-masked]>, HTTP Working Group<mailto:[email-masked]>

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 (陈智昌) <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Peter Lepeska <[email-masked]>
Date: Mon, 4 Nov 2013 14:07:07 -0800

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 <[email-masked]>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.
>
>   *From:* Peter Lepeska <[email-masked]>
> *Sent:* ‎Monday‎, ‎November‎ ‎4‎, ‎2013 ‎1‎:‎08‎ ‎PM
> *To:* William Chan (陈智昌) <[email-masked]>
> *Cc:* Martin Thomson <[email-masked]>, HTTP Working Group<[email-masked]>
>
>  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.
>

---

From: Peter Lepeska <[email-masked]>
Date: Mon, 4 Nov 2013 14:07:50 -0800

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 <[email-masked]> wrote:

>> 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
>>  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.
>>
>> On Mon, Nov 4, 2013 at 10:29 AM, William Chan (陈智昌) <
>> [email-masked]> wrote:
>>
>>> On Mon, Nov 4, 2013 at 10:14 AM, Martin Thomson <
>>> [email-masked]> wrote:
>>>

---

From: Mike Bishop <[email-masked]>
Date: Mon, 4 Nov 2013 22:20:31 +0000

What’s slowed down?  The desired window size is expressed in the SETTINGS frame which the client sends before the server has sent any content.  I’m not clear on the situation you’re concerned about which isn’t covered.

Avoiding sending any unwanted data to the client is a more general problem with push, and I don’t think anyone has solved that completely.  The small-window approach does limit how much unwanted data can be sent, which is the best we have so far (and the same thing that your approach appears to achieve).  Trying to completely prevent a specific push in the first place is something of a holy grail, but there hasn’t been a proposal so far that achieves that without massive complexity and state on the server side and/or large amounts of data transfer and privacy disclosure on the part of the client.

Sent from Windows Mail

From: Peter Lepeska<mailto:[email-masked]>
Sent: ?Monday?, ?November? ?4?, ?2013 ?2?:?07? ?PM
To: Mike Bishop<mailto:[email-masked]>
Cc: William Chan (陈智昌)<mailto:[email-masked]>, Martin Thomson<mailto:[email-masked]>, HTTP Working Group<mailto:[email-masked]>

On Mon, Nov 4, 2013 at 2:07 PM, Peter Lepeska <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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.

Sent from Windows Mail

Peter