1. October 12, 2004IETF 60,5 – Vancouver, BC draft-meylan-imap-statistics-lemonade-00.txt October 12 th 2004 Lemonade Interim Meeting Arnaud Meylan Randall Gellens {ameylan, randy}@qualcomm.com

2. October 12, 2004IETF 60,5 – Vancouver, BC Outline General IMAP statistics IMAP command compression by dictionary IMAP compression at the transport layer

3. October 12, 2004IETF 60,5 – Vancouver, BC General IMAP statistics We select common use cases –reading a 1KB message –searching in a populated mailbox for messages containing 'steve' – copying a message Traffic sniffed between a Cyrus server and a Mulberry client with Ethereal We counted a)bytes at Ethernet level b)IMAP commands bytes c)fraction IMAP bytes over the total number of bytes d)IP packets used for the transaction Results in order

4. October 12, 2004IETF 60,5 – Vancouver, BC IMAP statistics (2) Proportion of IMAP bytes in the client->server direction (usually the uplink) is high –Reducing IMAP traffic would benefit the uplink, which is typically slower Off-topic: keep an eye on TCP, without delayed Acks it is a bandwidth waster

5. October 12, 2004IETF 60,5 – Vancouver, BC Dictionary-based Compression Compress every IMAP command to one byte Compress all other IMAP vocabulary (\Deleted, FLAGS, quota) to two bytes Example scenario : client sends FETCH, STORE, SEARCH, STORE, COPY. –Original traffic (client to server only) : 225 bytes –Compressed traffic : 162 bytes Gain –28% on client to server direction –Marginal on server to client direction (user content dominates) Cost –Modify IMAP

6. October 12, 2004IETF 60,5 – Vancouver, BC Transport Layer compression Three use cases –Read about 100 messages from an IMAP mailing list –Read a few emails and download an uncompressed text document (3.87MB, 148-page with 47 figures) –Read a few emails and download three JPEG pictures (about 2MB per picture, 3.8Mpixels, 24bits RGB) Evaluation procedure –Capture whole trace with tcpdump –w –Compress whole trace offline with gzip –Same setup (Cyrus, Mulberry) –The Cyrus server we used does not support Binary Extension, therefore base 64 encoding is used

7. October 12, 2004IETF 60,5 – Vancouver, BC Transport Layer compression (2) Count –Raw size of attachments –Compressed size of attachments –Raw IMAP session –Compressed IMAP session –Compression ratio on IMAP session

8. October 12, 2004IETF 60,5 – Vancouver, BC Transport Layer compression (3) –The compression for text messages is good (3.28:1) it is comparable to the expected compression ratio for text –On uncompressed formatted text, the compression ratio remains pretty high at 2.81:1 –With compressed attachments it is worth running a stream compression whenever a base64 encoding will be used.  Though the encoding consistently adds about 1/3 to the size of the input data, stream compression will return much of this overhead –Stream compression will likely not provide any gain if IMAP's binary extension is used for compressed attachments