Subject: [p2p-sip] Interoperation Between Heterogenous P2P Overlay Networks

From: g06t6632 at campus.ru.ac.za (Mosiuoa Tsietsi)
Date: Fri, 25 Aug 2006 16:21:38 +0200

Hi all,

I have been listening in very intently on the list and have been very
intrigued by many of the comments that have been made particularly
concerning interoperation between heterogeneous P2P Overlays.  I read the
document draft-shi-p2psip-hier-arch-00.txt with great interest and would
like to comment on a statement made therein saying: 
 
"A peer in one P2P overlay (such as Chord) is difficult to route the SIP
message to another P2P overlay (such as Pastry) based on their individual
P2P peer locating service"

I can understand the difficulty as mentioned.  I have come up with an idea
that could (hopefully) ameliorate these difficulties.  I propose a node
architecture for a P2PSIP UA within the context of using DHTs as the basis
of a location service, with an added abstraction layer built in to the UA to
hide the differences in the DHT APIs.  This abstraction layer consists of a
layer of DHT plug-ins for different DHT algorithms.  These plug-ins will
allow "pluggability" of different DHTs in participating overlay nodes. This
design will allow all P2PSIP nodes to use a common {get, put, remove} API
which is then translated by the particular plug-in in use at that time.
This would eliminate the need for a gateway node (since all nodes can do
translation between DHTs) and is more kosher in strictest p2p sense.

I have begun using OpenChord and Bamboo (Java DHT implementations) to test
out my plugin theory.

Have I misunderstood the problem and oversimplified it?  Comments much
appreciated.

Mos

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060825/9e7f4621/attachment.html

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Fri, 25 Aug 2006 08:27:26 -0700

Mos,

>I have begun using OpenChord and Bamboo (Java DHT implementations) to
test out my plugin theory.

This is really extremely interesting. Please see if/when you can share
the results.

Thanks, Henry

________________________________

From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Mosiuoa Tsietsi
Sent: Friday, August 25, 2006 9:22 AM
To: p2p-sip at cs.columbia.edu
Subject: [p2p-sip] Interoperation Between Heterogenous P2P Overlay
Networks

Hi all,

I have been listening in very intently on the list and have been very
intrigued by many of the comments that have been made particularly
concerning interoperation between heterogeneous P2P Overlays.  I read
the document draft-shi-p2psip-hier-arch-00.txt with great interest and
would like to comment on a statement made therein saying: 
 
"A peer in one P2P overlay (such as Chord) is difficult to route the SIP
message to another P2P overlay (such as Pastry) based on their
individual P2P peer locating service"

I can understand the difficulty as mentioned.  I have come up with an
idea that could (hopefully) ameliorate these difficulties.  I propose a
node architecture for a P2PSIP UA within the context of using DHTs as
the basis of a location service, with an added abstraction layer built
in to the UA to hide the differences in the DHT APIs.  This abstraction
layer consists of a layer of DHT plug-ins for different DHT algorithms.
These plug-ins will allow "pluggability" of different DHTs in
participating overlay nodes. This design will allow all P2PSIP nodes to
use a common {get, put, remove} API which is then translated by the
particular plug-in in use at that time.  This would eliminate the need
for a gateway node (since all nodes can do translation between DHTs) and
is more kosher in strictest p2p sense.

I have begun using OpenChord and Bamboo (Java DHT implementations) to
test out my plugin theory.

Mos

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060825/c1ab282b/attachment.html

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Fri, 25 Aug 2006 09:37:27 -0700

Mosiuoa,

Would you have any plan to tackle interconnection between DHTs of asymmetric
geometry (eg., Chord, Bamboo) and those of symmetirc geometry (eg.,
Kademlia)?

I'm curious of that, because neighbors within a desired distance to a node
in Chord can be far-away "ET" to a node in Kademlia, and vice versa.

Unless *GET results* will carry DHT type tag so that one DHT may choose NOT
to store results reported by foreign DHTs in its finger/bucket table,
results from one DHT can be useless or even contaminating to another DHT.

When foreign results are not stored locally, the interconnection seems no
more p2p (between DHTs); it still needs gateways. In that case, hierarchical
or meshy p2p-sip interconnection seems matterless.

Not sure validity of my curiosity, though. If it's invalid, please correct
or ignore it. Thanks a lot.

Peter
----- Original Message -----
From: Mosiuoa Tsietsi
To: p2p-sip at cs.columbia.edu
Sent: Friday, August 25, 2006 7:21 AM
Subject: [p2p-sip] Interoperation Between Heterogenous P2P Overlay Networks

Hi all,

layer of DHT plug-ins for different DHT algorithms.  These plug-ins will all
ow "pluggability" of different DHTs in participating overlay nodes. This

