Subject: [p2p-sip] Interoperation Between Heterogenous P2P OverlayNetworks

From: ksankar at cisco.com (Krishna Sankar (ksankar))
Date: Fri, 25 Aug 2006 10:29:50 -0700

>	I can't understand your plug-in theory clearly. Although the
common API can be provided by your architecture, the 
<KS>

Yep, same here.
 
There are two distinct layers, the interface layer and the protocol
layer. The interface layer can be abstracted by a plug-in architecture,
thus making a system independent from programming changes. But if the
underlying protocol machines, state machines, information model and wire
formats are different, we will not be able to achieve interoperability
and will result in what Juwei has described.

The JMS (Java Messaging Service) world has parallels - the JMS API is
standard, so that we can use JMS either with JMS providers or with
products like Tibco, MQ et al. The programming does not change. But none
of them are interoperable; which means we cannot send a JMS message
through an IBM JMS implementation and expect BEA JMS to understand it.
This is because, the wire format and the protocols are not standardized.

That said, am interested in how Mos's idea works out. From the
beginning, this was one of my wishes - a substrate agnostic, transport
independent and orthogonally extensible P2P-SIP. But am not sure it can
be achieved ... 

</KS>

________________________________

	From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Juwei Shi
	Sent: Friday, August 25, 2006 10:12 AM
	To: 'Mosiuoa Tsietsi'; p2p-sip at cs.columbia.edu
	Subject: Re: [p2p-sip] Interoperation Between Heterogenous P2P
OverlayNetworks

	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,

	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

---

From: hu.xinyu at huawei.com (Seaward Hu)
Date: Sat, 26 Aug 2006 10:42:00 +0800

I agree with Krishna, let me show a example.
      We know that the Window OS can support many companies' CPU, but after
you install it in your computer with Pentium CPU, you can not simply move
the hard disk to another computer with AMD CPU and boot it successfully, for
the two kinds of CPU have different instruction set. To interwork between
the two computers, we need other protocols such as FTP, HTTP and SIP.
     So I mean not every node can bear the burden of supporting many kinds
of DHT protocol, for the efficient reason, the protocol for interworking
over different overlay is needed. And those strong nodes which equipped with
two kinds or more stack will become the GW.
      I don't know if I misunderstand Mos's idea, comments are appreciated.

Thanks.

Seaward 

> -----Original Message-----
> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Krishna 
> Sankar (ksankar)
> Sent: Saturday, August 26, 2006 1:30 AM
> To: Juwei Shi; Mosiuoa Tsietsi; p2p-sip at cs.columbia.edu
> Subject: Re: [p2p-sip] Interoperation Between Heterogenous 
> P2P OverlayNetworks
> 
> common API can be provided by your architecture, the <KS>
> 
> Yep, same here.
>  
> There are two distinct layers, the interface layer and the 
> protocol layer. The interface layer can be abstracted by a 
> plug-in architecture, thus making a system independent from 
> programming changes. But if the underlying protocol machines, 
> state machines, information model and wire formats are 
> different, we will not be able to achieve interoperability 
> The JMS (Java Messaging Service) world has parallels - the 
> JMS API is standard, so that we can use JMS either with JMS 
> providers or with products like Tibco, MQ et al. The 
> programming does not change. But none of them are 
> interoperable; which means we cannot send a JMS message 
> That said, am interested in how Mos's idea works out. From 
> the beginning, this was one of my wishes - a substrate 
> agnostic, transport independent and orthogonally extensible 
> P2P-SIP. But am not sure it can be achieved ... 
> 
> </KS>
> 
> 
> 	Subject: Re: [p2p-sip] Interoperation Between 
> Heterogenous P2P OverlayNetworks
> 	
> 	
> 
> 	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
> 
> 	 
> 
> 	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 
> 	"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.
> 
> 	 
> 
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>

---

From: g06t6632 at campus.ru.ac.za (Mosiuoa Tsietsi)
Date: Sun, 27 Aug 2006 05:42:41 +0200

