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 12:03:41 +0800
Cc: (wrong string) 陈智昌)" <willchan@chromium.org>
Message-Id: <033F3FF8-77CD-401F-B2E7-7AB747E0DDFA@gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Simultaneous reply to these two messages:

On 20140709, at 11:42 AM, Greg Wilkins <gregw@intalio.com> wrote:

> On 9 July 2014 13:33, David Krauss <potswa@gmail.com> wrote:
> 
> Dont forget the TCP send window, which is just as likely to be the actual limiting factor.
> 
> That is transparent to the frame size.  Implementation are not required (and in many cases probably not able) to take tcp window size into account when determining the size of a data frame.


On 20140709, at 11:42 AM, Roberto Peon <grmocg@gmail.com> wrote:

> Allowing a large frame-size setting for any stream implies a loss of reactivity for all other streams within that connection, so long as the stream with the larger framesize is used.
> 
> Essentially, it adds HOL blocking in. A frame size of 2^32, would potentially imply seconds of latency, and a failure of the protocol to deliver adequately.



HOL blocking is the senders own fault for getting ahead of itself. If the sender doesnt know how much it can instantaneously send due to a failure of the underlying TCP implementation, it should set a reasonable limit.

If attempting to fill a ridiculous frame limit isnt obviously a bad idea, then the spec might recommend not sending more than 16 or 32K unless the sender knows what theyre doing. (Many folks still deal with 16-32K/sec on a regular basis!)

The possibility of misbehavior shouldnt constrain us to use the graceful-degradation case *all the time*. Yet, every implementer should respect robustness over performance.
Received on Wednesday, 9 July 2014 04:04:19 UTC

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