Re: Large Frame Proposal

On 2014–07–09, at 10:56 AM, Greg Wilkins <gregw@intalio.com> wrote:

> 
> On 9 July 2014 12:35, David Krauss <potswa@gmail.com> wrote:
> Dynamic changes are unlikely to happen in practice;
> 
> If the proposal is accepted, Jetty is definitely planning on modifying our server to adjust the frame size setting to a large value when we see a single large upload on a request.
> 
> We will do the same for our client for downloads.

OK, I suspected I was having a failure of imagination anyway :P .

It seems pointless to only keep the frame size small only while little is being received anyway. Perhaps you intend to reduce the frame size when a request is received in the midst of a long data reception? This would trade-off HOL blocking against performance, as a single HOL block event would restore performance for subsequent requests.

I’m a bit skeptical of this scheme. The server is not responsible for (and barely capable of) fine-tuning the client’s request+upload stream. Could you confirm whether I’m thinking along the right lines?

> While I would have preferred a per stream limit for dynamic changes (to match the per stream flow control window) as per the original proposal, I've accepted the argument made by Martin that having that as an optional part of the specification makes unlikely to be useful.  A dynamic setting for the connection can be used almost the same.         But eitherway, I think the limit should be considered as part of the flow control algorithm and thus is naturally dynamic.

A per-stream setting would be nice. If I were designing from a clean slate, multiplexing would be strictly a lower layer and flow control would be a separate protocol contained within each stream. For better or worse, we still have multi-connection as a fallback.