Hi folks,

Thanks for the probing questions, they really make me think more
carefully about my idea, which is for all intents and purposes, work in
progress.  Firstly, interoperation aside, pluggability of algorithms is
useful to overlays because it doesn't commit them to one way of doing
things.  I don't think anyone is willing to stick out his/her head and
say Chord is best or Pastry is best for P2P SIP (neither am I saying
DHTs are the best p2p protocol, oops!).  An overlay can choose to
"switch" to another routing algorithm for experimental purposes and we
can examine differences in latency etc.

Now for the contentious issue, interoperation.  Say for sake of
arguement bob at chord.co.za wants to initiate a call with
alice at pastry.co.za.  Bob notices that the RHS of Alice's AOR is not
chord.co.za (not part of the local overlay).  So what next?  The idea is
still taking form in my mind, but if we are allowing storage of foreign
resource bindings in the local overlay, essentially, only one binding
for a given overlay may be enough since the P2PSIP proxy is flattened
across the foreign overlay and every peer is savvy enough to translate.

I could be wrong about this.  I did initially think of using a proxy (it
is the natural choice) but thought it would simply be an optimization to
the base case.  It may actually be the way to go since I also wanted to
explore interoperation with canonical SIP and that will definately need
gateways (for interest sake, I was thinking along the lines of
CoDoNS/Beehive and DNS-DHT translators..).

At any rate, I'm glad I got my idea out there.  The input is great!

Mos

---

From: jwshi at bupt.edu.cn (Juwei Shi)
Date: Mon, 28 Aug 2006 14:12:01 +0800

Hi, Mosiuoa

The idea only storing resource bindings is very interesting and I think that proxy nodes are still needed. The difference between our scheme and your scheme is that: we implement the inter-overlay operation via a higher level overlay and you implement that via only inter-domain resource operation/register. Does every overlay need to register to any other overlays as the resource? The efficiency, reliability, scalability and message overhead need to be evaluated by your future experiment. 

Thanks
Juwei

__________________________________________________

Hi folks,

Mos

---

From: hu.xinyu at huawei.com (Seaward Hu)
Date: Mon, 28 Aug 2006 20:14:45 +0800

Hi Mosiuoa
      Yes,  an overlay can choose to "switch" to another routing algorithm
for experimental purposes, however, it will cause the overlay out of work
temporarily, and this accident should be avoided in  a commercial
deployment, do you agree this?
     And the total number of different overlays will affect the efficiency
of the operation scheme of the inter overlay greatly, can you tell us more
details about your experiment ?

Thanks.
Seaward 

> Hi, Mosiuoa
> 
> The idea only storing resource bindings is very interesting 
> and I think that proxy nodes are still needed. The difference 
> between our scheme and your scheme is that: we implement the 
> inter-overlay operation via a higher level overlay and you 
> implement that via only inter-domain resource 
> operation/register. Does every overlay need to register to 
> any other overlays as the resource? The efficiency, 
> reliability, scalability and message overhead need to be 
> evaluated by your future experiment. 
> 
> Thanks
> Juwei
> 
> Thanks for the probing questions, they really make me think 
> more carefully about my idea, which is for all intents and 
> purposes, work in progress.  Firstly, interoperation aside, 
> pluggability of algorithms is useful to overlays because it 
> doesn't commit them to one way of doing things.  I don't 
> think anyone is willing to stick out his/her head and say 
> Chord is best or Pastry is best for P2P SIP (neither am I 
> saying DHTs are the best p2p protocol, oops!).  An overlay 
> can choose to "switch" to another routing algorithm for 
> experimental purposes and we can examine differences in latency etc.
> 
> Now for the contentious issue, interoperation.  Say for sake 
> of arguement bob at chord.co.za wants to initiate a call with 
> alice at pastry.co.za.  Bob notices that the RHS of Alice's AOR 
> is not chord.co.za (not part of the local overlay).  So what 
> next?  The idea is still taking form in my mind, but if we 
> are allowing storage of foreign resource bindings in the 
> local overlay, essentially, only one binding for a given 
> overlay may be enough since the P2PSIP proxy is flattened 
> I could be wrong about this.  I did initially think of using 
> a proxy (it is the natural choice) but thought it would 
> simply be an optimization to the base case.  It may actually 
> be the way to go since I also wanted to explore 
> interoperation with canonical SIP and that will definately 
> need gateways (for interest sake, I was thinking along the 
> lines of CoDoNS/Beehive and DNS-DHT translators..).
>

