Don't Call Us, We'll Call You

A truly rich user experience of unified communication (UC) depends on rich presence about people, devices, and applications. Rich presence goes beyond basic, on-off network availability to capture information about location, ambient environment, activities, moods, device capabilities, and much more.

A key aspect of rich presence is that it might change more or less frequently than network availability. For instance, my location might remain essentially the same for two weeks, but then I might go on a business trip that takes me to three different cities in a few days' time. Or I might engage in a wide variety of activities throughout my work day and publish them to my colleagues while my network availability remains constant.

As Internet entrepreneurs have launched rich presence services for things like location (Dopplr, BrightKite, FireEagle, etc.) and activity (Twitter, Jaiku, identi.ca, etc.), they have started out with a simple polling model derived from the distribution of Rich Site Summary (RSS) feeds for weblogs: publish a file and let interested parties use HTTP to poll for updates.

Unfortunately, we're finding that the polling model simply doesn't scale for presence. Here's why:

1. Rich presence is turning out to be very popular, so typical presence publishers might have 100 or more people following their feeds.
2. End users don't want to miss out on the latest happenings, so they poll all the time and need to be "rate limited" by presence services to (say) one poll every ten minutes.
3. A publisher might not publish an update for days at a time (leading to wasted polling) but then publish a number of updates in rapid succession (leading in some cases to missed updates).

Let's do the math. Consider a rich presence service in which each publishing user has 100 followers, each of whom polls the service once every ten minutes. When the service launches with 1,000 users, the service gets polled 167 times per second. When the early adopters push the number of users to 10,000, the service gets polled 1,667 times a second, a 900 percent increase in polls per second. When the service really starts to take off and reaches 100,000 users, the service gets polled 16,667 times a second. When the service becomes an Internet phenomenon and reaches a million users, the service gets polled 166,667 times a second - and promptly falls over.

Granted these numbers are a simplification (a few ultrapopular users may have 1,000 or more followers, while those on the "long tail" will have substantially fewer). But the critical points remain valid: polling will increase faster than linear, and most of the polling is an unnecessary waste of resources because it consists of followers asking "has the location changed?" and the service answering "nope" (via an HTTP 304 Not Modified result).

There has to be a better way. And there is: it's called publish-and-subscribe (pub/sub). In the pub/sub model, a follower subscribes to a publisher's location information (say) and the service pushes updates to the follower only when they occur.

Returning to our example of a location service, consider a publisher with 100 followers who doesn't go anywhere for 24 hours. On the polling model, in that 24-hour period the service would receive 14,400 requests for updates and return 14,400 responses that no change has occurred (28,800 total messages). By contrast, on the pub/ sub model, no messages whatsoever would be produced. A publisher who changes location 10 times in 24 hours would generate 1,000 messages, and even an extremely active publisher who changes location 100 times in 24 hours would generate only 10,000 messages.

Metcalfe's Law teaches us that the value of a network increases exponentially with the number of nodes. Yet the effectiveness of the polling model decreases exponentially with the number of nodes. Only a pub/sub model can enable truly Internet-scale (or even enterprise-scale) infrastructure for sharing information about locations, activities, and other forms of rich presence - which just happen to be the best drivers for communication and collaboration. So when it comes to rich presence, UC providers would do well to heed that old advice from the age of telephony: don't call us, we'll call you.

Dave Uhlir is Vice President of Product Marketing at Jabber, Inc. (www.jabber.com).