On 9 July 2014 22:26, Patrick McManus <pmcmanus@mozilla.com> wrote: > obviously if jumbo frames are not used jumbo frames dont matter > > but when they are used, all of the receivers streams are put at risk. So > the client is incented to use multiple connections so the risk is not > linked. And that's a fail for h2. > Patrick, I don't see the incentive to use multiple connections. If an endpoint wants streams to proceed in parallel, then it should not send nor accept large frames. We have already shown that going multiplexed over a single connection has advantages over multiple connections, but if an endpoint really wanted multiple connections with large frames, then it would use h1 rather than pervert h2. Besides, I don't think this is a black and white issue here. Firstly, it is not given that increases in frame sizes will be to huge frames, as it maybe that for a given network/situation 32KB frames give good throughput and acceptable QoS. More over, it is simply not the case that 16KB frames give good QoS and any thing greater does not. The proposal can also be used to decrease frame sizes if that is optimal for some situations. We have already accepted that endpoints have to be restrained with large headers if they want QoS, so we are already trusting them with that decision. How is this any different for large data? 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 Wednesday, 9 July 2014 12:42:03 UTC