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

Re: #540: "jumbo" frames

From: Roberto Peon <grmocg@gmail.com>
Date: Wed, 25 Jun 2014 13:06:52 -0700
Message-ID: <CAP+FsNe-X2CbRD+7XGtrcFacc72MwEBf8bDu-WRGmA10fjXMhg@mail.gmail.com>
To: K.Morgan@iaea.org
Cc: Patrick McManus <pmcmanus@mozilla.com>, Jason Greene <jason.greene@redhat.com>, Nicholas Hurley <hurley@todesschaf.org>, Mark Nottingham <mnot@mnot.net>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Willy Tarreau <w@1wt.eu>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>, Martin Dürst <duerst@it.aoyama.ac.jp>
On Wed, Jun 25, 2014 at 1:00 PM, <K.Morgan@iaea.org> wrote:

> On 25 June 2014 21:48, grmocg@gmail.com wrote:
> > The same is true for any other optional thing under the sun.
> > It doesn't seem to be a motivating argument for including more optional
> features, though.
> > -=R
> That's not the point.  Patrick implied that adding the jumbo frame option
> kills the ability to efficiently mux.  That's simply false.

A jumbo frame option requires the implementation to be smart to before the
protocol becomes effective/useful for web traffic.

> On Tuesday,22 April 2014 09:00, fielding@gbiv.com said [1]:
> "Likewise, restricting packet sizes to a small length in order to prevent
> fools from HOL blocking
>  their own multiplexed channels makes some sense, for browser developers.
>  However, it actively harms applications of HTTP that are not interested
> in multiplexing
>  because they only want to transmit a single large data stream.
>  ... I don't think it makes sense to limit an application-level protocol
> to the worst case.
>  ....Roy"
> So let's be straight.  There are legitimate use cases for jumbo frames.
>  You and Patrick just think the world is full of a bunch of what Roy calls
> "fools" (see above) who will HOL block their own multiplexed channels.  Roy
> (and I) don't disagree.  Roy (and I) don't think it makes sense to limit
> the protocol to protect against an unknown number of fools.

Keep in mind that the original SPDY had much, much larger max framesizes,
and I designed it that way in concert with Mike.
Implementation experience, however, provided hard data that this actually
happens, and harms the user.

Received on Wednesday, 25 June 2014 20:07:19 UTC

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