The document describes ROME, an architecture that optimizes DHT-based peer-to-peer networks like Chord. ROME aims to reduce message costs by keeping the ring size just large enough to support current workload, rather than scaling with total network nodes. Each node monitors its workload and performs add or replace operations to dynamically adjust the ring size as needed. Simulation results show ROME achieves smaller average ring sizes, lower hop counts, and reduced query failure rates compared to Chord under fluctuating workloads and node lifetimes.

1. ROME: Optimising DHT-based
Peer-to-Peer Networks
James Salter and Nick Antonopoulos
Department 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

2. Outline
 Introduction and Background
 ROME Architecture
 Processes for Expansion
 Evaluation
 Conclusions and Future Work

3. 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

4. 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

5. 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)

6. Chord
20
0 1
8
12
15
2 3 4 5 6 7 8

7. Chord
log2(n) hops worst case
½log2(n) hops average

8. 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

9. ROME Architecture
ROME
Chord
Lower
Layers

10. Normal
Node Workload Monitoring
Zero LimitTarget Threshold
Overloaded

11. 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

12. Replace Operation
Overloaded

13. Replace Operation
Overloaded

14. Replace Operation

15. Add Operation
Overloaded

16. Add Operation
1615 17 18 19 20 22 23 24 25 2621 2714
ID: 27ID: 14
workload
ID: ??

17. Add Operation
Overloaded

18. Add Operation

19. 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?

20. Dynamic Ring: Mean Hop Count
0
1
2
3
4
5
6
3000 5000 7000 9000
Mean Node Lifetime (secs)
MeanHopCount
128 nodes
256 nodes
512 nodes
1024 nodes

21. Effect on Query Failure Rates
0%
20%
40%
60%
80%
100%
1000 3000 5000 7000 9000
Mean Node Lifetime (secs)
%CorrectLookups
1024 nodes
512 nodes
256 nodes
128 Nodes
64 Nodes

22. 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 increase
network-wide workload?

23. Effect on Ring Size
0
200000
400000
600000
800000
1000000
1200000
0 30000000 60000000 90000000
Network-wide Workload
RingSize
Chord
ROME

24. Mean Hops per Lookup
0
2
4
6
8
10
12
0 30000000 60000000 90000000
Network-wide Workload
MeanHops/Lookup
Chord
ROME

25. Utilisation of Ring Capacity
0%
20%
40%
60%
80%
100%
0 30000000 60000000 90000000
Network-wide Workload
CapacityUtilisation
Chord
ROME

26. 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?