Re: Striving for Compromise (Consensus?)

On Fri, Jul 11, 2014 at 10:47 AM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> This seems to be the set that people are talking about most seriously:
>
> On 11 July 2014 00:48, Greg Wilkins <gregw@intalio.com> wrote:
> > 1) Increase frame size to 16-bits
>

This seems OK in conjunction with 1a and 1b. But not without 1a + 1b.


>  > 1a) Add a settings for max_frame_size
> > 1b) ...that defaults to 16k
> > 1c) ...with some minimum (which might be 256, though a 256 byte frame
> could be all padding...)
>

This minimum needs to be bigger, like I've said before. A laughable size
like 256 just provides too much opportunity for someone to shoot themselves
in the face. 4k is still my suggestion here, based on telemetry on
compressed header sizes in Firefox.


> > 2) Remove reference set from HPACK allowing for "streaming" decoding.
>

Yes, please!


>  > 3) Requiring that all ":"-headers appear first.
>

Sounds fine by me.


>  > 4) Only allowing CONTINUATION if the previous frame is max_frame_size.
>

I'm not totally against this at first glance, but as you point out below,
it's not well understood, and that makes me opposed to this. We're trying
to nail down the protocol, not introduce more uncertainty or opportunities
for footguns.


> > 5) Allowing interleaving of CONTINUATION frames with other frames.
> > 5b) The size of the HEADERS and CONTINUATION frames are removed from the
> > flow control window, but the they are never flow controlled.
>

No on both counts. Interleaving is, as Roberto pointed out, bad. Modifying
the flow control window without flow controlling that which modifies the
window is disgustingly asymmetric, and another great opportunity for a
footgun. And flow controlling headers means we can easily get ourselves in
a state where we can't start new streams that are absolutely necessary. So,
no.


> I think that 4 and 5 might be problematic.
>
> 4 doesn't seem to be well understood, but the interaction between TCP
> congestion window and something like the proposed 5b could mean some
> serious stalling/HOL issues.  More serious than the issues it purports
> to address.
>
> I think that 5 is a non-starter.  Roberto's analysis on this has
> convinced me that this is an undesirable feature.
>
>