Subject: [p2p-sip] dhts

From: matthewsp at avaya.com (Matthews, Philip (Philip))
Date: Tue Nov 1 14:32:51 2005

I agree with David.

I think we could standardize a negotiation framework
(which is really a capabilities advertisement mechanism)
along with rules for how to select between alternatives.

Along this line, I am thinking that the hierarchical P2P network
discussed in a separate thread on this list (and the referenced paper)
is looking increasingly attractive.
It allows different groups of peers to use different DHT algorithms.
Say for example, one group of peers (group A) wishes to use algorithm X,
while another group (group B) wishes to use algorithm Y, where both X
and Y
are advanced DHT algorithms. If all nodes also speak some basic
P2P algorithm Z, then we have a hierarchy, with group A nodes using
algorithm X
internally, group B nodes using algorithm Y internally, and the two
groups themselves
being treated as two nodes in a second level, which speaks algorithm Z.
Note that algorithm Z does not have to scale to lots of nodes, since
at its level there are only two: the node representing group A and the
node representing
group B. 

How groups A and B form are good questions. Does a node belong to group
A
simply because it speaks protocol X, or does group A has some other
natural
cohesive grouping? For example, do a bunch of nodes speaking David's
SoSimple
P2P protocol find each other through some (external?) mechanism,
and a bunch of nodes speaking the Nimcat P2P protocol find each other
through
another mechanism, and then the two groups talk using protocol Z?

If others agree with me that a hierarchical approach is the way to go,
then I think that we might be able to:
- Standardize a framework for hierarchical P2P networks
- Standardize a negotiation mechanism for the P2P protocol being used in
a group
- Standardize a simple protocol Z as the default P2P protocol

I agree with David's comment that the pattern (and format) of messages
used
in one P2P protocol may differ quite a bit from the messages used in a
different
protocol. I am not sure how successful we would be if we tried to
standardize
(for example) the message format, and leave only the algorithm open.

- Philip

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David A. Bryan
> Sent: November 1, 2005 11:59
> To: Roy, Radhika (AEAD)
> Cc: [email-masked]
> Subject: Re: [p2p-sip] dhts
> 
> I think this is the spirit of the thread, but a warning that in
> practice getting this together may be quite difficult, since different
> types of p2p implementations exchange different information between
> nodes for admission and upkeep of the overlay.
> 
> I think if we take this approach, the negotiation of a p2p mechanism
> and the implementation thereof (how p2p information is conveyed
> between nodes) will have to be two independent things, and I doubt we
> can standardize how the information is conveyed between nodes in a way
> that doesn't take into account what algotithm is being used. We may
> need a negotiation mechanism and then different "standards" for how
> the nodes maintain the overlay, since the information contained in
> messages and even the pattern and reason for messages exchanged
> between nodes can vary greatly for different p2p mechanisms.
> 
> David
> 
> 
> On 11/1/05, Roy, Radhika (AEAD) <[email-masked]> wrote:
> > So, the logical conclusion seems to be as follows:
> >
> > 1. P2P protocol will be algorithm agnostic
> >
> > 2. P2P protocol will allow capabilities to negotiate any 
> algorithm to be
> > used among the respective peers
> >
> > 3. P2P scheme will standardize couple of algorithms that can be
> > negotiated among the peers starting with a simple one first
> >
> > It appears that P2P protocol scheme should be flexible enough to use
> > algorithms and others per-(each)-peer basis.
> >
> > To extend this further, it may also be said for transport (reliable,
> > unreliable) and security (transport layer, IP layer) that the P2P
> > protocol should also use the same principle.
> >
> > Is that the right summary of this thread so far?
> >
> > Best regards,
> > Radhika
> >
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Eunsoo Shim
> > Sent: Tuesday, November 01, 2005 11:15 AM
> > To: David A. Bryan
> > Cc: [email-masked]
> > Subject: Re: [p2p-sip] dhts
> >
> > 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
> >
> > David A. Bryan wrote:
> >
> > >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
> > >
> >
> 
> _______________________________________________
> p2p-sip mailing list
> [email-masked]
> http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip
>