Gossipbased Overlay Topology Management

1
Gossip-based Overlay Topology Management

• Márk Jelasity and Ozalp Babaoglu
• University of Bologna
• In this paper we propose a generic protocol for
  constructing and maintaining a large class of
  topologies. In the proposed framework, a topology
  is defined with the help of a ranking function.
  The nodes participating in the protocol can use
  this ranking function to order any set of other
  nodes according to preference for choosing them
  as a neighbour. This simple abstraction makes it
  possible to control the self-organization process
  of topologies in a straightforward, intuitive and
  flexible manner
• Work presented at ESOA 2005 P2P 2005 with
  Alberto Montresor

2
Gossip communication

• Has been used for
• Information dissemination (e.g. multicast)
• Failure detection
• Load balancing
• Data aggregation
• Etc
• Now suggested for general topology management of
  overlay networks

3
Gossip communication

• Proposal Gossip-based topology management
• Not of some specialized overlay networks, as in
  past work
• But for established overlays like Chord
• Makes use of a common base gossip protocol,
  with ranking rules to create desired topology

4
Motivation

• Generalization of topology management and
  maintenance
• Resulting in a single topology component for
  many overlays
• Allowing topology to be easily changed on demand,
  without developing entirely new protocols

5
The approach in detail
Application
peers
Core protocol
RankingRules
Peer Sampling Service
selectPeer()
getView()
selectView()
6
The approach in detail - core

• Every node has
• A view, containing its c favoured peers
• I.e. the best peers it has found so far
• The ability to differentiate between two peers by
  applying a good-ness rank
• Access to a random view service
• Providing a (roughly) uniform-random selection of
  n peers from the network1

1. The Peer Sampling Service Experimental
Evaluation of Unstructured Gossip-Based
Implementations, MW04
7
The approach in detail - core
my view rnd.view
view 561,186,772,34,59
selectView() Take the best-ranked c peers
of merge (my view, my rnd.view, qs
view, qs rnd.view)
my view rnd.view
selectPeer() Best peer in view (q)
c 5
8
The approach in detail - core
view 561,186,983,34,615
c 5
9
The approach in detail - core

• A peer sampling service provides the random
  view used in the protocol
• Works similarly to the gossip topology management
  protocol, but is looking for random peers
  instead of good peers
• This helps rapid convergence to the desired
  topology
• Particularly useful when a new node joins the
  overlay, and all other nodes have very good views

10
The approach in detail - core

• Rapid convergence for new nodes

view
view
view
view
11
The approach in detail
Application
peers
Core protocol
RankingRules
Peer Sampling Service
selectPeer()
getView()
selectView()
12
The approach in detail - ranking

• A Chord-like DHT
• Successor and predecessor peers
• Numerically closest left and right IDs
• Finger table (long-range) peers
• Use a second instance of the protocol, with a
  ranking function favouring nodes with close IDs
  viewed as bit-patterns
• Node 10111 has fingers 11111,10101,10110..

13
The approach in detail - ranking

• A binary tree
• Nodes again have IDs expressed as bit-patterns,
  and a node 0,acam has the children ac,am,0 and
  acam,1
• Domain and latency-based trees are more difficult
  to envisage

14
Evaluation
A cycle is a period of time in which every node
in the system is updated once Convergence
factor is the factor by which the number of
target links found increases from one cycle to
the next All evaluation is based on simulations
214 16,384 217 131,072 220 1,048,576
15
Evaluation
Healing parameter means the H oldest links are
removed froma nodes view each cycle Number of
nodes in experiment 10,000 c 20 Churn
percent is removing thegiven percentage of
nodes fromthe system (randomly) andreplacing
them with new nodes (new nodes have random views)
16
Evaluation
Healing parameter means the H oldest links are
removed froma nodes view each cycle Number of
nodes in experiment 10,000 c 20 Churn
percent is removing thegiven percentage of
nodes fromthe system (randomly) andreplacing
them with new nodes (new nodes have random views)
Same data, but only counting nodes older than 10
cycles
17
Evaluation
Healing parameter means the H oldest links are
removed froma nodes view each cycle Number of
nodes in experiment 10,000 c 20 Churn
percent is removing thegiven percentage of
nodes fromthe system (randomly) andreplacing
them with new nodes (new nodes have random views)
Same data, but only counting nodes older than 20
cycles
18
Case study

• Jump-starting Chord
• Existing overlay join protocols are not
  designed to handle the massive concurrency
  involved in setting up a large Chord overlay from
  scratch
• This kind of behaviour is needed in systems like
  PlanetLab or Grids, where large overlays are
  constructed on-demand

19
Case study

• Jump-starting Chord
• Nodes are given a random initial view
• Use the described gossip protocol to converge
  close to the Chord overlay
• Hand off to actual Chord when complete

20
Summary

• New way of specifying the topology of overlay
  networks
• Topology component rules
• Common approach for many topologies

21
Summary

• Positives
• Simple resilient protocol for general topology
  management in overlay networks
• Quickly builds correct topology with many nodes
• Problems
• Applicability to some specific topologies is
  uncertain
• For fault-tolerance, the approach is aimed at
  topology only no ability to make other state
  persistent / recoverable

22
Observations related work

• Seems strongly related to SLOSL-style overlay
  specification
• Also some relation to iOverlay type frameworks
  for overlay development
• Overlay construction / deployment in GridKit?