Subject: Re: [Sipping] P2P requirements

From: Brijesh Kumar <[email-masked]>
Date: Tue, 01 Feb 2005 08:29:34 -0500

From: Cullen Jennings <[email-masked]>
Date: Monday, January 31, 2005 9:17 pm
Subject: [Sipping] P2P requirements

> 
> Right now I am somewhat interested in the space of what might be 
> possibleand what would be the limitations of theses systems. I'm 
> not even sure I
> know what I want, but, hey, I might know when I see it. I agree we 
> needrequirements before we could fully specify anything, however, 
> I'm at a
> somewhat almost pre requirements exploratory stage. Sort of like 
> jabber was
> back when the IETF was only working on it's 2nd or 3rd proposal 
> form IM
> systems :-) 

Hi Cullen:

I along with my colleague Mahfuz have been looking into SIP for 
P2P for quite sometime. 

We have been investigating using sip P2P architecture, not just 
for VoIP, but for enabling a wide range of multi-media applications
and for secure session control needed for these applications.

In my opinion, your sip p2p draft with Brian using DHT for sip registrations 
is good beginning in this direction (and so is the work in Henning's group). 
The current draft on P2P sip only covers the tip of the problem since P2P 
applications, when viewed in their entirety, present a number of new p2p 
specific issues (such as security, multicast, speed, service discovery etc). Some 
of the current sip mechanisms may not necessarily be suitable when used with 
sip p2p architecture.  We plan to provide more specific input on this. More,
specifically, we have done substantial work in the service discovery and service
mobility area.

I have a few more comments on your mail.

> I think one of the interesting problems to me is can we allow 
> people to form
> adhoc networks. Imagine several people show up at IETF and decide 
> to form a
> chat group - this is useful. People can choose a name, get on a 
> group, and
> chat. Perhaps they are doing shared editing on a collaborative 
> tool of some
> sort. Perhaps the chat takes the form of voice and video that is
> conferences. So far this is possible relying on DNS and central 
> servers to
> help with the rendezvous. 

I can provide many strong use cases than this where P2P sip is not just
a good to have option, but provides a preferable solution. For example,
a WPAN (wireless personal area networks) consisting of a number of 
multi-media devices (mp3 players, cell phones, dvd players, PDAs etc.)
provides an ideal environment for P2P sip. P2P SIP is not just an
option but is required because a PAN does not necessarily have any 
permanently available node to be designated as a sip registrar. Also,
PAN membership could be very dynamic depending upon a PAN User's 
location. 

We would like to use SIP in these envronments, but without
having to designate any node as sip registrar (battery issues, also
need to keep a particular node on-line etc.)

> Now perhaps those people are on an 
> airplane using
> 802.11 and don't have connectivity to the global DNS root servers 
> or any
> central servers. 

I just flew on Lufthansa that had 802.11 connectivity ($30 for the
entire duration of flight). So, not a good example any more ;-).

> Perhaps the airplanes will all have connectivity but
> perhaps the users are in some disaster area and "off the net". Could
> something interesting be done here? Definitely. In fact there are 
> many ways
> it could be done. 

PANs and ad-hoc networks provide ideal situations. 

> It may turn out  that the properties possible with these 
> approaches can all
> be solved better in other ways. Much of the experience with 
> optimizing P2P
> systems has come to a design like the standard SIP P2P design 
> where you use
> central servers with minimal state and pointers to correct edge 
> them push
> all the work to to the edge. The typical SIP UA with a central 
> register is a
> classic example of this style of P2P design. 

The initial node bootstrapping and scalability of P2P solution will
always remain an issue to be specified. Most, current P2P systems
use some sort of hybrid approach to scale, and that is contrary to 
pure P2P sip architecture. Also, DHT maintenance in a large network
is non-trivial issue, and need to be specified in its entirety. 

cheers,

--bk

_______________________________________________
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: "Brian Rosen" <[email-masked]>
Date: Tue, 1 Feb 2005 08:56:53 -0500

> PAN membership could be very dynamic depending upon a PAN User's

Another use case is emergency responders at an incident scene.  Think Fire
and Police folks at an isolated structure  They may have connectivity to
each other, but not to any fixed infrastructure (tower).  They MUST be able
to communicate in the absence of any pre existing infrastructure.

Brian