Subject: [p2p-sip] Interoperation Between HeterogenousP2P OverlayNetworks

From: ksankar at cisco.com (Krishna Sankar (ksankar))
Date: Sat, 26 Aug 2006 10:58:03 -0700

1.	Agreed, pluggability will make it easier to change and/or
experiment with different algorithms. Good abstraction.
2.	Like Seaward pointed out, one issue is the different
characteristics of the underlying algorithms. The question is, will we
be able to abstract such that the interfaces will work comfortably
across all algorithms ?
3.	Yep, we would need a translation/transformation interface to
"interoperate just-in-time" between different mechanisms
4.	Yep, proxy is an optimization, than a fundamental architecture
artifact.
5.	Good work and keep the discussions going (and implementations!).

Cheers
<k/>

> -----Original Message-----
> From: Mosiuoa Tsietsi [mailto:g06t6632 at campus.ru.ac.za] 
> Sent: Saturday, August 26, 2006 8:43 PM
> To: Seaward Hu
> Cc: Krishna Sankar (ksankar); 'Juwei Shi'; p2p-sip at cs.columbia.edu
> Subject: RE: [p2p-sip] Interoperation Between HeterogenousP2P 
> OverlayNetworks
> 
> 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
> > > 
> > 
> > 
> > 
>