Re: fast compressors for TLS (was lzip vs. xz)

[Nikos Mavrogiannopoulos]

On Sat, Apr 21, 2012 at 6:13 AM, Patrick Pelletier
<address@hidden> wrote:

> Snappy is another possible option.  (Although at least according to the lz4
> benchmarks, snappy doesn't perform quite as well as lz4.)  I mention it
> because a co-worker of mine is using snappy to compress some real-time data
> between two machines on the same LAN, and he seems very happy with it.

I don't really plan to work on it soon (but will accept any patches of
course), but
indeed all available options should be evaluated.

> I'm afraid I missed the beginning of the conversation.  Are you guys
> planning on standardizing this new compression method in an RFC?  (i. e. in
> the 0-63 "standards action" or 64-223 "specification required" compression
> methods)  Or is this just going to be in the "private use" area (224-255),

Not really but close. But were considering whether there are fast compression
algorithms decently described that could at some point be
standardized. That is, to
avoid sticking with non-standard extensions.

> only for when one gnutls instance is talking to another gnutls instance?  It
> would be nice to have a standardized, fast compression method implemented by
> more than one TLS library.  (Compression seems to be rarely used in TLS; I
> assume because people feel zlib is too slow.)

zlib is pretty slow in TLS according to some benchmarks I did (long
time ago). Having a low-latency compression
algorithm there might change that.


regards,
Nikos