Subject: [hybi] permessage-bzip2, -lz4 and -snappy

From: Tobias Oberstein <[email-masked]>
Date: Sat, 8 Jun 2013 05:50:25 -0700

Hi,

we are experimenting with adding new compression methods to the PMCE framework provided by Takeshi's "permessage-compression" draft http://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-09

Motivation:

While "permessage-deflate" balances CPU, memory and compression ratio and "zlib" is widely available, other compression methods either provide higher compression ratios (consuming more CPU and/or memory) or lower CPU and/or memory load.

We are thinking of

 - permessage-bzip2
 - permessage-lz4
 - permessage-snappy

We have already implemented "permessage-bzip2" in AutobahnPython (both client and server). The others will follow.

Here is an example opening handshake:

GET /runCase?case=6&agent=AutobahnPython/0.6.0 HTTP/1.1
User-Agent: AutobahnPython/0.6.0
Host: 127.0.0.1:9001
Upgrade: WebSocket
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Sec-WebSocket-Key: 900jKLXzMJ6OrZ3v9HgyOA==
Sec-WebSocket-Extensions: permessage-bzip2; c2s_compress_level, permessage-deflate; c2s_no_context_takeover; c2s_max_window_bits
Sec-WebSocket-Version: 13

HTTP/1.1 101 Switching Protocols
Server: AutobahnTestSuite/0.5.4-0.6.0
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Accept: 0sry1e2yduhqN51p9afaWmkcFnU=
Sec-WebSocket-Extensions: permessage-bzip2

When connecting from a client only supporting "permessage-deflate" (e.g. current Chrome Canary), server will fallback to that of course.

==

I'd like to ask on the list:

a) any interest by other implementors?

b)
- how should the new PMCEs be specified? within Takeshi's current draft or outside?
- how to register the extension names and parameters?
- does above even make sense, given that (as far as I know), none of bzip2, lz4 or snappy has an RFC?

/Tobias

---

From: Takeshi Yoshino <[email-masked]>
Date: Fri, 14 Jun 2013 00:46:49 +0900

> - how should the new PMCEs be specified? within Takeshi's current draft or

As we experienced for permessage-deflate, for each algorithm it should take
long time for investigation on characteristics, performance metrics, and
survey on implementation feasibility. I think they should be specified in a
separate RFC.

> - how to register the extension names and parameters?

We don't have any registry to control extension parameters. Each spec
should define their parameters individually, and only register their
extension name to the extension name registry.

> bzip2, lz4 or snappy has an RFC?

RFC 2616 doesn't have formal reference to compress. We have RFC for DEFLATE
but it's informative.

We should at least have some normative doc even outside of IETF if
possible. I have no idea about IPR of those algorithms.