Speaking of Standards

NOTE: 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.

---

Could Skype realistically replace its proprietary peer-to-peer (P2P) algorithm with P2PSIP?

Over on his Skype Journal site, Phil Wolff shows another example of why I’ve always followed the mantra “Never put online, in any form, anything you don’t want to appear on the front page of a news site” when Phil shows what was obviously intended to be a private email about ideas of what to do with Skype. (This has all surfaced as part of Skype’s ongoing legal battles on a number of different fronts, which I’m not going to dive into here.)

Per Phil’s article, the idea was this:

- buy skype, replace p2p with SIP (standard-based, open, can interwork with other VoIP systems – like the Cisco phones)

What’s perhaps most interesting about Phil’s post, though, were the comments that started with Lee Dryburgh of eComm fame weighing in saying that it makes ZERO sense (technically) and then went on from there. Lee and Shidan Gouran then got into a bit of a discussion in the comments.

Leaving the personal jabs aside, it’s actually an interesting discussion to consider. (And knowing both Lee and Shidan, I’m sure that they actually agree on way more than they disagree on.)

WHAT IS P2PSIP?

Lee’s right that there’s a difference between “SIP” as a protocol and all the overlays, DHTs and everything else that goes with “P2P” protocols. To Lee’s points about the difference, though, that is precisely what the “P2PSIP” work happening within the P2PSIP Working Group of the IETF is addressing. For those who want to read the proposed P2PSIP protocol itself, the latest draft is here in two parts:

http://tools.ietf.org/html/draft-ietf-p2psip-base
http://tools.ietf.org/html/draft-ietf-p2psip-sip

The first draft defines a P2P protocol called “REsource LOcation And Discovery (RELOAD)”. The second draft explains how RELOAD can be used with SIP.

To Lee’s points, RELOAD is a separate protocol from “SIP”. Now, RELOAD does indeed use a Chord-based DHT… though, the best place to start is probably the Architecture section at the beginning to understand how the pieces fit together.

So what is being called “P2PSIP” within the IETF is more this:

P2PSIP = SIP + P2P-protocol

More info about all things related to P2PSIP can be found at a great site maintained by David Bryan, co-chair of the IETF P2PSIP Working Group:

http://www.p2psip.org/

I’ve also written more about “P2PSIP” here on this blog, including this piece back in May 2008 about why I believe P2PSIP is important.

BUT COULD SKYPE REALLY USE P2PSIP?

Probably.

The question is really –

Could Skype swap out it’s proprietary P2P protocol for the P2P protocol proposed as part of P2PSIP?

That’s the larger issue. As Lee points out, SIP is “just” a signaling protocol for setting up communication sessions. The decentralized P2P nature of Skype is due to its proprietary P2P algorithm, not its session signaling.

That’s the key point, really – there are two different layers of communication going on here:

1. networking between the endpoints (the P2P layer)
2. call and chat signaling setup, modification, tear-down, etc.

The P2P layer is probably the hardest one to replace. The signaling layer is probably easier as there are any number of choices out there today, including SIP, XMPP and others.

Plus, as Shidan Gouran accurately points out, Skype’s current system is NOT entirely decentralized/P2P. It is much more of a hybrid system. There are centralized enrollment/authentication servers (as we learned in the multi-day outage a few years back), a centralized directory (although pieces of that could potentially be spread across the P2P overlay) and of course centralized PSTN interconnectivity.

Could all that be replaced with a different P2P protocol? Probably… although certainly not without a lot of work – and also the severe headaches of dealing with backward compatibility and getting the huge installed base of Skype users to upgrade to a new client.

Could that protocol be P2PSIP? Again, probably. The advantage would be that the SIP layer would give Skype interoperability with other systems, networks, devices, etc.

THE OTHER OPTION

I’d note, too, that the email Phil quotes says “replace p2p with SIP”. It does not say “replace p2p with p2psip”. There very well could be folks thinking of dumping the whole proprietary P2P protocol and dumping P2P in general and migrating to be a “standard” kind of SIP system like Gizmo (yes, which Skype has been rumored to be buying) or any of the other SIP-based consumer softphone services out there.

Sure, I’m sure they could technically do it. As an open standards guy, it would be great on one level in that it would help move us along toward the great big “interconnect” many of us so want to see. It would, though, require a much different architecture than what Skype has used so successfully today.

SO….

Will Skype replace their proprietary protocol with P2PSIP?

Ha… I haven’t a clue… nor does anyone else outside those walls. All we can do is have moments of technical amusement like this speculating on the possibility.

