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

Re: #540: "jumbo" frames

From: Willy Tarreau <w@1wt.eu>
Date: Wed, 25 Jun 2014 21:59:41 +0200
To: Roberto Peon <grmocg@gmail.com>
Cc: Patrick McManus <pmcmanus@mozilla.com>, Jason Greene <jason.greene@redhat.com>, Nicholas Hurley <hurley@todesschaf.org>, Mark Nottingham <mnot@mnot.net>, K.Morgan@iaea.org, Poul-Henning Kamp <phk@phk.freebsd.dk>, Greg Wilkins <gregw@intalio.com>, IETF HTTP WG <ietf-http-wg@w3.org>, Martin Dürst <duerst@it.aoyama.ac.jp>
Message-ID: <20140625195941.GU5531@1wt.eu>
Hi Roberto,

On Wed, Jun 25, 2014 at 12:47:11PM -0700, Roberto Peon wrote:
> The benefit to jumbo frames is solely that one can do fewer sendfile/splice
> calls, at the cost of more framing complexity,

If we just use a single bit to indicate whether the advertised length is
shifted or not, I don't think we can call that "more framing complexity",
and I would personally be fine with this (as with anything that allows
to pass 1MB or so of data I guess).

> and at the cost of having
> naive implementations (especially server implementations) do things that
> would affect performance/latency such that HTTP2 would be a downgrade.
> Patrick mentions this, and it is a large motivator here-- getting the
> muxing wrong, as is much more likely to happen with larger frame sizes,
> means poor latency.

Well, a naive implementation will not do any muxing at all, that's the
most complex part to deal with in my opinion. I think that anyone who's
able to implement the muxing correctly will not have any trouble with

     len <<= (8 * R);

And for senders, it does not change anything, they continue to send the
reserved bit to zero and nothing changes over the wire.

> Experimentation with this seems reasonable as an extension.

I suspect that we're going to rediscover the benefits of TCP's window
scaling :-/

Received on Wednesday, 25 June 2014 20:00:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC