Re: Large Frame Proposal

On 10 July 2014 10:40, Roberto Peon <grmocg@gmail.com> wrote:

>
> On Wed, Jul 9, 2014 at 5:21 PM, Greg Wilkins <gregw@intalio.com> wrote:
>
>>
>> It is not a choice between small==good and large==bad.   ...
>>
>
> I'm happy with 64k as a max-representable framesize :)
> 128k is almost OK-- I'd just steal a bit from the type field.
>

So max frame size is a little bit of personal preference mixed in with some
experience gained from SPDY (on todays networks with todays traffic).

I expect opinions and experience are going to change over the next 10 to 15
years.

So the point of the proposal is to move the limit from being a fixed
capacity of the frame format to a settings that can adapt to preferences,
fashion, direction of the wind, whatever.      While 64KB may well be
better than 16KB today, I don't think we can say it will always be so in
all situations.    Having the limit as a setting is just more flexible.



> I didn't personally mind the window-update part of the proposal, btw. I
> thought it was reasonable given that negative windows already need
> handling. *shrug*
>
>>
I still think it is a good idea.... but discussion about it was a
distraction for the more important changes in the proposal.  Martins point
about it not being that worthwhile if optional is also a good one.
I'm happy to re-propose it as a separate proposal once larger frames are
accepted.


I'm fairly sure it isn't a strawman since I'm talking about evidence of
> misuse of the capability of sending large frames as evidenced in SPDY :)
>

The strawman is to say that because you can send huge frames that they will
be sent in situations that will break multiplexing therefore this proposal
breaks multiplexing.   I see it as a strawman because a bad actor can
already send HEADERS+CONTINUATION* of arbitrary size an a good actor has an
incentive to not break multiplexing.


> Regardless, I'm saying that the current framesize was a direct reaction to
> that experience and evidence.
>

which is really great, and thus 16KB is the default value suggested for the
limit.   But that direct experience and evidence will not be correct for
all situations nor for all time.     Let's not lock in one snapshot of
traffic into the base capabilities of the framing layer.


Lets assume that we're OK with larger frame sizes.
> At that point the question becomes: How large should the length field be?
> Imho, 64k for a frame is plenty large: 2048 frames/gig seems cheaply
> doable.
>
> I've said it elsewhere, in other ways but:
> I'm down with a larger max framesize (within limits: I feel that even 2^24
> is pushing it).
> I'm supportive of a setting for max framesize.
>

I think we are essentially in agreement.   I see 2^31 frame sizes as
essentially infinite and yes 64KB or 128KB max frame sizes will almost
certainly give lots of wiggle room.   But setting a hard limit at just
above todays optimised max frame size is asking for trouble in the future.

I think of 2^31 as infinite size and I don't expect anybody to ever send
infinite frames.   The limit is in the settings not in the frame format.

cheers


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