The Java ™ Reliable Multicast ™ Service

1. The Java™ Reliable Multicast™ Service Phil Rosenzweig Boston Center for Networking Sun Microsystems Laboratories http://www.sunlabs.com/ pmr@east.sun.com 1

2. Outline • Multicast Technology • Push and HTTP • Multicast vs. HTTP for Information Distribution • Reliable Multicast Applications and Requirements • JRM Service Overview • JRM Service Architecture • Tree-base Reliable Multicast Protocol (TRAM) • Automatic Tree Formation • Congestion Detection and Flow Control • Project Status • Future Directions • Questions & Answers 2

3. SCALABILITY is the number one problem in networking…Everything else is secondary 3

4. Multicast Unicast Data Server Data Server One Copy of Entire Data Stream Per User Customized Data Stream Shared By All Users in a Group Client Client Client Client Client Client What is Multicast? 4

5. Routers Replicate Packets R R S R S R R R 5

6. Multicast Scales Better Than Unicast One-to-One (TCP, HTTP) Network Load One-to-Many (Multicast, Broadcast) Receivers 6

7. Multicast is a Key Enabling Technology • Provides a solution to bandwidth crisis, timely delivery and latency control • Bandwidth • enabling audio/video broadcasting, multipoint collaborative applications (shared whiteboard, virtual classroom), multicast file transfer (software distribution) • Timely delivery • news updates, stock tickers, event notification • Latency • make database coherency work • remove serialization of multiple database updates • Most applications require reliable delivery in order to be feasible 7

8. Current State of Multicast • Most routers, switches, NICs and TCP/IP stacks support multicast • Product issues remain: pruning (routers), filtering (switches), addressing (NICs), IGMP (TCP/IP stacks) • MBONE operational on the Internet • See http://www.lbl.gov/WWW-Info/MBONE.html • Significant work in IETF on standardization • IP Multicast (RFC 1112), IGMP, DVMRP, PIM, ... • Reliable multicast is a research topic in the IRTF • Reliable Multicast Research Group (RM) started in March, 1997 • Many protocols proposed and under development • SRM (LBL), RMTP (Bell Labs), TMTP (UKentucky), RMP (Nasa), Starburst, LRMP (Inria), TRAM (Sun Labs) • Hard problems: Congestion control, address allocation, … 8

9. “Push” Technology • Push technology category created by Pointcast, Marimba, others • Gives the illusion of automatic delivery of content to the desktop • “Push” applications are really based on client “pull” technology or polling • Clients configured for what content to pull (minimal server side control) • Clients periodically initiate interaction with server to check for updates • Big problem! These systems are built over... • HTTP infrastructure of the web • Unicast connections (point to point) • Networks are clogged with automated update traffic • Real push requires the ability to multicast updated content to many recipients • Publish/subscribe (event driven updates) can also benefit from multicast 9

10. Top 10 Web Sites (bytes) Source: Optimal Networks Corp Sixth Int’l WWW Conference 10

11. Subscriber Subscriber Desktop Desktop ISP ISP ISP ISP Subscriber Subscriber Subscriber Subscriber Subscriber Desktop Desktop Desktop Desktop Desktop Pointcast Clients Pull From Server HTTP end to end Pointcast Data Center Server Internet Application Content from providers intranet Corporate intranet 11

12. ISP ISP Subscriber Subscriber Subscriber Subscriber Subscriber Desktop Desktop Desktop Desktop Desktop Pointcast with I-Server Pointcast Data Center I-Server Pulls from Data Center Clients Pull From I-Server HTTP end to end Server Internet Application I-Server Content from providers intranet Corporate intranet 12

13. ISP ISP Subscriber Subscriber Subscriber Subscriber Subscriber Desktop Desktop Desktop Desktop Desktop Pointcast with Caching Manager and Multicast Pointcast Data Center Caching Mgr pulls from Data Center Data pushed to clients from I-Server Administrative control at I-Server Server Internet HTTP Application Caching Manager Content from providers Multicast intranet Corporate intranet 13

14. Reliable Multicast Application Types Source: presentation by Mark Handley at the April 1997 meeting of the IRTF RMRG. 14

15. Example: News and Events Distribution Thousands of Receivers Mobile client Reuters CNN Server Mobile client SOURCES App SW Sender Mobile client Network WS Calendar Thin client Thin client Corp Data PC RELIABLE DELIVERY 15

16. JRM Service - A Platform for Multicast Apps • Enables building applications that multicast data from “senders” to “receivers” over “channels” with distributed control over content mix • Organized as a set of libraries and services for building multicast applications • Functional components: • A common API which supports multiple concurrent reliable multicast transport protocols, selectable by applications depending on needs • Tree-based Reliable Multicast Protocol designed for reliable multicast to very large numbers of receivers • Services for multicast address allocation and channel management • Dynamic filtering - Java software pushed into the network to implement policies and data customization downstream at the receiver which are configured at the server 16

17. User data Data & Policy JRM Service Data Flow Model Channel Advertisements Receivers Join Receivers (many) Sender Unreliable Multicast LAN/WAN Reliable Multicast Sending application with JRM Service libraries (reliable multicast) Data • Sender advertises channels, receivers join • Sender sends data over channels to receivers • Data dynamically filtered by Java software downstream • Reliable multicast transport provides timely delivery using low bandwidth Receiving application with JRM Service libraries (reliable multicast) 17

18. Application Channel Management Transport Address Allocation JRM Service Systems • Transport system transports data over multicast • Address allocation system manages multicast address allocation • Channel management system manages channels. This includes: • creating, configuring, and destroying channels • advertising or distributing channel information to receivers and others • encrypting channel data and authenticating senders, receivers, etc. • applying and distributing dynamic filters • multiplexing several channels on a single multicast address 18

