W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: Large Frame Proposal

From: Greg Wilkins <gregw@intalio.com>
Date: Wed, 9 Jul 2014 22:41:35 +1000
Message-ID: <CAH_y2NE9gDstpeOw3aZ86Bf2gvJisf3Xce3TWbGLDZYzR1B14Q@mail.gmail.com>
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Roberto Peon <grmocg@gmail.com>, David Krauss <potswa@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC