Re: Implementation Notes on Server Push

[William Chan (陈智昌) <[e-mail]>]

On Wed, May 15, 2013 at 6:59 PM, Patrick McManus <[e-mail]>wrote:

>
> On Wed, May 15, 2013 at 5:41 PM, William Chan (陈智昌) <[e-mail]
> > wrote:
>
>>
>>> 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.
>>>
>>
>> When you say storage, do you mean memory or disk?
>>
>
> could be either, or both. depending on deployment.
>
>
>
>> What do you think about SETTINGS_MAX_CONCURRENT_STREAMS vs flow control
>> here?
>>
>
> deserves experimentation.. though flow control seems more fine grained to
> me.
>

It depends. Both are just knobs with partial control. Stream flow control
needs to leave the window large enough to save RTTs, but can put a cap on
how much any single response can be. But it doesn't really help if you just
open a bunch of streams. Connection flow control is too coarse grained
though, since it's shared by pull streams. Martin's proposal is pretty
simple, yet useful. I like it. It's a specific instance of stream group
flow control, much like connection flow control is. But it seems to serve a
good purpose and doesn't require a group definition mechanism, since
connection and directionality of streams are good definitions for
establishing the groupings.

That said, I'd like to hold back from adding any mechanisms unless we have
implementers that will commit to experimenting with it.

I think a lot of this also goes back to whether or not we want to define
strict mechanisms in the protocol for controlling this, or we want to
advertise hints in the semantic layer (HTTP client hints or whatever).

Yeah, we need to experiment. I think your current flow control usage is
interesting and probably a good idea. You guys are way ahead of us on
tuning push :) We're still in the ironing out bug phase.


>
>
>> Also, when you say an established sink, how about the browser cache?
>>
>
> For a pretty significant set of deployments I would rather wait 1 rtt than
> deal with storage i/o :)
>

Hah, fair enough :)