Location aware CHORD

1. Location aware CHORD Ashwin, Vivek, Manu CS-7460 Project Presentation

2. Motivation • Current P2P systems like CHORD – NOT location aware. • Nodes closer in ID space might not be close in physical space • Latency between nodes not considered in NODE_ID assignment • Hence, extra latency incurred in accessing close by objects (close by in ID space) .

3. Lookup(14) Worse case CHORD Lookup 6 14 1 11 13 20 4

4. Lookup(14) Worse case CHORD Lookup 6 14 1 2 11 13 20 4

5. Lookup(14) Worse case CHORD Lookup 6 14 1 3 2 11 13 20 4

6. Motivation(2) • Mapping physically close nodes to be logically close allows for shorter hops • Hence the need for considering location awareness while assigning NODE_IDs

7. Solution • Our proposed solution involves finding the physical proximity between nodes and using this to map the nodes with Node ID’s • Assign some nodes as ‘landmark’ nodes • Ideally they should be spread evenly over of the entire physical space • Precision depends on the number of landmark nodes

8. Solution(2) • For each node, latencies to all landmark nodes are first obtained and these (or a scaled version of these) form the co-ordinate vector • The approximate distance between two nodes can now be estimated with their co-ordinate vectors • The latencies need to be recorded only during start-up and can be periodically updated • Optimal for systems where the data size is small. e.g. CFS

9. Mapping Co-ordinates • Our trivial solution converts the co-ordinate vector into Node ID’s by scaling each latency value down into a small number of levels • Alternatively physical coordinate estimates from approaches such as GNP can be converted into Node ID’s using a similar method

10. Pros and Cons + Node ID’s now approximately reflect the underlying physical topology + Physically close nodes now have close logical ID’s and vice-versa + Chord look-up algorithm remains the same + The upper-bound on look-up latency remains the same (O( log N)) - Fault-tolerance can be compromised in case of correlated failures • Work around is to store replicas at Node IDs separated evenly across the node space

11. Evaluation • Wrote our own simulator (1000 lines of C code) to simulate average look-up latencies for Chord and Location-aware Chord • 1000 node system and 10 Landmark nodes with approx. half the nodes being alive • 100 different keys inserted into the system and consequently 100 look-ups are made

12. Chord vs LA_Chord Red – CHORD Blue – Location aware CHORD

13. Effect of Number of Landmarks

14. Results • Avg. lookup latency improvement of 29.31% • Occasional blips due to conflicts in Node ID’s • Does not take into account the retrieval latency which could also potentially improve

15. Future Work • Study improvements in retrieval latency • Quantify overhead of co-ordinate computation • Quantify the effect of the number of landmarks used • Study alternative coordinate mapping techniques