Chord Advanced issues

1. Chord Advanced issues

2. Analysis Search takes O(log(N)) time • Proof 1 (intuition):At each step, distance between query and peer hosting the object reduces by a factor of at least 2 Takes at most m steps: is at most a constant multiplicative factor above N, lookup is O(log(N)) • Proof 2 (intuition):After log(N) forwarding steps, distance to key is at most Number of node identifiers in a range of is O(log(N)) with high probability (why? SHA-1!) So using successors in that range will be ok

3. Analysis (contd.) • O(log(N)) search time is true only if finger and successor entries correct • When might these entries be wrong?

4. Analysis (contd.) • O(log(N)) search time is true only if finger and successor entries correct • When might these entries be wrong? • When you have failures

5. Search under peer failures Lookup for K42 fails (N16 does not know N45) Say m=7 0 N16 N112 X N96 X N32 Who has abcnews.com? (hashes to K42) X N45 N80 File abcnews.com with key K42 stored here

6. Search under peer failures One solution: maintain r multiple successor entries in case of failure, use other successor entries Say m=7 0 N16 N112 N96 X N32 Who has abcnews.com? (hashes to K42) N45 N80 File abcnews.com with key K42 stored here

7. Search under peer failures • Choosing r=2log(N) suffices to maintain correctness with high probability • Say 50% of nodes fail (i.e prob of failure = 1/2) • Pr(for given node, at least one successor alive)= • Pr(above is true for all alive nodes)=

8. Search under peer failures (2) Lookup fails (N45 is dead) Say m=7 0 N16 N112 N96 N32 Who has abcnews.com? (hashes to K42) X X N45 N80 File abcnews.com with key K42 stored here

9. Search under peer failures (2) One solution: replicate file/key at r successors and predecessors Say m=7 0 N16 N112 N96 N32 Who has cnn.com/index.html? (hashes to K42) K42 replicated X N45 N80 File cnn.com/index.html with key K42 stored here K42 replicated

10. Need to deal with dynamic changes • Peers fail • New peers join • Peers leave Need to update successors and fingers, and ensure keys reside in the right places

11. New peers joining Some gateway node directs N40 to N32 N32 updates successor to N40 N40 initializes successor to N45, and obtains fingers from it N40 periodically talks to neighbors to update finger table Say m=7 0 Stabilization protocol N16 N112 N96 N32 N40 N45 N80

12. New peers joining (2) N40 may need to copy some files/keys from N45 (files with fileid between 32 and 40) Say m=7 0 N16 N112 N96 N32 N40 N45 N80 K34,K38

13. Concurrent join 0 N16 N112 N20 Say m=7 N24 N96 N28 N32 K24 N80 N45 K38 Argue that each node will eventually be reachable

14. Stabilization Protocol Concurrent peer joins, leave, or failure might cause the invariant to be violated, causing loopiness (?) or failure of lookups • periodically a stabilization algorithm checks and updates pointers and keys. [TechReport on Chord in the list of readings] defines weak and strong stability • Ensures non-loopiness of fingers, eventual success of lookups and O(log(N)) lookups w.h.p.

15. Effect on lookup If in a stable network with N nodes, another set of N nodes joins, and the join protocol correctly sets their successors, then lookups will take O(log N) steps w.h.p

16. Effect on lookup Consistent hashing guarantees that there be O(log N) new nodes w.h,p between two consecutive nodes 0 N16 N112 N20 Transfer pending N96 N24 Linear Scan Will locate K24 N28 K24 N32 N80 N45 K38

17. Loopy network N1 (succ (pred (u))) = u N3 N96 N5 stable N78 N24 Must be false for strong stability N63 What is funny / awkward about this?  v: u < v < successor (u) (Weakly stable)

18. Weak and Strong Stabilization N1 Loopy network N3 N96 N5 N78 N24 N63 • u (successor (predecessor (u))) = u. Still it is weakly stable but not strongly stable.

19. Strong stabilization • The key idea of the algorithm is:Let each node u ask its • successor to walk around the ring until it reaches a node • v : u <v ≤ successor(u). If • v: u <v < successor(u) then loopiness exists, and reset successor(u):=v Takes O(N2) steps. But loopiness is a rare event. No protocol for recovery exists from a split ring.

20. New peers joining (3) • A new peer affects O(log(N)) other finger entries in the system. So, the number of messages per peer join= O(log(N)*log(N)) • Similar set of operations for dealing with peers leaving

21. Cost of lookup • Cost is O(Log N) as predicted by theory • constant is 1/2 Average Messages per Lookup Number of Nodes

22. Robustness • Simulation results: static scenario • Failed lookup means original node with key failed (no replica of keys) • Result implies good balance of keys among nodes!

23. Strengths • Based on theoretical work (consistent hashing) • Proven performance in many different aspects • “with high probability” proofs • Good tolerance to random node failures

24. Weakness • Member join & leave are complicated • aggressive mechanisms requires too many messages and updates • no analysis of convergence in lazy finger mechanism • Key management mechanism mixed between layers • upper layer does insertion and handle node failures • Chord transfer keys when node joins (no leave mechanism!) • Routing table grows with # of members in group • Worst case lookup can be slow

25. Discussions • Network proximity (can we factor in latency?) • Protocol security • Malicious data insertion • Malicious Chord table information • Keyword search • ...