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 14:26:57 -0700
Message-ID: <CAP+FsNcUSBipeiO6JeyHqcM=x9ycMCgVLkZdkU827iEZ7UNygA@mail.gmail.com>
To: "K.Morgan@iaea.org" <K.Morgan@iaea.org>
Cc: Jason Greene <jason.greene@redhat.com>, Patrick McManus <pmcmanus@mozilla.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>
But it does not remove the continuation 'kludge'. It substitutes one
'kludge' for another 'kludge' and doesn't change the orthogonal requirement
to handle arbitrarily large headers...

Continuation has the advantage of being a known annoyance.
There have been proposals for requiring that CONTINUATION (and similar
non-stream-initiating-HEADERS frames) carry only non-state-modifying data,
in which case many of the annoyances w.r.t. continuation go away.
I'd prefer investigation into avenues like that, personally.

Jumbo frames have the disadvantage of folks not realizing the harm they
cause, and then causing it anyway.
-=R


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

> On 25 June 2014 22:22, grmocg@gmail.com wrote:
> > The sender determines how to apportion data into frames.
> > We were seeing whole files transmitted as a single frame.
> > -=R
>
> The sender can only apportion data into frames less than
> SETTINGS_MAX_FRAME length; and if you never change it, he has to use 16K or
> less.
>
> This is exactly the point. The jumbo frames eliminates the CONTINUATION
> "kludge" & allows use cases which need jumbo frames to have them if the
> peer gives consent.  All while not preventing efficient muxing with 16K
> frames.
> 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 21:27:25 UTC

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