Subject: [p2p-sip] dhts

From: RoyR at saic-abingdon.com (Roy, Radhika (AEAD))
Date: Tue Nov 1 12:05:51 2005

I am providing comments on this, "... different p2p mechanisms."

My understanding has been so far that we will standardize only ONE p2p
mechanism. That is, only ONE p2p protocol that will need algorithms,
transports, security features, and others.

Please note that only ONE p2p protocol, but many algorithms, many
transports, many security features, etc.

Is this assumption not correct?

Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
David A. Bryan
Sent: Tuesday, November 01, 2005 11:59 AM
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
> >
>

---

From: bryan at ethernot.org (David A. Bryan)
Date: Tue Nov 1 12:16:05 2005

I think we might be having a terminology problem here.

I would use the term different algorithms for p2p to mean one could
use chord, epichord, kademlia, CAN, flood, etc, and I think that
people are proposing we be able to have more than one and negotiate
which one.

I'm not sure what you mean by one protocol but many algorithms. One
SIP-based type protocol that lets you use different p2p algorithms
underneath? That is what I am saying may be very difficult, since the
different protocols communicate such different information between
each other, and I opened the suggestion that if we do this, we may
need different documents describing the date exchanged between
different implementations. Whether that is a different protocol or not
is a debatable point, I suppose one could say it is.

Maybe we can find a single p2p mechanism that meets all needs and it
will be a moot point, but I still think if we do, one could come up in
a few years that is better, and we would need to have the flexibility
to use that new p2p mechanism.

David