Februar 17, 2006 GDS meeting - LIP 1

MOve: an application-Malleable Overlay

UIUC / INRIA Collaboration

Februar 17, 2006 GDS meeting - LIP 2

Disclaimer

Context of this work: Work done during our collaboration with

Urbana-Champaign Indranil Gupta & Ramsés Morales

Side work

Februar 17, 2006 GDS meeting - LIP 3

Why another overlay ? Structured overlays

Chord KaZAa

Unstructured overlays Gnutella Swim

Februar 17, 2006 GDS meeting - LIP 4

Targeted applications

Group-based applications Distributed white board Gaming platform Replication service …

Nodes within subgroups will interact

Februar 17, 2006 GDS meeting - LIP 5

Example: a gaming platform

Februar 17, 2006 GDS meeting - LIP 6

Needed properties Connectivity

Nodes should be able to communicate with others

Efficient updates Within a group nodes share a common

state Volatility resilience

Both at global and subgroup levels

Februar 17, 2006 GDS meeting - LIP 7

Who knows whom ? Every one knows every one

Not scalable !!! Only a partial view of the system

Who knows whom relation <=> an overlay Ideally

Stay connected Support for fault tolerance Related node should be close in the overlay

Februar 17, 2006 GDS meeting - LIP 8

Random graph benefits Theoretical results

The graph will stay connected if there are more than log(n) links per peer (where n is the overall number of peers in the system)

Goal To keep connectivity => try to stay close to

random graphs

Februar 17, 2006 GDS meeting - LIP 9

Non-application links

Take advantage of random graphs A subset of the links are “random” Weight according to the Round Trip Time

-> taking the underlying topology into account

Use “swim” algorithms

Februar 17, 2006 GDS meeting - LIP 10

Application links

To take into account application groups Create links between peers belonging to a

same group New links Replacing non-application links Sharing application links

Februar 17, 2006 GDS meeting - LIP 11

Sharing a same space

Februar 17, 2006 GDS meeting - LIP 12

Replacement policy If there is room enough an no link exist

-> link creation If the node has resources enough ->

link creation (else) drop a non-application link, or

change a non-application link to an application one

Februar 17, 2006 GDS meeting - LIP 13

What happens when a node joins ?

Februar 17, 2006 GDS meeting - LIP 14

Random walk

A mechanism to get new neighbor Called periodically

To avoid pathological topologies For fault tolerance To increase the clustering degree

Februar 17, 2006 GDS meeting - LIP 15

The random-walk mechanism

Februar 17, 2006 GDS meeting - LIP 16

Simulation

UIUC-INRIA_SIM A discrete event simulator ~ 5000 lines of java code Using the GT-ITM topology generator

Kenneth L. Calvert, Matthew B. Doar, and Ellen W. Zegura. Modeling Internet topology. IEEE Communications Magazine, 35(6):160 ﾐ 163, June 1997.

Februar 17, 2006 GDS meeting - LIP 17

Evaluation: Clustering coefficient (random graph…)

Februar 17, 2006 GDS meeting - LIP 18

Evaluation:Connectivity

Februar 17, 2006 GDS meeting - LIP 19

Evaluation:Controlled clustering

Februar 17, 2006 GDS meeting - LIP 20

Evaluation:Link sharing benefit (1)

Februar 17, 2006 GDS meeting - LIP 21

Evaluation:Twisting the overlay

Februar 17, 2006 GDS meeting - LIP 22

Evaluation:Resilience to failures

Februar 17, 2006 GDS meeting - LIP 23

Conclusion

MOve: a malleable overlay Nodes remain connected Strong connections within subgroups High volatility resilience

Paper submited to DSN 2006

Februar 17, 2006 GDS meeting - LIP 24

Link with replication…

Far from JuxMem BUT

Can be use for replication Greater scale Smaller warranties