Re: Large Frame Proposal

Simultaneous reply to these two messages:

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

> On 9 July 2014 13:33, David Krauss <potswa@gmail.com> wrote:
> 
> Don’t 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 2014–07–09, 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 sender’s own fault for getting ahead of itself. If the sender doesn’t 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 isn’t obviously a bad idea, then the spec might recommend not sending more than 16 or 32K unless the sender knows what they’re doing. (Many folks still deal with 16-32K/sec on a regular basis!)

The possibility of misbehavior shouldn’t constrain us to use the graceful-degradation case *all the time*. Yet, every implementer should respect robustness over performance.