ROME: Optimising DHT-basedPeer-to-Peer Networks

James Salter and Nick AntonopoulosDepartment of Computing, University of Surrey, UK

6th July 2005

The financial support of the UK Engineering and Physical Sciences Research Council (EPSRC) (for JS) is gratefully acknowledged

             

Outline

Introduction and Background

ROME Architecture

Processes for Expansion

Evaluation

Conclusions and Future Work

             

What is P2P?

Client/ServerPeer-to-Peer

No central server Node to node

connections Resilient Large #messages

Clients send requests to/via a central server

Small #messages Single point of failure

File sharing, distributed computing, instant messaging

             

P2P Network Characteristics

Nodes can act as clients and servers No centralised server/authority

In Pure P2P Networks Network is highly dynamic

Nodes join and leave regularly Large-scale

Potentially millions of nodes Nodes are autonomous

But co-operate to share/retrieve resources

             

Chord

Structured Peer-to-Peer architecture Well-known in the research field Combines advantages of other P2P

architectures: An index of resources (e.g. Napster) But distributed over multiple nodes (e.g. Gnutella)

Based on Distributed Hash Tables Simple lookup mechanism

Given a key, it will return associated value(s)

             

Chord

20

0 1

8

12

15

2 3 4 5 6 7 8

             

Chord

log2(n) hops worst case½log2(n) hops average

             

ROME Concept

Message cost is proportional to number of nodes in network (n)

Reduce n, reduce message cost Goal: Keep the ring “just big enough”

Must always support current workload Not unnecessarily large

Workload should determine ring size, not number of nodes in the network

Adding additional functionality to Chord

             

ROME Architecture

ROMEChordLowerLayers

             

Normal

Node Workload Monitoring

Zero LimitTarget Threshold

Overloaded

             

Node Workload Monitoring

Node-level monitoring only shows the status of a single node

Ring-level monitoring would provide a complete view

Why not monitor at the ring level? Requires global knowledge Nodes need to report to a central entity Workload can fluctuate rapidly Many regular update messages Defeats the object of reducing message cost

             

Replace Operation

Overloaded

             

Replace Operation

Overloaded

             

Replace Operation

             

Add Operation

Overloaded

             

Add Operation

1615 17 18 19 20 22 23 24 25 2621 2714

ID: 27ID: 14

wor

kloa

d

ID: ??

             

Add Operation

Overloaded

             

Add Operation

             

Dynamic Ring Performance

Reduction in hop count by controlling network size based on theoretical work: Max hops per lookup = log2(n) Mean hops per lookup = ½ log2(n) If ring A < ring B, then log2(A) < log2(B) - in a static ring with correct routing information

Does this hold true in more realistic dynamic scenarios, with nodes joining/leaving or failing?

             

Dynamic Ring: Mean Hop Count

0

1

2

3

4

5

6

3000 5000 7000 9000Mean Node Lifetime (secs)

Mea

n H

op C

ount

128 nodes256 nodes512 nodes1024 nodes

             

Effect on Query Failure Rates

0%

20%

40%

60%

80%

100%

1000 3000 5000 7000 9000Mean Node Lifetime (secs)

% C

orre

ct L

ooku

ps

1024 nodes512 nodes256 nodes128 Nodes64 Nodes

             

Reducing Ring Size with ROME

Node Pool: 1 million nodes Node Capacity: 100 units Upper Threshold: 95% (95 units)

Initial network-wide workload: 1 unit ROME Ring size: 1 node Chord Ring size: 1 million nodes

What happens as we increasenetwork-wide workload?

             

Effect on Ring Size

0

200000

400000

600000

800000

1000000

1200000

0 30000000 60000000 90000000

Network-wide Workload

Rin

g Si

ze

ChordROME

             

Mean Hops per Lookup

0

2

4

6

8

10

12

0 30000000 60000000 90000000

Network-wide Workload

Mea

n H

ops/

Look

up

ChordROME

             

Utilisation of Ring Capacity

0%

20%

40%

60%

80%

100%

0 30000000 60000000 90000000Network-wide Workload

Cap

acity

Util

isat

ion

ChordROME

             

Conclusions

Chord: DHT-based structured P2P architecture with message cost proportional to nodes in structure

ROME: Reduce number of nodes in structure, reduce message cost Add/replace processes on each node allow

Chord ring to grow as necessary Workload controls size, not nodes in network

Smaller message costs than standard Chord when control ring building

What if workload decreases?