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

Re: Large Frame Proposal

From: Patrick McManus <pmcmanus@mozilla.com>
Date: Wed, 9 Jul 2014 11:18:10 -0400
Message-ID: <CAOdDvNpMoSdk+KVtG+5f_bhq7KtX0LQXv9B0xSRQ10O_LLbpYQ@mail.gmail.com>
To: Greg Wilkins <gregw@intalio.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 Wed, Jul 9, 2014 at 8:41 AM, Greg Wilkins <gregw@intalio.com> wrote:

> 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 I have N transactions on a connection that uses jumbo frames then all N
transaction have a responsiveness risk anytime a jumbo frame is used
because the server cannot react to a CANCEL (or other high priority event)
without serializing the entire jumbo frame.  If I start a 500MB download
and then cancel it and start a different 500MB download the subsequent
transfer cannot happen in a timely fashion if the first one used a 500MB
frame and they all share the same connection.

There are two fixes to that problem:

1] don't use jumbo frames. that's the status quo. Its a good thing - but
the preface above was "when they are used"

2] place N transactions on N connections the way h1 does. The stream cancel
turns into a tcp rst which gives the appropriate level of reactivity.
Unfortunately now I'm not running a prioritized muxed protocol with good
connection handling - that is a bad thing :)

I appreciate that the proposal makes frames larger than 16KB optional for
the receiver and I appreciate it. My objection is that you can't create
large frames at all and have it be compatible with a prioritized mux'd
protocol - so it shouldn't be there because there really is no other reason
to want h2 other than priority mux and large frames are inherently not
priority mux friendly. I also appreciate that it allows mini frames (is
that the opposite of a jumbo frame?) but at this point in the schedule it
doesn't seem to be addressing a demonstrated problem, so I'd rather proceed
on the LC call track with this as an extension.


> 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 15:18:37 UTC

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