Subject: RE: [Sipping] New I-D on P2P SIP

From: "Johnston, Alan" <[email-masked]>
Date: Mon, 31 Jan 2005 19:46:32 +0000

Hi David,

Thanks for your reply.  This is exactly the discussion that we need to
have on this topic - thanks for starting it on the list.

See comments below.

Thanks,
Alan Johnston
sip:[email-masked]

> -----Original Message-----
> From: David Bryan [mailto:[email-masked]] 
> Sent: Monday, January 31, 2005 8:55 AM
> To: Johnston, Alan
> Cc: [email-masked]
> Subject: Re: [Sipping] New I-D on P2P SIP
> 
> 
> Thanks for submitting the draft. I think there are quite a 
> few things in this draft that should provoke some good 
> discussion. I have a few comments to get the discussion started.
> 
> First, I think we need to think carefully about the 
> motivation for using SIP as a P2P mechanism. I think the 
> reason for using SIP at all (as opposed to a pure -- no SIP 
> P2P) is obviously to allow reuse of device endpoints and all 
> of the things that go along with that -- infrastructure, the 
> features developed in the various SIP groups, ability to talk 
> to installed non-P2P SIP systems etc. It is demonstrably true 
> one could make a pure P2P VoIP/IM system, but without support 
> for SIP, it is creating an island. Once we realize that we 
> want to use SIP at some level, there are essentially two 
> approaches -- use pure SIP (as we did in our draft), or 
> replace a chunk of SIP with P2P (as Alan is proposing here). 
> Both definitely help nail the reuse issue.
> 
> The earliest work I did in this actually went along the same 
> line as the one proposed in Alan's draft. The first 
> papers/design/implementation for SOSIMPLE we tried here at 
> W&M used pure Chord for the underlying mechanism of 
> discovery, and then used SIP to communicate between 
> devices/establish session. In other words, we did a chord 
> search to find the user's contact, then simply sent an invite 
> directly to it. The implementation was essentially a full SIP 
> stack fed information obtained by a full Chord 
> implementation.

Do you have any references/descriptions of this that you can point us
to?

> I think there are a number of issues there 
> that made it unattractive, at least in my mind:
> 
> * Devices implemented in this way would need to support 
> multiple protocols. While an approach using SIP as transport 
> for the P2P mechanism still requires the code for the P2P 
> algorithms, it does not require a second underlying 
> protocol/stack.

Yes - this is a familiar argument, but not very convincing from an
architectural point of view.  Hopefully other arguments will sway us one
way or the other.

I can also imagine a scenario in which a proxy server acts as a P2P
gateway for a domain.  As a default outbound proxy, it could receive
incoming requests, perform P2P discovery and rendezvous, then redirect
the request with the device URI.  In this way, some of the benefits of
P2P can be provided to "old" SIP phones and clients.

> Similarly, we would have concerns about the 
> new underlying P2P protocol that are already being addressed 
> for SIP (NAT traversal, and things like shapers, SBCs etc. 
> properly seeing this traffic as voice/IM/video -- and not 
> file sharing, for example). 

I'm not sure I understand what you mean.  Do you mean that you hope that
P2P Internet communications will be treated differently from P2P file
sharing, and perhaps not treated as an outcast?  Or do you mean that you
want P2P traffic to be subject to intermediaries like other C/S SIP
traffic?

If the former, I'd agree that we would want our own network distinct
from file sharing - and optimized for our discovery/rendezvous
mechanism.  I think separating the discovery and rendezvous
functionality from NAT traversal relay service is a key idea here.  Many
system administrators have serious concerns about traffic relaying
though unsuspecting nodes - in comparison, storing a few encrypted
fragments of URI mappings for other peers is much less of a concern.

If the latter, I'm not sure we want intermediaries (B2BUAs, ALGs, etc.)
messing with our P2P SIP traffic.  This might actually be an argument
for not using SIP.

