1 / 15

Location aware CHORD

Location aware CHORD. Ashwin, Vivek, Manu. CS-7460 Project Presentation. 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

quang
Télécharger la présentation

Location aware CHORD

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related