Subject: [P2PSIP] RE:

From: JiangXingFeng <[email-masked]>
Date: Mon, 05 Mar 2007 11:53:14 +0800

Hi, Henry:
> Your understanding is correct, and I see no reason not to use
> openDHT-like networks (maybe even commercial as intended by its
> developers) either:
> 
> 1. A multipurpose global "Internet at the application layer", and/or
> 2. A bootstrap mechanism for P2PSIP.
> 
> A discussion would be very interesting and welcome indeed.

Do you mean that the infrastructure like what OpenDHT provides to provide
service is used to organize P2PSIP overlay and help new nodes bootstrap?

If my understanding is correct, the OpenDHT should run as stable as
possible, because there will a variety of applications or services will be
built on it. In this case, the quality of nodes making up of OpenDHT is very
different from peers which are discussed in the current P2PSIP mailing list,
so the design of Peer protocol should change accordingly. 

What about your opinions?

--
Jiang XingFeng

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: Peili Xu <[email-masked]>
Date: Mon, 05 Mar 2007 15:01:32 +0800

Hi XingFeng,

The tradistion of the IETF is to build general flexible and extensible
protocol toolset for various current and potential application. A good
example is SIP which can be used for Internet Realtime Application, telecom
IP multimedia system 
and also Enterprise network. 

As proposed by Heny, I also think when considering the protocol solution, we
need to consider the senario that a common P2PSIP overlay providing common
routing service for Clients to communicate. 
Applications and services (other than P2PSIP routing service) can then run
over this routing infrastructure.

Cheers.
Peili

-----Original Message-----
From: JiangXingFeng [mailto:[email-masked]] 
Sent: Monday, March 05, 2007 11:53 AM
To: [email-masked]
Cc: 'P2PSIP Mailing List'
Subject: [P2PSIP] RE:

--
Jiang XingFeng

---

From: EdPimentl <[email-masked]>
Date: Mon, 5 Mar 2007 09:24:43 -0500

Why are we using OpenDHT as an example, when currently OpenDHT method of
putting bits on the wired is not compliant with the drafts being discussed.
What is the group recommending for those planning on building/coding  (line
in the sand) to the emerging standards? CHORD, BAMBOO, KADEMLIA or OpenDHT?
We do understand that at some point in the future it will be DHT protocol
agnostic... and today this is not the case.

Looking for your comments.
Best,
-E

-- 
Thanks in advance and best regards,

Ed Pimentel
AgileCO
Founder

Mail:   edpimentl[at]gmail.com
IM:     edpimentl [AOL | Jabber | Yahoo | MSN ]
Voip:   edpimentl [SKype | GoogleTalk ]

Mobile Content Marketing/Management/Digital Delivery
http://mobilecentral.ws

Mobile ( Relevant, Ambient, Location ) based Social Network
http://TagR.mobi (Alpha)

Mobile Payment - P2P Payment
http://agilepay.ws

Sponsor of P2PSIP  open source [viasip_ng] project
Creating a standards base P2PSIP dSIP infrastructure
https://sourceforge.net/projects/viasip/
Mailing List [email-masked]
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 5 Mar 2007 08:29:59 -0800

Ed Pimentel wrote:

>Why are we using OpenDHT as an example, when currently OpenDHT method of >putting bits on the wired is not compliant with the drafts being >discussed.

This is a good and also important question that will require some work to answer properly. Please see one alternative:

http://tools.ietf.org/wg/sip/draft-singh-p2p-sip-01.txt 

 though I want to make it clear I am not married to this approach or any other submitted so far.

Now that the P2P SIP WG has quite a number of proposals, including the above, I would like to see a paper on the design options and a comparison of the pros and cons of the various concepts.

This is probably the most important decision this WG will make and such a decision deserves a formal comparison paper and thorough discussions.

We may be attached (or even invested in) to one proposal or another, but do we want to fail by rushing into the wrong decision?

What do you all think? Take a hum during the meeting? 
(Paper on design choices)

Thanks, Henry

________________________________________
From: EdPimentl [mailto:[email-masked]] 
Sent: Monday, March 05, 2007 8:25 AM
To: JiangXingFeng
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] RE:

Why are we using OpenDHT as an example, when currently OpenDHT method of putting bits on the wired is not compliant with the drafts being discussed.
What is the group recommending for those planning on building/coding  (line in the sand) to the emerging standards? CHORD, BAMBOO, KADEMLIA or OpenDHT? 
We do understand that at some point in the future it will be DHT protocol agnostic... and today this is not the case.