---

From: g06t6632 at campus.ru.ac.za (Mosiuoa Tsietsi)
Date: Mon, 28 Aug 2006 14:41:55 +0200

Hi Juwei,

I liked you idea of a higher level overlay facilitating inter-domain
interoperation.  It is actually reminiscent of a paper I read on SIPpeer by
Kundan and Henning where they also use the concept of a global P2P SIP
domain.  To answer your question, my idea is that any given peer can
register in another overlay for a binding, but no special peer is designated
for this purpose.  A single peer represents the entire overlay as peers will
have added registrations under the address overlay at pastry.co.za essentially
flattening the proxy and distributing its operations over the entire
overlay.  Yes reliability, scalability etc factors you mentioned will be
looked into, I will be thinking very hard about hoe the design can affect
all these.

Thanks for the interest.
Mos

-----Original Message-----
From: Juwei Shi [mailto:jwshi at bupt.edu.cn] 
Sent: 28 August 2006 08:12
To: 'Mosiuoa Tsietsi'; 'Seaward Hu'
Cc: 'Krishna Sankar (ksankar)'; p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Interoperation Between HeterogenousP2P
OverlayNetworks

Hi, Mosiuoa

The idea only storing resource bindings is very interesting and I think that
proxy nodes are still needed. The difference between our scheme and your
scheme is that: we implement the inter-overlay operation via a higher level
overlay and you implement that via only inter-domain resource
operation/register. Does every overlay need to register to any other
overlays as the resource? The efficiency, reliability, scalability and
message overhead need to be evaluated by your future experiment. 

Thanks
Juwei

Hi folks,

Mos

---

From: g06t6632 at campus.ru.ac.za (Mosiuoa Tsietsi)
Date: Mon, 28 Aug 2006 19:55:32 +0200

Hi,

Yes, during a DHT switch, the service will be rendered temporarily
unavailable.  The system will have to restabilize and peers re-initialize
routing tables under the new scheme of things.  In that, you are right.  (It
would be interesting to investigate ways and means to make this process as
quick and efficient as possible.)  I don't imagine that in a commercial
setting, this "rebooting" will occur often.  It can be used when number of
users have increased by factors or geographic distribution has changed
greatly, and we want to see how different DHTs work out.

Help me think here:  The local DHT is represented in other overlays by a
peer in the local overlay which becomes (for all intents and purposes) the
gateway.  This is much like OpenDHT where all servers act as gateways to the
network. Overhead occurs intra-DHT where all peers (or most?) have to
additionally register as overlay at overay.co.za in addition to their
individual registrations.  Externally, overhead should be the same as the
base case (GW) but internally is where the monster lies.

I do wish that I had more to offer the group at this stage in terms of
concrete results.  I am still coding away.  As they do become available, I
would love to share my experiences, and I must admit, questions raised in
this thread have already significantly affected my way forward.  Many
thanks, and keep questions rolling.

-----Original Message-----
From: Seaward Hu [mailto:hu.xinyu at huawei.com] 
Sent: 28 August 2006 14:15
To: 'Juwei Shi'; 'Mosiuoa Tsietsi'
Cc: 'Krishna Sankar (ksankar)'; p2p-sip at cs.columbia.edu
Subject: RE: [p2p-sip] Interoperation Between HeterogenousP2P
OverlayNetworks

Hi Mosiuoa

Thanks.
Seaward