Re: per stream (initial) flow window size

Thanks Mark.


On Wed, Oct 9, 2013 at 4:41 PM, Mark Nottingham <mnot@mnot.net> wrote:

> Hi Ilya,
>
> I've created an issue for this:
>   https://github.com/http2/http2-spec/issues/261
>
> Not sure if we'll get to discussing it at the meeting this week.
>
> Cheers,
>
>
> On 08/10/2013, at 4:14 PM, Ilya Grigorik <ilya@igvita.com> wrote:
>
> > SETTINGS allows us to set a default starting window for all streams +
> update this default later. However, I think there are compelling cases
> where it would be beneficial to allow different streams to start with a
> different initial window size (similar to optional priority in headers
> frame). Given that this would effectively be a new feature... let me try to
> motivate why the extra complexity is worth it based on some of the recent
> work I've been involved with:
> >
> > We want to make browser pre{fetch,rendering} smarter [1,2]. Meaning, we
> want to be able to discover critical page resources as early as possible
> and kick off fetches for those assets also. However, since some of these
> assets are large (and there can be many of them), we need to control how
> much data we fetch (e.g. if we are too aggressive we may slow down the host
> page, and/or incur high overhead for the user).
> >
> > A concrete example of this is the work we've been experimenting with in
> PageSpeed [3], where we are aggressively inlining CSS/JS and even doing
> "page splits": the rewriter effectively creates two pages, the first is the
> "prefetch friendly" version which fits in < 15KB (one RTT), and second is
> the diff that fills in the rest once the navigation is triggered via an XHR
> -- if that sounds crazy, then that's not too far from the truth. That said,
> we have a working prototype, and it's showing impressive results.. For
> example, we can take a mobile wikipedia page, which currently takes 9s
> (!!!) to first render (on a 3G profile), down to 1.6s [3] by using the
> combination of prefetch + page split strategies.
> >
> > What does flow control have to do this with all this? When issuing a
> prefetch, we would like to be able to open a request with a lower initial
> window (e.g. 15KB), and fetch just the head of the document - in most
> cases, this will allow us to discover the critical resources, initiate
> requests for them, etc. Then, if the navigation is triggered, we would just
> increment the window and "resume" the stream to get the rest of the page...
> This eliminates the need for server rewriting / page splitting, which has a
> lot of gnarly edge conditions. Handling this at the transport layer would
> make it much, much simpler and more powerful.
> >
> > (Yes, we could lower the initial window for all streams, but that's
> counter productive in majority of cases... we'd just end up sending a lot
> more WINDOW_UPDATE frames for non-prefetch request.)
> >
> > Further, the ability to set a custom window size also allows us to
> adjust this logic based on type of asset, prior knowledge of the site, or
> other signals. For example, the other use case is progressive rendering of
> images - i.e. using flow control to fetch image layers and having control
> over where and when to stop. Concretely, we could fetch first X KB, which
> may provide a reasonable low-res preview of the asset, and then continue
> fetching subsequent layers until some condition is met (end of file, or max
> resolution of device is reached -- if you're a 2x device, don't fetch the
> 3x layers). I'm intentionally skipping over the image container discussions
> here, since that's a separate conversation.. But I'll note that many sites
> are already trying to provide this sort of experience, except through
> rather poor implementation: inline low-res asset, render that, then
> initiate a separate XHR to fetch image and replace with high-res version.
> Needless to say, we can do much better, and there is strong interest in
> providing this sort of functionality natively...
> >
> > --
> >
> > In short, there are interesting cases where the initiator of the stream
> may want to control the initial window size: to decrease it, and perhaps
> even to increase it in some cases. There are multiple ways to achieve this,
> but one plausible strategy would be to allow an optional
> SETTINGS_INITIAL_WINDOW_SIZE payload in the headers frame, not unlike the
> optional priority field -- minimal overhead, no races between initiating
> the request and WINDOW_UPDATE, etc.
> >
> > Thoughts?
> >
> > Ilya
> >
> > [1]
> https://docs.google.com/document/d/1wck0tFTiibKzZDuBeyK0lrKTKsZ5pqfvcR__1r2m834/edit
> > [2]
> http://lists.w3.org/Archives/Public/public-web-perf/2013Aug/0010.html
> > [3] https://developers.google.com/speed/pagespeed/optimization
> > [4]
> http://www.webpagetest.org/result/130715_PZ_08063384bd76cd2206a1b39e8678e438/3/details/
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>