Re: Large Frame Proposal

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
>
>
>