As I’ve noted before, Skype has been hiring in this year some great folks with lots of SIP experience… but… Skype is also a HUGE user of SIP on its backend for PSTN interconnectivity… plus they rolled out their Skype for SIP program this year…. so they have lots going on related to SIP.

We’ll see… all we can really say is that the time ahead will continue to be an interesting one for all things related to Skype…

Long-time readers will know that I have a fascination with the ideas behind P2PSIP, which I explained once before in a post “P2PSIP and pushing voice down into local clouds”. While it has very little directly to do with my work here at Voxeo, I’ve continued to help a team of folks with the IETF who are working on an Internet-Draft providing an overview of the security concerns related to P2PSIP.

Given the upcoming IETF 75 meeting, I published an updated version of the Internet-Draft last week. It is available at:

http://tools.ietf.org/html/draft-matuszewski-p2psip-security-requirements

Those of you interested in SIP, P2P networks or security in general may find it of interest. Here’s the abstract:

This document provides a security overview and analysis for the Peer- to-Peer Session Initiation Protocol (P2PSIP) overlay network. It discusses security threats for the P2PSIP architecture and its components. It compares security difference between client/server (C/S) and P2P implementations of SIP, and then partitions the P2PSIP architecture into layers and analyzes the security issues in each layer and the security relationship among the layers.

My particular contribution in this revision was writing a new section on “Interconnection to other networks“. Many, if not most, P2PSIP networks will want to interconnect with the legacy PSTN or with other SIP networks. This section takes a look at what the security ramifications are and what an implementor of a P2PSIP network should consider.

Comments and feedback about this draft are of course welcome. At IETF75 in Stockholm I know that members of the author team will be asking the P2PSIP Working Group to accept this as a “working group document” (another step on the path to becoming a RFC) and there will undoubtedly be further revisions of the document.

---

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook or following us on Twitter.

---

Technorati Tags: sip, p2p, p2psip, security, ietf, standards

What are the components of a “peer-to-peer (P2P)” network? What are the different types currently available? When does it make sense to consider using a P2P architecture?

Given the intense amount of interest in P2P networking these days, the Internet Architecture Board recently came out with a new Internet-Draft, draft-iab-p2p-archs, on “Peer-to-peer (P2P) Architectures” that aims to help provide answers to these types of questions. Here’s the introduction:

P2P (Peer-to-peer) systems have received a great deal of attention in the last few years. A large number of scientific publications investigate different aspects of P2P systems, several scientific conferences explicitly focus on P2P networking, and there is an IRTF (Internet Research Task Force) Research Group (RG) on P2P systems (the Peer-to-Peer RG). There are also several commercial and non- commercial applications that use P2P principles running on the Internet. Some of these P2P applications are among the most widely used applications on the Internet at present.

However, despite all the above, engineers designing systems or developing protocol specifications do not have a common understanding of P2P systems. More alarming is the fact that many people in the telecom and datacom industries believe that P2P is synonymous with illegal activity, such as the illegal exchange of content over the Internet or P2P botnets.

The goal of this document is to discuss the tradeoffs involved in deciding whether a particular application can be best designed and implemented using a P2P paradigm or a different model (e.g., a client-server paradigm). The document also aims to provide architectural guidelines to assist in making such decisions. This document provides engineers with a high-level understanding of what defines a P2P system, what types of P2P systems exist, the characteristics that can be expected from such systems, and what types of applications can be implemented using P2P technologies. Such understanding is essential in order to appreciate the tradeoffs referred to above. In addition, we stress the importance of the fact that P2P systems can be used to implement perfectly legitimate applications and business models by providing several examples throughout the document.

Given my own long-standing personal interest in P2P networks (some of which I’ve written about here), I was pleased to see this document come out. Anything that helps improve the overall understanding out there of P2P systems is, in my opinion, a good thing.

The draft is still undergoing some revisions (and I know the authors would welcome further comments) and I believe a new version will be coming out soon. The latest version should always be able to be found at:

http://tools.ietf.org/html/draft-iab-p2p-archs

---

If you found this post interesting or helpful, please consider either subscribing via RSS or following on Twitter.

---

Want to learn more about Peer-to-peer SIP (P2PSIP)? If so, I’ve now put up a video podcast episode where I’m interviewing David Bryan, chair of the IETF working group on P2PSIP. As long-time readers are probably aware, I’ve written about P2PSIP here a number of times – and also explained my particular interest. I continue to find P2PSIP a fascinating area of research… and so you can probably expect to continue to see more articles on it in the future.