--
Jiang XingFeng

Ed Pimentel
AgileCO
Founder

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 5 Mar 2007 09:52:02 -0800

-----Original Message-----
From: Henry Sinnreich 
Sent: Monday, March 05, 2007 10:30 AM
To: 'EdPimentl'; JiangXingFeng
Cc: P2PSIP Mailing List; Kundan Singh; 'Henning Schulzrinne'
Subject: RE: [P2PSIP] RE:

Thanks, Henry

--
Jiang XingFeng

Ed Pimentel
AgileCO
Founder

---

From: EdPimentl <[email-masked]>
Date: Mon, 5 Mar 2007 13:05:38 -0500

Hello Henry,

Thanks for addressing this concern.
Because of the previous work done at Columbia.edu and good documentation we
have been leaning towards CHORD....
Have even applied at getting a slice at PlanetLAB to develop and test our
work.

We actually will begin planning and coding in the next two weeks using the
latest drafts from P2PSIP and Henning S.
I really do welcome comments and suggestions on which one to start with so
we can be true to the letter and spirit of this WG.
Again, welcome feedback and recommendations.

On 3/5/07, Henry Sinnreich <[email-masked]> wrote:
> This is a good and also important question that will require some work to
> answer properly. Please see one alternative:
>
> Now that the P2P SIP WG has quite a number of proposals, including the
> above, I would like to see a paper on the design options and a comparison of
> the pros and cons of the various concepts.
>
> This is probably the most important decision this WG will make and such a
> decision deserves a formal comparison paper and thorough discussions.
>
> We may be attached (or even invested in) to one proposal or another, but
> do we want to fail by rushing into the wrong decision?
>
> Sponsor of P2PSIPopen source [viasip_ng] project

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Mon, 5 Mar 2007 19:21:31 +0100

Hello all,

2007/3/5, EdPimentl <[email-masked]>:
> Because of the previous work done at Columbia.edu and good documentation
> we have been leaning towards CHORD....

As far as I know it relies on 'Internet connection'. From my point of view
P2PSIP should has an AS philosphy, not relying on other 'external' services.
What do you think?

> Thanks in advance and best regards,

Regards,
Victorp

On 3/5/07, Henry Sinnreich < [email-masked]> wrote:
> > >Why are we using OpenDHT as an example, when currently OpenDHT method
> > of >putting bits on the wired is not compliant with the drafts being
> > >discussed.
> >
> > This is a good and also important question that will require some work
> > to answer properly. Please see one alternative:
> >
> > This is probably the most important decision this WG will make and such
> > a decision deserves a formal comparison paper and thorough discussions.
> >
> > From: EdPimentl [mailto: [email-masked]]
> > What is the group recommending for those planning on building/coding
> > (line in the sand) to the emerging standards? CHORD, BAMBOO, KADEMLIA or
> > OpenDHT?
> > We do understand that at some point in the future it will be DHT
> > protocol agnostic... and today this is not the case.
> >

-- 
Victor Pascual Ávila

mail:[email-masked]
sip:[email-masked]
fon user: 223364
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 5 Mar 2007 11:49:10 -0800

Victor Pascual Ávila wrote:

➢ From my point of view P2PSIP should has an AS philosphy, not relying on other 'external' services.

1. P2P SIP requires a network of bootstrap servers as well. 
So why not in the form of openDHT?

2. A P2P overlay may be used for more than just one type of service.

3. Clean separation of functions.

4. Columbia University has researched several approaches, including the use of openDHT.

5. Last and most important, Bamboo on openDHT has well published performance reports and fixes from what was learned in global implementations and lab simulations to cope with Internet impairments. 
I have not seen any comparable numbers or graphics showing reported performance. See the top 4 bullets at http://opendht.org/pubs.html  

Just well written I-Ds are no substitute IMHO. 

Thanks, Henry

________________________________________
From: Victor Pascual Ávila [mailto:[email-masked]] 
Sent: Monday, March 05, 2007 12:22 PM
To: EdPimentl
Cc: Henry Sinnreich; Kundan Singh; P2PSIP Mailing List
Subject: Re: [P2PSIP] Re: Design decisions

Hello all,

Thanks for addressing this concern.
Because of the previous work done at Columbia.edu and good documentation we have been leaning towards CHORD.... 
Have even applied at getting a slice at PlanetLAB to develop and test our work. 

