Subject: Re: [Sipping] P2P requirements

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 01 Feb 2005 00:27:54 -0500

Cullen Jennings wrote:

> 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.  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. 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. Multicast comes to mind. I like the rendezvous stuff in
> iChat. Very adaptive DNS comes to mind. I like dyndns. DHTs could be used.
> I'm sure all these systems approaches would end up with significantly
> different characteristics. I'm queries about what's possible,

A simpler solution in many of these cases is merely to have one 
participant take on the role of "proxy/registrar" and then use something 
like SLP to allow other participants to discover its IP address.

A "true" p2p solution becomes required when the group is sufficiently 
large and distributed that there is no reasonable way for there to be 
just one that takes on this role.

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

"standard SIP p2p design"? which standard is that?

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: Mauricio Arango <[email-masked]>
Date: Wed, 02 Feb 2005 18:39:12 -0500

I think the general problem you are addressing is P2P-based name translation.
Instead of using DNS it would use a P2P-based discovery mechanism.

SIP would be one of the systems using such discovery mechanism,
but not necessarily the only one. In the case of SIP-based application
the number of entries in such system could be huge (billions)
assuming all the potential clients in the mediun term. Therefore, scaling
issues are comparable to those in file sharing. There is good
research work in this area, including DHT, however distributed
hashing solutions are not ready to replace DNS. I don't believe
SIP-based applications have any advantages for using DHT solutions
as compared to file sharing.

I think this problem is not just a SIP issue but a general discovery
issue. SIP would be one of the systems that could benefit from
such discovery mechanism.

I think this is a great area of work, however  the challenges for replacing
DNS with a highly distributed, P2P-based discovery mechanism
are huge.

Mauricio Arango

-------------------------------------

Cullen Jennings wrote:

> Right now I am somewhat interested in the space of what might be possible
> and 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 need
> requirements 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 :-)
>
> 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.
>

---

From: "Juha Heinanen" <[email-masked]>
Date: Thu, 3 Feb 2005 04:21:39 +0200 (EET)

there must be some ery good reasons for inventing all those new p2p
protocols we have read on this mailing list, but i would still like to
hear why an existing protocol, namely DNS, is not good for discovery?

my sip uri is sip:[email-masked].  if someone wants to get my contact
information, they could simply make a sip srv query on jh.tutpro.com,
which my sip ua is keeping up to date via dynamic dns updates either
directly or indirectly using xmlrpc, for example.

what is wrong with this kind of DNS approach?

-- juha

---

From: Tyler Johnson <[email-masked]>
Date: Wed, 02 Feb 2005 21:44:43 -0500

Juha,

I agree with you that the primary problem is one of 'discovery', though 
I might term it addressing. And I agree that DDNS solves this problem. 
It seems to me the larger goal of P2P SIP is precisely to enable an 
architecture in which intelligent endpoints do not require a service 
provider (i.e. someone running a proxy on the public Internet) in order 
to function reasonably (i.e. be reachable via an AOR). In this scenario, 
end to end authentication is a requirement, of course. It changes the 
business case entirely, away from a carrier market, to one in which 
endpoints are commodity and the service is completely devolved.

-- 
Tyler Johnson
http://www.unc.edu/~trjohns1

---

From: "Mike Hammer" <[email-masked]>
Date: Thu, 3 Feb 2005 10:30:24 -0500

Define completely devolved.  

The minute you start having "super-nodes" in the system, it is no longer
P2P.  You now have a service provider, whether you pay for it or not.  It is
just the nature of the SP that has changed.  From what I have seen thus far,
you don't have a clue as to who you are dealing with, and that may be a
worse remedy (security, performance) than the perceived problem.

Speed and reliability must be accounted for, and thus far DNS appears to
work well.

Mike

   >-----Original Message-----
   >From: [email-masked] 
   >[mailto:[email-masked]] On Behalf Of Tyler Johnson
   >Sent: Wednesday, February 02, 2005 9:45 PM
   >To: [email-masked]
   >Subject: Re: [Sipping] P2P why not DNS for discovery?
   >
   >Juha,
   >
   >I agree with you that the primary problem is one of 
   >'discovery', though I might term it addressing. And I agree 
   >that DDNS solves this problem. 
   >It seems to me the larger goal of P2P SIP is precisely to 
   >enable an architecture in which intelligent endpoints do 
   >not require a service provider (i.e. someone running a 
   >proxy on the public Internet) in order to function 
   >reasonably (i.e. be reachable via an AOR). In this 
   >scenario, end to end authentication is a requirement, of 
   >course. It changes the business case entirely, away from a 
   >carrier market, to one in which endpoints are commodity and 
   >the service is completely devolved.
   >
   >Juha Heinanen wrote:
   >
   >> 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
   >
   >--
   >Tyler Johnson
   >Use [email-masked] for questions on 
   >current sip Use [email-masked] for new developments of core SIP
   >