1. Load Balancing in Structured P2P System Ananth Rao, Karthik Lakshminarayanan, Sonesh Surana, Richard Karp, Ion Stoica IPTPS ’03 Kyungmin Cho 2003/05/20

2. Outline Introduction Load Balancing Schemes Evaluation

3. Observations and Problems Observations in Structured P2P  Objects and nodes are assigned IDs at random  Highly heterogeneous Each peer has different storage, bandwidth, CPU, etc. Problems  Imbalance in the number of items stored at a node  Low performance

4. Need for Load-Balancing To maintain the system in a state in which load on a node is less than its target  Load: Depends on the particular P2P system E.g. Storage, Network bandwidth.  Target: Maximum load a node is willing to hold

5. Solution Approach Chord Ring Virtual Servers Contiguous region of the ID space Each node can be responsible for more than one virtual servers Node A Node C Node B

6. Solution Approach Chord Ring Node A Node C Node B Virtual Servers Contiguous region of the ID space Each node can be responsible for more than one virtual servers

7. Chord Ring 20 11 3 10 20 15 Allow dynamic re-mapping of load in a system Virtual server is the basic unit of load movement Node A Node C Node B T=50 T=15 T=35 Heavy L=45 L=31 L=3 L=41 30 Solution Approach (Cont’d)

8. Chord Ring 20 11 3 10 30 15 Node A Node C Node B T=50 T=15 T=35 L=45 L=31 L=14 L=30 Allow dynamic re-mapping of load in a system Virtual server is the basic unit of load movement Solution Approach (Cont’d)

9. Strong Points Direct Extension of Existing Structured P2P  Meaningful fast extension Movement of virtual servers appears as a join followed by a leave – supported by all DHTs Dynamic Load Balancing

10. Weak Points Cost of moving virtual servers may be high  Especially, load changes frequently  In Chord, finding and updating other nodes takes O(log 2 n) times Vulnerable  Moving virtual servers  Moving keys that is responsible for a node  Malicious peer removes a file  Can’t detect who remove a file No Performance Comparison with existing structured P2P systems  But, simulation about their three load balancing schemes

11. Outline Introduction Load Balancing Schemes Evaluation

12. Light node picks a random ID, contacts the node x responsible for it, and accepts load if x is heavy. Scheme 1: One-to-One L L L L L H H H L

13. Scheme 2: One-to-Many Light nodes report their load information to directories. Heavy node H gets this information by contacting a directory. H contacts the light node which can accept the excess load. Light nodes L1L1 L4L4 L2L2 L3L3 Heavy nodes H3H3 H2H2 H1H1 Directories D1D1 D2D2 L5L5

14. Scheme 3: Many-to-Many Many heavy and light nodes rendezvous at each step. Directories periodically compute the transfer schedule and report it back to the nodes, which then do the actual transfer. Heavy nodes H3H3 H2H2 H1H1 Directories D1D1 D2D2 L4L4 Light nodes L1L1 L2L2 L3L3 L4L4 L5L5

15. Outline Introduction Load Balancing Schemes Evaluation

16. Simulation Setup Three schemes were simulated for up to 32,000 nodes, and compared along 2 metrics  Total Load transferred to achieve balance  Number of probes Distributions chosen  Target of nodes Pareto  Loads on virtual servers (i) Gaussian (ii) Pareto

17. Metric 1: Total Load Transferred Total load transferred  Load moved depends only on distribution of loads, not on the load balancing scheme. Operational range  Many-to-many scheme is able to produce balance even at very high system load (when load is up to a fraction of 0.94 of capacity).  Other two schemes work only up to a factor of about 0.8

18. Metric 2: Time taken for Balance One-to-one scheme may be sufficient if loads remain stable over long time scales Number of probes to achieve balance Load/Target

19. Other Results Size of the Directory  How many heavy and light nodes must come together to keep the total number of probes small?  Most heavy nodes shed their load by making only one probe, for number of nodes per directory as low as 16.