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. 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) 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.
Received on Thursday, 10 July 2014 00:21:58 UTC