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

Re: Large Frame Proposal

From: Greg Wilkins <gregw@intalio.com>
Date: Fri, 11 Jul 2014 12:16:31 +1000
Message-ID: <CAH_y2NHedfFm_mUUyaLwt=01pt4YcjTboJbippiavWFA3hbrWQ@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
OK, so keep the stream ID at 31 bits.

I cannot see that similar arguments do not apply to length. There are
already use-case for 64KB headers, so a 16b frame size is only just big
enough for them today, so we have zero room for growth and there are some
headers already larger than 64KB, so we are cutting off some users.

I can't live with 16 bit length.

24 bit minimum for me.


On 11 July 2014 11:54, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 10 July 2014 18:12, Greg Wilkins <gregw@intalio.com> wrote:
> > 24 bits of each is still 16MB frames and 16M streams in a connection....
> I
> > think both are reasonable guesses for infinity and this is a good
> compromise
> > between all the concerns.
> We've had input to the effect that a rollover would occur too
> frequently for some users at a 24-bit identifier.  I think that the
> number in question was a rollover every 10 minutes happens anyway.
> I'd have to confirm whether that is at 31 or 24.  Given how disruptive
> a rollover is, a the extra bits are useful.
> Note also that stream identifiers are used elsewhere, so we'd need to
> rework things in a few other places if they changed in size.

Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.
Received on Friday, 11 July 2014 02:17:00 UTC

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