Guest post: David Bryan responds on P2P, P2PSIP and Skype
Monday, October 26th, 2009NOTE: David Bryan, co-chair of the IETF’s P2PSIP Working Group, left this text as a comment to my earlier post about P2PSIP and Skype. Given it’s length and great content, I thought it should run as a guest post and David was fine with that. The text below is entirely his.
So a few points, in no particular order:
Lee mentioned (as have others before) that P2PSIP is “copy-cat Skype”. This always bothers me, not because we came first (we certainly didn’t) but because it wasn’t my vision for P2PSIP (although others certainly had that view) . When I came up with P2PSIP and brought it to the IETF, I wanted to do things SIP couldn’t do at all. SIP can theoretically build a system that looks like Skype. To me, the interesting areas for P2PSIP were distributed softswitches/corporate IM (config-free small office, etc.), rapid response (quickly set up a communications system after a natural disaster), ad-hoc clusters for IM/app sharing (think Google wave away from the Internet), and vendors adding voice to apps without becoming an ISP. You could do a Skype-like service with P2PSIP (sort of: see below) but that wasn’t really the idea that got me started creating P2PSIP.
To me, Skype’s success was solving the NAT issue and getting the user experience right. P2P was a means to an end/efficiency multiplier, but not the reason for the success. Skype just worked. SIP’s major flaw is embedded IP addresses. Skype avoids this, uses media relays (P2P, but could have been centralized) and “falls back” (in the worst case) to tunneling over port 80. Users love this. Administrators and protocol purists hate it as it breaks traffic characterization, shaping, etc. Skype’s closed garden (one protocol stack) also ensured things just worked. Closed gardens and HTTP tunnels are at odds with the SIP goal of vendor/carrier interoperability. The two achieve different goals. (Today, many folks believe ICE with ISP-provided relays has addressed the SIP NAT problem. It looks promising, but until we have a Skype-sized Internet deployment, some say the jury is out. Time will tell.)
You could theoretically deliver a Skype-like experience with either a SIP or P2PSIP solution. Pure P2PSIP is very decentralized (every node is a peer and central servers are only used for obtaining a certificate), so you would need a hybrid approach if you want to maintain customer control. You could also use regular SIP with ICE, and many, many servers if you could solve the scalability problems. The best approach might be conventional SIP between the endpoints and a cloud of servers, with the servers sharing information using P2P. This ends up looking much like a SIP version of Skype’s super-peer model, executed in the cloud.
All this still begs the question of what happens to the Skype ecosystem of hardware, etc. If you go SIP, what do you break in the process? As Dan York and Shidan Gouran point out, Skype has many options, lots of great engineers, and lots of cash, but nobody outside of Skype knows what they will do.
As an aside to Lee’s comment on P2PSIP as a standard (it is fair to say adoption in product has been very slow, I’m sorry to say): The standard is moving, just at the (glacial) pace of standards, which can be frustrating for idea guys like Lee or I. In the early days, P2PSIP had lots of ideas, chatter, and excited non-standards folks, so work moved quickly. Today, with an accepted draft in progress and a more mainstream standards audience, iterations have slowed. That said, things are moving, there is strong interest, and a lot of hard work by the editors and participants.
My biggest worry is the protocol becoming too cumbersome. We are building a very flexible, universal DHT protocol with mandatory ICE and TLS/DTLS security. This is great for some scenarios, but overkill for others (ad-hoc, for example), and I worry the bulk may make it unsuitable for some of the scenarios I first imagined. I think many of these may migrate to the cloud. DHTs will be used, but as a means to distribute data among servers, not all the way to the edge as I first anticipated. Things change. Progress is good. I’m very excited to see how DHT principals in the cloud might solve many of the problems posed of a pure P2P approach. (eComm talk for SF, Lee?)
David Bryan is co-chair of the IETF P2PSIP Working Group and maintainer of http://www.p2psip.org/ More about David can be found at http://www.ethernot.org/ or on Twitter at @davidbryan.
If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.
Could Skype realistically replace its proprietary peer-to-peer (P2P) algorithm with P2PSIP?
RSS Feed
