Subject: [lemonade] Compression: TLS or Application-layer

From: Eric Burger <[email-masked]>
Date: Mon, 27 Sep 2004 12:18:09 -0400

We discussed at IETF 60 and the Dallas Interim whether we should have
facilities in IMAP for compressing documents or if we should use
transport-layer facilities for compressing everything.

Seeding the discussion:

P-IMAP and its brethren have special document manipulation commands that
explicitly gzip the content.  The server (or client) knows the document is
compressed by the command (or parameter) used.

Alternately, transport protocols such as TLS compress the entire stream.
TLS with a null cipher gives compression without the cost of X.509 startup.

Does anyone have DATA on the computational complexity, resulting compression
ratio, and I/O impact (e.g., must scan entire document vs. compress on x
Bytes)?

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 27 Sep 2004 18:51:40 +0200

Eric Burger writes:
> Does anyone have DATA on the computational complexity, resulting 
> compression ratio, and I/O impact (e.g., must scan entire document 
> vs. compress on x Bytes)?

I ran a few IMAP connection logs through something much like P-IMAP and 
something much like TLS compression last year, when I wrote the 
draft=compress.

Not sure whether I still have the data. Can look tomorrow in the office. 
The conclusions are simple, anyway: synonyms (e.g. "F" for "FETCH") are 
meaningless, compressing the stream as it goes is good, compressing 
individual fetch responses less good.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 28 Sep 2004 15:19:56 +0200

> Not sure whether I still have the data. Can look tomorrow in the office.

Sorry, no.

I took threee IMAP sessions from different clients and made the 
following five transmfomations on each:

1. I replaced every keyword with its first letter, to see what effect 
terse synonyms have. (This broke the IMAP stream, e.g. FETCH and FLAGS 
both mapped to F, but I didn't care about that detail. I just wanted an 
estimated total number of bytes.)

2. I used libz on the stream. From client to server I added Z_SYNC_FLUSH 
after each command. In the other direction I added Z_SYNC_FLUSH after 
each tagged response.

3. I used gzip -9 on each response independently.

4. As 1+2.

5. As 1+3.

Sadly, I don't have the resulting transformed files. From memory, 2 was 
the best. 4 was the same as 2 (but I liked 2 better because it was 
cleaner). 3 was somewhat less good -- as I recall, it was hurt mostly 
by 'body[header.fields (...)]' fetches.

As a result, I wrote the now expired draft for compress=deflate.

If there's substantial interest, I could redo it.

Arnt