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

[Brodie Thiesfield <[e-mail]>]

On Wed, May 25, 2011 at 11:40 AM, Greg Wilkins <[e-mail]> wrote:
> 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.

As stated earlier, I'm happy to live with no arbitrary extension use
of the reserved bits. This will require the explicit permission to use
reserved bits to be removed from the spec (see section 4.8).

Removing extension use of opcodes doesn't seem reasonable, but without
some sort of allocation scheme there will be no guaranteed interop
between extensions as multiple extensions may attempt to use the same
opcode. This will be the actual cause of the unpredictibility that
Gabriel was worried about.

Since there are already extensions being created that make use of
extended opcodes (e.g. the elusive google-mux), now is really the time
now to figure out how opcodes are allocated. At the very least, two
opcodes (e.g. 0x7 and 0xF) should be explicity reserved for future
expansion of the opcode space, which gives us somewhere to move if we
continue the free for all now.

Regards,
Brodie

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