1. Februar 17, 2006GDS meeting - LIP1 MOve: an application-Malleable Overlay UIUC / INRIA Collaboration

2. Februar 17, 2006GDS meeting - LIP2 Disclaimer Context of this work: Work done during our collaboration with Urbana-Champaign Indranil Gupta & Ramsés Morales Side work

3. Februar 17, 2006GDS meeting - LIP3 Why another overlay ? Structured overlays Chord KaZAa Unstructured overlays Gnutella Swim

4. Februar 17, 2006GDS meeting - LIP4 Targeted applications Group-based applications Distributed white board Gaming platform Replication service … Nodes within subgroups will interact

5. Februar 17, 2006GDS meeting - LIP5 Example: a gaming platform

6. Februar 17, 2006GDS meeting - LIP6 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

7. Februar 17, 2006GDS meeting - LIP7 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

8. Februar 17, 2006GDS meeting - LIP8 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

9. Februar 17, 2006GDS meeting - LIP9 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

10. Februar 17, 2006GDS meeting - LIP10 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

11. Februar 17, 2006GDS meeting - LIP11 Sharing a same space

12. Februar 17, 2006GDS meeting - LIP12 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

13. Februar 17, 2006GDS meeting - LIP13 What happens when a node joins ?

14. Februar 17, 2006GDS meeting - LIP14 Random walk A mechanism to get new neighbor Called periodically To avoid pathological topologies For fault tolerance To increase the clustering degree

15. Februar 17, 2006GDS meeting - LIP15 The random-walk mechanism

16. Februar 17, 2006GDS meeting - LIP16 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.

17. Februar 17, 2006GDS meeting - LIP17 Evaluation: Clustering coefficient (random graph…)

18. Februar 17, 2006GDS meeting - LIP18 Evaluation: Connectivity

19. Februar 17, 2006GDS meeting - LIP19 Evaluation: Controlled clustering

20. Februar 17, 2006GDS meeting - LIP20 Evaluation: Link sharing benefit (1)

21. Februar 17, 2006GDS meeting - LIP21 Evaluation: Twisting the overlay

22. Februar 17, 2006GDS meeting - LIP22 Evaluation: Resilience to failures

23. Februar 17, 2006GDS meeting - LIP23 Conclusion MOve: a malleable overlay Nodes remain connected Strong connections within subgroups High volatility resilience Paper submited to DSN 2006

24. Februar 17, 2006GDS meeting - LIP24 Link with replication… Far from JuxMem BUT Can be use for replication Greater scale Smaller warranties