Mos

_______________________________________________
p2p-sip mailing list
p2p-sip at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Fri, 25 Aug 2006 09:48:33 -0700

Some clarification. By "GET results" below I meant the results from a "find
node" or the side effects from failure of a "find value" operation, not the
node value itself. The results are normally tuples of (node id, node
address).

Peter
----- Original Message -----
From: "Peter Pan" <huang-ming.pan at comcast.net>
To: "Mosiuoa Tsietsi" <g06t6632 at campus.ru.ac.za>; <p2p-sip at cs.columbia.edu>
Sent: Friday, August 25, 2006 9:37 AM
Subject: Re: [p2p-sip] Interoperation Between Heterogenous P2P
OverlayNetworks

Networks
> layer of DHT plug-ins for different DHT algorithms.  These plug-ins will
all

---

From: bryan at ethernot.org (David A. Bryan)
Date: Fri, 25 Aug 2006 13:01:04 -0400

I would be interested to hear more as well. There has been a good bit
of discussion of the practicality of using a generic API (I know
Henning and his students have been working on some of this) vs. using
different commands that are optimized for a particular DHT, and
allowing different optimized versions. The results of your experiments
(particularly if they are extended to several other DHTs), and
information on how message count and latency are altered using a
common vs. a proprietary would be interesting. Thanks!

David

On 8/25/06, Mosiuoa Tsietsi <g06t6632 at campus.ru.ac.za> wrote:
> document draft-shi-p2psip-hier-arch-00.txt with great
> interest and would like to comment on a statement made therein saying:
>

---

From: jwshi at bupt.edu.cn (Juwei Shi)
Date: Sat, 26 Aug 2006 01:12:20 +0800

Hi, Mos

I can't understand your plug-in theory clearly. Although the common API can
be provided by your architecture, the underlying lookup protocols still
differ. If every node has all kinds of overlays, it must join all overlays.
That is to say, all nodes can do translation between DHTs means every node
should join all DHTs. Then the DHT operation message overhead will be
significantly increased and I personally don't think it is a practical way
for heterogeneous overlay interwroking. Furthermore, if every node runs all
kinds of DHTs, there's no need of interworking. 

Do I comprehend your idea correctly? Can you give us an session initial
example between Bob in Chord and Alice in Pastry?

Thanks

Juwei

  _____  

Hi all,

Mos

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060825/7519f1fb/attachment.html

---

From: g06t6632 at campus.ru.ac.za (Mosiuoa Tsietsi)
Date: Sun, 27 Aug 2006 01:04:24 +0200

Henry,

Firstly, thanks for the interest!
I have already done most of the work with OpenChord.  I am currently
knee-deep in the Bamboo side of things.  I hope to have something
working early next month and would be happy to share my results and
experiences with the group.

Cheers. 
On Fri, 2006-08-25 at 08:27 -0700, Henry Sinnreich wrote:
> ______________________________________________________________________
> From:p2p-sip-bounces at cs.columbia.edu
> I have been listening in very intently on the list and have been very intrigued by many of the comments that have been made particularly concerning interoperation between heterogeneous P2P Overlays.  I read the document draft-shi-p2psip-hier-arch-00.txt with great interest and would like to comment on a statement made therein saying: 
>  
> ?A peer in one P2P overlay (such as Chord) is difficult to route the SIP message to another P2P overlay (such as Pastry) based on their individual P2P peer locating service?
> 
>  
> 
> idea that could (hopefully) ameliorate these difficulties.  I propose
> a node architecture for a P2PSIP UA within the context of using DHTs
> as the basis of a location service, with an added abstraction layer
> built in to the UA to hide the differences in the DHT APIs.  This
> abstraction layer consists of a layer of DHT plug-ins for different
> DHT algorithms.  These plug-ins will allow ?pluggability? of different
> DHTs in participating overlay nodes. This design will allow all P2PSIP
> nodes to use a common {get, put, remove} API which is then translated
> by the particular plug-in in use at that time.  This would eliminate
> the need for a gateway node (since all nodes can do translation
> between DHTs) and is more kosher in strictest p2p sense.
> 
>  
>

---

From: g06t6632 at campus.ru.ac.za (Mosiuoa Tsietsi)
Date: Sun, 27 Aug 2006 02:39:49 +0200

Peter,

