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

Re: Large Frame Proposal

From: Roberto Peon <grmocg@gmail.com>
Date: Wed, 9 Jul 2014 17:54:12 -0700
Message-ID: <CAP+FsNci98f=K9+ehkhOBnh5w41qZ4xZhNFyFZoeu-wLUWSdvQ@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Greg Wilkins <gregw@intalio.com>, David Krauss <potswa@gmail.com>, Patrick McManus <pmcmanus@mozilla.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Jul 9, 2014 at 5:47 PM, Mark Nottingham <mnot@mnot.net> wrote:

>
> On 10 Jul 2014, at 10:40 am, Roberto Peon <grmocg@gmail.com> wrote:
>
> > Lets assume that we're OK with larger frame sizes.
> > At that point the question becomes: How large should the length field be?
> > Imho, 64k for a frame is plenty large: 2048 frames/gig seems cheaply
> doable.
> >
> > I've said it elsewhere, in other ways but:
> > I'm down with a larger max framesize (within limits: I feel that even
> 2^24 is pushing it).
> > I'm supportive of a setting for max framesize.
>
> There's another aspect here -- if we have larger frames, are people OK
> with the max frame size becoming the effective ceiling on compressed header
> block size, because CONTINUATION is ditched in the process?
>
> Thanks,
>
>

That can become very dangerous.
If there is a single limit on framesize, then it would end up being large
because the receiving party is unlikely to know how large the headers
should be, and must set it to as large as they ever believe headers might
be.
That negatively impacts reactivity.

One could fix this by have separate headers vs data max frame size.
Then we'd need to figure out which one mapped to SETTINGS and other control
frames.
Would it be a control-frame vs data-frame setting?
Bleh.

-=R
Received on Thursday, 10 July 2014 00:54:39 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC