Title: Distributed Object Location in a Dynamic Network
1Distributed Object Location in a Dynamic Network
- Kirsten Hildrum, John D. Kubiatowicz, Satish Rao
and Ben Y. Zhao
2 DOLR(Decentralized Object Location and Routing)
3Requirements
- Deterministic location
- Routing locality routes should have low stretch
- Minimal storage and computational load
- Dynamic membership
4Main Results
System Stretch Storage Node Insertion Metric
PRR, 1997 O(1) O(log n) -- Special
PRR this O(1) O(log n) O(log2 n) Special
Tapestry, 2000 Low in practice O(log n) -- General
Tapestry this Low in practice O(log n) O(log2 n) General
5Additional Results
- Handle deletes
- Simultaneous insertions
- Algorithm with polylog stretch for general
metrics. - Similar to Bourgains use of subsets to embed a
general metric into L2
6Outline
- Background and previous work
- PRR/Tapestry
- Insertion
- Maintaining deterministic location
- Low stretch A nearest neighbor algorithm
- Related Work
- Conclusion
7Neighbor Table
1
NodeID 2245
8Basic Tapestry Mesh(from PRR97)
9Use of Mesh for Object Location
10Surrogate Routing
- Neighbor table will have holes
- Must be able to find unique root for every object
- Our solution try next highest.
- For 2176, try 2177
- For 213? Try 214?
- Need all Ø really are Ø -gt root unique.
11Outline Again
12Insertion
- Build own neighbor table
- Want Closest for each entry (note cannot copy
from nearby node) - Has to add self to other tables
- Fill in holes
- May replace further node
1
13Finding the Closest Node
- Building table means finding nearest neighbor for
each entry. - Our algorithm find nearest level-i node for
every i in process of finding overall nearest - Easily extend to find other entries
14Network Assumption
- Nearest neighbor is hard in general metric
- Assume the following
- Ball of radius 2r contains only a factor of c
more nodes than ball of radius r. - Also, b gt c2
- Both assumed by PRR
- Start knowing one node allow distance queries
15Algorithm Idea
- Call a node a level i node if it matches the new
node in i digits. - The whole network is contained in forest of trees
rooted at highest possible imax. - Let listimax contain the root of all trees.
Then, starting at imax, while i gt 1 - listi-1 getChildren(listi)
- Certainly, listi contains level i neighbors.
16We Reach The Whole Network
NodeID 0xEF34
17The Real Algorithm
- Simplified version ALL nodes in the network.
- But far away nodes are not likely to have close
descendents - ? Trim the list at each step.
- New version while i gt 1
- Listi-1 getChildren(listi)
- Trim(listi-1)
18How to Trim
- Consider circle of radius r with at least one
level i node. - Level-(i-1) node in little circle must must point
to a level-i node in the big circle - Want listi had radius three times listi-1
and listi 1 contains one level i
19Animation
20True in Expectation
- Want listi had radius three times listi-1
and listi 1 contains one level i - Suppose listi-1 has k elements and radius r
- Expect ball of radius 4r to contain kc2/b
- Ball of radius 3r contains less than k nodes, so
keeping k all along is enough. - To work with high probability, k O(log n)
21Steps of Insertion
- Find node with closest matching ID (surrogate)
and get preliminary neighbor table - If surrogates table is hole-free, so is this
one. - Find all nodes that need to put new node in
routing table via multicast - Optimize neighbor table
- w.h.p. contacted nodes in building table only
ones that need to update their own tables - Need
- No fillable holes.
- Keep objects reachable
22Need-to-know nodes
- Need-to-know a node with a hole in neighbor
table filled by new node - If 1234 is new node, and no 123s existed, must
notify 12?? Nodes - Acknowledged multicast to all matching nodes
23Acknowledged Multicast Algorithm
Locates Contacts all nodes with a given prefix
- Create a tree based on IDs as we go
- Nodes send acks when all children reached
- Starting node knows when all nodes reached
The node then sends to any 5430?, any 5431?, any
5434?, etc. if possible
543??
5431?
5434?
54340
54345
24Outline Again
25Related Work
- Many peer-to-peer systems
- Not locality-aware
- Chord Stoica, Morris, Karger, Kaashoek,
Balakrishnan - CAN Ratnasamy, Francis, Handley, Karp, Shenker
- Pastry Rowstron and Druschel
- Polylog stretch, general metric
- Awerbuch and Peleg 1991 (not dynamic)
- Rajaraman, Richa, Vöcking, Vuppuluri 2001
- Constant stretch, special metric
- Plaxton, Rajaraman, Richa 1997 (not dynamic)
- Nearest Neighbor
- Karger and Ruhls 2002
- Thorup and Zwick 2001
- Clarkson 1997
26Future Work
- Getting stretch is low in practical systems
- Transit stub networks
- Network structure inside stub
- Periodic optimization
- Better handling of inserts in presence of
deletes
27Extra/Backup Slides
28Related Work
System Node Insertion Stretch Hops Metric
CAN, 2001 O(r) -- O(rn1/r) General
Chord, 2001 O(log2 n) -- O(log n) General
Pastry, 2001 O(log2 n) -- O(log n) General
Awerbuch Peleg, 1991 -- polylog polylog General
PRR, 1997 -- O(1) O(log n) Special
RRVV, 2001 polylog polylog polylog General
PRR this O(log2 n) O(1) O(log n) Special
Tapestry O(log2 n) Low in practice O(log n) General
29Maintaining Object Availability
- Object requests continue
- New node resends requests for object it does not
have via surrogate - Established node always checks that that it is
final destination. - Sometimes-checking would require state.
- May get cycle for non-existent objects, but can
be detected.
30Body
- Finding the nearest neighbor
- Can query for distance between self and any given
node. - Assume a low expantion property (low dimentional)
- Karger and Ruhl, May 2002.
- Our algorithm not as good for general problem,
but solves our particular problem better - No additional storage needed
- Finds all levels of table
31Picture
32Introduction
- Object Location/DOLR slide
- Related Work table
- Not much done with stretch
- Our results
- Add insertion to PRR/Tapestry
- Deletes
- Parallel inserts
- Solve nearest neighbor problem inprocess
- Similar to Karger and Ruhl
- Result for general metric spaces