1 / 14

Slingshot: Time-Critical Multicast for Clustered Applications

Slingshot: Time-Critical Multicast for Clustered Applications. Mahesh Balakrishnan Stefan Pleisch Ken Birman Cornell University. The Contemporary Datacenter. Building-wide super-clusters: 1000s of commodity blade-servers Typically used as commercial website back-ends: Amazon, etc.

jkeiper
Download Presentation

Slingshot: Time-Critical Multicast for Clustered Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Slingshot: Time-Critical Multicast for Clustered Applications Mahesh Balakrishnan Stefan Pleisch Ken Birman Cornell University

  2. The Contemporary Datacenter • Building-wide super-clusters: 1000s of commodity blade-servers • Typically used as commercial website back-ends: Amazon, etc. • Software Paradigms: SOA, Eventing, Publish/Subscribe… • … many-to-many communication, Multicast!

  3. Multicast in the Datacenter • IP Multicast available: adding reliability to it is a well-researched technology… • Scalability dimensions • Number of receivers • Number of senders? • Number of groups? • Metrics • Throughput • Timeliness?

  4. Time-Critical Applications • … dealing in perishable data: stock quotes, location updates • … willing to trade complete reliability for timeliness • … requiring tunable reliability/ timeliness/ overhead tradeoffs • Probabilistic Guarantee of Timeliness? • For x% overhead, y% of lost packets are recovered in time t. • Remainder can be optionally recovered in time t’.

  5. Design Space • Reactive vs. Proactive • Reactive: Loss Discovery • ACK • Sender-Based Sequencing • If the multicast rate in a group is constant, the inter-multicast time at any sender goes up linearly with the number of senders • Gossip – Scalable • Proactive: FEC – Tunable

  6. Slingshot Overview Receiver-Based FEC: Senders send initially via unreliable IP Multicast Phase 1: Receivers repair losses by proactively sending each other FEC repair packets Phase 2: Remaining losses are recovered from the sender Each receiver sends an error correction (XOR) packet to c randomly selected receivers with the last r packets it received Rate-of-fire parameter (r, c): Allows tuning of overhead-timeliness tradeoff

  7. Protocol Details 0 • Two Packet Types: Repair Packet : List of Data Packet IDs: (sender1,seqno1), (sender2,seqno2)…. Data Packet : Packet ID (Sender, SeqNo) Less than Network MTU Application MTU: 1024 XOR of Data Packets Application Payload Terminology: Data packets are included in repair packet

  8. Protocol Details 1 • Data Structures: • Data Buffer: received data packets • Repair Bin: pointers to last <r data packets • Arrival of Data Packet dp at Receiver: • dp is added to the data buffer • &dp is added to the repair bin • If repair bin size equals r, a repair packet rp is created from its contents, and the repair bin is cleared • rp is dispatched to c random receivers

  9. Protocol Details 2 • Arrival of Repair Packet rp at Receiver: If #(missing included data packets) == • 0: rp is discarded • 1: it is recovered by XORing rp with the other r-1 data packets • >1: rp is stored in a special buffer, in case future data packet arrivals and recoveries make it usable

  10. Evaluation Setup • 64 node rack-style cluster at Cornell • Loss rate fixed at 1%: packets dropped at end buffers • All nodes send and receive • Inter-node latencies = 50-100 microseconds • Group Data Rate: 1000 packets per second • Each node multicasts 64 packets per second; i.e one packet every 64 milliseconds

  11. Slingshot Tunability For 27% overhead, 93.5% Lost Packets are recovered at an avg. of 3.5 milliseconds Example Tradeoff Points between Overhead, Timeliness, and Reliability Overhead and Recovered Packets plotted on left y-axis, Recovery Time on right

  12. Slingshot vs SRM Slingshot recovers 93% in 10 ms, 97% in 25 ms Fastest SRM packet Recovery is 2.2 seconds 93% in 4.85 seconds, 97% in 5.1 seconds 2-3 Orders of Magnitude faster

  13. Slingshot Scalability: Group Size Simulation Results: Gossip-Style Scalability: Insensitive to scale beyond a certain size

  14. Conclusion • Slingshot provides a tunable, probabilistic guarantee of timeliness • Outperforms SRM by 2 orders of magnitude in a 64 node system • Insensitive to number of senders • Future Work: • Achieve scalability in other dimensions (number of groups) • Build a time-critical middleware layer that uses Slingshot as a generic primitive

More Related