As far as I know it relies on 'Internet connection'. From my point of view P2PSIP should has an AS philosphy, not relying on other 'external' services. What do you think?

We actually will begin planning and coding in the next two weeks using the latest drafts from P2PSIP and Henning S. 
I really do welcome comments and suggestions on which one to start with so we can be true to the letter and spirit of this WG. 
Again, welcome feedback and recommendations.

Regards,
Victorp 

-----Original Message-----
From: Henry Sinnreich 
Sent: Monday, March 05, 2007 10:30 AM
To: 'EdPimentl'; JiangXingFeng
Cc: P2PSIP Mailing List; Kundan Singh; 'Henning Schulzrinne'
Subject: RE: [P2PSIP] RE:

Thanks, Henry

--
Jiang XingFeng

Ed Pimentel

-- 
Victor Pascual Ávila

---

From: "David A. Bryan" <[email-masked]>
Date: Mon, 5 Mar 2007 16:53:55 -0500

Changing the focus a bit here...

I've read the drafts, including the one by Singh Henry references
below, but I still don't understand what people mean when they talk
about an "OpenDHT" proposal. OpenDHT is a service...it isn't a
protocol, unless people are talking about just taking and
standardizing what OpenDHT sends on the wire *as* the protocol.
OpenDHT describes themselves as:

"OpenDHT is a publicly accessible distributed hash table (DHT)
service. In contrast to the usual DHT model, clients of OpenDHT do not
need to run a DHT node in order to use the service. Instead, they can
issue put and get operations to any DHT node, which processes the
operations on their behalf. No credentials or accounts are required to
use the service, and the available storage is fairly shared across all
active clients."

>From my understanding, it is a group of machine which implement a DHT
using Bamboo, and serve as a DHT on behalf of clients. I believe it is
also the idea some people have in mind when they talk about a
service-based architecture. OpenDHT encourages people to use it to
store/retrieve information, so in some ways, the ultimate end systems
don't participate in any way in the P2P aspects of the system.
Currently OpenDHT runs on a few hundred nodes on a closed
academic/industrial research system called planet lab which a general
user cannot become a member of, although obviously that could be
different in a different deployment. To me it looks like a way to play
with a DHT but not really one that users can leverage or use.

So a few things I want to discuss about this philosophy:

* First, what do people think the WG would do in the event we went
with a model like this? I would assume the model advocated here is
that we use unmodified SIP entities (proxies, UAs or whatever) that
contact OpenDHT nodes to store information for them. Since the actual
SIP entities are not participating in the overlay in such a model,
what is it we standardize here? Do we take the current protocol sent
over the wire by OpenDHT, flesh it out more fully, and standardize
that protocol (or perhaps two protocols -- between the peers and
between the clients who just use the service and the peers)?

(if the answer to the above is yes, how would we leverage it to deal
with NATs? PlanetLab is NAT free. Also, how about security and
identity? OpenDHT says they don't use credentials or accounts, which
seems to imply we would need to build some infrastructure like this on
top if this system can be used for a real system. Although we can
obviously look since it is open source, does anyone know what OpenDHT
is using as a protocol on the wire -- not the programming interface --
since as a WG we need to standardize that? (XML? Something they
created?) Is there a document that describes the protocol they use?)

* How does this approach eliminate a service provider? I don't think
it is scalable for us all to just use the few hundred planet lab
servers as our data store servers, so the question is who would
provide the servers (in the physical sense of that word -- the
machines/electricity/bandwidth) that today are running the OpenDHT
peers? People have always proven poor at providing free resources in
the past, so if most people just choose to use the DHT "cloud", who
provides that cloud and how do we ensure reliability for it?

* Is there only one cloud? How can I create a (private) system in such
an approach? What about an off-line cloud for ad-hoc or emergency
responder cases? Does OpenDHT support this today?

> So why not in the form of openDHT?

What we need are some peers that can serve this role, but they don't
really need to be servers, as long as they are semi-persistent. I
think the approach of volunteer nodes such as OpenDHT takes could be a
good model of a few people volunteering to be the "cloud" of
bootstraps -- might be much easier to get volunteers to be a "Peer
that will just quickly respond with a list of peers for you" then to
get volunteers to be a "Peer that will store your stuff for you".
Would that make some sense here?

> 2. A P2P overlay may be used for more than just one type of service.

True, but remember the first item explicitly excluded from scope in
this WGs charter is creating or using DHTs for other services, so we
need to stick to SIP.

> 3. Clean separation of functions.

