Re: Large Frame Proposal

Thanks, Greg.

I believe your proposal is preferable to what we have today in H2.


On Mon, Jul 7, 2014 at 8:14 PM, Greg Wilkins <gregw@intalio.com> wrote:

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

OK - thanks for clarifying.   I don't recall any such learning from SPDY.
 It certainly wasn't learning while I was at Google.

BTW, some history:
* SPDY originally used large frames too - 24bits - and let you use it as
you wished.  Some people worried that these large frame sizes would be
abused someday and felt compelled to shrink them.  But, as far as I know,
those arguments were only theoretical.  The fact is that you're really only
going to hurt yourself; and 'you' is the server.  Proxies are a different
story.

* SPDY's final field sizes were not arbitrary - they were an evolution
based on lessons of what is valuable and what works.  Initially all headers
were limited to 16k-ish.  This was because we didn't "like" large headers.
 But, when put to practice there are edge cases which needed to be dealt
with, and some apps out there, wisely or not, use ridiculously sized
headers.  It just happens.  Increasing the size was always preferable
because:
   a) we learned that the constraint itself wasn't very valuable and didn't
make anything materially better.
   b) there were edge cases where the constraint just didn't work, and the
solutions were worse than the initial problem.



>
> 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.
>
>
Ok. I don't see any real need for these either.  They may introduce new
oddities if someone goes crazy with them.  I'd lean toward not adding these
if possible.

Mike






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