1. SomeCast A 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 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 Real-Time data - stocks - auctions - QoS requirements - reliability - timeliness Network is best-effort e.g., Internet

3. Why a New Paradigm? RTP/UDP trades reliability for timeliness ARQ trades timeliness for reliability - e.g., TCP for unicast, SRM for multicast Deadline-aware ARQ improves timeliness, but does not hide congestion-induced delays - e.g., Li, Ha and Varghavan work on TCP FEC approaches are not deadline-aware - e.g., SHARQFEC of Kermode, our ARM

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

5. SomeCast Features Supports Real-Time Reliable Multicast 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. 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) K = 20 pkts 100 ms time Received 8 pkts Member of S1 with thruput 100 pkt/s Join S2 (thruput 40 pkt/s) Deadline Received 8+5+2=15 pkts Expects 5 more pkts from S1 and 2 from S2 Received 22 pkts (successful recovery)

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