Meanwhile, enjoy the video – and if you have visited my Emerging Tech Talk video podcast, you’ll find other videos there dealing with emerging technology issues:

---

If you found this post interesting or helpful, please consider either subscribing via RSS or following on Twitter.

---

Technorati Tags: sip, p2p, p2psip, voxeo, emergingtechtalk, ett, davidbryan, danyork

The Squawk Box interview I mentioned yesterday about P2P SIP is now available for download. It was an enjoyable interview with David Bryan and I think you’ll learn a lot about P2P SIP from it. We talked about what P2PSIP is, why you might use it, where it might be applicable, what the security ramifications might be and how you might use P2PSIP. It’s quite a fascinating area of research and development and we’ll be curious to see how it all evolves.

Technorati Tags: squawk box, sip, p2psip, p2p, dan york, ietf

UPDATE: The podcast referenced here is now available for listening.

---

Given that I’ve written here before about Peer-to-Peer (P2P) SIP (and why it’s of interest to us), I thought I’d invite you to join in tomorrow (July 9, 2008) at 11am US Eastern time when I’ll be interviewing David Bryan, co-chair of the IETF’s P2PSIP Working Group and CEO of SIPpeerior Technologies, about P2P SIP… what it is, who might use it, and why it matters.  It should be an enjoyable and interesting call for those of us who are interested in the underlying networks that make VoIP possible.  

If you would like to join into the call and are a Facebook user, you can easily join the call through the Calliflower application for Facebook.  If you don’t use Facebook,  you can just go to the Calliflower.com website (you will need to create a free account there).  If you can’t join us at 11am US Eastern time tomorrow (Wednesday, July 9th), you will also be able to listen to the show later in the day when I post it to Alec Saunders blog at Saunderslog.com.

