Re: [hybi] hum #3: Message

Scott Ferguson <ferg@caucho.com> Fri, 06 August 2010 02:12 UTC

Return-Path: <ferg@caucho.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 00B0A3A69A5 for <hybi@core3.amsl.com>; Thu, 5 Aug 2010 19:12:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 eJvwUx6hrIXf for <hybi@core3.amsl.com>; Thu, 5 Aug 2010 19:12:05 -0700 (PDT)
Received: from smtp115.biz.mail.re2.yahoo.com (smtp115.biz.mail.re2.yahoo.com [66.196.116.35]) by core3.amsl.com (Postfix) with SMTP id EAF853A66B4 for <hybi@ietf.org>; Thu, 5 Aug 2010 19:12:04 -0700 (PDT)
Received: (qmail 13322 invoked from network); 6 Aug 2010 02:12:32 -0000
Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp115.biz.mail.re2.yahoo.com with SMTP; 05 Aug 2010 19:12:32 -0700 PDT
X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C
X-YMail-OSG: M0A3JlYVM1kf1HoYu0ePG2CxSvK2ct.cJoUQfBMIYppcayl DJdc8Xf7BgyMlteeXcSFeM64kBVG4Ejyc.wt_F.VWRNy8UZLztn0ALQ1HCyE shPEO6OPRSEBaT1ftSD4N0pWrJXv0YFpGFDPXeTdJqn..5m_OzO_Q_bZomRt eI8Gosquuf6VfRSC7TSnRGA7OL1Fwr5tEY2E4sxVB0BUMJHRCZyb62MRuYIh Kge36D_cH8NiCOpa_UOfKgXmuzRJS1wEV57euI3xD9k4SzIuxku_AsCxpmhl oA4k066c3HlInxekJhf3eamu.h6ne6IA1Dd1PX9P0BYjxst07FOpupK_GNtE jHXjcZDPtlubvLDhJQExEvB2Y1AN8MhDxuPwXh1iRBhfiwMphkEzKbryZsCj pN5HkEgN8sTGtdJv4ZZnNvY6QnT.lEmqv2K.0qOXOwf6mpP9P
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4C5B6F8A.7050600@caucho.com>
Date: Thu, 05 Aug 2010 19:12:26 -0700
From: Scott Ferguson <ferg@caucho.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Ian Hickson <ian@hixie.ch>
References: <4C5AE93D.4040803@ericsson.com> <Pine.LNX.4.64.1008051758290.5947@ps20323.dreamhostps.com>
In-Reply-To: <Pine.LNX.4.64.1008051758290.5947@ps20323.dreamhostps.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] hum #3: Message
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Fri, 06 Aug 2010 02:12:07 -0000

Ian Hickson wrote:
> On Thu, 5 Aug 2010, Salvatore Loreto wrote:
>   
>>    * A message may be composed of one or more "frame"s
>>    * Each frame has a length indication, encoded in a fixed number of
>>      bits (where that lengths is fixed in the specification to be written)
>>     
>
> When transfering large blocks of data, chunking is quite inefficient. This 
> means that we'd need to make sure that the fixed width field is at least 
> long enough to handle large chunks of data.
>   

Instead of guessing, I measured chunking vs non-chunking for large 
(16meg) HTTP requests (10000 requests measured by ab on localhost, 
single client) using Resin.

The biggest difference I saw was 3% after several runs, most were within 
1%, and in some cases the chunked beat length (yay GC.)

That was HTTP chunking (8 bytes with 4 encoded as ascii hex), a 8k 
chunk/buffer size, and zero application time (write a pre-filled 64k 
buffer 256 times). In other words, a bigger overhead than the proposed 
frame header.

In other words, the overhead of chunking is so small that it's barely 
measurable, even in the most extreme case.

-- Scott
> At terabit Ethernet speeds, 32 bits is not enough since you could transfer 
> that much in mere seconds, so presumably we'll use 64 bits.
>
> Do we really want a length that long? 
>
> The alternative is variable width lengths, which are no more complicated 
> to implement than fragmentation, and which do not preclude using 
> fragmentation either, and which remain compact at any length.
>
>
>   
>>    * A message may be composed of one or more "frame"s
>>     
>
> I think we should obtain real-world experience with how people use 
> WebSockets before we add fragmentation support to the technology. Since it 
> can easily be worked around at the application layer (by having 
> fragmentation in the subprotocol), we can easily collect information on 
> how people are using this after we have initial deployments.
>
>
> Other relevant e-mails on the subject from other people:
>
> http://www.ietf.org/mail-archive/web/hybi/current/msg02841.html
> http://www.ietf.org/mail-archive/web/hybi/current/msg02830.html
> http://www.ietf.org/mail-archive/web/hybi/current/msg02892.html
>
>