Re: Large Frame Proposal

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

> 
> On 9 July 2014 13:01, Jeff Pinner <jpinner@twitter.com> wrote:
> I fear the they will happen frequently in practice, requiring dynamic
> changes to the frame encoder/decoder. In practice they will likely be
> driven by what is seen at the HTTP layer (large uploads/downloads,
> file-transfer, etc).
> 
> I'm not sure I understand the extra dynamics that you think this proposal requires?
> 
> Currently a sender must dynamically adjust frame size by max(connection window, stream window).  This proposal changes that to 
> max(connection window, stream window, settings limit).

Don’t forget the TCP send window, which is just as likely to be the actual limiting factor.

> In the receiver,  it probably does rule out the simple impl of just allocating a 16KB and expecting a full frame to fit into it.  But such naive impls do not actually work in practise as you invariably receive more than one frame in your initial 16KB buffer, so subsequent frames can still wrap over a buffer boundary.   The handling you have to do for that is no different to the handling you have to do for large frames.  So I still don't see any additional complexity?

If a receiver advises that the max frame size is 16KB, then it may align each frame to the front of that buffer at the time it’s processed. This is not going to be complicated by anything, or simplified except maybe by switching to UDP instead :P .