Re: Large Frame Proposal

OK. So it sounds like we don’t need to reserve away bits then. We can just stick with the 32 bit limit.

On Jul 11, 2014, at 9:59 AM, Roberto Peon <grmocg@gmail.com> wrote:

> As I mentioned before, IIRC we've seen response headers as large as 12mb, at which point we said: OK, lets have a 2G limit (effectively infinite), because clearly we can't predict this.
> 
> -=R
> 
> On Jul 11, 2014 7:05 AM, "Jason Greene" <jason.greene@redhat.com> wrote:
> So it sounds like the two remaining concerns with the large frame prosal are:
> 
> 1) Someone might repeat the abuse of SPDY (shove entire files in a frame)
> 
> 2) Fragmentation.
> 
> 
> For [1] I propose a very simple compromise, we use 18 bits + 14 reserved bits. It gives us 256K, which is plenty to fit big headers, and near term growth of communication channels. It also allows big headers without *requiring* a continuation, which was a key element of the spec  The reserved bits make it easy for us to expand this later because all implementations will be trivially compliant in subsequent releases (no wire change necessary). We can of course quibble on the goldilocks number, but that is a small detail compared to the overall benefits of the proposals changes.
> 
> For [2] I think that the use cases are very limited and solving this requires significant revamping of the current continuation form (probably matching some or many of Jeff’s changes). I am not against this, but I think it would be easier to manage the changes if we went forward with the large frame proposal, and then worked out the details of a fragmentation enhancement. Otherwise we might end up in a loop.
> 
> Thanks.
> 
> 
> On Jul 10, 2014, at 9:16 PM, Greg Wilkins <gregw@intalio.com> wrote:
> 
> > 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.
> >
> > regards
> >
> >
> >
> >
> >
> >
> >
> >
> > 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.
> 
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> 
> 

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

Received on Friday, 11 July 2014 15:23:33 UTC