Subject: [p2p-sip] dhts

From: RoyR at saic-abingdon.com (Roy, Radhika (AEAD))
Date: Tue Nov 1 11:46:38 2005

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 11:59:36 2005

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

---

From: ag at ag-projects.com (Adrian Georgescu)
Date: Tue Nov 1 12:25:13 2005

I would imagine the purpose of an IETF WG would be to design a simple 
protocol/algorithm that will allow me and my friends to meet at IETF, 
light up our wifi SIP devices and make an ad-hoc network where we can 
connect to each other at SIP application level like 802.X does at layer 
2. For this ad-hoc network a simple standard P2P could be standardized 
among vendors.

The most relevant (for me) requirements for developing SIP P2P would be:

4.5.  NAT and Firewall Traversal

How to solve NAT and allocating a third party media relay in a clever 
manner when necessary and based on some policy. I am not sure one can 
simply assume any P2P SIP device can do NAT traversal for others it 
might not have the resources or desire to do this.

4.1.  Resources for Distribution

Have an ad-hoc P2P location service, ONE and only ONE simple and 
compatible P2P algorithm among peers

5.5.  Interconnect with P2P, non-P2P and PSTN networks

Link the P2P ad-hoc location service with permanent location services 
provided by the DNS

4.3.  DHT Changeability and 6.1.  Support for different DHTs

This seems difficult to achieve and should not be a requirement. 
Imagining a complex scenario where DHT protocol A meets protocol B will 
introduce yet another type of gateway, "The P2P Gateway", we do not 
need yet another gateway we just need a distributed location service 
that interfaces with the DNS for public identities. We have DNS and SIP 
registrar functions and we could use them right and marry them with the 
P2P DHT algorithm.

Regards,
Adrian

On Nov 1, 2005, at 5:49 PM, Roy, Radhika ((AEAD)) wrote:

> _______________________________________________
> p2p-sip mailing list
> [email-masked]
> http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip