Subject: [calsify] Designing iCalendar Clients - Network Usage Considerations

From: "George Sexton" <[email-masked]>
Date: Fri, 19 Mar 2010 13:46:01 -0600

Gentle Readers,

This is a paper I felt compelled to write that discusses some issues with
designing iCalendar clients.

Overview
__________________________________________________

With the proliferation of iCalendar clients on the internet, network usage
is starting to become a significant factor. This paper will discuss some
ways that iCalendar client designers can minimize the network impact of
their software while at the same time increasing the perceived speed and
usability for their end users.

I will mention some specific client applications for illustrative purposes.

The Problem
__________________________________________________

iCalendar compliant clients are proliferating rapidly. Outlook 2007 supports
iCalendar subscriptions, along with other clients like Apple iCal, Apple
iPhones, Mozilla Sunbird and many others. This proliferation is resulting in
increased bandwidth usage. Here's a typical usage scenario that we're
seeing:

An Apple iCal user with version 3.08 of iCal on Mac OS 10.5.8 subscribes to
a remote calendar that is 700K Bytes in size. This user is polling the
file every 15 minutes. This one user consumes:

.7 MB * 4 Times Hour * 24 Hours Day = 67.2 MB day or 2016MB per month.

It doesn't take very many users like this to start representing an issue.

The Solutions
__________________________________________________

There are 3 things iCalendar client designers can do to minimize their
network
footprint. They are:

1) Use If-Modified-Since requests
2) Use GZIP compression
3) Restrict update frequency to suggested values

If-Modified-Since Requests
__________________________________________________

In the above example, the biggest problem is that the client is mindlessly
re-downloading the file even though it has not changed. The server as part
of its response sends a date header, and a last-modified date. If the client
kept track of that value and submitted it as a "If-Modified-Since" header as
part of the next request, the server could respond with a HTTP 304
"Unchanged" response. This would reduce the bandwidth used every 15 minutes
from around 700K to under 3K Bytes.

As a benefit, since the server response would be a 304 there would be no
need for the client to parse the 700KB iCal event file to determine if
anything has changed or needs applied.

Apple iPhone and Outlook 2007 do implement If-Modified-Since requests. Apple
iCal and Mozilla Sunbird do not.

Mozilla Sunbird supports If-None-Match/ETag mechanisms for reducing usage,
but these mechanisms are not widely supported by servers.

GZIP Compression
__________________________________________________

Many web servers implement GZIP compression. When a client sends request a
request with an Accept-Encoding header that includes GZIP they respond with
GZIP encoded output. GZIP compression can reduce the size of an iCalendar
file by a factor of 12 or more. In our example, the 700KB file would be
reduced to a size of around 59K.

The trade-off here is the overhead for de-compressing the file. Designers
writing software for desktop operating systems have a great deal of CPU
power that largely sits idle. For that software, using GZIP compression
would add virtually no slow-down. Designers writing software for portable
devices have to decide whether the overhead of decompressing the GZIP file
is greater than the overhead of 12 times as much network utilization. In
other words, is it faster for a portable device to download a 59KB file and
gunzip it or download the 700KB file.

Apple iPhone, iCal <= 3.08, and Outlook 2007 do not support GZIP
compression. Apple iCal >=4.0, and Mozilla Sunbird do support GZIP
compression.

Update Frequency
__________________________________________________

An obvious problem in the scenario described initially is that the end user
has set the update interval to 15 minutes. The iCalendar file the user
downloads has set a calendar level entry X-PUBLISHED-TTL of PT120M,
suggesting to the client that it not refresh more frequently than every two
hours. X-PUBLISHED-TTL is a proprietary extension recognized by some
applications. A proposed draft extension to RFC-5545 suggests a new header
value of CALENDAR-REFRESH-INTERVAL:

http://tools.ietf.org/html/draft-daboo-icalendar-extensions-00#section-4.6

Client designers should seriously consider honoring a published refresh
interval. Users should at minimum be warned if they select a refresh
interval more frequent than the suggested value.

Outlook 2007 honors X-PUBLISHED-TTL.

Putting it All Together
__________________________________________________

If the client in our example implemented all of these suggestions, and the
output file contained a 2 hour refresh interval which the client honored,
the utilization would be roughly: 

Download Updated gzipped file once per week: 59KB = 236KB / Month
Check for updates every two hours: 3KB * 12 Times Day * 30 Days month=1080KB

Total utilization Month: 1316 KB month

Percent Savings: ~99.936%

Even if the client did not honor the refresh interval, utilization would be
reduced from 2016MB/Month to approximately 8.9MB/Month for a savings of
99.56%.

Conclusions
__________________________________________________

The proliferation of iCalendar as a format for exchanging calendar data is
dramatically increasing the usability and availability of calendar data to
end users. In many ways, iCalendar is finally fulfilling its vision. In
order to keep this proliferation from overwhelming servers, designers need
to take steps to reduce their footprint in the environment. Failure to do so
may result in calendar providers disabling iCalendar feeds, or blocking what
they perceive as ill-behaved clients from accessing their data.

George Sexton
MH Software, Inc.
303 438-9585
www.mhsoftware.com