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. 6 11 13 14 20 4 Lookup(14) Worse case CHORD Lookup 1

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

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

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