19. JRM Service Architecture Application Security Server Channel Management API (CMAPI) Channel Management System Multicast Address Management API (MAMAPI) Multicast Address Manager Encryption Security API Multicast Transport API (MTAPI) Multicast Address Management SPI (MAMSPI) Unreliable Multicast Tree-based Reliable Multicast Protocol (TRAM) Other Multicast Transport Protocols Session Announcement Protocol Allocator (SAPA) Static Administratively Scoped Allocator (SASA) Authentication SAP API SAP Support 19

20. Basic TRAM Model Sender, Group Head Receiver, Group Head Receiver, Group Member Groups Data Cache Multicast Data Message Unicast Ack Message Multicast Local Repair (Retransmission) 20

21. Automatic Tree Formation • Build a tree from the sender which includes all of the receivers in the session • Each receiver is associated with a repair head • Be able to add new receivers to the tree at any time • Recover from head failure through re-affiliation • Operate on networks which may or may not support bi-directional multicast • What is a suitable repair head? • shortest TTL distance • eagerness to be head • number of members (large vs. small) • head experience • repair data availability 21

22. Repair Tree Construction - Unidirectional 1. Beacon sent with session TTL • Triggers heads to advertise 2. Heads advertise with expanding ring search (ERS) 3. Receivers pick “best” head • Smallest TTL • Eager > reluctant • Highest group member count • Advantages • works for one-way multicast nets • Disadvantages • Head advertisement bandwidth • Head advertisements never stop Sender (1) Beacon Head Head (3) HeadBind (2) HeadAdvertisements (4)AcceptMember Receiver 22

23. Repair Tree Construction - Bi-directional 1. Beacon send with session TTL • Triggers receivers to solicit heads 2. Receivers solicit with ERS 3. Heads advertise 4. Receivers pick “best “ head • Advantages • Member solicitation avoids continuous advertisement • Member solicitation provides local isolation • Disadvantages • Member solicitation bandwidth issue when many receivers affiliating simultaneously in LAN environment Sender (1) Beacon Head Head (4) HeadBind (2) MemberSolicitation (5)AcceptMember (3) HeadAdvertisements Receiver 23

24. Optimizations • Combine unidirectional and bi-directional techniques • Unidirectional prior to start of data transmission • Bi-directional following start of data • Ongoing tree optimization • An optimal tree • minimizes TTL of repairs - every member in a group is affiliated to the closest repair head • promotes scalability - multiple repair groups that have few overlapping repair regions • Likely that the initial tree constructed in TRAM is sub-optimal • Every member and repair head continuously optimizes • A member hears from a better repair head • Redundant repair heads (LAN) • Unicast repairs • Reducing the number of repair heads. • Apply LAN-based tree formation algorithm 24

25. LAN-Based Tree Formation • Bottom-up approach: build a subtree on the LAN before affiliating it with the rest of the tree • Previous techniques not optimal for LANs: • Most of the LAN members will affiliate with repair heads that are not on the LAN, resulting in increased TRAM traffic on the link. • All LAN members that are potential repair heads will start advertising for members, causing increased traffic on the LAN. • One repair head on the LAN, suppresses advertisements, reduces LAN to one logical member • Elect a LAN head using bi-directional method and TTL 1 • Members on LAN naturally attach to LAN head • LAN head attaches off the LAN • Elect additional LAN heads from those already affiliated • Small change to packets and algorithms 25

26. Congestion Detection and Flow Control • Receivers (including heads) detect congestion • Use repair tree to aggregate and propagate feedback to sender • Repair heads filter out duplicate congestion reports • Sender filters out duplicate and old congestion reports • Rate-based flow control • Adaptive increase/decrease • Adaptive adjustment cycle (to deal with feedback delay) • Other optimizations • Staggering ACKs • Rate monitoring at sender • Limiting number of unACKed packets outstanding • Duplicate retransmission suppression • Pause sender to allow retransmissions at heads 26

27. Repair Tree and Feedback • Use a window to implement selective ACKs • Each receiver sends an ACK for each window to its parent • ACK may contain a mask of lost packets • ACK may also contain congestion indication • Each receiver tries to send ACKs at a different point in ACK window 27

28. Detecting Congestion • If a receiver sees an increase in the number of missing packets from last window to current window • If a repair head’s cache grows to high-water-mark • If a repair head gets an ACK that contains congestion report (not previously sent) 28

29. Rate Based Flow Control • Sender uses a token bucket to send packets at a given rate • Increases/decreases rate based on congestion signal • Maintains rate within pre-configured maximum and minimum • Receivers that cannot deal with the minimum rate get “pruned” 29

30. Adaptive Increase and Decrease • Upon congestion, sender reduces rate by 50%, as recommended • How much should the increase be? • Use “slow start” initially • initial rate = 10% maximum • increment = 10% maximum • A constant amount is always wrong for some network • Some bad ideas: • adapt using most recent peak rate • adapt using moving average rate • lead to diminishing increases, oscillation, inability to achieve optimal rate • Following a decrease, recalculate increase amount increment = ( historical peak rate - current rate ) / 4 30

31. Project Status • Project start - 3/97 • 6 internal software releases completed • Pilot applications built so far • File transfer • Stock ticker • Chat (multi-sender) • 2 technical reports published • http://www.sunlabs.com/technical-reports/1998/1998.html 31

32. Future Directions • Adaptive congestion control • Repair tree optimization • Linkage to physical topology (router assist) • Security in a multicast environment • Key distribution and management for authentication and encryption • New IRTF research group forming • Multicast address allocation • Coordination across organizational boundaries • IETF malloc working group • Performance 32