Re: Striving for Compromise (Consensus?)

On 11 Jul 2014, at 7:41 pm, <K.Morgan@iaea.org> <K.Morgan@iaea.org> wrote:

> On Friday,11 July 2014 09:32, jpinner@twitter.com wrote:
> 
>> How do people feel about the following compromise:
> 
> -1
> It eliminates both purposes of the 'Greg et al' proposal:
>  a) Eliminate the CONTINUATION ugliness (complexity, processing, etc.), and
>  b) add bits & settings for tuning frame lengths.

See my previous message to Willy. These are not issues, they’re a wish list. 

To be clear — the time to argue over the aesthetics of the protocol has long passed; I’m not willing to hold this effort up because there’s disagreement about how it looks. If there are concrete technical issues that aren’t on the list, bring them up. If you think that this proposal doesn’t address the relevant issues, say so. “It’s too complex” isn’t a concrete technical issue; it’s a judgment call with many facets, as discussed. I pulled Roberto up for justifying a position with “bleh” earlier today, and I expect no less from everyone else.

Likewise, asking for the result to look in a particular way (such as particular settings) is an unreasonable request at this stage in this protocol’s development; you need to show concrete problems that are caused by the design or proposal.

Be aware that the even then, the WG may decide not to address a particular issue.


>> 1) Increase frame size to 16-bits.
> 
> I don't know how this could be claimed as a good idea without also having the SETTINGS_HEADER_SIZE & SETTINGS_FRAME_SIZE setting.  Roberto, Patrick, etc. have repeatedly said that 16K is the 'optimal' frame size for multiplexing on today's networks.  Moving to 16 bits without a setting means everybody will use 64K.  Remember, in the 'Greg et al' proposal the default frame size is still 16K (actually it's literally one better - it's 16K instead of 16K-1!).

Let other people make their own assessments of the proposal, please. If Roberto, Patrick et al like this proposal, all the better.


> It's also terribly short-sighted to not have any space for expansion.  At the very least you should keep 1 reserved bit so you can do the ugly "jumbo frame" hack later when you figure out you want bigger frame sizes.

I’m getting unsympathetic to arguments of the “we might need that” variety. The WG has long held that if major changes are necessary, the protocol can be versioned much more easily than from /1 to /2.

Let’s focus on what we need now. If we need 31 bits to address our issues, so be it — but this is largely separable from the current discussion about header sizes, buffering, etc.


>> 2) Remove reference set from HPACK allowing for "streaming" decoding.
> 
> This is a good idea.
> 
> 
>> 3) Requiring that all ":"-headers appear first.
> 
> This is also a good idea.
> 
> 
>> 4) Only allowing CONTINUATION if the previous frame is 2^16-1 bytes.
> 
> See Roberto's thread "Fragmentation for headers: why jumbo != continuation" [1] for reasons why he thinks this is a bad idea.

See also my follow-up (in anticipation of that).


>> 5) Allowing interleaving of CONTINUATION frames with other frames.
> 
> Admittedly better than the status quo, but still not entirely clear why this is necessary. i.e. why not 1*HEADERS instead?

Let’s agree on the general approach before we go into tweaking.



Thanks,


--
Mark Nottingham   http://www.mnot.net/

Received on Friday, 11 July 2014 10:53:46 UTC