Wednesday, January 6, 2010

interview David Bryan on P2P technologies

Telecosm Interview: David Bryan on Peer to Peer Technology

I am pleased that David Bryan agreed to be interviewed for the first of what I hope will be a regular feature on the Telecosm blog: interviews! I am very interested in peer to peer technology and its many applications, and was thrilled when David agreed to help me launch this part of the blog. David Bryan wears two very big hats:



* He is Chief Executive Officer of Sipeerior Technologies, a leading provider of standards-based, OEM software solutions designed to enable serverless implementations of real-time communications applications.
* He is co-chair of the Peer-to-Peer Session Initiation Protocol (P2PSIP) working group at the Internet Engineering Task Force (IETF), the standards-making group for the Internet.

I am particularly pleased the David was able to take some time for the interview from his busy schedule, as there is an IETF meeting underway in Philadelphia this week.


IKE: Peer-to-peer file-sharing applications such as BitTorrent get a lot of press, so when people hear peer-to-peer they could be excused for thinking only about file-sharing. What other applications could be enabled by peer-to-peer technology?

DAVID: I think that is a great question. Peer-to-Peer is one of those things where people not only immediately think file-sharing, but immediately think music piracy too, which is really unfortunate. Peer-to-Peer is a technology, in the same way that client-server – the mechanism used for everything from email to web servers – is a technology. I think as people get their heads around peer-to-peer you will see it used in more and more places. It really is just a way to take advantage of the tremendously fat pipes we have in place to our homes, and the powerful devices we have connected to those. It's a great way to leverage that power, for companies to offer services without the need for large data centers, and to be "green" while doing it, since the end device is being fully utilized.

People also think about only large, Internet-scale communities connected by P2P. I think that you will see many of these, but will also see P2P being used within an enterprise or even a home. Communications, in the form of VoIP or IM is obviously one area where this is very attractive. Small office systems can be server-less, and incorporate all the wonderful features that large office systems have today, such as IM and presence. These systems are running today. Consumer electronics is another area where you will see P2P being used. Some of this looks like file sharing – video on demand content shared between set-top boxes for example, but it can also be used to enable features such as communications between users of consumer devices or for gaming. Imagine being part of a community of users with digital home hubs, where I can post content, look at others’ content, and then communicate and notate their content. Today that would require a big back-end commitment from the vendor. With P2P, much of that can be pushed to the edge.

IKE: Why is SIPeerior’s technology important?

DAVID: I think there are number of reasons what we are doing is really unique and important. We have focused on working on a standards-based approach to P2P. One of the problems P2P has today is that many of the applications that employ the technology are either "black" or at least "grey" in the eyes of ISPs and system administrators. They may not want to allow BitTorrent or Skype traffic on their networks. A big part of this is that it the technology isn't transparent. They don't know what they are dealing with. Similarly, it won't interface with existing devices, and it won't usually operate in a stand-alone, enterprise way.

What we have done is worked since day one to promote and open standard for peer-to-peer (P2P), and in particular P2PSIP. We are working to promote a documented, open standard for the P2P part, and using established, well known mechanisms for call signaling (SIP), NAT traversal (ICE), encryption (DTLS), etc. We offer software for building generic P2P applications, as well as very specialized software for P2PSIP. Both are based on open specifications, and "play nice" with other Internet applications. Our VoIP side products are SIP compliant in the sense that you can take a cluster of P2PSIP phones and connect in a few off the shelf SIP phones, gateways, or even servers if you want a hybrid architecture. You can do that with devices based on SIPeerior's technology today. I think the approach of being standards-based for both the P2P and the call portion is really unique.

We’ve also really focused on reliability and redundancy. Our customers aren’t building a file-sharing network where downtime is acceptable. They need things to work in real-time, and P2P can be a very good way to handle reliability, when done correctly, and I think that is what we bring to the table – a robust, embeddable software library that is open and allows vendors to eliminate their servers.

IKE: How could peer-to-peer VoIP applications improve on the current, widely-deployed client-server VoIP applications like Vonage?

DAVID: I think this question really depends on who's perspective you are looking at this from. For a provider, particularly a hosted provider like Vonage, P2P can be a way to provide a very similar service at a far lower cost, using what we refer to as a hybrid architecture, where some servers are used but much functionality is pushed to the edges using P2P. Essentially, they can push P2P technology into each phone or edge box/ATA in the network, and offload all the basic call processing away from their core. No need to buy soft switch ports or data center capacity for them.

While doing this, they can still use centralized servers for billing, call termination, and even some advanced services, and if they are using P2PSIP, these servers and gateways can be the same ones they are using today. If SIPeerior software was being used in this type of deployment, this would all be secured using our certificate mechanism, so the certificates are used to authenticate the peers to one another, ensuring the overlay contains only paying, trusted devices, and also to provide their credentials for each centralized service. In many ways you get the same thing IMS offers, of allowing user-by-user access to each service and feature, but it is all handled in the certificates issued, making things much simpler from a deployment perspective.

For the end user, regular services look no different, which I think is a very good thing. However, the end user over time will see many features added that would just be too costly to add if the provider needed to back each one with a server to implement it. That is where the real magic in P2P comes in for the end user, since suddenly the only cost for a new application becomes developing it, even if it involves lots of data sharing. The end user's device and connection enables it, not the provider or vendor's data center.

IKE: The IETF meeting started on March 9th in

Philadelphia
. What is the current state of peer-to-peer SIP protocol development? What progress is expected at the

Philadelphia
meeting?

