Re: [hybi] frame length encoding

"Shelby Moore" <shelby@coolpage.com> Sat, 21 August 2010 14:55 UTC

Return-Path: <shelby@coolpage.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E4F23A6988 for <hybi@core3.amsl.com>; Sat, 21 Aug 2010 07:55:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.047
X-Spam-Level:
X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=0.552, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyIt2mEKYp6K for <hybi@core3.amsl.com>; Sat, 21 Aug 2010 07:55:50 -0700 (PDT)
Received: from www5.webmail.pair.com (www5.webmail.pair.com [66.39.3.83]) by core3.amsl.com (Postfix) with SMTP id 2B6363A68F1 for <hybi@ietf.org>; Sat, 21 Aug 2010 07:55:50 -0700 (PDT)
Received: (qmail 26373 invoked by uid 65534); 21 Aug 2010 14:56:22 -0000
Received: from 121.97.54.174 ([121.97.54.174]) (SquirrelMail authenticated user shelby@coolpage.com) by sm.webmail.pair.com with HTTP; Sat, 21 Aug 2010 10:56:22 -0400
Message-ID: <9038007a07cb2e7f2659663b8bc6af82.squirrel@sm.webmail.pair.com>
In-Reply-To: <AANLkTinHqxUOZaVANFpC52t8FfgNw2L5_A-s9Az3Fm7p@mail.gmail.com>
References: <AANLkTimKbmcpgx8k0uXUWvCO=8w9pPrtV=3y4qh6363k@mail.gmail.com> <20100820192927.GA32620@1wt.eu> <4C6EEA55.2050205@hs-weingarten.de> <AANLkTinHqxUOZaVANFpC52t8FfgNw2L5_A-s9Az3Fm7p@mail.gmail.com>
Date: Sat, 21 Aug 2010 10:56:22 -0400
From: Shelby Moore <shelby@coolpage.com>
To: Pieter Hintjens <ph@imatix.com>
User-Agent: SquirrelMail/1.4.20
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] frame length encoding
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: shelby@coolpage.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Aug 2010 14:55:51 -0000

> Option 1 is simplest and sufficient for all use cases. There is no
> advantage
> in a more complex algorithm and non-trivial costs in complexity, and
> inefficiency for frames of 125-254 bytes if we use option 2.

At least 267% incorrect.

The Option 2 inefficiency is only 3/125 to 3/254, which is 2.4% to 1.2%.

Whereas, Option 1 is 8/127 to 8/254, which is 6.3% to 3.1%.

Also Option 1 increases inefficiency by 267% from 3/255 to 8/255 and all
values between to 2/65535 to 8/65535.

Also Option 1 causes a big discontinuity in inefficiency at 126, and that
could be a source of random performance patterns, which is hard to
quantify.

Also I want to suggest that we change Option 2 to re-use the 7 bits from
the first byte instead of adding 2 bytes, then we only add 1 byte.  The
only disadvantage is the values from 32768 to 65335 which incur a 0.002%
inefficiency.  But then our efficiency for 125 to 32767 will increase by
50%!!

So I think it is a "no brainer" that we adopt my modification for Option 2:

long long len = readByte();
switch (len) {
  case 126:
    len = ((len & 0x7f) << 8) + readByte();
    break;
  case 127:
    len = readLongLong();
    break;
}



>
> Option 1 gets my vote.
>
> -Pieter Hintjens
>
> Sent from my Android mobile phone.
>
> On Aug 20, 2010 10:49 PM, "Roderick Baier"
> <roderick.baier@hs-weingarten.de>
> wrote:
>> Willy Tarreau schrieb:
>>> Hi John,
>>>
>>> On Fri, Aug 20, 2010 at 03:08:08PM -0400, John Tamplin wrote:
>>>> Option 2
>>>> ========
>>>> Use 7 bits in the frame header, and if the value is 0-125, that is the
>>>> length. If the value is 126, then the next 2 bytes are a 16-bit
>>>> length.
> If
>>>> the value is 127, the next 8 bytes are a 63-bit length (the high bit
> must be
>>>> zero).
>>>>
>>>> long long len = readByte();
>>>> switch (len) {
>>>> case 126:
>>>> len = readUnsignedShort();
>>>> break;
>>>> case 127:
>>>> len = readLongLong();
>>>> break;
>>>> }
>>>
>>> This looks really nice and optimal to me !
>>>
>>> +1 !
>>>
>>
>> +1
>>
>>
>> _______________________________________________
>> hybi mailing list
>> hybi@ietf.org
>> https://www.ietf.org/mailman/listinfo/hybi
>>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>