Re: [hybi] preliminary WebSockets compression experiments
Jamie Lokier <jamie@shareable.org> Tue, 27 April 2010 13:37 UTC
Return-Path: <jamie@shareable.org>
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 14D5D3A6A8D for <hybi@core3.amsl.com>; Tue, 27 Apr 2010 06:37:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.434
X-Spam-Level:
X-Spam-Status: No, score=-1.434 tagged_above=-999 required=5 tests=[AWL=-1.435, BAYES_50=0.001]
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 tm+Td2AQktyc for <hybi@core3.amsl.com>; Tue, 27 Apr 2010 06:37:52 -0700 (PDT)
Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 8A7A03A69EB for <hybi@ietf.org>; Tue, 27 Apr 2010 06:37:41 -0700 (PDT)
Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from <jamie@shareable.org>) id 1O6kya-0005ch-DL; Tue, 27 Apr 2010 14:37:24 +0100
Date: Tue, 27 Apr 2010 14:37:24 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Mike Belshe <mike@belshe.com>
Message-ID: <20100427133724.GA25405@shareable.org>
References: <q2z3f94964f1004231247zc7b60dc3l5fbb4748d129c3c@mail.gmail.com> <z2o2a10ed241004231448l7a63e329p98e04fbe1a750539@mail.gmail.com> <4BD59DA0.6060506@webtide.com> <k2m2a10ed241004260928q2448b8f6nae7c13db81a97579@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <k2m2a10ed241004260928q2448b8f6nae7c13db81a97579@mail.gmail.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
Cc: hybi@ietf.org
Subject: Re: [hybi] preliminary WebSockets compression experiments
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: Tue, 27 Apr 2010 13:37:53 -0000
Mike Belshe wrote: And the best answer is to have the protocol help avoid it. > You can do so by encrypting everything to avoid tampering, or you can > avoid it by mandating compression. It's not necessarily "best". First, if you encrypt everything end to end, that will prevent intermediaries from applying joint compression to multiple streams. That is most relevant to opportunistic multiplexing, but it isn't the only way. The results which started this thread strongly imply that joint compression of a stream of small objects is sometimes far better than individual compression of them - enough to tip the balance in favour of compression versus not, in some cases. Second, end to end encryption rules out some devices from using the protocol at all - they don't have enough processing capacity and/or memory to do it. Third, same applies to mandatory compression, if it is one of the compression types which needs a lot of processing and/or memory. Fourth, we know that many client locations block many different kinds of outgoing traffic, and some of them block anything they don't understand. That no doubt includes all encrypted traffic from some of them. It should not be mandatory to encrypt, for that reason. Fifthly, forcing implementations to use a compression scheme which was good in the year 2000 (deflate), is looking a bit dated now for compression performance (bzip2, lzma are better for many things), and is too compute intensive for on the fly encryption on slower or heavily loaded or power-sensitive devices (lzo family are better for that)... projecting ahead to 2015, 2020, the "mandatory" part of the spec would probably get ignored or worked around by many implementations. Sixthly, we're assuming proxy-caches play no role in these protocols. With WebSocket itself, that's true, but with protocols like SPDY that might be layered over it, it is likely (imho) that a role will be found for proxy-caches. End-to-end encryption is not compatible with that. -- Jamie
- Re: [hybi] preliminary WebSockets compression exp… Jamie Lokier
- Re: [hybi] preliminary WebSockets compression exp… Mike Belshe
- [hybi] preliminary WebSockets compression experim… John Tamplin
- Re: [hybi] preliminary WebSockets compression exp… Mike Belshe
- Re: [hybi] preliminary WebSockets compression exp… John Tamplin
- Re: [hybi] preliminary WebSockets compression exp… Roberto Peon
- Re: [hybi] preliminary WebSockets compression exp… John Tamplin
- Re: [hybi] preliminary WebSockets compression exp… Roberto Peon
- Re: [hybi] preliminary WebSockets compression exp… John Tamplin
- Re: [hybi] preliminary WebSockets compression exp… Roberto Peon
- Re: [hybi] preliminary WebSockets compression exp… John Tamplin
- Re: [hybi] preliminary WebSockets compression exp… Jamie Lokier
- Re: [hybi] preliminary WebSockets compression exp… Greg Wilkins
- Re: [hybi] preliminary WebSockets compression exp… Greg Wilkins
- Re: [hybi] preliminary WebSockets compression exp… John Tamplin
- Re: [hybi] preliminary WebSockets compression exp… Mike Belshe
- Re: [hybi] preliminary WebSockets compression exp… Greg Wilkins
- Re: [hybi] preliminary WebSockets compression exp… Mike Belshe