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 12:48:06 -0700
Message-ID: <CAP+FsNfnW7KDamWHE0NfS+wKTNtOQCGWXUX7MCg_R2U3fgKx_g@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>
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


On Wed, Jun 25, 2014 at 12:42 PM, <K.Morgan@iaea.org> wrote:

> On 25 June 2014 21:30, pmcmanus@mozilla.com wrote:
> >
> >> It’s a very common use-case.
> >
> > unfortunately its one that is in direct competition with the driving
> reason for h2:
> > prioritized mux on one connection. Minimally you should prove out that
> can
> > coexist with jumbo frames because spdy showed us it was a problem. ...
>
> Adding the jumbo frame capability does not force an implementation to send
> or accept frames longer than 16K-1.
>
> The default is 16K-1 and won't change unless you update the setting.
>
> This email message is intended only for the use of the named recipient.
> Information contained in this email message and its attachments may be
> privileged, confidential and protected from disclosure. If you are not the
> intended recipient, please do not read, copy, use or disclose this
> communication to others. Also please notify the sender by replying to this
> message and then delete it from your system.
>
>
Received on Wednesday, 25 June 2014 19:48:33 UTC

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