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

From: ksankar at cisco.com (Krishna Sankar (ksankar))
Date: Tue, 30 May 2006 12:03:42 -0700

Agreed. We should keep the accidental complexities (e.g. DHT et al) to a
minimum and ascertain the essential domain complexity (i.e. the
mechanics for SIP). As you aptly said, the goal is to have a P2P-SIP
stressing min complexity, faster organization without a pure central
authority, easier interoperability, good architecture and orthogonal
extensibility to incorporate newer technologies. 

Cheers
<k/>
> -----Original Message-----
> From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On 
> Behalf Of David A. Bryan
> Sent: Tuesday, May 30, 2006 11:06 AM
> To: Krishna Sankar (ksankar)
> Cc: Alan Johnston; Cullen Jennings (fluffy); P2P-SIP
> Subject: Re: [p2p-sip] What are we doing - question 1
> 
> 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
> 
> On 5/30/06, Krishna Sankar (ksankar) <ksankar at cisco.com> wrote:
> >
> > 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
> > >
> >
> > _______________________________________________
> > p2p-sip mailing list
> > p2p-sip at cs.columbia.edu
> > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
> >
>