SMA Computer Science Seminar
EpiChord: Parallelizing theChord Lookup Algorithm with
Reactive Routing StateManagement
Ben Leong, Barbara Liskov, and Eric D. Demaine
MIT Computer Science and Artificial Intelligence Laboratory
{benleong, liskov, edemaine}@mit.edu
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.1
Structured Peer-to-Peer Systems
Large scale dynamic network
Overlay infrastructure :ScalableSelf configuringFault tolerant
Every node responsible for some objects
Find node having desired object
Challenge: Efficient Routing at Low Cost
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.2
Address Space
N15
N10
N17
N20
N25
N30N35
N40
N47
N49
N51
N57
N62
N0 N6
Most common — one-dimensional circularaddress space
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.3
Mapping Keys to Nodes
N15
N10
N17
N20
N25
N30N35
N40
N47
N49
N51
N57
N62
N0 N6
K13
K2
K47
K32
K52K54
successor of key is its owner
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.4
Distributed Hash Tables (DHTs)
A Distributed Hash Table (DHT) is adistributed data structure that supports aput/get interface.
Store and retrieve {key, value} pairs efficientlyover a network of (generally unreliable) nodes
Keep state stored per node small because ofnetwork churn ⇒ minimize book-keeping &maintenance traffic
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.5
Distributed Hash Tables (DHTs)DHTs trade off (i) routing state and/or (ii)bandwidth for lookup performance:
Routing Table size ranges from O(log n) toO(n)
Lookup Topology (Gummadi et al., 2003) –ring, tree, xor, hypercube, butterflyParallel lookup – Kademlia (xor)(Maymounkov and Mazieres, 2002)
⇒ EpiChord explores the trade-offs in movingfrom sequential lookup to parallel lookup andfrom O(log n) to O(log n) + + state
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.6
Chord
N15
N10
N17
N20
N25
N30N35
N40
N47
N49
N51
N57
N62
N0 N6
Each node periodically probes O(log n)fingers
Achieves O(log n)-hop performanceSMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.7
Recursive Lookup
N15
N10
N17
N20
N25
N30N35
N40
N47
N49
N51
N57
N62
N0 N6
K12
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.8
Recursive Lookup
N15
N10
N17
N20
N25
N30N35
N40
N47
N49
N51
N57
N62
N0 N6
K12
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.9
Recursive Lookup
N15
N10
N17
N20
N25
N30N35
N40
N47
N49
N51
N57
N62
N0 N6
K12
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.10
Recursive Lookup
N15
N10
N17
N20
N25
N30N35
N40
N47
N49
N51
N57
N62
N0 N6
K12
Takes O(log n) hops to get to the destinationnode.
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.11
Iterative Lookup
N15
N10
N17
N20
N25
N30N35
N40
N47
N49
N51
N57
N62
N0 N6
K12
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.12
Iterative Lookup
N15
N10
N17
N20
N25
N30N35
N40
N47
N49
N51
N57
N62
N0 N6
K12
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.13
Iterative Lookup
N15
N10
N17
N20
N25
N30N35
N40
N47
N49
N51
N57
N62
N0 N6
K12
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.14
Iterative Lookup
N15
N10
N17
N20
N25
N30N35
N40
N47
N49
N51
N57
N62
N0 N6
K12
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.15
Summary: Chord
Stores O(log n) state (fingers) at every node⇒ storage is not the problem, probing trafficis limiting factor.
Takes O(log n) hops per lookup ⇒ Okay forsome applications, too slow for others
Non-zero probability that a node may fail inbetween probe ⇒ Node failures detected bytimeout
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.16
Our Goal
We want to do better than O(log n)-hoplookup without adding extra overhead.
Use a combination of techiques:Piggyback information on lookupmessagesAllow cache to store more than O(log n)routing stateIssue parallel queries during lookup
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.17
Outline
Parallel Lookup Algorithm
Reactive Cache Management
Simulation Results
Related Work
Conclusion
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.18
Preliminaries
p: Degree of parallelism – “threads”
l: Number of entries returned per query(l = 3)
h: Number of hops
We call an EpiChord network that sends out pqueries in parallel for a lookup a p-wayEpiChord.
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.19
EpiChord Lookup Algorithm
YOU ARE HEREYOU WANT: K2
N15
N10
N17
N20
N25
N30N35
N40
N47
N49
N51
N57
N62
N0 N6K2
Known node
Unknown node
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.20
EpiChord Lookup Algorithm
N15
N10
N17
N20
N25
N30N35
N40
N47
N49
N51
N57
N62
N0 N6K2
Known node
Unknown node
query for K2
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.21
EpiChord Lookup Algorithm
N15
N10
N17
N20
N25
N30N35
N40
N47
N49
N51
N57
N62
N0 N6K2
Known node
Unknown node
p−1 queries
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.22
EpiChord Lookup Algorithm
N15
N17
N20
N25
N30N35
N40
N47
N49
N51
N6K2
Known node
Unknown node
N57, N62, N0, N10
N57
N62N0
N10
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.23
EpiChord Lookup Algorithm
N15
N10
N17
N20
N25
N30N35
N40
N47
N49
N51
N57
N62
N0 N6K2
Known node
Unknown node
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.24
EpiChord Lookup Algorithm
N15
N10
N17
N20
N25
N30N35
N40
N47
N49
N51
N57
N62
N0 N6K2
Known node
Unknown node
N0, N6
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.25
EpiChord Lookup Algorithm
N15
N10
N17
N20
N25
N30N35
N40
N47
N49
N51
N57
N62
N0 N6K2
Known node
Unknown node
N0, N6
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.26
EpiChord Lookup Algorithm
N15
N10
N17
N20
N25
N30N35
N40
N47
N49
N51
N57
N62
N0 N6K2
Known node
Unknown node
FOUND K2!!
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.27
EpiChord Lookup Algorithm
Intrinsically iterativeLearn about more nodesAvoid redundant queries – typically2(p + h) messages
Additional policies to learn new routingentries:
When a node first joins network, obtains acache transfer from successorNodes gather information by observinglookup traffic
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.28
Key Insights
No compelling reason to decouple lookupsfrom network maintenance
Can employ parallel lookup if:Lookup pathlengths are shortAdopt an iterative approach to avoidredundant queries
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.29
Key Insights
Parallel Lookup and Large State have asomewhat symbiotic relationship
Lookup pathlengths are short if we store alot of state⇒ with short pathlengths, parallel lookup isfeasibleStoring a lot of state increases outdatedstate⇒ increases maintenance bandwidth orincreases timeouts⇒ parallel queries can mitigate timeouts
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.30
Proximity
We do not track latency information orexplicitly use proximity information
But parallel asynchronous lookup exploitsproximity indirectly
Key observation — Final sequence of lookupsthat returns the correct answer first isapproximately equivalent to aproximity-optimized lookup sequence
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.31
Reactive Cache Management
Traditional (active) approach⇒ Ping fingers periodically
Our approach:Cache entries have a fixed expirationperiodDivide address space into exponentiallysmaller slicesPeriodically check if each slice hassufficient (j) un-expired entriesIf not, make a lookup to the midpoint of theoffending slice
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.32
Division of Address Space
Estimate number of slices from k successorsand k predecessors
j and k are system parameters ⇒ choosek ≥ 2j SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.33
Cache Invariant
Lookup correctness is guaranteed because inthe worst case, can simply follow thesuccessor pointers
For O(log n)-hop lookup performanceguarantee:
Cache Invariant: Every slice contains atleast j
1−γ̂cache entries at all times.
where γ̂ is a local estimate of the probabilitythat a cache entry is out-of-date
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.34
Summary
Piggyback extra information on lookups
Allow cache to contain more than O(log n)state
Flush out old state with TTLs
Use cache entries in parallel to avoid timeouts
Check that cache entries are well-distributed.Fix if necessary.
Now, let’s evaluate performance : (i) latencyand (ii) cost
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.35
Worst-Case Performance
If j (entries/slice) = 1, equivalent to Chord
Assume a uniformly distributed workload,worst-case lookup pathlength is at most
1
2logα n, α = 3j +
6
j + 3(j > 1)
If j = 2, α = 7.2 and expected worst-caselookup pathlengths are at most only12 log2 n12 logα n
= logα 2 ≈ 13 of that for Chord
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.36
Reduction in Background Probes
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5
n=2,000n=20,000
n=200,000n=1,000,000
Pro
port
ion
ofca
che
inva
riant
satis
fied
Lookup traffic relative to minimal background network maintenance traffic
Probably at least 20 to 25% savingsSMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.37
Simulation Setup
Our simulation is built on the ssfnet simulationframework
10,450-node network topology organized as25 autonomous systems, each with 13routers and 405 end-hosts
Average roundtrip time (RTT) between nodesin the topology is approximately 0.16 s ⇒timeouts set at 0.5 s
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.38
Simulation Topology
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.39
Simulation Setup
Compare EpiChord to the optimal sequentialChord lookup algorithm (base 2)
What’s optimal? We ignore Chordmaintenance costs and assume that thefinger tables are perfectly accurate regardlessof node failures
The competing sequential lookup algorithm isthus a reasonably strong adversary and notjust a straw man
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.40
System Parameters
Timeout = 0.5 s
Retransmits = 3 times
Node lifespan – exponentially distributed withmean 600 s (10 mins)
Cache Expiration Interval = 120 s (2 mins)
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.41
Simulation Setup
The assumed workloads will affectcomparisons (Li et al., 2004)
Consider 2 types of workloads:Lookup-Intensive200 to 1,200 nodes, r ≈ 1
600 ⇒ rn ≈ 0.3 to 2query rate, Q ≈ 2 per secChurn-Intensive600 to 9,000 nodes, r ≈ 1
600 ⇒ rn ≈ 1.0 to15query rate, Q ≈ 0.05 to 0.07 per sec
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.42
Hop Count – Lookup-Intensive
0
1
2
3
4
5
200 300 400 600 800 1000 1200 1400
Chord1-way EpiChord2-way EpiChord3-way EpiChord4-way EpiChord5-way EpiChord
Ave
rage
num
ber
ofho
pspe
rlo
okup
Network Size (Logscale)
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.43
Latency – Lookup-Intensive
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
200 300 400 600 800 1000 1200 1400
Chord1-way EpiChord2-way EpiChord3-way EpiChord4-way EpiChord5-way EpiChord
Ave
rage
look
upla
tenc
y(s
)
Network Size (Logscale)
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.44
Messages Sent Per Lookup
0
5
10
15
20
200 300 400 600 800 1000 1200 1400
5-way EpiChord4-way EpiChord3-way EpiChord2-way EpiChord1-way EpiChord
Chord
Ave
rage
num
ber
ofm
essa
ges
per
look
up
Network Size (Logscale)
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.45
Hop Count – Churn-Intensive
0
1
2
3
4
5
6
7
500 1000 1500 2000 3000 4000 5000 6000 8000 10000
Chord1-way EpiChord2-way EpiChord3-way EpiChord4-way EpiChord5-way EpiChord
Ave
rage
num
ber
ofho
pspe
rlo
okup
Network Size (Logscale)
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.46
Latency – Churn-Intensive
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
1.1
1.2
1.3
500 1000 1500 2000 3000 4000 5000 6000 8000 10000
1-way EpiChordChord
2-way EpiChord3-way EpiChord4-way EpiChord5-way EpiChord
Ave
rage
look
upla
tenc
y(s
)
Network Size (Logscale)
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.47
Messages Sent Per Lookup
0
5
10
15
20
25
30
500 1000 1500 2000 3000 4000 5000 6000 8000 10000
5-way EpiChord4-way EpiChord3-way EpiChord2-way EpiChord1-way EpiChord
Chord
Ave
rage
num
ber
ofm
essa
ges
per
look
up
Network Size (Logscale)
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.48
Summary
Increasing p improves hop count and latencyand reduces lookup failure rate
Since our approach is iterative ⇒ about2(p + h) messages per lookup
Higher lookup rates yield better overallperformance due to caching
Number of entries returned per query l > 3does not affect performance much, so we setl = 3
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.49
Related Work
Chord (Stoica et al., 2001)
DHash++ (Dabek et al., 2004)
Kademlia (Maymounkov and Mazieres, 2002)
Kelips (Gupta et al., 2003)
One-Hop (Gupta et al., 2004)
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.50
Conclusion
Parallel lookup and reactive routing statemaintenance algorithm trades off storage withbetter lookup performance w/o increasingbandwidth consumption
Reduce both lookup latencies andpathlengths over Chord by a factor of 3 byissuing only 3 queries asynchronously inparallel per lookup w/o using more messages
Novel token-passing stabilization schemeautomatically detects and repairs globalrouting inconsistencies
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.51
SMA Computer Science Seminar
EpiChord: Parallelizing theChord Lookup Algorithm with
Reactive Routing StateManagement
Ben Leong, Barbara Liskov, and Eric D. Demaine
MIT Computer Science and Artificial Intelligence Laboratory
{benleong, liskov, edemaine}@mit.edu
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.52
What good are DHTs?
Finding a needle in a haystack
Load balancing — partition by id
Fault tolerance — replication
RendezvousMulticast/Event notificationDynamic name registration/resolution
NO known killer app! (except perhaps filesharing)
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.53
Limitations
Distributed programs are hard(er) to write
Mutable Data
Latency – but we can find and cache or doone-hop (maybe)
Security – need admission control
Need for point-of-entry – susceptible to DoSattack
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.54
My Two Cents
DHT is not always the right answer; acentralized solution may be better if you havecontrol over the nodes
Even if a DHT is the right answer, you have topick the “right” DHT
There is no “best” DHT – they all trade offbetween cost and performance
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.55
Background Maintenance Traffic
Need to ping every 60 s for 90% validity
j = 2 ⇒ min routing set 4× Chord
Need only half probes because of symmetry
Since 120 s = 2 × 60 s ⇒ backgroundmaintenance bandwidth ≤ Chord
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.56
What’s Stabilization
Correctness of routing is guaranteed bycorrectness of successor/predecessorpointers
In worst case, simply follow a chain ofsuccessor pointers – slow but correct.
Stabilization – process that maintains andrepairs successor/predecessor pointers
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.57
Definitions
We say that the network is
weakly stable if, for all nodes u, wehave predecessor(successor(u)) = u;strongly stable if, in addition, for eachnode u, there is no node v such thatu < v < successor(u); andloopy if it is weakly but not stronglystable (see (Stoica et al., 2002)).
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.58
Weak Stabilization
Nodes periodically probe their immediateneighbors and exchangesuccessor/predecessor lists
All messages contain IP address, portnumber and node id
Unlike Chord, no need for node to explicitlynotify its successor after node join
Theorem 1 The weak stabilization protocolwill eventually cause an EpiChord networkto converge to a weakly stable state.
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.59
Strong Stabilization
p
p
pKey idea: to detect loops, all we need to do isto traverse the entire ring and make sure thatwe come back to where we started
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.60
Strong Stabilization
A naive scheme to pass a single token alongthe ring will take a long time and is relativelyinefficient ⇒ implement parallelizetoken-passing
a node when sees a stabilization token (orimmediately after it joins the network), it willpick a random waiting period from the interval(tmin, tmax) after which it will initiate strongstabilization
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.61
Strong Stabilization
If a node sees a token before its timer runsout:
it will reset its timer and choose againchoose q nodes from its cache andgenerate secondary tokens
Do this recursively to propagate a token to allnodes in O(log n) hops
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.62
Token Generation Example
1
2q−2
q−1nx
nxn1
n1
n2
n3
n2
nq−1nq
nq
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.63
Strong Stabilization
Theorem 2 The strong stabilization protocolwill eventually cause an EpiChord networkto converge to a strongly stable state.
Key Intuition:Take any set of r nodes and have themsend a message to the consecutive node.If a loop exists, at least one pair will detectit.
Our insight is that this property does notchange if you choose the r nodes recursively.
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.64
Modelling Cache Composition
Consider a network of steady state size n,where per unit time
a fraction r of the nodes leavea fraction f of the cache entries are flushedEach node makes Q lookups uniformlyover the address spacep queries are sent in parallel for eachlookup
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.65
Modelling Cache Composition
Where x is the number of live nodes that isknown to a node at time t, we obtain thefollowing relation:
d
dtx(t) =
incoming queries︷ ︸︸ ︷
pQ(1 −x
n) −
entriesflushed
︷︸︸︷
fx −
nodes departed butnot flushed︷ ︸︸ ︷
(1 − f)rx
This assumes that new knowledge comesonly from incoming queries
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.66
Modelling Cache Composition
Where y is the number of outdated cacheentries at time t, we have the followingrelation:
d
dty(t) =
dead nodesnot flushed︷ ︸︸ ︷
(1 − f)rx −
dead nodesflushed︷︸︸︷
fy −
outdated nodes discovered bytimeouts of outgoing queries
︷ ︸︸ ︷
pQ(y
x + y)
If churn is low relative to lookup rate, cachemaintenance protocol is unimportant
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.67
Modelling Cache Composition
If churn is high, the proportion of outdatedentries in the cache, γ, is
γ = limt→∞
y
x + y≈
√
1 + (1−f)rf
− 1√
1 + (1−f)rf
If cache entries are flushed at node failurerate (i.e., f ≈ r),
γ ≈√
2 − f − 1√
2 − f≤ 1 −
1√
2= 0.292
⇒ most 30% of cache entries will beoutdated
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.68
Cache – Lookup-Intensive
0
100
200
300
400
500
600
700
800
900
200 400 600 800 1000 1200 1400
5-way EpiChord - live entries3-way EpiChord - live entries1-way EpiChord - live entries
5-way EpiChord - outdated entries3-way EpiChord - outdated entries1-way EpiChord - outdated entries
Ave
rage
num
ber
ofen
trie
sin
cach
e
Network Size (Logscale)
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.69
Cache – Lookup-Intensive
0
0.01
0.02
0.03
0.04
0.05
0.06
0.07
0.08
0.09
0.1
0.11
0.12
0.13
0.14
0.15
0.16
0.17
0.18
0.19
0.2
200 300 400 600 800 1000 1200 1400
1-way EpiChord2-way EpiChord3-way EpiChord4-way EpiChord5-way EpiChord
Network Size (Logscale)
Frac
tion
ofou
tdat
edca
che
entr
ies
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.70
Cache – Churn-Intensive
0
20
40
60
80
100
120
140
500 1000 1500 2000 3000 4000 5000 6000 8000 10000
5-way EpiChord - live entries3-way EpiChord - live entries1-way EpiChord - live entries
5-way EpiChord - outdated entries3-way EpiChord - outdated entries1-way EpiChord - outdated entries
Ave
rage
num
ber
ofen
trie
sin
cach
e
Network Size (Logscale)
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.71
Cache – Churn-Intensive
0.11
0.12
0.13
0.14
500 1000 1500 2000 3000 4000 5000 6000 8000 10000
1-way EpiChord2-way EpiChord3-way EpiChord4-way EpiChord5-way EpiChord
Frac
tion
ofou
tdat
edca
che
entr
ies
Network Size (Logscale)
SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.72
References
Dabek, F., Li, J., Sit, E., Robertson, J., Kaashoek, M. F., and
Morris, R. (2004). Designing a DHT for low latency and high
throughput. In Proceedings of the 1st Symposium on Net-
worked Systems Design and Implementation (NSDI 2004),
pages 85–98.
Gummadi, K., Gummadi, G., Gribble, S., Ratnasamy, S.,
Shenker, S., and Stoica, I. (2003). The impact of DHT rout-
ing geometry on resilience and proximity. In Proceedings of
the 2003 ACM SIGCOMM Conference, pages 381–394.
Gupta, A., Liskov, B., and Rodrigues, R. (2004). Efficient rout-
ing for peer-to-peer overlays. In Proceedings of the 1st Sym-
posium on Networked Systems Design and Implementation
(NSDI 2004), pages 113–126.
Gupta, I., Birman, K., Linga, P., Demers, A., and van Renesse,
R. (2003). Kelips: Building an efficient and stable P2P DHT
through increased memory and background overhead. In
Proceedings of the 2nd International Workshop on Peer-to-
Peer Systems (IPTPS ’03).
Li, J., Stribling, J., Morris, R., Kaashoek, M. F., and Gil, T. M.
(2004). DHT routing tradeoffs in network with churn. In
Proceedings of the 3rd International Workshop on Peer-to-
Peer Systems (IPTPS ’04).
Maymounkov, P. and Mazieres, D. (2002). Kademlia: A peer-
to-peer information system based on the xor metric. In Pro-
72-1
ceedings of the 1st International Workshop on Peer-to-Peer
Systems (IPTPS ’02).
Stoica, I., Morris, R., Karger, D., Kaashoek, F., and Balakrish-
nan, H. (2001). Chord: A scalable Peer-To-Peer lookup ser-
vice for internet applications. In Proceedings of the 2001
ACM SIGCOMM Conference, pages 149–160.
Stoica, I., Morris, R., Liben-Nowell, D., Karger, D., Kaashoek,
M. F., Dabek, F., and Balakrishnan, H. (2002). Chord: A
scalable peer-to-peer lookup service for internet applica-
tions. Technical report, MIT LCS.
72-2