Host Multicast: A Framework for Delivering Multicast to End Users

1. Host Multicast: A Framework for Delivering Multicast to End Users Beichuan Zhang (UCLA) Sugih Jamin (UMich) Lixia Zhang (UCLA) INFOCOM

2. Motivation • Fast increasing need for scalable and efficient group communication • Slow deployment of IP Multicast • Implemented in most OS and routers • But not widely enabled • Emerging End-host based Multicast • Member hosts duplicate and forward packets • Easy to deploy, but less efficient

3. Host Multicast • A hybrid approach • Goal: Ubiquitous Multicast • Design Requirements • Deployable on the current Internet • Install a user-space program at end hosts • No support is required from OS, routers and servers • Enable multicast applications • Compatible with IP Multicast to the furthest extent • Use IP Multicast where available • Keep IP Multicast service model • Provide incentive to future deploy

4. Rendezvous Point (HMRP) RP DM Host Unicast Tunnel Designated Member (DM) DM DM Host Host IP Multicast Island Normal Member Host Host Host To bootstrap new members Architecture Host Group Management Protocol (HGMP) for intra-island management Each member runs our daemon program at user-space Host Multicast Tree Protocol (HMTP) to build inter-island tunnels A network of any size that supports IP Multicast, e.g. single host, Ethernet, campus network etc.

5. Components Rest of the talk is focused on HMTP

6. Host Multicast Tree Protocol (HMTP) • Build a bi-directional shared-tree connecting all islands • The tree should be congruent to physical network topology to be efficient • use member-to-member round-trip time as distance metric in current design • The tree should be robust • be able to handle node failure, dynamic join/leave etc.

7. A A A B B C C D D C D F F G G G F G G Where is my group? H Root of your group is A H Join Group root HMRP always knows the root of the tree. A newcomer does a depth-first search of the tree to find a close member as its parent. Clustering nearby members makes the tree congruent to physical network topology to the first order. B E RP

8. A A B B C C D C D H F F G G F G G Tree Maintenance • Each member keeps its children list and root path up to date by exchanging REFRESH and PATH messages with neighbors. • Root sends REFRESH message to HMRP. B E RP

9. A B B C C D C H D F F G G F G G Member Leave and Partition Recovery • Parent deletes the leaving node from children list. • Direct Children repair the tree by running join procedure in the reverse order. • If root is leaving, the first node contacting HMRP is assigned as new root. B A E RP

10. Tree Improvement • Periodically re-run the join procedure • To accommodate changes in network conditions and group membership • Start from a randomly picked node in the root path. • Less frequent than REFRESH and PATH messages.

11. G Loop Detection and Resolution • Loop is possible: • Multiple conflicting joins happen at the same time. • Detection: • One’s root path contains itself • Resolution: • Leave the current parent and re-join the tree from the root. • Loop is rare. B A C D F E

12. Performance Metrics • Tree Cost: sum of all tree link delays • Cost ratio to IP Multicast • Tree Delay: delay from one member to another along the tree • Delay ratio to unicast delay • Link Load • Number of duplicate packets carried by a physical link. • Compared to Unicast Star and IP Multicast

13. stabilized leave done stabilized done join Convergence

14. Tree Cost

15. Tree Delay

16. Link Load

17. Internet Experiment • A real topology of 96 hosts and 978 routers, derived from NLANR’s traceroute data. • Tree cost ratio 0.99 • Mean delay ratio 1.76 • Worst link load 8

18. Conclusion • Related Work of HMTP • Centralized • ALMI etc. • Mesh-based • Narada, Gossamar etc. • Tree-based • Yoid, BTP etc. • Future Work • Reducing HMTP tree delay • Supporting Multiple DMs in one island

19. ~ The End ~