Re: Large Frame Proposal

On Wed, Jul 9, 2014 at 5:21 PM, Greg Wilkins <gregw@intalio.com> wrote:

>
> On 10 July 2014 09:51, Roberto Peon <grmocg@gmail.com> wrote:
>
>> With a small framesize, that'll work just fine.
>> With a large framesize, that won't work. You may end up with single
>> frames which take seconds or even hours (4GB of data on a low bandwidth
>> link, for instance) to drain.
>>
>
> Again with this strawman analysis!
>
> It is not a choice between small==good and large==bad.    There is a
> spectrum of possible frame sizes and picking a single arbitrary 16KB frame
> size is unlikely to be optimal in even a majority of today's networks.
> This proposal is to allow 32KB, 64KB 128KB frames much more than it is to
> occasionally allow a much larger frame.  In fact we have removed the
> WINDOW_UPDATE part of the proposal that would facilitate easy sending of
> very large frames for large content.
>

I'm happy with 64k as a max-representable framesize :)
128k is almost OK-- I'd just steal a bit from the type field.

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*


>
> it would be interesting to perform an experiment on a fast network and
> compare user experience between multiplexed  traffic over 16KB frames vs
> 64KB frames.   I'm betting that most users will not notice the difference
> in terms in QoS/interruptability etc. but they will notice the faster down
> load times of images etc. with the large frame size.
>
> Regardless, the argument against this proposal based of the fact that
> sending a 2GB frame will break multiplexing is a straw man.  Just because a
> mechanism can be misused is not a sufficient argument against it.   In this
> case, large frames requires the collaboration of both peers, while large
> headers can currently be sent by a single peer (Even if it will get 431'd)
>

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 :)
Regardless, I'm saying that the current framesize was a direct reaction to
that experience and evidence.

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



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