RSVP Support in MediaBase VoD Streamer Improving QoE for VOD Subscribers using RSVP Sanjay Mehta

QoE of Managed Video services SP IPTV managed video services (live and VOD) rely on Diffserv & generous Capacity-Planning to ensure QoE This is feasible & cost economical when video load is small or predictable, and when operator is willing to tolerate widespread QoE degradation in the face of less common combination of events (*) This is not cost-economical when video peak is unpredictable, or when the operator wants to minimize QoE degradation in the face of rare combination of events (*)  Some SPs plan to use resource reservation protocols for the services to scale and deliver deterministic video quality experience (*) e.g. dual failures, failure during unexpected peak,…

RSVP Value RSVP provides an end-to-end reservation protocol which allows network resources to be allocated for VOD sessions Resources are allocated before the video session starts, allowing a go or no-go decision before the stream starts Resources can be reclaimed from some sessions after establishment (e.g. congestion after network failure/reroute), allowing to protect QoE of remaining sessions Well suited for IPTV operator as services are implemented in managed networks that can deploy RSVP between source and destinations (or edge)

RSVP and RTSP RTSP is the streaming protocol used for VOD DESCRIBE, SETUP, PLAY, TEARDOWN, etc. RSVP messages need to be interleaved/synchronized with RTSP messages PATH, RESV, PATH-TEAR, RESV-TEAR, etc. In our VOD server, RSVP reservations are optional for first-phase Allow for site by site deployment of RSVP Second-phase will require RESV before starting the stream

Successful request (“Optional Reservation” Mode) STB sends a stream request VOD server sends a PATH message and starts streaming after getting RTSP play command STB or Receiver Proxy sends the RESV VOD server replies with a RESV-CONF if requested Once the RTSP stream is torn-down a PATH-TEAR is send by the VOD server

Failed request (“Optional Reservation” Mode) STB sends a stream request VOD server sends a PATH message and start streaming after getting RTSP play command A router on the path to the STB does not have enough resources so it sends a PATH-ERR or RESV-TEAR VOD server send a PATH- TEAR and stop the RTSP session

RSVP Implementation Implemented an end-point RSVP library under Linux RedHat 5.x and used that library to introduce RSVP for a VOD server RFC2205 Written in C with C++ wrapper Simple API session = rsvp_create_stream(spec, callback) callback ( event, session, data)  switch(event) {  case RSVP_API_PATH_ERROR:  case RSVP_API_RESV_RECEIVED: ..... Tested at customer site

RSVP Testing Testing performed at SP site in France 4000 streams per VOD server  2.2 Mb/s per stream, 8.8 Gb/s total  Refresh interval 5 seconds  Very low CPU utilization  No need for RFC 2961 RSVP Refresh Reduction mechanism Rerouting of streams Simulate link failure

Protocol extensions As RSVP gets deployed and more sophisticated video services are supported, it is likely that small extensions may be needed

Conclusion In well managed network RSVP can provide bandwidth reservation for IPTV services improving QoE as video traffic increases The protocol is easy to implement and integrates well with streaming protocols as for example RTSP The protocol scales well and it is supported by some network equipment providers

Successful request – Backup slide (“Mandatory Reservation” Mode) STB sends a stream request VOD server sends a PATH message STB or Receiver Proxy sends the RESV VOD server replies with a RESV-CONF if requested STB send a RTSP Play Request and the VOD server starts streaming Once the RTSP stream is torn-down a PATH-TEAR is send by the VOD server