Chord: A Scalable Peertopeer Lookup Service for Internet Applications

1
Chord A Scalable Peer-to-peer Lookup Service for
Internet Applications

• Ion Stoica, Robert Morris, David Karger,
• M. Frans Kaashoek, Hari Balakrishnan
• Presented by Bo Han for CMSC 818T
• (based on Robert Morriss talk on SIGCOMM 2001)

2
Introduction

• Core operation in peer-to-peer systems is to
  efficiently locate the node that stores a
  particular data item.
• Chord is a scalable distributed protocol for
  lookup in a dynamic peer-to-peer system with
  frequent node arrivals and departures.
• Only one operation given a key, it maps the key
  onto a node.
• Simplicity, provable correctness, and provable
  performance.

3
The lookup problem
N2
N1
N3
Internet
Keytitle ValueMP3 data
?
Client
Publisher
Lookup(title)
N6
N4
N5
4
Centralized lookup (Napster)
N2
N1
SetLoc(title, N4)
N3
Client
DB
N4
Publisher_at_
Lookup(title)
Keytitle ValueMP3 data
N8
N9
N7
N6
Simple, but O(N) states and a single point of
failure
5
Flooded queries (Gnutella)
N2
N1
Lookup(title)
N3
Client
N4
Publisher_at_
Keytitle ValueMP3 data
N6
N8
N7
N9
Robust, but worst case O(N) messages per lookup
6
Routed queries (Freenet, Chord, etc.)
N2
N1
N3
Client
N4
Lookup(title)
Publisher
Keytitle ValueMP3 data
N6
N8
N7
N9
7
Related Work

• Freenet(Clarke, Sandberg, Wiley, Hong)
• CAN (Ratnasamy, Francis, Handley, Karp, Shenker)
• Pastry (Rowstron, Druschel)
• Tapestry (Zhao, Kubiatowicz, Joseph)
• Chord emphasizes simplicity

8
Design Objectives

• Load Balance Distributed hash function spreads
  keys evenly over the nodes (Consistent hashing).
• Decentralization Fully distributed (Robustness).
• Scalability Lookup grows as a log of number of
  nodes.
• Availability Automatically adjusts internal
  tables to reflect changes.
• Flexible Naming No constraints on key structure.

9
Applications

• Lookup(key) algorithm that yields the IP address
  of the node responsible for the key.
• Notify the application of changes in the set of
  keys that the node is responsible for.
• Example applications
• Cooperative Mirroring
• Time-shared storage
• Distributed indexes
• Large-Scale combinatorial search

10
Routing challenges

• Define a useful key nearness metric.
• Keep the hop count small.
• Keep the routing tables small.
• Stay robust despite rapid changes.

11
Chord properties

• Efficient O(log(N)) messages per lookup.
• Scalable O(log(N)) states per node.
• Robust survives massive failures, join or leave.
  O(log2(N)) messages.
• An Nth node joins (or leaves), only an O(1/N)
  keys are moved to a different location.
• Proofs are in paper / tech report.
• (Assuming no malicious participants)

12
Chord overview

• Provides peer-to-peer hash lookup
• Lookup(key) ? IP address.
• Chord does not store the data.
• How does Chord route lookups?
• How does Chord maintain routing tables?
• How does Chord cope with changes in membership?

13
Chord IDs

• m-bit identifier space for both keys and nodes.
• Key identifier SHA-1(key).
• Node identifier SHA-1(IP address).
• Both are uniformly distributed.
• How to map key IDs to node IDs?

14
Consistent hashing Karger 97
Key 5
K5
Node 105
N105
K20
Circular 7-bit ID space
N32
N90
K80
A key is stored at its successor node with next
higher ID
15
Basic lookup
N120
N10
Where is key 80?
N105
N32
N90 has K80
N90
K80
N60
16
Simple lookup algorithm

