Subject: [p2p-sip] Interoperation Between HeterogenousP2P OverlayNetworks

From: g06t6632 at campus.ru.ac.za (Mosiuoa Tsietsi)
Date: Wed, 06 Sep 2006 22:37:02 +0200

Hi Juwei,

Some more thoughts...
I think that the main issue lies in whether or not we will allow lookups
to be done in foreign DHTs when that peer does not belong to that DHT.
I'm guessing maybe you believe they should.  I think interoperation can
be simplified by allowing foreign nodes to use the look-up semantics of
the foreign DHT (via the use of plug-ins - note that the plug-in the
node is using does not have to be the same one being used for local
lookups) to access bindings needed for session establishment.  This can
be a "guest function".  As such, nodes can use a local plug-in to
participate in thei local DHT (get,put,remove) and temporarily use
another plug-in to simply do gets from there.  Below is a quote from the
freepastry.org website commenting on interoperation between freepastry
and simpastry:

"Two implementations of Pastry are currently available for download:
FreePastry from Rice University and  SimPastry/VisPastry from Microsoft
Research. The initial releases of both implementations support a
semantically similar API. A joint, language independent API for Pastry
is currently being defined and will be supported by future releases of
both implementations."

This leads me to believe that if the semantics are similar,
interoperation is possible.  Please let me know what you (and all else!)
think.

Regards,
Mos

On Mon, 2006-08-28 at 14:12 +0800, Juwei Shi wrote:
> 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,
> 
> 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 
> On Sat, 2006-08-26 at 10:42 +0800, Seaward Hu wrote:
> >      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-----
> > > From: p2p-sip-bounces at cs.columbia.edu 
> > > [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
> > > 
> > > >	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
> > > 
> > > 	 
> > > 
> > > 	 
> > > 
> > > _______________________________________________
> > > p2p-sip mailing list
> > > p2p-sip at cs.columbia.edu
> > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
> > > 
> > 
> > 
> > 
> 
> 
-- 
The Law of Unintended Consequences:  for every action, there is an
excellent chance of producing an opposite and totally disproportionate
reaction. - Clyde Haberman