Re: Large Frame Proposal - WINDOW UPDATE

I've split this out to a different subject as it is really a separable part
of the proposal (and almost
was not included).


On 8 July 2014 08:40, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 7 July 2014 15:31, Greg Wilkins <gregw@intalio.com> wrote:
> > well we could make it compulsory if that makes the proposal more likely
> to
> > be accepted :) We could mandate that all implementation MUST make random
> > fluctuations to the max frame size to hunt down and shame those
> implementers
> > who stupidly think that they need not implement a feature that they do
> not
> > need. [ Note that was sarcasm for those who don't get it ]
> >
> > I think the WINDOW_UPDATE is well motivated to support the known
> use-cases
> > where multiplexing is not needed momentarily.     However the proposal
> > stands on without it and it could be removed if the WG explicitly
> > acknowledges that they will not support the issue that it is trying to
> > address (or comes up with an alternative).
> >
> > But I'd ask the WG to mull on the proposal in total for at a little bit
> > before we abandon parts of it.
>
>
> I don't think that I was clear enough.  I really don't like that part,
> compulsory or not.


Sorry - was just being facetious.  I get it that you don't like it :)


> I think that it's an unvarnished attempted to cram
> per-stream settings into the protocol.  It's unnecessary and very
> poorly supported.
>

Well while I think others would argue that per stream settings are useful -
I'm neither trying to make that point nor cram in a per-stream setting.
I truly believe it is a flow control parameter that any moderately
intelligent flow control algorithm would like to adjust if possible.

A simpler and better approach for those connections that need generous
> frame sizes occasionally would be to advertise a large setting.  As
> PHK is fond of telling us: you don't have to use all of it.
>

I don't think using a generous setting works.   If you make then setting
generous before you issue a request, you don't have any idea if the
response is going to be a single big stream or 80 pushed streams.    If it
is the later and you have set a large data frame setting, then you are
going to be in QoS pain.

You could have a small setting, and then once you see that only 1 stream is
active in response adjust the connection setting.  But sometimes you will
be wrong and just after you adjust the setting more requests might be
issued or more push promises might arrive. By the time you try to adjust
the connection setting back, you may have 80 streams being pushed at you,
all with a large frame to start with (although the connection flow control
window may save you here).

So it can be done with the SETTINGS, but would be a little more risky and a
little more complex..... but hey the up side is that if you went to the
effort to make it work, it would work for all peers without the need for
them to understand Max Frame Size in an update...... hmmmm that almost
convinces me.

OK I've got some pondering to do... might even attempt an implementation if
the rest of the proposal looks like it might get up.

cheers









-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.