W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: Large Frame Proposal

From: David Krauss <potswa@gmail.com>
Date: Wed, 9 Jul 2014 11:33:58 +0800
Cc: (wrong string) 陈智昌)" <willchan@chromium.org>, Mike Belshe <mike@belshe.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <EA156EEA-C8ED-4E1C-AADE-BC9899EEDAAD@gmail.com>
To: Greg Wilkins <gregw@intalio.com>

On 20140709, 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).

Dont 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 its processed. This is not going to be complicated by anything, or simplified except maybe by switching to UDP instead :P .
Received on Wednesday, 9 July 2014 03:34:36 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC