Re: [hybi] method of allocation of reserved bits to extensions

[Greg Wilkins <[e-mail]>]

The simplest solution is to say that the 3 bits (and spare opcodes) in
the framing are reserved for future versions of the protocol - ie off
bounds to all extensions.

Extensions that want to send bits and extra opcodes will always have
to allocated bytes in the payload to carry them.

Then we have two choices - come up with an allocation scheme in the
spec (eg based on ordering like I've suggested), that may save a few
bits per frame;  or we could leave this to the extensions to do their
own allocation (minimum 1 octect for extensions wanting flags and/or
opcodes).   I tend to agree that the bit savings might not be worth
the effort to specify such a system, specially if we have a
frame-deflate extension that would compress all those wasted bits
anyway.

The only outcome I'm strongly against is the status quo - where we
have a few scarce resources with no fair share mechanism defined.
This will just result in unfair market forces being used to make
defacto allocations of those bits (and opcodes for that matter).   It
is better not to have them than to have them with no fair share
policy.

cheers



On 21 May 2011 04:05, Brian <[e-mail]> wrote:
> This seems fine to me too, but a bit more complicated than just
> letting extensions prepend a byte for themselves to the payload data.
> Honestly.. quibbling over wasting 7 bits by allocating a whole byte in
> this day and age seems silly, even for things like cell phones.  My
> cell phone (iPhone on AT&T in Los Angeles) is routinely able to
> transfer data at over a megabit per second (and even faster when I get
> out of the city).  So if there are a small handfull of "wasted" bytes
> in the payload to accommodate extension data/flags, nobody's really
> going to notice.
>
> I would support the dynamically allocated flags mechanism that can
> dynamically add more bytes to accomodate more extensions, but I just
> think it seems a little unnecessary.
>
> Brian
>
> On Fri, May 20, 2011 at 12:50 AM, "Andy Green (林安廸)" <[e-mail]> wrote:
>> On 05/20/2011 07:42 AM, Somebody in the thread at some point said:
>>>
>>> Gabriel
>>>
>>> I'm concerned that if we really restrict usage of the reserved bits,
>>> then we will force extensions into using whole bytes at the start of
>>> the payload, when they really only want 1 bit.  If we really do get
>>> into the situation where we have many extensions, then we could have
>>> many wasted bits.
>>>
>>> How about just having a mechanism that if we can allocated as many
>>> reserved bits as we like, and if more than 3 are allocated then extra
>>> bytes are prepended to the payload (as needed) for the extra bits.
>>> Thus we could have unlimited extensions needing unlimited bits.
>>>
>>> If a client doesn't want to play that game, then all it need do is
>>> never handshake with extensions that need more than 3 bits.
>>
>> Sounds good to me.
>>
>> This idea of reserved bits being misered is not only unnecessary but it is
>> really inefficient - it'll lead to only special, big, connected players
>> being able to use them and because they are permanently allocated to
>> particular extensions in that model, there will always be a desire to
>> withhold them "for later".
>>
>> Dynamic allocation way anyone can randomly decide their extension will use
>> them, no central allocation is needed and multiple extensions using reserved
>> bits will always play well (plus or minus other doubts about extension
>> ordering not related to reserved bits).
>>
>> -Andy
>> _______________________________________________
>> hybi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hybi
>>
>