icdcs99

Fault Tolerant Video-On-Demand Services: 

Fault Tolerant Video-On-Demand Services Tal Anker, Danny Dolev, Idit Keidar, The Transis Project

VoD Service: 

VoD Service VoD: Full VCR control 1 video stream per client Client C1 VoD Service provider Requests Video Stream Movies disk(s)

High Availability: 

High Availability Multiple servers at different sites Fault tolerance: servers can crash Managing the load: new servers can be brought up / down load should be re-distributed 'on the fly' migration of clients

The challenges: 

The challenges Low overhead Transparency How do clients know whom to connect to? 'abstract' service Clients should be unaware of migration

Buffer Management andFlow Control: 

Buffer Management and Flow Control Overcome jitter, message re-ordering and migration periods Re-fill buffers quickly after migration avoid buffer overflow Minimize buffers minimize pre-fetch bandwidth Dynamically adjust transmission rate to client capabilities Re-negotiation of QoS

Features of our solution: 

Features of our solution Use group communication in the control plane connection establishment fault tolerance and migration Flow control explicitly handles migration Low overhead ~1/1000 of the bandwidth Negligible memory and CPU overhead Commodity hardware and publicly available network technologies

Environment: 

Environment Implementation UDP/IP over 10 Mbit/s switched ethernet Transis Sun Sparc and BSDI PC’s as video servers Win NT machines as video clients MPEG1 andamp; 2 hardware decoders Machine and Network Failures

Implementing the abstract service: 

Implementing the abstract service Use group communication clients communicate with a well known group name (logical entity) unaware of the number and identity of the servers in the group Servers periodically share information about clients (every 1/2sec) If a server crashes (or is overloaded), another server transparently takes over

Group Communication: 

Group Communication Reliable Group Multicast (Group Abstraction) Message Ordering Dynamic Reconfiguration Membership with Strong Semantics (Virtual Synchrony) Systems: Transis, Horus, Ensemble, Totem, Newtop, RMP, ISIS, Psync, Relacs

The group layout of the VoD service: 

The group layout of the VoD service

Transis Allows Simple Design: 

Transis Allows Simple Design Group abstraction for connection establishment and transparent migration Reliable group multicast allows servers to consistently share information Membership services detects conditions for migration Reliable messages for control Server takes ~2500 C++ code lines Client takes ~4000 C code lines (excluding GUI and display)

VoD Client: Multi Threaded Design: 

VoD Client: Multi Threaded Design Client buffer accounts for jitter period when migration occurs Obviously, Flow-Control and Buffer management were needed

Flow Control: 

Flow Control Feedback based flow-control (sparse): FC messages are sent to the logical server (session group) Clients determines the changes in the flow:

Emergency Flow Control: 

Emergency Flow Control When the server receives an emergency message: The server change the fps rate: fps = latest-known-fps + emergency quantity The emergency quantity decays every second (by a factor) While the quantity is above zero, the server ignores FC messages from the client

Performance Measurements : 

Performance Measurements On HUJI Network (LAN) Servers at TAU and clients at HUJI (WAN) The measurements show the system is robust and support our transparency claims

Software Buffers: 

Software Buffers

Hardware Buffers: 

Hardware Buffers

Skipped Frames on LAN: 

Skipped Frames on LAN

Skipped Frames on WAN: 

Skipped Frames on WAN

Summary: 

Summary Scalable VoD service Load balancing Tolerating machine and network failure All the above are achieved practically for free: ~1/1000 of the total bandwidth Negligible memory and CPU overhead

Thanks to ...: 

Thanks to ... Gregory Chockler The other members of the Transis project