- 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>
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 :-/
Regards,
Willy
Received on Wednesday, 25 June 2014 20:00:22 UTC