[chord] Chord and SIP

Wed Jan 26 11:45:16 EST 2005

Mike,

Thanks for your reply.  See my comments below.

Thanks,
Alan Johnston
sip:alan at sipstation.com

> -----Original Message-----
> From: Michael Walfish [mailto:mwalfish at csail.mit.edu] 
> Sent: Tuesday, January 25, 2005 8:25 PM
> To: Johnston, Alan
> Cc: Emil Sit; chord at amsterdam.lcs.mit.edu
> Subject: RE: [chord] Chord and SIP
> 
> 
> Hi Alan,
> 
> You seem to be interested in the possible interactions 
> between SIP and Chord or, more generally, between SIP and 
> distributed hash tables (DHTs). (Chord is a particular DHT 
> design.) If I'm misunderstanding your question, please let me know.
> 

You are correct.

> As you imply in your original note, there seem to be two ways 
> DHTs and SIP can interact, and these two are logically 
> separate but probably exclusive:
> (1) the DHT (assuming its nodes have public IP addresses) can 
> help SIP with the rendezvous function simply because the DHT 
> implements a put-get interface on (key,value) pairs or (2) 
> SIP can help the DHT nodes (which might be firewalled or 
> NATed) establish point-to-point connections with each other.
> 
> If the DHT is being run as a service (like OpenDHT, which is 
> something you should check out if you've not yet heard of it; 
> http://www.openhash.org), then the DHT could help with (1). 
> If the DHT is running on end-users' desktops to do file 
> sharing or telephony (e.g., the Kademlia DHT, which is inside 
> Overnet), then SIP might help the DHT nodes communicate 
> without the DHT software having to implement 
> firewall-punching logic, which logic has been implemented in 
> several peer-to-peer apps, skype being a notable example, as 
> you mention. A paper by Paul Francis at SIGCOMM's Network 
> Architecture workshop argues that SIP would be useful for 
> exactly this purpose. The paper is:
> 
> www.cs.cornell.edu/People/francis/nutss-fdna.pdf 
> 

Thanks for the pointer - I hadn't seen this paper - looks interesting.

> Also (and this is probably off-topic; sorry) some in the HIP 
> community have suggested that SIP could could be useful for 
> HIP or vice-versa. If you're curious about this, please let me know.
> 

Yes, HIP is on my list of things to get to know better - I may take you
up on this offer at a later date.

> -Mike
> 
> | Date: Wed, 26 Jan 2005 01:47:18 +0000
> | From: "Johnston, Alan" <alan.johnston at mci.com>
> | To: Emil Sit <sit at mit.edu>
> | Cc: chord at amsterdam.lcs.mit.edu
> | Subject: RE: [chord] Chord and SIP
> | 
> | Hi Emil,
> | 
> | Thanks for your reply.  I'm reading up on Twine - it looks 
> | interesting. It seems CFS might also be useful to SIP as a lookup 
> | mechanism for rendezvous.
> | 
> | SIP is an application layer protocol used to establish, modify, and 
> | terminate media sessions over the Internet.  It has some built in 
> | rendezvous capabilities that allow devices with dynamic IP 
> addresses 
> | or that change their point of attachment to the Internet to be 
> | reachable using a SIP URI.
> | 
> | I'm interested in finding out about the Chord protocol "on 
> the wire" 
> | between peers over the Internet.  The documentation I've 
> read so far 
> | says that it uses sends RPCs over UDP using ephemeral ports.  Are 
> | there any plans to use TLS as a transport?  Use of certificates for 
> | peer authentication?
> | 
> | Transporting Chord over SIP would allow the use of some of SIP's 
> | security and authentication mechanisms (such as TLS, 
> S/MIME, etc.) but 
> | I'm still not sure that it is a good justification.
> | 
> | Thanks for all your help.
> | 
> | Thanks,
> | Alan Johnston
> | sip:alan at sipstation.com
> | 
> | > -----Original Message-----
> | > From: Emil Sit [mailto:sit at MIT.EDU]
> | > Sent: Tuesday, January 25, 2005 11:02 AM
> | > To: Johnston, Alan
> | > Cc: chord at amsterdam.lcs.mit.edu
> | > Subject: Re: [chord] Chord and SIP
> | > 
> | > 
> | > Alan,
> | > 
> | > On Tue, 25 January 2005 at 13:34 (+0000), Johnston, Alan wrote:
> | > > opinion with others looking into P2P.  I had assumed that SIP 
> | > > could
> | > > utilize the Chord protocol for discovery (use a SIP URI 
> as a search 
> | > > key and get back the IP address of the node that has 
> the current 
> | > > address of that URI) then run as normally.  However, others are 
> | > > proposing that the Chord DHT algorithm be run *over* 
> SIP.  That is, 
> | > > messages between peers used to establish, modify, and 
> query peers 
> | > > would be carried over SIP messages.
> | > 
> | > I don't think any of us are very familiar with SIP and its
> | > capabilities.
> | > 
> | > Chord provides a mechanism for providing rendezvous services
> | > efficiently. If you needed, you could use Twine [1] for 
> | > service discovery.  Or you could build your own service to 
> | > layer on top of Chord so that you can provide the kinds of 
> | > performance and data availability that your application requires.
> | > 
> | > Whether Chord is run separately (for example, using our
> | > implementation) or over SIP seems orthogonal to how it is 
> | > used by an application. I imagine there would be some loss of 
> | > efficiency in running the Chord protocols over SIP, depending 
> | > on how things are encoded.
> | > 
> | > [1] http://nms.lcs.mit.edu/projects/twine/
> | > 
> | > --
> | > Emil Sit / MIT CSAIL PDOS / http://pdos.lcs.mit.edu/chord/  
> | > 
> | 
> | _______________________________________________
> | chord mailing list
> | chord at amsterdam.lcs.mit.edu 
> | https://amsterdam.lcs.mit.edu/mailman/listinfo/chord
> | 
> 
> 