SomeCast A Paradigm for Real-Time Adaptive Reliable Multicast

1. SomeCastA Paradigm for Real-Time Adaptive Reliable Multicast Presented by: Ibrahim Matta IEEE Real-Time Technology and Applications Symposium (RTAS ‘2000), May 30 – June 2, 2000, Washington D.C. Joint work with Jaehee Yoon and Azer Bestavros Computer Science Department Boston University {matta, jaeheey, bestavros}@cs.bu.edu

2. The SomeCast Paradigm Network is best-effort e.g., Internet QoS requirements - reliability - timeliness • Real-Time data • stocks • auctions • Data encoding is distributed to proxies (senders) • Sender multicasts its data • Client (receiver) joins as many multicast groups as needed • to reliably recover data by its deadline

3. Why a New Paradigm? • RTP/UDPtrades reliability for timeliness • ARQtrades timeliness for reliability - e.g., TCP for unicast, SRM for multicast • Deadline-aware ARQimproves timeliness, butdoes not hide congestion-induced delays - e.g., Li, Ha and Varghavan work on TCP • FECapproaches are not deadline-aware - e.g., SHARQFEC of Kermode, our ARM

4. SomeCast accesses SOME servers basedon current network state and client’s deadline Why a New Paradigm? • AnyCastselects “best” server - e.g., Fei, Bhattacharjee, Zegura and Ammar • ManyCastaccesses replicated servers concurrently - e.g., work of Byers, Luby and Mitzenmacher

5. SomeCast Features • Supports Real-Time ReliableMulticast • Receiver-initiated, thus scalable in - number of receivers - diverse path characteristics and conditions • Meet QoS while conserving resources - receiver joins SOME concurrent multiCAST sessions - approaches AnyCast when deadline is loose - approaches ManyCast when deadline is stringent

6. FEC Dispersal and Reconstruction • Source employs FEC (e.g., Reed-Solomon Codes) • Original K data packets are dispersed into s K packets; • s > 1 is “stretch” factor • Receiver reconstructs original data by recombining • any K packets

7. A SomeCast Protocol: Overview • s K encoded packets distributed to senders • Sender multicasts data as long as one or more receivers are members of its group • Initially, a receiver joins one or more groups • Receiver periodically estimates its throughput from each sender • Receiver adjusts number of groups it is a member of based on number of packets it expects to receive by its deadline

8. SomeCast Receiver • Receiver maintains number of packets received from each sender • When K packets are received by deadline, receiver decodes data and leaves all groups it is a member of • Receiver periodically updates its throughput estimate from each sender • Receiver estimates number of packets expected from each sender by the deadline: expPkts = Throughput x (Deadline - now)

9. K = 20 pkts Received 8+5+2=15 pkts Received 8 pkts Member of S1 with thruput 100 pkt/s Deadline 100 ms time Join S2 (thruput 40 pkt/s) Expects 5 more pkts from S1 and 2 from S2 Received 22 pkts (successful recovery) SomeCast Receiver (cont’d) • Receiver computes total number of packets it expects from senders it is subscribed to • Receiver joins additional sender(s), or leaves redundant sender(s)

10. SomeCast Extensions • Selection of the best set of senders - static and dynamic measures, e.g., distance, congestion, load • TCP-friendly transmission by senders - even if sender reduces its rate, a receiver can recover by joining more senders

11. Simulation Model • SomeCast compared against UniCast and ManyCast using ns simulator • UniCast: receiver only joins primary sender • ManyCast: receiver joins all senders all the time • SomeCast-1 - receiver starts with one sender (the primary) • SomeCast-N - receiver starts with all N senders

12. Simulation Model (cont’d) • Senders are CBR, N = 5 • Up to 32 on-off cross • connections on each link, • up to 30% loss rates at receivers • 1 MB original data, K=1000 packets • Each sender has 2K encoded packets • Simulation stopped when every receiver • receives K packets by deadline, or • simulation clock exceeds deadline

13. Performance Metrics • Guaranteed Deadline Percentage - percentage of receivers which successfully received K packets by deadline • Goodput - ratio of useful packets received to packets sent • Average Number of Groups Joined - average number of groups that a receiver joins

14. Performance vs Laxity • SomeCast strikes a good balance • - approaches ManyCast at lower laxities • - approaches UniCast at higher laxities

15. Number of Groups vs Laxity • SomeCast receiver adapts number of groups • to which it subscribes depending on deadline

16. Effect of Update Frequency in SomeCast-1 • With more frequent updates, a receiver can adjust its • level of service in a more timely fashion • SomeCast-1 receiver can join more senders at lower laxities

17. Effect of Update Frequency in SomeCast-5 • With more frequent updates, especially at higher laxities, • a receiver can leave redundant groups in a timely fashion

18. Conclusions • SomeCast paradigm supports - reliable multicast of real-time data - a large set of heterogeneous receivers • Receiver-initiated, thus scalable in - number of receivers - diverse path characteristics/conditions • SomeCast performance - superior to ManyCast and AnyCast