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

From: "Johnston, Alan" <[email-masked]>
Date: Mon, 31 Jan 2005 08:03:22 +0000

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

---

From: David Bryan <[email-masked]>
Date: Mon, 31 Jan 2005 09:55:04 -0500

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. 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. 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). 

* 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.

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. 

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.

In any case, I think there are some interesting issues raised here, and
look forward to the discussion. 

--David