1. 1 FairOM: Enforcing Proportional Contributions among Peers in Internet-Scale Distributed Systems Yijun Lu †, Hong Jiang †, and Dan Feng * † University of Nebraska-Lincoln, USA * Huazhong University of Science and Technology, China

2. 2 Introduction Overlay multicasting –vs. IP multicasting –Need not to modify current machines –More flexible: it is an overlay! –Performance is reasonably good –Circumvent censorship Applications –Multimedia dissemination –Large (scientific research) data delivery, such as those in Data Grid

3. 3 Fairness? New requirement –Come from equal status of nodes. –Examples ä Sites in data grid ä Peer-to-Peer network Single-tree-based scheme is not sufficient –Leaves do not contribute to forwarding Forest-based scheme –Data split into stripes –Each tree spans the whole network and multicasts one stripe –Each node is an interior node in exactly one tree

4. 4 But, How about Multi-Sessions? In existing forest-based schemes, each peer is asked to contribute once, but it may cause hot spot, which prevents multi-sessions. Example: –Two sessions: from A and B –Node C contributes 90% of its bandwidth to A’s session, via one contribution –There is not enough bandwidth left for C to support B’s session A better idea? –C contribute, say 20%, to each session.

5. 5 FairOM (Fair Overlay Multicasting) New definition of fairness –Peers’ contributions are proportional to their total outgoing bandwidth. Analogy to taxation –Assume people are in the same tax bracket Implication to performance –Enabling multi-sessions –Reduce possible hot spots, thus improving quality of service.

6. 6 Outline Problem formulation Design Evaluation Related Work Current Status

7. 7 Problem Formulation Key assumptions –Data is split into stripes –There are excessive bandwidth within the system, so that building a multicasting forest is feasible Conditions for a complete FairOM forest –Each peer receive all the stripes –The contributed bandwidth is not larger than its total outgoing bandwidth Design goal –Minimize the standard deviation of all contribution ratios

8. 8 Design: Overview Basic idea –Build a FairOM forest in two phases –1 st phase: build a skeleton –2 nd phase: make the forest complete Assumption –A new peer knows at least one member in the group –All peers know what the multicasting source is

9. 9 Design 1: Establish Neighborhood A neighborhood establishment procedure –Starts with a peer’s bootstrap neighbor –Gets its neighbor’s neighbor list –Fine tune: ä Upper bound of a neighbor list ä Add neighbor with low delay After neighborhood is established –This procedure is used to maintain the neighborhood

10. 10 Design 2: A Key Data Structure Five stages of contribution ratio –Stage 1: (0, 20%] –Stage 2: (20%, 40%] –etc. Explanations –Each stripe has an associated Staged Spare Capacity Group –# of stages—a trade-off –Resides in multicasting source Staged spare capacity group

11. 11 Design 3: Forest Construction (I) Purpose –Not supposed to build a complete forest –Provide a skeleton on which the second phase can improve Mechanism –A predefined contribution quota –Source sends invitation out, the receivers relay it –A peer contributes no more than its pre-defined contribution ratio –A parent-child relationship is maintained by heart-beat checking

12. 12 Design 4: Forest Construction (II) Purpose –Build a complete FairOM forest Mechanism –Peers register contribution to source’s staged spare capacity group –Peers with missing stripes seek help from source –Source examines the staged spare capacity group and assigns a parent for adoption

13. 13 Design 5: Minimize Delay Purpose –Incorporate delay information into consideration –The lower the delay, the better the multicasting performance Mechanism –Upon adoption request, source assigns more than one potential parents (currently, we use 3) –Peer chooses the one with the lowest multicasting delay –This procedure is safe—cycle free.

14. 14 Design 6: Handle Join & Departure Joins after the forest is build –Run neighborhood establishment procedure –Seek adoption from its neighbors –Ask source for any missing stripes Departures –Decent departure ä Its parents reclaim their contributions ä Its children seek adoptions –Node failures ä Heart-beat checking will detect the failure ä Then, it is same with that in decent departure

15. 15 Design 7: Two issues Stress put on the source –Use a source pool ä Simple, but assume other nodes are as trustable and stable as source –Use a Byzantine-protocol-based inner source circle ä Safe, but complex The security issue –Currently, we assume that peers are trustworthy –Can possibly use distributed audit

16. 16 Evaluation: Setup Network model –Transit-Stub model Parameters –1000 peers in network –Connected by 1452 routers Emulate bandwidth information –Bandwidth of peers are randomly chosen between 10 and 20, in terms of how many stripes they can forward

17. 17 1. Enforcing Proportionality Metric –StdR of peers’ contribution ratio Parameters –# of stripes: 2, 4, and 8 Results –Enforce proportionality effectively

18. 18 2. Forest Construction Overhead Metric –Node stress: # of messaged received by each peer Results –Average node stress ä 300 over 192 seconds –Max node stress ä 6585 over 192 seconds ä This is the multicasting source ä Translates to < 34.4 KB/s bandwidth cost

19. 19 3. Multicasting Performance 1. All nodes receive data in 8 seconds 2. Avg. delay is 4.1 seconds

20. 20 4. Path Diversity Definition –Avg. # of stripes lost if one node fails –Ideally, the number should be 1 Setup –Randomly fail one node, which is not the multicasting source Results

21. 21 Related Work Single-tree-based scheme –Overcast –ESM (End System Multicast) Forest-based scheme –SplitStream –CoopNet Mess-based scheme –Bullet Impact of heterogeneous bandwidth –In the context of DHT-based multicasting protocols

22. 22 Current Status Improve scalability –Fully distributed forest construction algorithm Improve adaptability –What if the total outgoing bandwidth of peers changes? Implementing a prototype on Planet-Lab