Over the last week, the voice over IP (VoIP) industry has been abuzz about the first-ever networkwide Skype outage. For nearly 36 hours starting on Thursday, Aug. 16, the service was unavailable to almost all of its subscribers. Speculation ran wild about the cause of the outage, with many fearing that a denial-of-service (DoS) attack was in progress. At the end of the outage, Skype issued a press release, indicating that a massive restart of users' computers in a short period of time, a consequence of a Windows update, had caused the outage.

 

Though many were upset by the outage, the truth is that the Skype service has been operational almost continually since its inception - a credit to its designers. No matter what the technology foundation is, achieving highly available network connectivity is no small feat. In some respects, peer-topeer (P2P) technologies, on which Skype is based, make the problem simpler. P2P networks move much of the work to the clients, alleviating the network load that centralized severs would otherwise have to handle. This can help improve availability. However, P2P network technologies make high availability harder in other respects. P2P technologies are a tool, and like all other tools, they have their strengths, and they have their weaknesses.

 

What are these weaknesses? There are three big ones: security, software upgrades, and manageability.

 

Security

 

Without a doubt, security is one of the toughest problems in a P2P network. Fundamentally, this is because the service a user is receiving (the ability to make a call or send an instant message) is provided by functionality hosted in computers on the desktops of random people around the world, people whose motives and machines cannot be trusted. This is in contrast to traditional clientserver models, where the clients trust the servers that are providing them service and rely only on those servers for the service they get.

 

Indeed, at first glance, this might seem to make P2P networks unworkable. How can you possibly offer a service in a network where not all of the components trust each other? If all of the computers in a P2P network were compromised, you couldn't. Fortunately, most users in the world are not malicious, only a few. It is possible to design P2P networks that use redundancy and randomization techniques to protect against cases where only a small number of clients are misbehaving. The trick, then, is to make sure that only a small number are misbehaving. One of the best-known attacks on P2P networks, called the Sybil attack, involves a single malicious user starting up many clients on the network in order to obtain control over enough of it to be able to compromise the service. This attack can be prevented only by limiting, somehow, the number of distinct clients a single user or organization can place on the network.

 

Of course, attacks are also possible on client-server systems. But P2P systems introduce many more potential attack vectors, and thus raise the bar significantly on the amount of work required to deploy a secure system.

 

Software Upgrades

 

Any system, whether it is client-server or P2P, needs to worry about software upgrades. How do you upgrade the software on each of the components in the system without disrupting service, especially when the upgrade changes the protocols used to communicate among those components? In clientserver systems, this problem is well-understood and, though challenging, readily addressed. Servers can support both old and new clients, and when the clients connect, use the correct technology for each type of client.

 

However, in P2P systems, the problem is far more daunting. The P2P system will need to operate in an environment where the clients can be using different versions of the software and their corresponding protocols, and any number of those clients might get used in the processing of a specific call. P2P networks are highly distributed and work only because of a common set of processing functions that happen on each node, and updating them on-the-fly is extremely hard. Indeed, if upgrading a client-server system without disruption can be considered similar to changing the engines on a 747 in midflight, upgrading a P2P system without disruption is analogous to changing the engines, navigation systems, wings, and fins of a 747 in midflight - all at the same time.

 

Manageability

 

Software upgrades are just one part of the more general manageability problem. Any system needs to be monitored and maintained while it operates. Problems need to be detected when they happen. There need to be tools to troubleshoot those problems. There need to be mechanisms to change configurations or adjust the operation of the system to address those problems.

 

In client-server systems, centralized servers can provide interfaces for these management functions. Where do these functions reside in a P2P system? If a user has a problem, and his calls won't connect, where can an administrator go to diagnose what happened? Even simple management functions - like knowing how many users are connected to the system - become very challenging. In a client-server system, it's easy to get such a count. In P2P systems, getting an exact count is impossible. It's possible to obtain an estimate, but doing even that has challenges (for example, malicious endpoints can disrupt the estimation process).

 

Don't despair though! These security, upgradeability and manageability issues are not insurmountable. They are just challenges, ones that must be overcome to some degree in order to realize the benefits that P2P systems can provide. The issues are easier to address if they are considered upfront, at the very beginning of the design of the P2P system and its protocols. The Internet Engineering Task Force (IETF) is now beginning the design of the P2P protocols that will be used to provide a standards-based P2P SIP solution, and these are exactly the kinds of issues being considered.

 

With these challenges in mind, it is impressive that the Skype network has gone this long without seeing a substantial outage. P2P technologies represent a trade-off, making some things easier while making other things harder. There is simply no such thing as a free lunch.

 

Jonathan Rosenberg is the co-author of SIP and SIMPLE. He is currently a Cisco Fellow and architect for the IP Communications Business Unit in the Voice Technology Group at Cisco (www.cisco.com).

 

 

Unified Communications Communications Magazine Table of Contents