• Lookup(my-id, key-id)
• n my successor
• if my-id lt n lt key-id
• call Lookup(id) on node n // next hop
• else
• return my successor // done
• Correctness depends only on successors

17
Finger table allows log(N)-time lookups
½
¼
1/8
1/16
1/32
1/64
1/128
N80
Every node knows m other nodes in the ring
18
Finger i points to successor of n2i-1
N120
112
½
¼
1/8
1/16
1/32
1/64
1/128
N80
Each node knows more about portion of circle
close to it
19
Lookup with fingers

• Lookup(my-id, key-id)
• look in local finger table for
• highest node n s.t. my-id lt n lt key-id
• if n exists
• call Lookup(id) on node n // next hop
• else
• return my successor // done

20
Lookups take O(log(N)) hops
N5
N10
N110
K19
N20
N99
N32
Lookup(K19)
N80
N60
21
Joining linked list insert
N25
N36
1. Lookup(36)
K30 K38
N40
1. Each nodes successor is correctly
maintained. 2. For every key k, node successor(k)
is responsible for k.
22
Join (2)
N25
2. N36 sets its own successor pointer
N36
K30 K38
N40
Initialize the new node finger table
23
Join (3)
N25
3. Set N25s successor pointer
N36
K30 K38
N40
Update finger pointers of existing nodes
24
Join (4)
N25
4. Copy keys 26..36 from N40 to N36
N36
K30
N40
K38
Transferring keys
25
Stabilization Protocol

• To handle concurrent node joins/fails/leaves.
• Keep successor pointers up to date, then verify
  and correct finger table entries.
• Incorrect finger pointers may only increase
  latency, but incorrect successor pointers may
  cause lookup failure.
• Nodes periodically run stabilization protocol.
• Wont correct a Chord system that has split into
  multiple disjoint cycles, or a single cycle that
  loops multiple times around the identifier space.

26
Failures might cause incorrect lookup
N120
N10
N113
N102
Lookup(90)
N85
N80
N80 doesnt know correct successor, so incorrect
lookup
27
Solution successor lists

• Each node knows r immediate successors.
• After failure, will know first live successor.
• Correct successors guarantee correct lookups.
• Guarantee is with some probability.
• Can choose r to make probability of lookup
  failure arbitrarily small.

28
Choosing the successor list length

• Assume 1/2 of nodes fail.
• P(successor list all dead) (1/2)r
• I.e. P(this node breaks the Chord ring)
• Depends on independent failure
• P(no broken nodes) (1 (1/2)r)N
• r 2log(N) makes prob. 1 1/N

29
Lookup with fault tolerance

• Lookup(my-id, key-id)
• look in local finger table and successor-list
• for highest node n s.t. my-id lt n lt key-id
• if n exists
• call Lookup(id) on node n // next hop
• if call failed,
• remove n from finger table
• return Lookup(my-id, key-id)
• else return my successor // done

30
Simulation overview

• Quick lookup in large systems.
• Low variation in lookup costs.
• Robust despite massive failure.
• Iterative implementation.
• 10,000 nodes, No. of keys range from 105 to 106.
• Experiments confirm theoretical results

31
No. of Keys per Node
32
Chord lookup cost is O(log N)
Constant is 1/2
33
Failed Lookups/Failed Nodes
34
Failed Lookups as function of Fail/Join Rate
35
Chord Summary

• Chord provides peer-to-peer hash lookup.
• Efficient O(log(n)) messages per lookup.
• Robust as nodes fail and join.
• Good primitive for peer-to-peer systems.
• http//www.pdos.lcs.mit.edu/chord

36
Misc.

• Sound theoretical work (about 1173 citations).
• Has been used in CFS (SOSP 2001) and Ivy (OSDI
  2002)
• Ring Partitions might pose a problem.
• Scalability of Stabilization protocol.
• How often does the stabilization procedure need
  to run?
• How to balance consistence and network overhead?
• Virtualized ID space lacks locality
  characteristics.
• Physical topology of the underlying IP network.