Thanks so much for your comments,  mine inline [Mos]:
> geometry (eg., Chord, Bamboo) and those of symmetirc geometry (eg.,
[Mos]: Here I am limited by algorithms that have been implemented in
software.  I have found that there is more stuff in Java along the lines
of DHTs that C/C++ (though I did fiddle with sipdht, which is C).  I
settled for Java and therefore, therefore for proof of concept, have
decided to use OpenChord (based on Chord,naturally) and Bamboo (loosely
based on Pastry) as it appears (as far as I can see) they are the most
prominent Java based DHTs.
> results from one DHT can be useless or even contaminating to another DHT.
[Mos]: Sorry, not 100% sure I fully understand the question.  Yes, much like D Bryan 
et al proposed using DHT-type tags in their draft "draft-bryan-sipping-p2p-02"
the p2p messages will contain DHT-type and overlay ID parameters.  A
peer in one DHT will not have fingers pointing to peers in another, but
one DHT may store resource bindings (i.e. name to address bindings of
some peers in the other overlay) of another.
> or meshy p2p-sip interconnection seems matterless.
[Mos]: Yes, if we do not store foreign results, I think an explicit gateway is necessary.
> or ignore it. Thanks a lot.
[Mos]: Hope that answers some of your questions.  Please let me know if you are unclear on what I've said.

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Fri, 25 Aug 2006 19:11:36 -0700

Mosiuoa, your research work must be very interesting and challenging.

Storing resource bindings but not foreign finger tables is good idea to
insulate a DHT from specific intrinsics of another. Just a lookup procedure
has to start all over when a node finds a cached resource binding of a
foreign node to be stale, at that time a gateway seems still needed to
deliver the GET service across DHT boundary (because no *foreign fingers*
are available). Am I correct?

Peter
----- Original Message -----
From: "Mosiuoa Tsietsi" <g06t6632 at campus.ru.ac.za>
To: "Peter Pan" <huang-ming.pan at comcast.net>
Cc: <p2p-sip at cs.columbia.edu>
Sent: Saturday, August 26, 2006 5:39 PM
Subject: Re: [p2p-sip] Interoperation Between Heterogenous P2P
OverlayNetworks

Networks
> > concerning interoperation between heterogeneous P2P Overlays.  I read
the
> > message to another P2P overlay (such as Pastry) based on their
individual
> > I can understand the difficulty as mentioned.  I have come up with an
idea
all
> > I have begun using OpenChord and Bamboo (Java DHT implementations) to
test

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Sun, 27 Aug 2006 08:02:27 -0700

Mos,

>I am currently knee-deep in the Bamboo side of things.

This seems to be the most promising exploration worth sharing with the
P2P SIP folks. Bamboo is in my understanding the only (or foremost) DHT
that defines peer neighbors in terms of delay.

This alone should make Bamboo the preferred DHT for VoIP.

Besides, the http://opendht.org/ is already an available network
_service_ and its commercialization would relieve us from having to
plant our own bootstrap servers.

What do you think?

Thanks, Henry 

-----Original Message-----
From: Mosiuoa Tsietsi [mailto:g06t6632 at campus.ru.ac.za] 
Sent: Saturday, August 26, 2006 6:04 PM
To: Henry Sinnreich
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Interoperation Between Heterogenous P2P
OverlayNetworks

Henry,

Cheers. 
intrigued by many of the comments that have been made particularly
concerning interoperation between heterogeneous P2P Overlays.  I read
the document draft-shi-p2psip-hier-arch-00.txt with great interest and
would like to comment on a statement made therein saying: 
>  
> "A peer in one P2P overlay (such as Chord) is difficult to route the
SIP message to another P2P overlay (such as Pastry) based on their
individual P2P peer locating service"
> DHT algorithms.  These plug-ins will allow "pluggability" of different

---

From: adamfisk at gmail.com (Adam Fisk)
Date: Sun, 27 Aug 2006 15:13:01 -0500

I have been using Open DHT for over a year now, and my experience with it
has been adequate but not great.  The basic problem is that Planet Lab has a
fair number of stale nodes so connections often fail.  Also, for any
significant sized deployment, it just wouldn?t scale because you need more
nodes participating.

I think Bamboo is a good option.  l actually think a better option is the
mojito dht nearing completion over at LimeWire, however.  It?s a separate,
pure DHT module.  I?ve worked with many of the coders, and they really know
what they?re doing.  In my experience with the Bamboo *code*, it?s written
by people more specialized in academic algorithm research and less in
software engineering.  That?s not to say it doesn?t work or anything against
them at all (I don?t truly know if it would work on a large scale), but it?s
not the easiest code to play with.

The LimeWire guys also have the advantage of being able to instantly test
their DHT on a network with millions of nodes.  That alone will make Mojito
the DHT of choice in the near future.  It?s a modified version of Kademlia.
Azureus is also a candidate, but I?ve heard bad things about the code.
Check out mojito:

https://www.limewire.org/fisheye/browse/limecvs/mojito

-Adam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060827/796d8dcc/attachment.html

---

From: br at brianrosen.net (Brian Rosen)
Date: Mon, 28 Aug 2006 13:44:10 -0400

This touches on a very important issue.

The charter is going to say, I believe, that the working group will agree on
a single "must implement" DHT, while allowing others.  That word "agree" is
the one I'm commenting on.  

In Montreal, there was a feeling that we WOULD be able to agree on the one,
"must implement" DHT.  We are not, and should not, making that choice now.
We are however, agreeing we WILL make a choice.

Does that feel right to the larger group?

Brian

________________________________________
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Adam Fisk
Sent: Sunday, August 27, 2006 4:13 PM
To: Henry Sinnreich
Cc: p2p-sip at cs.columbia.edu; Mosiuoa Tsietsi
Subject: Re: [p2p-sip] Interoperation Between Heterogenous
P2POverlayNetworks

I have been using Open DHT for over a year now, and my experience with it
has been adequate but not great.? The basic problem is that Planet?Lab has a
fair number of stale nodes so connections often fail.? Also, for any
significant sized deployment, it just wouldn?t scale because you need more
nodes participating. 
?
I think Bamboo is a good option.? l actually think a better option is the
mojito dht nearing completion over at LimeWire, however.? It?s a separate,
pure DHT module.? I?ve worked with many of the coders, and they really know
what they?re doing.? In my experience with the Bamboo *code*, it?s written
by people more specialized in academic algorithm research and less in
software engineering.? That?s not to say it doesn?t work or anything against
them at all (I don?t truly know if it would work on a large scale), but it?s
not the easiest code to play with. 
?
The LimeWire guys also have the advantage of being able to instantly test
their DHT on a network with millions of nodes.? That alone will make Mojito
the DHT of choice in the near future.? It?s a modified version of Kademlia.?
Azureus is also a candidate, but I?ve heard bad things about the?code.?
Check out mojito: 
?
https://www.limewire.org/fisheye/browse/limecvs/mojito
?
-Adam

?

What do you think?

Thanks, Henry

-----Original Message-----
From: Mosiuoa Tsietsi [mailto:g06t6632 at campus.ru.ac.za]
Sent: Saturday, August 26, 2006 6:04 PM
To: Henry Sinnreich
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Interoperation Between Heterogenous P2P
OverlayNetworks

Henry,

Firstly, thanks for the interest!
I have already done most of the work with OpenChord.??I am currently 
knee-deep in the Bamboo side of things.??I hope to have something
working early next month and would be happy to share my results and
experiences with the group.

Cheers.
intrigued by many of the comments that have been made particularly
concerning interoperation between heterogeneous P2P Overlays.??I read 
the document draft-shi-p2psip-hier-arch-00.txt with great interest and
>
>
>
> I can understand the difficulty as mentioned.??I have come up with an
> idea that could (hopefully) ameliorate these difficulties.??I propose
> built in to the UA to hide the differences in the DHT APIs.??This
> DHT algorithms.??These plug-ins will allow "pluggability" of different 
> by the particular plug-in in use at that time.??This would eliminate 
> Have I misunderstood the problem and oversimplified it???Comments much
> appreciated.
>
>
>
> Mos
>
>
>
>
>
>

---

From: bryan at ethernot.org (David A. Bryan)
Date: Mon, 28 Aug 2006 14:54:10 -0400

That was my understanding of how the ad-hoc went as well.

David

On 8/28/06, Brian Rosen <br at brianrosen.net> wrote:
> has been adequate but not great. The basic problem is that PlanetLab has a
> Azureus is also a candidate, but I?ve heard bad things about thecode.
> Check out mojito:
>
> I have already done most of the work with OpenChord.I am currently
> knee-deep in the Bamboo side of things.I hope to have something
> concerning interoperation between heterogeneous P2P Overlays.I read
> > I can understand the difficulty as mentioned.I have come up with an
> > idea that could (hopefully) ameliorate these difficulties.I propose
> > built in to the UA to hide the differences in the DHT APIs.This
> > DHT algorithms.These plug-ins will allow "pluggability" of different
> > by the particular plug-in in use at that time.This would eliminate
> > Have I misunderstood the problem and oversimplified it?Comments much
> > appreciated.
> >
> >
> >
> > Mos
> >
> >
> >
> >
> >
> >

---

From: enrico.marocco at telecomitalia.it (Marocco Enrico)
Date: Tue, 29 Aug 2006 13:21:48 +0200

> Does that feel right to the larger group?

I'm quite sure the group has already agreed on that, at least at IETF66.

--
Enrico
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster at telecomitalia.it.

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------