Re: [hybi] deflate-stream and masking

"Arman Djusupov" <arman@noemax.com> Mon, 20 June 2011 14:52 UTC

Return-Path: <arman@noemax.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08A311E808E for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 07:52:28 -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=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eD7is4ASzg1d for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 07:52:23 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id B6EF111E80BE for <hybi@ietf.org>; Mon, 20 Jun 2011 07:52:23 -0700 (PDT)
Received: from ArmanLaptop by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id DUU40622; Mon, 20 Jun 2011 17:52:22 +0300
From: "Arman Djusupov" <arman@noemax.com>
To: "'Bob Gezelter'" <gezelter@rlgsc.com>, <hybi@ietf.org>
References: <20110620070915.ef1fc80126c74c6c202a919c41c7bb0b.f9a4892276.wbe@email03.secureserver.net>
In-Reply-To: <20110620070915.ef1fc80126c74c6c202a919c41c7bb0b.f9a4892276.wbe@email03.secureserver.net>
Date: Mon, 20 Jun 2011 17:51:17 +0300
Message-ID: <002a01cc2f59$878be970$96a3bc50$@noemax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKAhv+d7vI6B6bMaZMky64pplNS/pNdpCuA
Content-Language: en-us
Subject: Re: [hybi] deflate-stream and masking
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 20 Jun 2011 14:52:28 -0000

I don't think we should take the "mux" extension into account when
discussing the deflate-stream extension. Compressing "mux" channels is a
special case that should be covered by the "mux" extension specification. 

Combining all multiplexed streams into a single deflate channel is a good
idea because it is actually very cheap memory wise, otherwise compressing
each sub-channel with a separate DEFLATE stream could end up being very
expensive memory wise. You can expect over 200KB of memory needed per each
sub-channel, this basically kills the whole purpose of sub-channels which
are actually supposed to decrease the load on the server side. Two-three
thousands of compressed sub-channels would be enough to put the server on
its knees.

I consider the deflate-stream extension just as basic transport compression
which is offered "out of the box" by a WebSocket implementation,
irrespective of whether it supports multiplexing or not. 

With best regards,
Arman

> -----Original Message-----
> From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of
> Bob Gezelter
> Sent: Monday, June 20, 2011 5:09 PM
> To: hybi@ietf.org
> Subject: Re: [hybi] deflate-stream and masking
> 
> As I have noted before, Greg's observation about the interaction of
masking
> and compression is undoubtedly correct.
> 
> To be effective, compression must be done when the steam of data is most
> strongly correlated. In short, this should be BEFORE multiplexing,
encryption,
> and masking. Data on different multiplexed streams cannot be assumed to
> be correlated, and correlation is needed for effective compression.
> 
> Encrypting or masking data to create randomness similarly negates the
> effectiveness of compression.
> 
> When dealing with correlated data (e.g., the contents of a printable file,
or
> even a PostScript file), I have seen compression factors of 100:1. If the
data
> had first been encrypted, or randomly masked, the ratio would have been
> likely 2:1 (what is often achieved by disk or tape compression
facilities), or
> even less than 1:1 (worst case).
> 
> Compression should be done within each sub-stream (assuming
> multiplexing, which is not in the current specification), and in any
event,
> before encryption and masking.
> 
> - Bob Gezelter, http://www.rlgsc.com
> 
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi