SMA Computer Science Seminar EpiChord: Parallelizing the Chord - - PowerPoint PPT Presentation

SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management

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 : Scalable Self configuring Fault 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 N30 N35 N40 N47 N49 N51 N57 N62 N0 N6

Most common — one-dimensional circular address 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 N30 N35 N40 N47 N49 N51 N57 N62 N0 N6 K13 K2 K47 K32 K52 K54

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 a distributed data structure that supports a put/get interface. Store and retrieve {key, value} pairs efficiently

• ver a network of (generally unreliable) nodes

Keep state stored per node small because of network 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) to O(n) Lookup Topology (Gummadi et al., 2003) – ring, tree, xor, hypercube, butterfly Parallel lookup – Kademlia (xor) (Maymounkov and Mazieres, 2002) ⇒ EpiChord explores the trade-offs in moving from sequential lookup to parallel lookup and from 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 N30 N35 N40 N47 N49 N51 N57 N62 N0 N6

Each node periodically probes O(log n) fingers Achieves O(log n)-hop performance

SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.7

Recursive Lookup

N15 N10 N17 N20 N25 N30 N35 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 N30 N35 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 N30 N35 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 N30 N35 N40 N47 N49 N51 N57 N62 N0 N6 K12

Takes O(log n) hops to get to the destination node.

SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.11

Iterative Lookup

N15 N10 N17 N20 N25 N30 N35 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 N30 N35 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 N30 N35 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 N30 N35 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 traffic is limiting factor. Takes O(log n) hops per lookup ⇒ Okay for some applications, too slow for others Non-zero probability that a node may fail in between probe ⇒ Node failures detected by timeout

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)-hop lookup without adding extra overhead. Use a combination of techiques: Piggyback information on lookup messages Allow cache to store more than O(log n) routing state Issue 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 p queries in parallel for a lookup a p-way EpiChord.

SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.19

EpiChord Lookup Algorithm

YOU ARE HERE YOU WANT: K2 N15 N10 N17 N20 N25 N30 N35 N40 N47 N49 N51 N57 N62 N0 N6 K2 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 N30 N35 N40 N47 N49 N51 N57 N62 N0 N6 K2 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 N30 N35 N40 N47 N49 N51 N57 N62 N0 N6 K2 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 N30 N35 N40 N47 N49 N51 N6 K2 Known node Unknown node N57, N62, N0, N10 N57 N62 N0 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 N30 N35 N40 N47 N49 N51 N57 N62 N0 N6 K2 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 N30 N35 N40 N47 N49 N51 N57 N62 N0 N6 K2 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 N30 N35 N40 N47 N49 N51 N57 N62 N0 N6 K2 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 N30 N35 N40 N47 N49 N51 N57 N62 N0 N6 K2 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 iterative Learn about more nodes Avoid redundant queries – typically 2(p + h) messages Additional policies to learn new routing entries: When a node first joins network, obtains a cache transfer from successor Nodes gather information by observing lookup 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 lookups from network maintenance Can employ parallel lookup if: Lookup pathlengths are short Adopt an iterative approach to avoid redundant 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 a somewhat symbiotic relationship Lookup pathlengths are short if we store a lot of state ⇒ with short pathlengths, parallel lookup is feasible Storing a lot of state increases outdated state ⇒ increases maintenance bandwidth or increases 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 or explicitly use proximity information But parallel asynchronous lookup exploits proximity indirectly Key observation — Final sequence of lookups that returns the correct answer first is approximately equivalent to a proximity-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 expiration period Divide address space into exponentially smaller slices Periodically check if each slice has sufficient (j) un-expired entries If not, make a lookup to the midpoint of the

• ffending 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 successors and k predecessors j and k are system parameters ⇒ choose k ≥ 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 in the worst case, can simply follow the successor pointers For O(log n)-hop lookup performance guarantee:

Cache Invariant: Every slice contains at

least

j 1−ˆ γ cache entries at all times.

where ˆ γ is a local estimate of the probability that 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) latency and (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 2 logα n, α = 3j + 6 j + 3 (j > 1) If j = 2, α = 7.2 and expected worst-case lookup pathlengths are at most only

1 2 log2 n 1 2 logα n = logα 2 ≈ 1

3 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.1 0.2 0.3 0.4 0.5 0.6 0.7 0.5 1 1.5 2 2.5 3 3.5 4 4.5 n=2,000 n=20,000 n=200,000 n=1,000,000

Proportion of cache invariant satisfied Lookup traffic relative to minimal background network maintenance traffic

Probably at least 20 to 25% savings

SMA 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 simulation framework 10,450-node network topology organized as 25 autonomous systems, each with 13 routers and 405 end-hosts Average roundtrip time (RTT) between nodes in 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 sequential Chord lookup algorithm (base 2) What’s optimal? We ignore Chord maintenance costs and assume that the finger tables are perfectly accurate regardless

• f node failures

The competing sequential lookup algorithm is thus a reasonably strong adversary and not just 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 with mean 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 affect comparisons (Li et al., 2004) Consider 2 types of workloads: Lookup-Intensive 200 to 1,200 nodes, r ≈

1 600 ⇒ rn ≈ 0.3 to 2

query rate, Q ≈ 2 per sec Churn-Intensive 600 to 9,000 nodes, r ≈

1 600 ⇒ rn ≈ 1.0 to

15 query 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

1 2 3 4 5 200 300 400 600 800 1000 1200 1400 Chord 1-way EpiChord 2-way EpiChord 3-way EpiChord 4-way EpiChord 5-way EpiChord

Average number of hops per lookup Network Size (Logscale)

SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.43

Latency – Lookup-Intensive

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 Chord 1-way EpiChord 2-way EpiChord 3-way EpiChord 4-way EpiChord 5-way EpiChord

Average lookup latency (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

5 10 15 20 200 300 400 600 800 1000 1200 1400 5-way EpiChord 4-way EpiChord 3-way EpiChord 2-way EpiChord 1-way EpiChord Chord

Average number of messages per lookup Network Size (Logscale)

SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.45

Hop Count – Churn-Intensive

1 2 3 4 5 6 7 500 1000 1500 2000 3000 4000 5000 6000 8000 10000 Chord 1-way EpiChord 2-way EpiChord 3-way EpiChord 4-way EpiChord 5-way EpiChord

Average number of hops per lookup Network Size (Logscale)

SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.46

Latency – Churn-Intensive

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 EpiChord Chord 2-way EpiChord 3-way EpiChord 4-way EpiChord 5-way EpiChord

Average lookup latency (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

5 10 15 20 25 30 500 1000 1500 2000 3000 4000 5000 6000 8000 10000 5-way EpiChord 4-way EpiChord 3-way EpiChord 2-way EpiChord 1-way EpiChord Chord

Average number of messages per lookup 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 latency and reduces lookup failure rate Since our approach is iterative ⇒ about 2(p + h) messages per lookup Higher lookup rates yield better overall performance due to caching Number of entries returned per query l > 3 does not affect performance much, so we set l = 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 state maintenance algorithm trades off storage with better lookup performance w/o increasing bandwidth consumption Reduce both lookup latencies and pathlengths over Chord by a factor of 3 by issuing only 3 queries asynchronously in parallel per lookup w/o using more messages Novel token-passing stabilization scheme automatically detects and repairs global routing inconsistencies

SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.51

SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management

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 Rendezvous Multicast/Event notification Dynamic name registration/resolution NO known killer app! (except perhaps file sharing)

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 do

• ne-hop (maybe)

Security – need admission control Need for point-of-entry – susceptible to DoS attack

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; a centralized solution may be better if you have control over the nodes Even if a DHT is the right answer, you have to pick the “right” DHT There is no “best” DHT – they all trade off between 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 ⇒ background maintenance 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 by correctness of successor/predecessor pointers In worst case, simply follow a chain of successor pointers – slow but correct. Stabilization – process that maintains and repairs 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, we have predecessor(successor(u)) = u; strongly stable if, in addition, for each node u, there is no node v such that u < v < successor(u); and loopy if it is weakly but not strongly stable (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 immediate neighbors and exchange successor/predecessor lists All messages contain IP address, port number and node id Unlike Chord, no need for node to explicitly notify its successor after node join

Theorem 1 The weak stabilization protocol

will eventually cause an EpiChord network to 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

p

Key idea: to detect loops, all we need to do is to traverse the entire ring and make sure that we 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 along the ring will take a long time and is relatively inefficient ⇒ implement parallelize token-passing a node when sees a stabilization token (or immediately after it joins the network), it will pick a random waiting period from the interval (tmin, tmax) after which it will initiate strong stabilization

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 runs

• ut:

it will reset its timer and choose again choose q nodes from its cache and generate secondary tokens Do this recursively to propagate a token to all nodes 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 2 q−2 q−1

nx

nx n1 n1

n2 n3

n2 nq−1

nq

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 protocol

will eventually cause an EpiChord network to converge to a strongly stable state. Key Intuition: Take any set of r nodes and have them send a message to the consecutive node. If a loop exists, at least one pair will detect it. Our insight is that this property does not change 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 leave a fraction f of the cache entries are flushed Each node makes Q lookups uniformly

• ver the address space

p queries are sent in parallel for each lookup

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 is known to a node at time t, we obtain the following relation:

d dtx(t) = incoming queries

• pQ(1 − x

n) − entries flushed

• fx

− nodes departed but not flushed

• (1 − f)rx

This assumes that new knowledge comes

• nly 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 cache entries at time t, we have the following relation:

d dty(t) =

dead nodes not flushed

• (1 − f)rx −

dead nodes flushed

• fy

−

• utdated nodes discovered by

timeouts of outgoing queries

• pQ(

y x + y )

If churn is low relative to lookup rate, cache maintenance 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 outdated entries in the cache, γ, is

γ = lim

t→∞

y x + y ≈

• 1 + (1−f)r

f

− 1

• 1 + (1−f)r

f

If cache entries are flushed at node failure rate (i.e., f ≈ r),

γ ≈ √2 − f − 1 √2 − f ≤ 1 − 1 √ 2 = 0.292

⇒ most 30% of cache entries will be

• utdated

SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.68

Cache – Lookup-Intensive

100 200 300 400 500 600 700 800 900 200 400 600 800 1000 1200 1400 5-way EpiChord - live entries 3-way EpiChord - live entries 1-way EpiChord - live entries 5-way EpiChord - outdated entries 3-way EpiChord - outdated entries 1-way EpiChord - outdated entries

Average number of entries in cache Network Size (Logscale)

SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.69

Cache – Lookup-Intensive

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 EpiChord 2-way EpiChord 3-way EpiChord 4-way EpiChord 5-way EpiChord

Network Size (Logscale) Fraction of outdated cache entries

SMA Computer Science Seminar EpiChord: Parallelizing the Chord Lookup Algorithm with Reactive Routing State Management – p.70

Cache – Churn-Intensive

20 40 60 80 100 120 140 500 1000 1500 2000 3000 4000 5000 6000 8000 10000 5-way EpiChord - live entries 3-way EpiChord - live entries 1-way EpiChord - live entries 5-way EpiChord - outdated entries 3-way EpiChord - outdated entries 1-way EpiChord - outdated entries

Average number of entries in cache 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 EpiChord 2-way EpiChord 3-way EpiChord 4-way EpiChord 5-way EpiChord

Fraction of outdated cache entries 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