Like many in the networking world, I’m keeping my eye on the emergence of Unified Communications. And like most, I believe UC holds tremendous potential for productivity and cost reduction. But I’m feeling lonely when it comes to my sense that there is an elephant in the UC project planning room and the name of that elephant is packet loss.

You already know my position on packet loss in general. Let me reiterate to set up my question about UC and the subject of this brief .

(1) Best efforts networks are inherently plagued by unpredictable packet loss caused by such things as collisions (particularly in wireless networks), high bit-error rate (BER), congestion, policing, traffic shaping, and route flaps.
(2) Packet loss is the mortal enemy of effective and responsive real-time network applications. Packet loss induces retransmission, i.e., delayed delivery of data. We all know what the delayed delivery of VoIP data sounds like. Most videoconferences actually get dropped at 3% packet loss. Virtualized desktop applications become unresponsive and there’s nothing like an unresponsive application to drive a user to find some other way to do it.
(3) Given 1 and 2 above, trying to roll out UC over best efforts networks—without first dealing with paket loss—may be a doomed proposition. Paying for dedicated lines, so-called fat pipes, may be a workable alternative, if you don’t mind the high costs, but remember that fat pipes are still quite limited in their geographical reach. That is to say that workforce telecommuters and far-flung branch offices will not be able to benefit from UC unless you can run over the top of a best efforts network like the the public Internet.

If you can’t get everybody in the organization into the UC fold, the old systems will have to be maintained for use by the forces you fail to unify… and what have you really accomplished?