[chord] Chord and SIP

[Michael Walfish]

(not copying Alan for now.)

Emil,

I read Alan's message like this: he wants to know whether there are
possible uses of Chord for SIP or vice-versa. (His own question is not
well-defined, though.)

SIP is a protocol that lets two hosts on the Internet, who may be behind
firewalls, negotiate to begin some kind of session (say, a phone
conversation over IP). SIP requires some facility to map from a user's
"SIP URI" (which is the user's identifier in the land of SIP) to a SIP
server, which server then helps with all of the SIP-related rendezvous. I
think that SIP usually depends on DNS for this mapping function, but he is
suggesting using Chord for it.

The other thing he talks about -- running Chord on top of SIP -- would
make sense for a use of Chord in which all of the hosts are behind NATs
and firewalls. In such a situation, SIP's firewall-penetrating abilities
(which can be used to build things like skype- and IETF-style
firewall-punching tricks) would be useful to Chord, he thinks. (Though 
skype doesn't use SIP, but that's not very important; it just means his 
mail was more confusing.)

The reason that the two things he's asking about are not entirely
orthogonal is simply that if there's only "one" Chord, and it's running on
desktops around the Internet, then that Chord couldn't then be used as the
rendezvous service by which those firewalled desktops discover each other
in the first place.

I'm not sure he necessarily knows what question he was asking, but he
seems to be curious whether there are "synergies" (vague business term
intentional) between SIP and structured peer-to-peer overlays, the answer
to which is yes. Perhaps somebody on the list should follow up with him to
point out that (a) if Chord is being run on desktops behind firewalls, it
might need firewall-punching tricks, which tricks could benefit from a SIP
substrate; (b) he's free to download Chord and use it for the SIP
discovery service and (c) Unless he imagines more than one Chord instance
in the world, (a) and (b) are probably exclusive.

Let me know if you want me to write to him.

-Mike


| Date: Tue, 25 Jan 2005 12:02:02 -0500
| From: Emil Sit <sit at mit.edu>
| To: "Johnston, Alan" <alan.johnston at mci.com>
| 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/
| 
|