Re: unclaimed push streams using up the connection window

On 2014–05–20, at 7:26 AM, William Chan (陈智昌) <willchan@chromium.org> wrote:

> There are implementation and protocol mitigations here:
> 1) A browser implementation could track all the associated push streams for a page and kill them when the page goes away. That's pretty ugly and violates some layering boundaries between the network stack and the web rendering engine.
> 2) If the client push implementation streams the push streams directly into cache, and manages the cached resources with a cache eviction policy, then the push streams will not persistently suck up the connection window, since they will get drained as fast as the cache can consume them.
> 3) From a protocol standpoint, we could separate push and pull connection windows so they can be managed separately.

Isn’t separation of windows (connection vs. stream) already a network layering violation? Why fragment flow control further? Pull streams are more critical but there’s still a bug if pushes are blocked.

Extending the connection window separately from a stream window simply indicates broken design. Is there any use-case that has been proven reliably interoperable? Why the commitment to this setup, given the problems a la BLOCKED?

If the client has nowhere to put the data at the time it’s pushed, then toss it in the bit-bucket and terminate the stream immediately. Delaying a PUSH until it’s useful defeats the purpose of pushing. It sounds like the described application model needs a per-page push cache, if the global cache won’t do. Trying to let the data to collect indefinitely on the server side can’t be good for anyone.

If it’s a performance issue, then send a PRIORITY frame instead.

> In Chromium's case, I think this will be a non-issue when we change our push implementation to stream directly to cache. I think this is only an issue if you have an HTTP/2 implementation that chooses to enable flow control yet has a naive push implementation.

Flow control is not optional. Push is. How is streaming directly to the cache not the naive implementation? More specialized protocols (which may not have a cache but wish to push, for example, firmware updates) should reject unwanted pushes as a rule, I would think.

> Originally, I thought this was more interesting to ietf-http-wg@, but maybe this isn't and implementations will figure it out. I'm not sure if there's anything for the working group to do here. But I'll send this email out anyway in case others feel differently.

Thanks, it’s good to have a handle on what implementation issues are driving evolution. Perhaps there should be another list for implementation discussion?

Received on Tuesday, 20 May 2014 03:08:02 UTC