Re: Large Frames, Continuations, Flow Control, and changing HPACK

While I'm a fan of removing the reference set (which has come up multiple
times before), I'm not a big fan of the rest of the changes proposed -
they're much more invasive than Greg's proposal. Being required to split
the HPACK encoding at JUST the right point to fit in a 64k frame is a much
uglier change than asking "I've generated more than 16k of headers. Does my
peer support a frame size that this fits in?" Given a choice between the
two (and without a choice of "keep the status quo" - which is still far and
away my preference), I would much rather have a simple setting with jumbo
frames (Greg, et al's proposal).

So, even though we aren't voting, I'll give this my proverbial -1 and
change my -1 on Greg's proposal to a +/-0 if we could keep the status quo,
or a strong +1 if we've come to consensus on dispensing with the status
quo. That comes with a couple caveats - I would want to see a larger
minimum for the max frame size (256 is laughably small, and is a really
good way to shoot oneself in the foot really easily - I propose 4k, based
on the numbers I see in Firefox's telemetry for compressed header size),
and I don't like the dynamic changing of frame size on a per-stream basis
(which feels both too invasive, and WAY too easy to get wrong).

--
Peace,
  -Nick


On Tue, Jul 8, 2014 at 3:11 PM, Jason Greene <jason.greene@redhat.com>
wrote:

>
> On Jul 8, 2014, at 5:01 PM, Mike Belshe <mike@belshe.com> wrote:
>
> >
> >
> >
> > On Tue, Jul 8, 2014 at 9:39 AM, Jeff Pinner <jpinner@twitter.com> wrote:
> > To be clear, the proposal is:
> >
> > 1) Remove the reference set from HPACK (use "Linear-H")
> >
> > +1; Kazu's data convinces me entirely.
> >
> > 2) Increase the frame size to 16-bits
> >
> > +1 to increase the size.  I would support going larger; the artificial
> limits never provided value in SPDY nor H2.  I liked Greg's proposal
> generally.
> >
> > 3) Allow interleaving of HEADERS frames
> > 4) Remove the "\0" separator hack.
> >
> > +1; these were hacks unresolved due to the global compressor.
> >
> >
> > Coupling this with my earlier proposal to add a "SYN_STREAM" header
> > would also allow us to:
> >
> > 5) Remove CONTINUATION frames entirely
> >
> > +1; this makes things much simpler.
> >
> > 6) Move END_* flags to the last HEADERS frame
> >
> > +1; makes things simpler.
> >
> > 7) Flow control HEADERS frames
> >
> > +1;  this is just simpler too.
> >
>
> Wow, are we actually approaching consensus? :)
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
>