Subject: [p2p-sip] dhts

From: matthewsp at avaya.com (Matthews, Philip (Philip))
Date: Tue Nov 1 07:43:16 2005

In my opinion, if we choose to standardize a DHT
(and I am not completely sure that is the right thing to do right now),
then we should pick a very simple algorithm that is easy to analyse
and implement. Don't worry that it doesn't seem to scale well or work
in all cases. Instead, provide a way to negotiate the use of another
algorithm.

I see this as analogous to the security mechanisms in various
IETF protocols. A number of protocols require the implementation of
simple password protection (or something equally simple) and allow
the negotiation of something more complex.

Part of my reasons for suggesting this is a suspicion (without any
real evidence so far) that we will NOT find a single algorithm
that will work well in all cases, and so different P2P overlay networks
will want to use different DHT algorithms. 

- Philip

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eunsoo Shim
> Sent: November 1, 2005 02:46
> To: Adam Fisk
> Cc: [email-masked]
> Subject: Re: [p2p-sip] dhts
> 
> I think you pointed out an important issue - selection of DHT.
> There are many DHT mechanisms and I am sure we will see more 
> in the future.
> I don't think this community intends to be an judge on DHT 
> mechanisms but we need to identify a very small number of 
> DHTs for specifications (and/or experiments) of P2P SIP while 
> making the protocol flexible enough to incorporate other DHT 
> mechanisms easily. (It is one of the requirements put in 
> draft-baset-sipping-p2preq-00.txt.)
> 
> So a question we have is how to select DHT mechanisms we are 
> going to use initially.
> I think it is an important meric if a particular DHT is well 
> understood by people who want to implement P2P SIP.
> But there are other requirements for DHT as well such as 
> robustness and lookup speed. Thus this community should come 
> up with a procedure for selection of DHTs for P2P SIP.
> I am trying to compile a proposal for such a procedure 
> (thanks to Rohan's advice).
> Any input on this will be appreciated.
> Thanks.
> 
> Eunsoo
> 
> 
> 
> ----- Original Message -----
> From: Adam Fisk <[email-masked]>
> Date: Monday, October 31, 2005 3:23 pm
> Subject: [p2p-sip] dhts
> 
> > I just wanted to pipe in on the DHT question to caution against 
> > the 
> > Chord bandwagon.  Sure, Chord is nice to reference because most 
> > people 
> > have heard of it.  That's really just because Chord was the first 
> > prominent DHT algorithm, though, and that's still it's primary 
> > distinguishing characteristic.  Other algorithms such as Kademlia 
> > are 
> > significantly more robust and have less rigid routing schemes, 
> > though. 
> > 
> > We should be clear that Chord should only be referenced *because 
> > people 
> > know it* and should not seriously be considered for real world 
> > implementations.  I'd actually prefer it if people stopped 
> > referencing 
> > Chord in the various drafts simply because it contributed to the 
> > misconception that it's a good option.
> > 
> > Thanks.
> > 
> > -Adam
> > _______________________________________________
> > p2p-sip mailing list
> > [email-masked]
> > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip
> > 
> 
> 
> 
> _______________________________________________
> p2p-sip mailing list
> [email-masked]
> http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip
>

---

From: bryan at ethernot.org (David A. Bryan)
Date: Tue Nov 1 10:42:45 2005

I'm fully in agreement here. I think that having multiple algorithms
-- and in particular very small simple algorithms as well as more
complex algorithms is essential. We are unlikely to be able to choose
one that will work in all cases, and are certain to not be able to
choose one that will be the "best" for any length of time -- there are
always advances in this area. I think Phillip's analogy to security is
a good one here -- devices should be able to negotiate a P2P protocol,
just as they can with security, encryption, or codec choice. We should
possibly even be able to negotiate non-DHT P2P mechanisms -- perhaps
in some very small scale cases we should use flood for simplicity.
Perhaps also in emergency cases?

--David

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Tue Nov 1 11:18:21 2005

Standardizing a DHT sounds somewhat overwhelming to me.
But if we put it as standardizing (or writing an experimental epec of )
a DHT for SIP-based Internet Telephony, Presence and Instant Messaging
(i.e., for specific target applications), the task sounds more
approachable and I feel more comfortable. And I think we have no choice
but to specify one or more DHTs for P2P SIP. Otherwise, we won't be able
to provide interoperability.

I also agree that we should start with simple algorithms. It is a good
idea to support negotiation about P2P algorithms.

Regards,

Eunsoo