Re: Large Frame Proposal

Mike,

I think the settings are needed with the ability to send larger frame
sizes.   If I understand the feedback from SPDY correctly, the larger frame
sizes there were some endpoints that were lazy with their frame sizes and
sent overly large ones that hurt multiplexing.

The intention of the proposal is to allow large frame sizes IF NEEDED, but
to use the settings to constrain implementations to the 16KB that has been
selected as a reasonable one-size-fits-all for todays traffic.   The
settings can then be adjusted without needing to rev the spec or deploy
extensions as experience is gained, traffic changes, networks change
etc.     It may well be that they are adjusted down initially as much as
they are adjusted up.

So I don't see it as a compromise - it is simply moving the limit that must
exist from being a fixed capability of the framing layer to be an
explicitly managed parameter of the protocol.

cheers





On 8 July 2014 10:07, Mike Belshe <mike@belshe.com> wrote:

>
>
>
> On Mon, Jul 7, 2014 at 12:50 AM, Greg Wilkins <gregw@intalio.com> wrote:
>
>>
>> squid3@treenet.co.nz
>>    - Greg Wilkins gregw@intalio.com
>>    - Jason Greene jgreene@redhat.com
>>    - Keith Morgan K.Morgan@iaea.org
>>    - Poul-Henning Kamp phk@phk.freebsd.dk
>>
>> [1] http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0926.html
>> [2] http://httparchive.org/interesting.php
>> [3] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/1664.html
>>
>>
>> --
>> 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.
>>
>
>


-- 
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.