|
There has been much interest of late in peer-to-peer VoIP systems. With the explosive growth that the flagship peer-to-peer VoIP application Skype has enjoyed many people who in the past scoffed at the idea are now giving this technology a second look. Proponents of the peer-to-peer approach cite its reduced infrastructure costs as a compelling argument for its superiority. Has a silver bullet been found? This article compares peer-to-peer technology as it applies to VoIP with the older and more traditional client-server approach in an attempt to answer this question. The focus is on technology not underlying business constraints that may dictate the use of one approach or another.
Stages of a Typical VoIP Call
A typical VoIP (define - news -alerts) session consists of three main stages: call setup, media transfer, and call teardown. Call setup consists of locating the callee, determining how to best communicate (e.g., which codec to use), tackling technical issues that may exist (e.g., presence of NATs and firewalls) and routing the call setup information to the callee (i.e., ringing his phone). Media transfer is initiated upon successful completion of the call setup and involves exchanging media (e.g., voice, video) directly between the endpoints unless technical difficulties (e.g., NATs or firewalls) necessitate the relay of the media over an intermediary network element. Call teardown is the process of hanging up the phone and releasing any resources that
may have been associated with the call.
The traditional client-server model relies on designated network components for call setup and possible media relay, while the peer-to-peer model takes advantage of a user network consisting of nodes or machines running a common application.
Scalability
In all likelihood, the most compelling argument in favor of peer-to-peer networks is their robustness. The peer-to-peer architecture enjoys the enviable characteristic of not having a single point of failure. Whereas in client server architectures all signaling communication between any two clients always travels to the server (thereby creating a central point of failure), in peer-to-peer systems, signaling information for different calls rarely travels the same end-to-end path twice even between the same two endpoints. A result of this architecture is that any number of nodes can be down and the end-to-end communication will still proceed unhindered. Each new user or node in the system increases scalability of the overall network by adding more routing options to a given call setup. In contrast, the client-server model requires large investments in infrastructure (e.g., redundant components for high availability, advanced monitoring applications, etc.) to support a similar number of users.
Given this scalable and robust architecture the questions that beg to be asked are why is the client-server model still around? Why is the growth of peer-to-peer VoIP being attributed for the most part to residential calling? Why have many corporate and enterprise users to date resisted the temptation of peer-to-peer communications?
An understanding of some of the shortcomings of peer-to-peer architectures can help answer these questions and may pave the way for hybrid peer-to-peer/client-server architectures that take advantage of the best elements of each. Specifically, we would like to look at: bandwidth utilization, security requirements, off network peering complexity and device mobility and show that the client-server model currently holds an edge in each of these categories over its peer-to-peer counterpart.
Bandwidth Utilization
Many calls today require relay of media via intermediary elements. Service providers are closer to the backbone of the Internet then desktop users and, in many cases, have lower layer peering arrangements in place with other service providers. Relay of media via the end user is far less optimal than that of corresponding client-server approach. Also, many node users are not happy to share their bandwidth with others during critical times of the day.
Security Requirements
Security concerns on peer-to-peer networks arise from the fact that these networks rely on untrusted intermediate nodes to relay data as opposed to trusted service providers in the client-server model. Peer-to-peer architecture is more prone to man-in-the-middle attacks and this being the case it is imperative that end-user data and/or media is always encrypted and that there is strong key management system ensuring that data is not compromised in transit. Even if these security steps are taken, it is still necessary for the community at large to trust that peer-to-peer applications perform this task adequately for this architecture to gain more traction. Based on the Skype phenomenon, it would appear that, while most residential users afford this trust readily, corporate and enterprise users are more skeptical and have yet to take this leap of faith in large numbers.
Off-Net Peering Complexity
Earlier, we spoke of the call setup stage being comprised of a number of steps. Probably the most time consuming step in a peer-to-peer network is that of finding the user on the other side of the network that needs to be signaled. Whereas in the client-server model information about end-users is obtained readily from a cache in the server, in peer-to-peer networks, a time consuming complex algorithm-based search is required to achieve the same result. In the case where the desired end user is on a different network (such as the PSTN), the situation is far worse for the peer-to-peer network. As opposed to client-server architectures, where peering relationships are commonplace and standard, in the peer-to-peer world, by its very nature, these relationships do not readily exist and peering is, therefore, not a trivial task. As big as a network gets, it is still only one of many such networks worldwide and, as a result, off-net peering issues must be resolved for peer-to-peer architectures to grow
ubiquitously.
Device Mobility
This somewhat orthogonal issue may yet prove to be the toughest challenge to the peer-to-peer model. As we are all aware, many of the calls today are being initiated via presence lists. Whereas in the past, to initiate a call we would dial a number, today, we compile lists of friends in presence lists and, when we see that our friends are online, we click on their icon/name to initiate communication. The pure peer-to-peer model assumes no servers and as a result this list is local to each users machine. There are two problems with this:
When a user wakes up, this new state must be propagated to all his friends regardless of their online status. This adds tremendous load to the system and does not scale well.
One of the most compelling arguments for VoIP is the freedom it allows its users when moving from place to place.
As opposed to the legacy PSTN phone network, where a users phone is fixed to a location, VoIP allows for a user to log-in from anywhere and on any device to make calls. If the presence list is fixed to a device and not stored on a server somewhere, how do I take it with me?
Hybrid Networks
What if we were to combine the best of both networks to create one that was more than the sum of its parts? What elements of each would we take? There isnt one answer to this and many future networks will have different elements of each. The gist of such a network is that each user node is connected also to the peer-to-peer network and also to an ITSP. If the destination is on this network the traffic flow might be peer-to-peer and if not it is client-server and the off-net peering is done by the server. If media relay is needed, it can be taken care of by the server (counterpart of the client) at the ITSP and not by user edge-nodes.
Conclusion
While there are merits to a peer-to-peer architecture in terms of scalability, the short to medium term promises strong contention from traditional client-server architectures. In the long run, look for combinations of the two architectures forming hybrid networks taking advantage of the positives each has to offer. IT
David Schwartz is founder and chief technical officer at Kayote Networks. For more information, please visit the company online at www.kayote.com (news - alerts).
If you are interested in purchasing reprints of this article (in either print or PDF format), please visit Reprint Management Services online at www.reprintbuyer.com or contact a representative via e-mail at [email protected] or by phone at 800-290-5460.
|
SUBSCRIPTIONS
TMCnet LOGIN
WEBINARS
