Re: [hybi] frame length encoding

"Shelby Moore" <shelby@coolpage.com> Sun, 22 August 2010 16:59 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 0B97E3A6888 for <hybi@core3.amsl.com>; Sun, 22 Aug 2010 09:59:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.194
X-Spam-Level:
X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=0.405, 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 xmgoRaKnB5bB for <hybi@core3.amsl.com>; Sun, 22 Aug 2010 09:59:17 -0700 (PDT)
Received: from www5.webmail.pair.com (www5.webmail.pair.com [66.39.3.83]) by core3.amsl.com (Postfix) with SMTP id EFE453A689B for <hybi@ietf.org>; Sun, 22 Aug 2010 09:59:16 -0700 (PDT)
Received: (qmail 43994 invoked by uid 65534); 22 Aug 2010 16:59:50 -0000
Received: from 121.97.54.174 ([121.97.54.174]) (SquirrelMail authenticated user shelby@coolpage.com) by sm.webmail.pair.com with HTTP; Sun, 22 Aug 2010 12:59:50 -0400
Message-ID: <65fc5176b7cc6c775ec167f4404b43ed.squirrel@sm.webmail.pair.com>
In-Reply-To: <AANLkTimAu5de0PnujHRwR0nnXFBpqdJoRWZ=UvGrLVJ7@mail.gmail.com>
References: <AANLkTimKbmcpgx8k0uXUWvCO=8w9pPrtV=3y4qh6363k@mail.gmail.com> <alpine.DEB.2.00.1008212037190.27211@tvnag.unkk.fr> <AANLkTinrsT+wV48nHvVW_1ChGYffkq7jisU2-PZnMyKg@mail.gmail.com> <alpine.DEB.2.00.1008212123460.27211@tvnag.unkk.fr> <20ef7ed5e135c57c1ee5a741658b9d98.squirrel@sm.webmail.pair.com> <1282423311.2014.6.camel@tng> <224b9ed365bd78fd5e316b8cb5f3f837.squirrel@sm.webmail.pair.com> <1282435214.2014.14.camel@tng> <AANLkTimo0MwZEMn1t1vrASfwC1bx82Q9Z_Ls3wVb-zUS@mail.gmail.com> <b95f074b65875865802f532bb5668ff2.squirrel@sm.webmail.pair.com> <AANLkTi=AXLFPSASV2zkBiUU=1StO=YSrKq_9AZ2ZnVHy@mail.gmail.com> <8cd6ecfebb4a073ecf94c8e1aa56e642.squirrel@sm.webmail.pair.com> <77aecf89c6c8673f1b999f80fa04e005.squirrel@sm.webmail.pair.com> <AANLkTik9tpCQr9LjK0qdLuA1KfJv1MN9yK2UZ1ytxfCW@mail.gmail.com> <fb8bfae1b88ade55cad4234af724004b.squirrel@sm.webmail.pair.com> <AANLkTimAu5de0PnujHRwR0nnXFBpqdJoRWZ=UvGrLVJ7@mail.gmail.com>
Date: Sun, 22 Aug 2010 12:59:50 -0400
From: Shelby Moore <shelby@coolpage.com>
To: John Tamplin <jat@google.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: Sun, 22 Aug 2010 16:59:18 -0000

> On Sun, Aug 22, 2010 at 12:22 PM, Shelby Moore <shelby@coolpage.com>
> wrote:
>
>> But I think you are missing my point as follows?
>>
>> Any ends that have a CPU load problem due to multi-core synchronization
>> overhead, may set their maximum size to 125, if eliminating the
>> conditional test will improve throughput. The downside is that is a lot
>> of
>> fragmentation that would not be necessary for the large source frames.
>>
>
> I think it is ridiculous to suggest an implementation would avoid a couple
> of conditional tests and instead would fragment a large frame into
> 125-byte
> frames to save CPU - the cost of the doing the fragmentation will dwarf
> the
> few instructions.

I sensibly assumed that the end that has the load issue (thus is not the
end doing the fragmenting) will choose the 125 frame size, because it has
no way to know that the sender wants to send large frames at the time the
maximum size handshake is negotiated. Even if it did know, I think it may
act selfishly due to economics.

>> The CPU load problem improves the larger the maximum frame can be, but
>> apparently not if there is conditionals in the size. That was the only
>> reason I proposed Option 1/15-bit, which gives a maximum frame size of
>> 32767 without any conditionals,
>
>
> 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).

>> and the cost is only adds 1 byte to header
>> for frame sizes smaller than 126, and removes 1 byte for the 2% of frame
>> sizes between 126 - 32767.
>>
>
> Yes, and my point above is that you add a byte in the 98% case and save a
> byte for the <2% case, which on average costs at least 0.96 bytes more per
> frame.

Say the average size is 50 bytes, then that is only a neglible 2% network
overhead cost.  If we fragment large messages to 125 instead of 32767 byte
frames, not only do we increase the network overhead to 1.6% but we
drastically increase CPU overhead.

I am arguing that maybe it is not better to squeeze the last 2% of blood
of performance and have it pop out as aliasing error in our design with a
huge bottleneck in another scenario.  That is the way nature (entropy,
Murphy's Law) works if we aren't careful in our analysis.  I am also
trying to propose concensus that makes everyone happy.