Re: Implementation Notes on Server Push

inline


On Tue, May 14, 2013 at 4:57 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> Great feedback.
>
> On 14 May 2013 12:14, Patrick McManus <pmcmanus@mozilla.com> wrote:
> > 304's seem to be a common cause of wasted pushed streams. I would see
> > servers respond with a 304 for index.html and still push 200 responses
> for
> > a.css and b.js when in a non-push world that would have been either 1 or
> 3
> > 304's. Maybe we should have a rule that you can only push to an
> assoc-stream
> > of 2xx ?
>
> I don't know if outright prohibition is necessary.  It might be that
> a.css has changed, but index.html hasn't.  But I consider that
> unlikely in the general case.  A word of caution seems appropriate.
>
> > There is language in the spec that if the client resets a stream that it
> > implicitly resets any associated streams too. That was complicated to
> > implement and pretty much broke my stream state model internally - while
> > researching it it appears that mod_spdy and chrome don't implement it at
> > all. The spec has an editorial note about removing that feature and I
> favor
> > that removal.
>
> I added that text, so I tend to agree. :)
>

I agree it should be removed. If we need a mechanism to close many streams,
we can add a new opcode type instead of some implicit requirement.


>
> > I found flow control for pushed streams immensely helpful. It lets the
> > client bound how much data can be pushed before there is a local GET
> matched
> > up with that. Relatedly, I changed my default SETTINGS window size from a
> > ~infinite value to be a smaller push-apropos value and then pipelined a
> > window update with each odd SYN_STREAM to make pulled streams ~infinite
> > again while preserving the smaller limit for push and this worked fine
> with
> > all existing servers to my pleasant surprise. That seems to mean at least
> > the spdy/3 windowing mechanism is simple enough for people to get right.
>
> That's interesting.  Do you believe that it would be worthwhile
> splitting the initial window size setting in two?  One for streams I
> initiate, one for streams you initiate?  That would save you a window
> update on every new stream.
>
> > As with other parts of the spec, I was faced in some implementations with
> > some very large data frames (90+KB) from servers when testing. Such
> frames
> > are impervious to CANCEL or any mechanism we might use to change
> priorities
> > driven by the client :(..  HTTP2 is doing the right thing by creating a
> > smallish max frame size.
>
> Small is good, but how small is small enough?
>
>
As usual: It depends (TM), but so long as the max frame size, etc. is small
enough that the mechanisms to deal with it exist, changing it becomes as
painless as changing a constant or config param.


-=R