This is sort of the heart of the OpenDHT question I think. What are we
trying to separate? I guess I see 3 things that can be separated:

1 The logical layer of gets/put/search from SIP call setup (although
could use SIP for both)
2 The protocols used
3 The nodes using it from the nodes providing the service

My way of thinking is that 1 is clearly a good thing to separate, but
I'm not as clear that 2 makes sense (I personally feel it does not)
and I think in many or most cases separation 3 is a bad idea. What do
we see as the separation that is valuable here, and how do we want to
capture that separation in our work?

> 4. Columbia University has researched several approaches, including the use of openDHT.

True, although many others have done research or developed products in
this area as well, many of which don't use OpenDHT. I think using
OpenDHT is a great way to conduct research -- it is a "testbed", but
that doesn't really make it well suited for a protocol to be defined
and used for commercial and non-commercial development on the
internet.

> I have not seen any comparable numbers or graphics showing reported performance. See the top 4 bullets at http://opendht.org/pubs.html

This might be an argument for Bamboo as a DHT, but choosing Bamboo
doesn't force us to use an OpenDHT type architecture. We have proposed
in a draft how to use Bamboo as one of many pluggable algorithms
within a P2PSIP context where each UA is a peer and using SIP here:

http://www.p2psip.org/drafts/draft-zangrilli-p2psip-dsip-dhtbamboo-00.html

Also we need to keep in mind these numbers are for stable servers on
University systems with no NATs and no security, so we need to factor
that into the decision.

I think there are a number of very big open questions here that I
would like to discuss more fully.

David

> Just well written I-Ds are no substitute IMHO.

I'd argue this is

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: "David A. Bryan" <[email-masked]>
Date: Mon, 5 Mar 2007 16:57:05 -0500

My last sentence got clipped to just "I'd argue this is". It should have read:

"I'd argue this is a good reason to see about getting together a
number of drafts we can implement and test or at least write to the
extent that we know we can do NAT traversal, security, etc."

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 5 Mar 2007 14:38:32 -0800

David,

I believe we agree to large extent on the arguments (except A. and B. as below), and it is probably my fault of speaking of openDHT when the actual alternatives meant here are Bamboo, Chord, etc. for the DHT itself. As for using SIP for the DHT, this is another design choice.

So there are a number of design choices with their pros and cons.

What are missing before we make a commitment are experimental results:

- How effective (%) is NAT traversal (types of NAT, NAT configurations, etc.)?

- What are the numbers for the call setup time? See the delays on the openDHT before some fixes.

- How many calls fail because there is non-transitive connectivity (peers cannot see each other)?

- What proportion of evil peers make the DHT fail? 30% as measured for Bamboo?

- There may be more...

There are good reports with numbers for _all the above_ for Bamboo at openDHT (the source of the confusion), but zero numbers in the other proposals that have been submitted to the P2P SIP WG. 

A. Just because an I-D is well written is no substitute for hard numbers. Otherwise, we would simply work on faith instead based on experimental results and measured numbers. 

If reporting numbers as for Bamboo is too difficult, at least if we could first make some informal tests on an implemented system, before making a commitment for a standard would really help.

B. And sure, a document showing the design choices, Bamboo-Chord, etc., SIP for the DHT or HTTP, etc. and quite a few other design choices. Writing and discussing such a document is preferable to discussing all the issues by e-mail.

Henry

-----Original Message-----
From: David A. Bryan [mailto:[email-masked]] 
Sent: Monday, March 05, 2007 3:57 PM
To: Henry Sinnreich
Cc: Kundan Singh; P2PSIP Mailing List
Subject: Re: [P2PSIP] Re: Design decisions

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: Dean Willis <[email-masked]>
Date: Tue, 6 Mar 2007 14:33:10 -0600

> standardizing what OpenDHT sends on the wire *as* the protocol.

I think the idea is that the P2P storage component can be modeled as  
a service in a service-oriented architecture. If it is, then it could  
potentially be used, as a service, by P2PSIP. This reduces the  
coupling to the definition of a service interface.

OpenDHT is an example of such a service and has an existing service  
definition that could be re-used.

The question that comes to mind: Is the service defined by OpenDHT  
adequate to P2PSIP, or do we expect more from the storage layer than  
what it does? If we expect more, can this "more" be defined as an  
additional service interface that can be implemented on top of the  
existing OpenDHT service interface?

And of course the underlying question: Is a service-oriented  
architecture a reasonable tool for P2PSIP?

--
Dean