Evaluation of a Scalable P2P Lookup Protocol for Internet Applications

1. Evaluation of a Scalable P2P Lookup Protocolfor Internet Applications Master Thesis Presentation by Samer Al-Kassimi Supervisors: Per Brand & Sameh El-Ansary Examiner: Vladimir Vlassov

2. Contents • P2P & the Chord protocol • Goals, Tools and Methodology • Traffic generator • Simulator • Experiments & Data Analysis • Conclusions & Future Work

3. Peer to Peer (P2P) 1 Server-Client Peer-to-Peer Server Node Client Node Client Node Internet Internet Node Node Client Client

4. N1 N2 Lookup(“title”) N3 Publisher@ Client Key=“title” Value=MP3 data… N4 N8 N6 N7 N9 N1 N2 Client N3 SetLoc(“title”, N4) DB Publisher@ Lookup(“title”) N4 N8 Key=“title” Value=file data… N9 N7 N6 Weaknesses of previous P2P systems 1 • Gnutella • unreliability • high cost O(N) • flooding network • Napster • single point of failure • high cost O(N)

5. Chord 1 • Belongs to the family of “routing” algorithms • Distributed hash tables • Scalable • most operations cost O(log2N) • Robust • Handles node failures well • Reliable • correct results in the face of network changes

6. doc 54 LOOKUP(54) N1 doc 10 N56 N8 N14 N51 N48 INSERT (doc 24) N21 N42 doc 24 N38 N32 doc 30 doc 38 Basic Topology: responsibilities and path following successors 1 • The successor of a key is responsible for that key • Lookups follow successors • This topology offers O(N) performance (non scalable)

7. N1 N56 N8 N14 N51 N48 N21 N42 N38 N32 Performance and scalability: fingers 1

8. doc 54 LOOKUP(54) N1 doc 10 N56 N8 N14 N51 N48 N21 N42 doc 24 N38 N32 doc 30 doc 38 Performance and scalability: fingers (2) 1

9. doc 54 N1 doc 10 N56 N8 N14 N51 N48 N21 N42 N38 N32 doc 38 Robustness: successors list and referrers list 1 • When a node fails, the network reorganizes itself • Further data structures are needed • The Chord ring holds its properties doc 24 doc 30

10. Objectives and methodology 2 • Goal: case study of Chord • Methodology: simulations that test scalability, robustness and reliability • Development: simulator and changes to a traffic generator • Design of test cases and run of the simulations

11. The traffic generator 2 • It’s a tool that generates network activity • inserts nodes into the network • makes nodes to leave • makes that nodes request lookups • Small changes were made to the way the generator works

12. The simulator 2 • Programmed in Java • Internals: loop traversing all nodes at each time unit to execute events • Messages are sent from node to node • Adjustable verbosity • Extendable properties • Customizable options (with XML)

13. The experiments 3 • Changes in the network size • is Chord scalable? network growth • Massive simultaneous node failures • is it robust? make nodes drop at once • Constant node joins and departures • Test reliability: are requests correctly replied?

14. Changes in the network size (1) 3 • One common changing value: networks with size N=2K, K=3..14 N = 8, 16, 32,…, 8192, 16384 nodes • Four subsets of experiments, combinations of two variables: • with/without successors list • constant/proportional identifier space • Path length is logged

15. Scalability Data Analysis(Changes in network size) 3

16. Scalability Data Analysis(Changes in network size) 3

17. Scalability Data Analysis(Changes in network size) 3

18. Scalability Data Analysis(Changes in network size) 3 • The successors list data structure provides slight improvement in queries path length • The fact that the identifier space is constant or proportional to the size of the network does not affect the results, although each node has more absolute information (but not relative)

19. Scalability Data Analysis(Changes in network size) 3

20. Changes in the network size (2) 3 • One common changing value: • networks with size N=2K, K=3..12 • N = 8, 16, 32,…, 2048, 4096 nodes • Three subsets of experiments, in which each node issues 10, 20 and 25 document search requests respectively • Path length and work load are logged

21. Scalability Data Analysis(Process load per node) 3

22. Scalability Data Analysis(Process load per node) 3

23. Massive simultaneous node failures 3 • 1,000 nodes • 0, 10, 20, 30, 40 and 50% of nodes are made to disappear at once respectively in each one of the 6 experiments • Successors list is of size r=2·log2N • Path lengths, timeouts and reply successes are logged

24. Robustness Data Analysis (Massive node failures) 3

25. Robustness Data Analysis (Massive node failures) 3 • When a node fails and it’s in the path of a lookup, a timeout is counted, and the lookup is retried. • Differences are minor • No undershooting, there’s always a reply Path lengths and timeouts (experiments) Path lengths and timeouts (paper data)

26. Constant node joins and departures 3 • 1,000 nodes, size is kept “constant” • Nodes continuously leave and join • frequencies f=1/(0.5i) per second, i=1..8 • rates R=0.05 to 0.40 in steps of 0.05 • Successors list is of size r=2·log2N • Referrers list (fingers that point the node) • Path lengths, timeouts, reply successes and accuracy are logged

27. Reliability Data Analysis(Constant network changes) 3 Data extracted from the experiments regarding reliability Data extracted from the paper

28. Reliability Data Analysis(Constant network changes) 3 • The traffic generator adds a source of error • It’s difficult to design the experiments with the way the traffic generator provides output • The referrers list provides better behaviour of the network under changing conditions • Chord behaves well in these scenarios

29. Conclusions 4 • Chord is a simple, and yet robust, reliable and scalable P2P protocol • Chord might not be the best solution for typical P2P uses • The simulator is a useful, easy-to-use, highly customizable tool • The traffic generator can be improved, some outputs are not accurate

30. Conclusions (2) 4 • A few points of the paper were not easy to interpret • The results of the experiments reasonably match previous research • Some experiments were difficult to reproduce

31. Future work 4 • Broaden the set of uses in which P2P technology can be put • Improve scalability and efficiency, offering O(logKN) instead of O(log2N) • Devise more experiments to get a deeper understanding of the protocol • Further development of the simulator (GUI? Interactivity?)

32. Questions? Okay, then… Thank you for coming!