Re: [hybi] frame length encoding

["Shelby Moore" <[e-mail]>]

Resending because I forgot to quote what I had written, which was critical
to the point!

Angry at myself.  Apologies.

Also clarified the point more, because I am still wondering if anyone
understands what I mean?


>> There is still a check of whether the value is the flag to indicate an
>> 8-byte length.  Having 2 compares to byte constants and associated
>> branches
>> instead of 1 compare to a short constant and a branch seems hardly a
>> significant additional processing requirement.
>
> I do not understand. With Option 1/15-bit, the 16-bits is read, the top
> bit is cleared, and that is the size to read (plus extra byte for rest of
> frame header).  No conditionals (notwithstanding extensions which is an
> orthogonal discussion).

CLARIFICATION of the context:

I meant in the case where maximum size had been negotiated to 15-bits.

Of course Option 1/15-bit would still support 8 byte size when the maximum
size was negotiated to larger than 32767.

========
I hope everyone understands my point.  I am saying that if you are going
to assume that some routers will decided to negotiate a fixed maximum size
that has no conditional tests for size header, then it is more efficient
overall to use Option 1/15-bit, than Option 1 or Option 2.

It is a bit convoluted to understand, but I think my logic is correct. I
hope others convey that they understand or they correct my logic.

The point above is that some agents may choose to always set their maximum
frame size to the size of the _SMALLEST_ size field, so that they don't
have to do comparison tests.

It was reported that on this list (and further discussed in private):

http://www.ietf.org/mail-archive/web/hybi/current/msg03453.html

that multi-core coordination overhead may not scale proportionally with
network bandwidth, and thus making the protocol as stateless as possible
is very important in that case. I am not arguing that is the case. I am
trusting the expertise of concensus. I am also saying why should we risk
it for 2% savings in network bandwidth overhead?