Subject: Re: [Sipping] SIP P2P draft

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

inline.

Cullen Jennings wrote:

> I would bet we want a generally mechanism. I like how STUN can be used by
> voice applications but also online gaming and many other things.
> 
> But I don't know about how likely a generally toolkit is. It would be very
> nice if possible but I don't think this stuff is understood well enough yet
> to know if you want very different approaches for different types of
> problems and query problems.

Hmm, sounds like an experimental specification would be the right target 
then.

We can figure out the requirements for a generic p2p toolkit in support 
of the things SIP needs to do; if those turn out to be useful for other 
things thats great too, but if its experimental we are not burdened with 
solving the world's p2p problems...

  For example, by carefully selecting what the
> user can not change as influencing the location in search space, you can
> stop the user from being able to insert themselves in an arbitrary locations
> which greatly improves the security of the scheme.

True, and SIP is a place where the requirements around security are 
likely to be different than file sharing.

> Say just SIP is bit braod too. The characteristics of a system to solve
> rendezvous is probably much different than saving address books and buddy
> lists which is probably much different from sharing PowerPoint presentation
> in a conference. 

Right. Clearly the first focus would need to be rendezvous. Presence and 
other application-driven SIP usages (i.e., places where xcap comes into 
play) are more complex.

>  
> Most of today work is somewhat centered around sharing files and making it
> difficult to shut down such a network while offering some level of
> obfuscation of who the users are. These properties may or may not be useful
> requirements.

I think that making it difficult to shut down the network is a goal in 
all usages. Obfuscation of users is a requirement for anonymous calls; 
we already know 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: Brijesh Kumar <[email-masked]>
Date: Tue, 01 Feb 2005 10:14:25 -0500

----- Original Message -----
From: "Johnston, Alan" <[email-masked]>
> There's some good ideas in here.
> 
> In my research and discussions with DHT implementers, running a DHT
> directly on top of SIP does not seem like a good idea - these guys 
> haveimplemented many, many optimizations including load balancing, 
> datastriping, and search optimization techniques that we'd have to 
> try to
> replicate in our SIP-only implementation.  If latency is at all an 
> issue(as it clearly is for a discovery mechanism for real time
> communication), then using reduced size finger tables and small
> successor node tables is not a good design strategy.

Having studied some of these issues, I would agree with above observations. 
The search latency in p2p could be substantial, and maintenace of DHT in a very 
dynamic environment is quite hard. But, for nearly static population of nodes, p2p
sip with DHT may be a very viable option.

However, the biggest mistake people can make is to think p2p in terms of DHT. 
DHT is suitable for certain size p2p networks. I can use p2p sip with five 
nodes and not need DHT at all. Also, hybrid p2p approaches like currently
deployed applications like skype etc. are also possible.

The first step in my opinion in p2p sip work should be to identify areas where 
applications can take benefits of p2p architecture without adversely getting 
affected by scalability and latency issues of large p2p networks.
 
> I believe that the NAT traversal/TURN discovery mechanism is one
> separate function that can be implemented with DHT.  Another is a
> registrar function.  A third is a redirect function.
 
As long as you can map resources to DHT node space, it will work 
regardless. So, all sip functions that require searching of certain 
resources or end-points are possible candidates. The identification
of candidate functions/ methods in sip architecture is not that 
hard. We have done some work in that direction, and would be interested
in contributing to IETF.

> There are also a number of generic protocols being developed in 
> the DHT
> community that we may be able to leverage - some are DNS-like with few
> writes but many reads, others store only pointers to information and
> deal with "flash events" in which a particular piece of data is 
> suddenlyof interest to a large group, others actually manage the 
> transport of
> chunks of data.
> 
> I agree with Robert that we need to discuss the requirements and 
> surveythe existing work to try to leverage this expertise as much 
> as possible
> before jumping into mechanisms.

True - the hard part will be to agree to one DHT mechanism since it is still
a topic of very active on-going research. 

Cheers,

--bk

---------------------------
Brijesh Kumar
home: home.comcast.net/~brijesh.kumar