RE: Striving for Compromise (Consensus?)

Hi Mark-

On Friday,11 July 2014 12:53, mnot@mnot.net wrote:
>On 11 Jul 2014, at 7:41 pm, <K.Morgan@iaea.org> <K.Morgan@iaea.org> wrote:
>> 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.

You lost me on this one. We (the Greg et al group) spent a considerable amount of time on our proposal with a rather detailed explanation of the issues and our proposed solutions, see [1].  There has been a lot of discussion on this proposal, IMO mostly positive from the WG, *including yourself.*

To say now that the two main goals of our proposal is a wish list totally baffles me.

I agree that since this has turned into a full-scale discussion of non-editorial changes there may be some "wishes" creeping in.  But I take issue with you calling this a wish list just because I didn't copy-and-paste each point from Greg's e-mail [1] when we introduced the proposal.


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

Gladly! But they better have some pretty sound justification as to why the "optimal" frame length for efficient and responsive multiplexing magically changed from 16K to 64K!!!


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

I think you're more optimistic than me :)  I seriously doubt it will be so easy to version so quickly. In any case, it will be much easier to go from /2 /3 if we have reserved bits so we don't have to modify the base framing header in an incompatible way or with an ugly hack. On the other hand, I'm also sympathetic to your idea to "focus on what we need now".  There are plenty of protocols that have reserved bits that will never be used.


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

This is NOT a tweak!  If header fragmentation can be accomplished with 1*HEADERS instead of HEADERS+CONTINUATION*, then keeping CONTINUATION is just keeping complexity for the sake of being too bothered to remove it. I keep bringing it up because nobody has provided a satisfactory answer as to why we still need CONTINUATION of we remove the reference set from HPACK.

-keith

[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/0427.html


This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Received on Friday, 11 July 2014 11:38:47 UTC