CSC 2231 Review of Chord

This paper presents a scalable look up protocol for structured p2p
systems. Its basic idea comes from the consistent hashing that considers
the logic space as a circle. Finger tables are proposed to resolve all
lookups via O(logN) messages.

Compared with flooding, Chord knows more about the locations of the
content, and thus it speeds up the process of look up and greatly reduces
the number of query messages. In detail, it organizes nodes in a
ring structure that builds up a simple mapping between nodes and their
corresponding contents. Chord can deal with nodes arrivals, departures and
normal failures.

One of the cons of Chord comes form its routing latency. As the author
mentioned, the log(N) of routing bound could lead to a quite long routing
latency in Internet if N is large. Although they can increase the length
of finger tables to reduce the routing hops, a larger finger table may
cause high maintenance overhead in case of churn in p2p systems.

Another reason of high routing latency lies in the ignorance of network
proximity in Chord. Nodes are close in the ring could be quite far in
physical network distance, and thus even a small number of routing hops in
Chord may lead to very large network latency in reality. This issue is
addressed in Pastry paper.

In addition, chord may not able to behave well in case of malicious
attacks. Malicious peers could simply return "no found" or route the query
to a wrong location so that the routing fails. This kind of attacks is
hard to avoid especially when there are a group of malicious nodes. From
this view, flooding is more robust since it forwards the request to all of
its known nodes.

In sum, it is a good paper that attempts to build a structured p2p system
to achieve fast look up. Another merit is that it clearly analyzes the
limitation of Chord.
Received on Sun Nov 06 2005 - 18:09:20 EST