Here’s a brief video preview:
{seesmic_video:{“url_thumbnail”:{“value”:”http://t.seesmic.com/thumbnail/kmVzYqKbI1_th1.jpg”}”title”:{“value”:”Voxeo Blog Video Entry: Invitation to join Squawk Box conf call tomorrow about P2P SIP ”}”videoUri”:{“value”:”http://www.seesmic.com/video/hykT2kiGjn”}}}

P.S. “Squawk Box” is a daily podcast on technical topics of the day hosted and produced by Alec Saunders and appearing on his Saunderslog blog. I often participate in the calls and as Alec is on vacation this month, he asked me to fill in as a host for him this week. Other than my involvement as a participant, there is no formal connection at all between Voxeo and the Squawk Box podcast.

As a followup to earlier posts, I thought I should mention that notes from the IETF’s P2P Infrastructure Workshop on May 28th are now available for download:

• Spencer Dawkins’ notes and Jason Livingood’s correction
• Alissa Cooper’s more detailed notes

• Updated slides, including those presented at the session. Comcast also made their slides available separately.

There is much discussion continuing on the “p2pi” mailing list (see the discussion archive) which is open to anyone interested to join. Plans are underway for BOF sessions at the upcoming IETF 72 meeting in Dublin. If you’re interested, definitely do join the list!

Technorati Tags: ietf, p2p, comcast, bittorrent, internet, networking, peertopeer, standards

“Why do you write so much about P2P SIP? Who’s really going to use it? Why do you care? Isn’t it really just a lame attempt to create an open standards version of Skype?”

As you might imagine, I’ve heard those questions more than a few times. And yet still I keep writing about it. Why? Part of the answer lies in my post back in December… today the world of SIP is all really “client/server” but the future might be quite different. Today you have SIP user agents that register and connect to SIP servers (which might be SIP proxies, SIP registrars or other types of servers). In fact, our own Prophecy product is a powerful SIP application server. Our Evolution developer portal is a massive SIP-application-server-in-the-cloud (more here) that connects to and from SIP clients.

But now imagine a SIP deployment without servers.

Imagine that you could simply distribute a series of SIP phones and have them all rapidly interconnect to each other and start communicating. Think of how fast you could potentially deploy a small office. In this time of US presidential campaigns, I think of the “advance teams” that are dropped into some office space in some city to organize an area. Imagine if they could be given a bunch of phones which just self-organized into a working communication environment? Plug the phones into a network switch and have them sort out extensions, PSTN gateways, all of that. There are all sorts of similar situations. Teams of consultants or auditors. Emergency environments. Short-term branch offices. Outside of the rapid deployment, there are just general uses in small businesses that don’t want to pay for servers. You could even see it being used in a home environment. Today this kind of thing can be done with “teleworker” phones hooked back to a central IP-PBX or hosted service (I know because I helped launch one back in 2003), but what if it could be even easier?

This is the promise of P2P SIP. Take a bunch of SIP endpoints and they form their own P2P “cloud” (or “overlay network” in P2P lingo). They discover resources like PSTN gateways or application servers. If a phone dies, the P2P cloud routes around it and continues. Communication happens.

Now the reality is not quite there today. There is a great amount of work being done within the IETF on this subject through the P2PSIP Working Group. There are P2PSIP implementations (mostly open source and a few commercial). There is a great amount of academic research going on (one example here). It is all still early days, though.

And on one level, that is what is so exciting. We are re-imagining what a network could be. We are pushing the power and intelligence truly out to the very edge of the network.

We are creating clouds.

Local clouds. Self-organizing clouds. Network “clouds” that connect to other clouds. It’s a different mindset… a different paradigm… thinking of networks not in terms of servers with their clients but in terms of nodes able to communicate with other nodes.

Will it work on a large scale? We’ll see… there’s a whole whack of security issues… privacy issues… scalability issues… but people are looking at those issues. Skype has certainly shown that a P2P telephony environment can be created and can be quite successful. (Although it should be noted that purists might not consider Skype a pure P2P network because they do have enrollment servers that deal with authentication, etc.) Other P2P networks for file sharing have shown the potential is there to build massively scalable networks. The building blocks are all around us.

So what’s the Voxeo angle, eh? Why do I care about it?

Two answers, really. First, there is the basic reality that just because you are creating a new way of connecting a telephony system it doesn’t remove the need for voice application services. You still want to run voice applications. You still need IVR systems. You still need ways to mashup voice with web services. You still need to connect to the PSTN. Some of those services may be able to live within the actual P2P cloud. Some of them will need to be in external servers or services. Obviously that’s what we do and so my interest is in how our software and services might play in this evolving space.

Second, it’s all about clouds. While there is a huge buzz these days about “cloud computing” and “virtualization“, this is what we’ve been doing here at Voxeo since our founding back in 1999! You can go right now to our Evolution developer portal, create your free account and start building voice applications that run in our massively distributed computing cloud. Behind the scenes, there’s a massively-scalable, geographically-distributed, open-standards-based, redundant (and, incidentally, patented) network architecture that virtualizes your voice and IVR applications. You have no idea what server your voice apps are running on and you don’t care. Need more ports… need more CPU cycles… the cloud adjusts for all of that. It’s all transparent to you.

Our “cloud” is then connected out into other “clouds”. You can connect to our cloud from the PSTN, SIP or Skype and then go back out to the PSTN or SIP clouds. We’re part of the massive interconnect currently being built online.

So as there is the potential to create local P2P “clouds”, my interest on multiple levels is pretty basic – how do we connect those small local clouds to our larger cloud and from there to the rest of the interconnected voice and data networks? I want to look at how our services can enable the proliferation of P2P SIP clouds.

Sure, large numbers of “production” deployments of P2P SIP are probably 3-5 years out… maybe even longer (but maybe not). At the current time there’s not a whole lot I can really do except engage in the ongoing conversations about P2P SIP and try to see what where it’s going. But that’s what I and my colleagues in our Office of the CTO do. We’re the guys up in the crow’s nest looking out and scanning the horizon for what’s coming next. Companies that expect to be around have to keep doing that. So that’s what I do. And that’s why I write about P2P SIP and why I’ll keep writing about it.

It’s all about the clouds… and how we connect them all together…

Technorati Tags: p2p, p2psip, sip, ietf, clouds, cloudcomputing, virtualization, ivr virtualization, peer to peer, skype, voxeo, voip, voice

As I wrote about previously, the IETF is hosting a “P2P Infrastructure Workshop” next week on May 28th on the MIT campus near Boston. There have been some updates in the past week:

• The workshop agenda has been published.

• The list of submitted papers is now available.

• Copies of the submitted papers are available for download as individual files or as a ZIP file containing all papers. (Note that this link does not work with all browsers. On my Mac it worked in Safari but not in Firefox 3.)

Reading through the agenda, it sounds like it will be a great session. P2P is really the next great area of network development, in my opinion, and making sure that the environment is such that we can do it well is key to seeing innovation and growth in that space. Anything like this workshop that can help set the stage for P2P developments is definitely to be encouraged.

P.S. I had hoped to attend myself, but given that I’ve got a moving truck showing up about 36 hours after this workshop ends (I’m moving from VT to NH) I somehow don’t see me getting down there.

Technorati Tags: ietf, p2p, networking, internet, workshops