DAVID: I think the meeting in

Philadelphia
will be a very exciting one. The P2PSIP group actually won't meet until Friday this time, since it is our rotating turn to go last, but I think everyone is very excited. The P2PSIP work has actually been going on for a very long time. I introduced the first draft on P2PSIP to the IETF back in January of 2005, and we had the first official meeting as a separate working group (rather than under the regular SIP- related groups) in March of 2007. As a result, we have a number of rather mature proposals at this point. The hope is at this meeting that we will be able to select a proposal (one leading candidate is actually a merge of several earlier proposals) that will serve as the basis for a real standard going forward. At that point the battle isn't over of course, the standards process is like making sausage, but there will be a reference for folks to look to for their implementations, and a place where consensus is documented. It will be a big step for P2PSIP, and I think at that stage things will really take off and we will see many different interoperable implementations emerge.

IKE: Ebay’s Skype is often credited as having the most widely-deployed peer-to-peer VoIP application, though the application is not completely peer-to-peer. What pieces of the Skype application appear to rely on servers, rather than peer-to-peer client software?

DAVID: There was an excellent paper out of Columbia University that took a look at the Skype application a few years ago, which can be found at http://www1.cs.columbia.edu/~library/TR-repository/reports/reports-2004/cucs-039-04.pdf. The methods they used to figure out what was going on are fascinating, since Skype is a closed protocol and everything is encrypted, meaning they had to use experiments to figure things out. Basically, Skype seems to use a central login server, contacted each time a user joins, while search and relaying of messages for users is distributed. This type of architecture is what is generally referred to as a hybrid architecture. This is a bit different than what a similar approach would look like using our software or what the IETF P2PSIP group is currently proposing. We'd still have a central server, but it would only be a certificate server, contacted at enrollment time and periodically when certificates expire. All of the day-to-day operation would be strictly between the peers.

It is also very interesting that when an application says it is P2P, it can mean many things. When I talk about P2P, I generally mean reducing or eliminating the central servers so that as much functionality as possible is pushed to the edges and resources are shared. Some other applications appear to mean only sharing resources, but still using centralized boxes. The Ooma service comes to mind, where at least from what I can tell, they still use servers for their call processing, but what is P2P about it is that users share each other's phone lines to allow for low priced calls, taking advantage of local lines. In many ways, it looks very much like Free World Dialup from a few years ago. I think it is really important when looking at a P2P application to determine exactly what it is that is being pushed to the peers.

IKE: How will peer-to-peer technology change the Internet?

DAVID: I think we are already seeing this today. File sharing and Skype account for a tremendous fraction of the bandwidth used on the Internet. In the longer term, I think we will have many little sub-clusters of devices – perhaps every instance of a particular manufacturer’s device will form one and all the computers or phones of a group of people with a common interest will form a P2P cluster. I think this is really the part of the big picture we aren't seeing today, since right now most of the P2P applications are built around a service model, really, where each user comes together into a giant collection. I see having a standard as driving P2P technology into more devices, and that means that new applications will emerge and smaller and smaller groups will form. Think about it like your buddy list, only it might be a P2P community of interest, able to collaborate, share data, and communicate.

I also think that the Internet will be changed in far less visible, but equally important ways. There are very strong economic incentives to move services that generate little revenue or are orthogonal to your main application away from your machines and out to the edge. Quite frankly, telephone services are clearly one of these. VoIP has made the service so cheap that it almost makes no sense to keep it on centralized servers when you can push the cost and bandwidth to the users in the call. Companies that figure out how to offer unique services this way will be very successful, because the infrastructure costs to deliver them approach zero other than development. We all heard how YouTube was 10 guys in a garage and a whole bunch of servers at a colocation facility somewhere. That is the real cost of that service. The costs of YouTube may have been very low relative to what the company is valued at, but even those costs will be squeezed out by P2P going forward. The change will, honestly, affect nearly everything about the Internet.


IKE: Peer-to-peer protocols have been predominantly used in consumer VoIP applications, so far. What opportunities are there for using peer-to-peer protocols in enterprise VoIP applications?

DAVID: Well, I talked a bit about this in responding to question 1, but I think a few areas really stand out. Replacing the PBX or key switch with a cluster of phones is the obvious one. This can be done for an entire enterprise, or just a branch office that is trunked back to a central PBX. This can scale to very large scales, since each new phone brings more processing, but we are already seeing some vendors position P2P as only applicable for the small office. Particularly for P2PSIP, the fact these devices speak regular SIP makes a small office P2P offering attractive, since as they grow they switch over to being "dumb" SIP phones attached to a PBX, but there is no technical reason you can't run a ten-thousand person enterprise on P2P. Combining wireless with P2P, perhaps with a femtocell base station is another area I think is exciting. Having your cell phone "magically" turn into a PBX device when you are in the office is a very exciting prospect.

Using P2P between enterprises is another area I think is very interesting. If each enterprise incorporates P2P into their firewall/SBC/edge device, the enterprises can cluster among themselves, and essentially eliminate the carrier in the middle. I think you'll see this both with companies that have many small offices, for example retail players, and from hardware vendors who want to create communities of their customers. You may also see this from carriers as a cost reduction mechanism.

I also expect to see many hosted providers switch to P2P. It saves administration and cost if they can drop their central switches and push much of the functionality to the edge. They basically only need to offer SIP trunks. I think that these kinds of applications and the larger enterprise systems will be very popular, particularly as the mechanisms to troubleshoot and configure P2P mature in the next couple of years.

No comments:

Post a Comment