Subject: [p2p-sip] What are we doing - question 1

From: ksankar at cisco.com (Krishna Sankar (ksankar))
Date: Tue, 30 May 2006 10:47:21 -0700

Good thoughts. Yep, first we need to define the layers, information
model and exchange mechanics. In the process if we can define a generic
DHT mechanism that would be good as well. We should not prematurely
choose a DHT. 

IMHO, any one of them will work and most probably newer ones will be
coming soon to a computer nearby anyway ... Of course, after we have
crisp and clear requirements, having worked on the various documents and
implementations, we could recommend one or two DHT mechanisms that fits
the bill. Most probably we would influence the DHT domain to come up
with more optimized setup for SIP ... 

"A very efficient optimized rat catching cat will not help if we are
looking for a horse" ;o)

Cheers
<k/>

> -----Original Message-----
> From: p2p-sip-bounces at cs.columbia.edu 
> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Alan Johnston
> Sent: Tuesday, May 30, 2006 10:40 AM
> To: Cullen Jennings (fluffy)
> Cc: P2P-SIP
> Subject: Re: [p2p-sip] What are we doing - question 1
> 
> Cullen Jennings wrote:
> 
> >Ok, I'm glad to hear that at least some people think we have some 
> >consensus on this. It's been hard to tell following the list so I 
> >appreciate people speaking up about it.
> >
> >I'll be very blunt about doing both proposal. It is not 
> clear to me if 
> >people think we should do both because
> >1) this is the technical long term solution we want, or
> >2) this would make it so at some level everyone agreed.
> >
> >Doing both will no doubt slow down finishing either. It is 
> not clear to 
> >the that the GET/PUT only protocol would be used if the other GET/ 
> >PUT/JOIN/LEAVE exists - it seems like you would just want 
> the later of 
> >the two. So if we look at our end goal, is there a need for GET/ PUT 
> >only.
> >  
> >
> Yes.  Real DHT nodes typically interact with 100s if not 
> 1000s of peer 
> nodes at any given instant.  Will every SIP UA be capable of doing 
> this?  Think wireless, low bandwidth, and embedded UAs.   
> 
> There is a very clear layering and architectural choices here 
> that if we 
> only somehow choose one single DHT and standardize it that we 
> will loose.
> 
> Also, I think we need to first decide what information should 
> be pushed 
> and pulled from the DHT, what format it is, and how it will be 
> retrieved.  Then, and only then do we have the requirements 
> for our DHT 
> layer.  To do both of these efforts them at the same time 
> makes no sense 
> to me.
> 
> Thanks,
> Alan
> 
> >On May 30, 2006, at 9:46 AM, Eunsoo Shim wrote:
> >
> >  
> >
> >>Enrico Marocco wrote:
> >>    
> >>
> >>>Cullen Jennings wrote:
> >>>      
> >>>
> >>>>I have many more question down each branch of this tree 
> but I think
> >>>>the high order bit is "who do we expect to run the servers that  
> >>>>store
> >>>>information in the DHT". One answer is a central 
> provider. The other
> >>>>answer is the users of the system. We need a crisp 
> decision on this.
> >>>>        
> >>>>
> >>>Off course there is broad consensus for the latter.
> >>>
> >>>I think nobody really wants to rely on a central provider 
> for storing
> >>>information; someone - mainly Alan and Henry - are 
> proposing to begin
> >>>with the definition of a Location Service Protocol, which could be
> >>>implemented from both external and P2P DHT-based services. 
>  The group
> >>>would then focus on the definition of some protocols to let SIP  
> >>>devices
> >>>build such DHTs.
> >>>
> >>>      
> >>>
> >>I agree with Enrico.
> >>The motivation of the proposal of using OpenDHT (or any public DHT
> >>service) for most, if not all, people who are talking about 
> it is that
> >>it will be easier for the proposed WG to start with the work of
> >>designing the access protocol (basically GET/PUT messages 
> between the
> >>UAs and the DHT nodes and then work on the more difficult DHT  
> >>protocol.
> >>I used to call the former the ON-SN protocol and the latter 
> the SN-SN
> >>protocol (GET/PUT/JOIN/LEAVE).
> >>
> >>I believe that there is a strong consensus that eventually P2PSIP  
> >>users
> >>should be able to build their own P2PSIP network without 
> relying on  
> >>any
> >>centralized provider.
> >>
> >>So the issue is whether we will work on two protocols in parallel or
> >>sequentially in my understanding but not whether we will 
> enable UAs to
> >>participate in a DHT.
> >>
> >>My preference is that we put both protocols as deliverables in the
> >>initial charter but plan to finish the access protocol before the  
> >>other
> >>protocol.
> >>
> >>
> >>    
> >>
> >>>Actually, I think the strongest consensus is only for the second  
> >>>part,
> >>>but it's just a feeling.
> >>>
> >>>      
> >>>
> >>Thanks.
> >>
> >>Eunsoo
> >>    
> >>
> >_______________________________________________
> >p2p-sip mailing list
> >p2p-sip at cs.columbia.edu
> >https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
> >
> >
> >  
> >
> 
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>

---

From: bryan at ethernot.org (David A. Bryan)
Date: Tue, 30 May 2006 14:06:05 -0400

I agree that we likely will discover most any DHT will work. However,
many of the (very) recent optimization of DHT papers I have seen are
marginally more efficient at a cost of massively increased complexity,
so it isn't always clear to me that newer=better. The folks designing
these are often (although certainly not always) algorithms
researchers, and often implementation is the furthest thing from the
mind of the paper author. We should be a bit careful.

David