Re: Large Frame Proposal

It wasn't a matter of acceptance-- it was a matter of reliability.

-=R


On Tue, Jul 8, 2014 at 9:05 PM, Greg Wilkins <gregw@intalio.com> wrote:

>
> On 9 July 2014 13:42, 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.
>>
>
> Indeed, that is why the proposal includes setting limits that should only
> be increased when it is known that QoS will not be affected or is not
> important.   Nobody is saying that sending 2^31-1 frames will not hurt QoS.
>
>
>
>> Larger framesizes matter only for non-TLS connections.
>>
>
> And TLS is very frequently offloaded and will be more often if the
> browsers insist on making it mandatory.
>
> So large framesizes may only be applicable for traffic within the data
> centre, but any such workload I can get off my server the better!
>
> Even for dynamic generated content from JSPs, Servlets etc. we have found
> that it is far more scalable to give them a nice big 64KB or 128KB buffer
> so they can run to completion without blocking and we can then flush that
> buffer asynchronously.
>
> It is also not yet given if TLS only deployment of h2 will be widely
> accepted.
>
> regards
>
>
>
>
>
>
>
> --
> Greg Wilkins <gregw@intalio.com>
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
> scales
> http://www.webtide.com  advice and support for jetty and cometd.
>