1. Tsunami: Maintaining High Bandwidth Under Dynamic Network Conditions Dejan Kostić, Ryan Braud, Charles Killian, Eric Vandekieft, James W. Anderson, Alex Snoeren, and Amin Vahdat

2. Overview Introduction / Background Motivation Related Systems Design of Tsunami Results Conclusion

3. Introduction D A B F E Source C Problem: Distribute a (possibly large) file to a large set of end hosts Design goals: Cannot reply on IP multicast No node may maintain global state Must be as efficient as possible Must be extremely resilient to failures, bandwidth changes, etc

4. Motivation What is Tsunami good for? –Software updates –File distribution to a large set of Internet users, CDN servers, or grid machines –Not suitable for multimedia streaming BitTorrent is the current deployed solution to this problem

5. Related Systems Hasn’t this problem been solved before? –BitTorrent –SplitStream –Slurpie –Bullet –Numerous others Not exactly

6. Design Questions What is the “correct” way to build a file distribution protocol? How do we react to changes in bandwidth as quickly as possible? How do we deal with unresponsive nodes or those that leave the network? How do we make the protocol as robust as possible?

7. More Design Questions Do we use push or pull? Should we encode the data? Use a tree or a mesh to distribute content?

8. Tsunami’s Design Uses a hybrid push/pull approach No encoding is used File is broken into fixed size pieces called “blocks” for transmission Both an overlay mesh (data) and tree (control) are used

9. Tsunami’s Design Tsunami can be viewed as a collection of related “strategies” –Bootstrapping strategy –Update propagation strategy –Request strategy –Sender strategy –Peering strategy

10. Bootstrapping Strategy Every new node joins at the “root” and obtains place in control tree Root node gives a short list of current mesh members to joining node to use as initial peers

11. How Do You Find Peers? Each node initially connects to nodes provided by the source RanSub is used to distribute random subsets of nodes periodically over the tree Nodes can peer with others discovered through RanSub Peering relationships are not mutual A hard max of 20 peers is enforced per node

12. Update Propagation Strategy Peers send “diffs” to each other containing updates about what new parts of the file they have received Diff sending is both reactive and proactive to minimize control overhead

13. Request Strategy Nodes make requests for blocks from their peers based on parts of the file they need Disjoint requests are made to eliminate duplicates Complex policy for maintaining “the right amount” of data in flight from each peer at all times

14. Sender Strategy Request strategy aims to have only one or two blocks queued per peer at all times Since the request strategy does most of the work, the sending strategy simply serves requests in FIFO (per peer) order

15. Peering Strategy Every node initially desires 10 peers Through measurements, a node decides whether it wants to add or remove a peer based on its current performance No fixed set of peers is maintained Peering relationships change as bandwidth changes

16. Results

18. Conclusions Tsunami is efficient even under changing bandwidth conditions Doesn’t use IP multicast No global state required at any node

19. Questions?