> 
> * While the P2P community is doing some outstanding work, it 
> isn't a stable standard. As far as I am aware, none of this 
> work is being done in a way that would lend itself to easy 
> implementation -- it changes frequently, libraries aren't 
> truly compatible with each other, etc.

Sure - we'd need to work with the P2P community and not try to use
research code. However, I think we could generate a lot of interest from
those in academia who would like to see how their ideas operate "in the
wild."

> 
> I also think that we need to differentiate mechanism from 
> application. I do agree that much of the research out there 
> feels that 160 entry finger tables are needed, but a careful 
> read of such papers will reveal most, though certainly not 
> all of them, are implicitly directed with file sharing as the 
> application, and DHT as the mechanism. The need for enormous 
> finger tables seems, to me anyway, to spring from the 
> application -- not the mechanism. Chat/Voice is different in 
> several very specific ways. 
> 

Yes - our needs are different from file sharing - we need to perform
this analysis.  One thing that worries me, though is perhaps different
ideas about the size of a P2P network.  In SIP, we think a large network
is 10,000 SIP phones.  In P2P terms, a large network is 10^5 nodes.
Searching time even for a network this large must be of the order of
seconds, not minutes.  Whatever we do must, above all else, scale to
networks bigger than anything out there today - Skype is just a drop in
the bucket of where a true P2P Internet communications network could be
in a few years time.

> In voice/IM, one often talks to the same individuals, 
> allowing caching (if only in a limited way due to mobility). 
> Because of that, you can also establish relationships (using 
> subscribe/notify) with many of the people you need to 
> communicate with, reducing searches. The number of phone 
> calls/IM sessions one makes in a day is likely lower than the 
> number of files searches one does in a day, and with a more 
> concentrated group of people. Finally, although there is a 
> good bit of discussion on this one, I think the number of 
> nodes in any particular overlay constructed with P2P SIP is 
> likely to be lower than the number participating in file 
> sharing, but I'm not really sure about that one.
> 

Agreed that file sharing and discovery/rendezvous will have different
usage patterns.  More thoughts (and perhaps simulations) are needed to
help us decide this.

> In any case, I think there are some interesting issues raised 
> here, and look forward to the discussion. 
> 
> --David
> 
> On Mon, 2005-01-31 at 03:03, Johnston, Alan wrote:
> > All,
> > 
> > Until it appears in the archives, here's a draft I just 
> submitted with 
> > some thoughts and ideas on P2P SIP:
> > 
> >      
> > http://ee.wustl.edu/~alan/draft-johnston-sipping-p2p-ipcom-00.html
> > 
> > Comments always most welcome.
> > 
> > Thanks,
> > Alan.
> > 
> > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: David Bryan <[email-masked]>
Date: Mon, 31 Jan 2005 18:26:11 -0500

> Do you have any references/descriptions of this that you can point us

Sure. The most recent paper before we switched to an all-SIP approach is
from November. Regular chord messages were used extensively in this
design. Several other things in this paper I now have different ideas
about or have concluded won't work, however, so any ideas in the draft
Cullen and I wrote supersede this document:

http://www.cs.wm.edu/~bryan/pubs/0411SOSIMPLE/paper.pdf

> P2P can be provided to "old" SIP phones and clients.

100% agree. This is essentially what we call an adapter node in the
draft, and can work with either a p2p or sip as underlying protocol
approach. I agree they will be an important architectural element no
matter how we implement.

> want P2P traffic to be subject to intermediaries like other C/S SIP

If we use the same underlying mechanism as file sharing, and the same
protocol, it will be very difficult for any device (shaper, firewall, or
what have you) to distinguish between a SIP lookup and file sharing
lookup, which could make deployment of P2P SIP using such a discovery
mechanism a difficult sell to people trying to block file sharing. I
think it is very important going forward that file sharing and P2P
Voice/IM/Video be distinguishable, even if we eventually discover it is
inevitable that the line will blur a bit.

--David