1 / 8

draft-meylan-imap-statistics-lemonade-00.txt

draft-meylan-imap-statistics-lemonade-00.txt. October 12 th 2004 Lemonade Interim Meeting Arnaud Meylan Randall Gellens {ameylan, randy}@qualcomm.com. Outline. General IMAP statistics IMAP command compression by dictionary IMAP compression at the transport layer.

deldon
Download Presentation

draft-meylan-imap-statistics-lemonade-00.txt

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Outline • General IMAP statistics • IMAP command compression by dictionary • IMAP compression at the transport layer

  3. 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 • bytes at Ethernet level • IMAP commands bytes • fraction IMAP bytes over the total number of bytes • IP packets used for the transaction • Results in order <client to server / server to client>

  4. 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. 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. 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. 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. 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

More Related