Re: Large Frame Proposal

On 10 July 2014 09:51, Roberto Peon <> 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.

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)


Greg Wilkins <> HTTP, SPDY, Websocket server and client that scales  advice and support for jetty and cometd.

Received on Thursday, 10 July 2014 00:21:58 UTC