[chord] Chord and SIP

[Johnston, Alan]

Hi Emil,

See more comments below.

Thanks,
Alan Johnston
sip:alan at sipstation.com

> -----Original Message-----
> From: Emil Sit [mailto:sit at MIT.EDU] 
> Sent: Tuesday, January 25, 2005 9:13 PM
> To: Johnston, Alan
> Cc: chord at amsterdam.lcs.mit.edu
> Subject: Re: [chord] Chord and SIP
> 
> 
> On Wed, 26 January 2005 at 01:47 (+0000), Johnston, Alan wrote:
> > 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.
> 
> We use sun rpc packets.  The packet formats are specified 
> using XDR and are available at 
>     http://amsterdam.lcs.mit.edu/cgi-bin/cvsweb.cgi/sfsnet/svc/
> You can also refer to RFC 1832 and 1831.
> 

Thanks - this is useful information.

> > Are there any plans to use TLS as a transport?
> 
> I think TLS would be too heavy-weight for the kind of 
> communication patterns that we currently see in Chord/DHash.  
> Our storage layer
> (DHash) stripes data out over many nodes for resilience and 
> to balance storage load across participating nodes evenly.  
> As a result, DHash exchanges traffic with many of the nodes 
> in the overlay in the course of storing and retrieving data.  
> There is no guarantee that once your local node talks to a 
> remote node once, it will need to talk to that same remote 
> node again in the near future.  
> 
> Even in our small deployments, implementations using 
> persistent connections (e.g. TCP) have caused the local node 
> to rapidly use up available socket buffers in the local node's kernel.
> 

Wow - that sounds like a lot of traffic.  In the SIP/Chord papers I've
read, they recommend only communicating with a small number of nodes and
maintaining a small finger table.  This sounds the opposite of your
implementation.  Also, they report very long search latency (perhaps due
to exactly this limitation).  

SIP messages are not small, either - they are often 300 bytes long and
have a number of transaction identifiers that need to be parsed and
stored.  Again, doesn't sound like running all this traffic over SIP is
such a good idea.

However, since UDP does not have any built in congestion control, if you
stay with UDP you will need to implement this at the application layer.

> > Use of certificates for peer authentication?
> 
> Certificates would need to be signed by some sort of central 
> authority.  Some lines of peer-to-peer thinking are not in 
> favor of such authorities. 

Sure - one could build an open P2P network or a closed P2P network.  The
closed network would require some kind of central authority to issue
certs.  There may be applications for both models.

 Some previous work in security 
> has suggested certificate authorities for admission control 
> (e.g. http://www.cs.rice.edu/~druschel/publications/security.pdf),
> but how to securely route packets in structured overlays 
> (such as Chord) is still an open research question.  
> 

Agreed. 

> 
> > 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.
> 
> I'm unsure about tunneling/running Chord over SIP as well.  I 
> wouldn't want to make SIP the next HTTP.

Yes - I've heard it said that 5060 is the new 80 :-) as firewalls open
this port for SIP.  However, these holes will close if arbitrary content
is tunneled over SIP and bad things happen.

> 
> -- 
> Emil Sit / MIT CSAIL PDOS / http://pdos.lcs.mit.edu/chord/  
>