1. Video On Demand

2. Video on Demand One video server Many video data Many clients
Client want to watch at any time
In this lecture, we will look at some representative research in video on demand protocols. Imagine you have a video server, loaded with tons of video. Clients can send request to the server and request to watch a particular video. The server have to response by streaming the requested video to the client. We want to be able to support large number of clients, and clients should be able to watch at anytime.
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

3. Assumptions Constant bitrate stream Perfect network transport
All of the work we will study today make simplifying assumptions about the data and network. Firstly, it assumes that the video data are encoded at a constant bitrate. Secondly, it assumes that the network is perfect – no packet loss, no jitter, no fluctuating available bandwidth. These assumptions are not reasonable for Internet, but is suitable for CATV network.
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

4. Unicast Solution One channel per client No start-up latency
No client buffer
Low client bandwidth
Large server bandwidth
Not scalable
Even with these assumptions, the problem of serving video to large number of clients remain challenging. Let’s look at the most straight forward solution. Suppose the server send a new stream in response to each new client request. Under this scheme, there is little start-up latency – the client only have to wait for one round trip time to receive the stream. The client bandwidth requirement is also small – it only needs to downlaod at the rate the video is playback. There is no buffer required at the client. The server, however, requires large amount of bandwidth to support large number of clients. Therefore the scheme is not scalable at all.
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

5. Multicast Solution Batching aggregate client requests
serve using multicast
clients have to wait
No client buffer
Low client bandwidth
“Scheduling Policies for an On-Demand Video Server with Batching”
Dan, Sitaram, Shahabuddin, IBM
The other obvious solution is to use multicast to serve clients requesting the same video. Clients requests that arrive with a short time period (say 10 minutes) can be served together using a single multicast stream. The drawback is that the clients have to wait. The obvious tradeoff here is the client waiting time and server bandwidth. Just like the unicast solution, the client does not need any buffering or any additional bandwidth.
This approach is call batching, because clients are served in batch.
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

6. Multicast Solution User-centered approach Data-centered approach
Scheduling data based on user requests
Data-centered approach
Don’t care about user
Just broadcast popular video
Batching is considered a user-centric approach. Data streams are scheduled based on user requests. If no client requests any stream, no stream is sent.
The other approach, which we will focus on today, is the data-centric approach. Under this approach, the server just multicast videos on to specific channels, and don’t care about users. User can just tune in to watch the video she desires. This approach is similar to that of TV or VoD on plane. This is useful for broadcasting hot video. This is the method we will focus on today.
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

7. Multicast Solution Batching Staggered Broadcast
Let’s begin by looking at the simplest way to implement a data-centric vod – staggered broadcast.
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

8. Staggered Broadcast Video C0 C1 C2 :
Staggered broadcast just begins broadcasting a video periodically, at regular interval. Client can tune in to a channel, and wait for the beginning of the video. C1 C2 :
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

9. Staggered Broadcast 2 hour video 5 minutes waiting time
Number of channels =
2 x 60 / 5 = 24
Required bandwidth =
The server needs large amount of bandwidth to support staggered broadcast. Suppose we have a 2 hour video, and we set the maximum client waiting time to be 5 minutes. The server will need to send the video in 24 different channels. This translates to 36Mbps per video (assume VCD). The advantage is that client does not require buffers.
1.5Mbps x 24 = 36Mbps
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

10. Multicast Solution Batching Staggered Broadcast clients have to wait
No client buffer
Low client bandwidth
Huge server bandwidth
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

11. Multicast Solution Batching Staggered Broadcast Periodic Broadcast
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

12. Periodic Broadcast Video C0 C1 C2 :
Periodic broadcast uses technique that is very similar to staggered broadcast. However, instead of broadcast each video entirely in each channel, periodic broadcast divide the video into segments. Each segment can then be broadcast to different channel. Client will tune into different channel at different time to receive different segments of the video. Because client have to wait for the beginning of the first segment to start watching the video, the time the client have to wait is equal to the first segment. C0 C1 C2 :
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

13. Pyramid Broadcast Video C0 C1 C2 :
If we make the first segment smaller, then we can reduce the waiting time! This is the basic idea behind pyramid broadcast. Pyramid broadcast divide a video in segments who size is an increasing geometric series.
Client receive data from two channels at one time. C0 C1 C2 :
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

14. Pyramid Broadcast Video C0 C1 C2 :
Let’s look at pyramid broadcast in greater details. We want to analyze the server bandwidth requirements, clients waiting time, client buffer requirements and client bandwidth requirements.
First, note that if we send each segment in each channel at the same rate as the video, we will encounter “hiccup” – discontinuity in video playback. We now analyze how much bandwidth the server need to broadcast one video. C0 C1 C2 :
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

15. Analysis of Pyramid Broadcast
Notations
B : Total available bandwidth
Bv : Bandwidth of video
Tv : Total length of each video
K : Number of segments per video
Ti : Length of segment i
 : Factor in geometric series
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

16. Channel Bandwidth playback time = Ti D’oh! download time = Ti+1Bv/Bi
Just
miss
it!
download time = Ti+1Bv/Bi
Download time for segment i+1 needs
to be smaller than Ti for it to arrive in time.
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

17. Channel Bandwidth NUS.SOC.CS5248-2010
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

18.  = 2
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

19. Start-up Latency Worst case waiting time = NUS.SOC.CS5248-2010
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

20. Optimal  T1 
2.5
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

21. Storage Requirements NUS.SOC.CS5248-2010
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

22. Pyramid Broadcast Large client bandwidth (KBv)
Huge client buffer (70–80% Tv)
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

23. Permutation-based Pyramid Broadcast
Permutation-based pyramid broadcast (PPB) is a combination of staggered broadcast and pyramid broadcast (PB)
It has two main differences vs PB: (1) Each segment is staggered and broadcast in p channels. (2) Client downloads one channel at a time (3) client can pause while download a segment, and resume later from another channel. C0 C1 C2
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

24. Channel Bandwidth playback time = Ti D’oh! Just miss X
it! X
download time = Ti+1Bv/Bi
X needs to be smaller than Ti for segment
i+1 to arrive in time.
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

25. Channel Bandwidth NUS.SOC.CS5248-2010
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

26. Client Latency NUS.SOC.CS5248-2010
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

27. Storage Requirement One channel at a time Can pause and wait
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

28. Storage Requirement Within time X, better not consume all data
pause
k-1
k-1 k
resume k
Within time X, better
not consume all data
in buffer. X
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

29. Storage Requirement Within time X, better not consume all data
pause
k-1
k-1 k k
resume
Within time X, better
not consume all data
in buffer. X
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

30. Storage Requirement NUS.SOC.CS5248-2010
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

31. Comparisons Scheme Storage Server’s BW Client’s Pyramid 70% KBv
20%
(+p)KBv
2-3 Bv
PBP has huge improvement in client access latency, storage requirement and bandwidth, at the expense of larger server’s bandwidth.
Carter, Long and Paris
“Video on Demand Broadcasting Protocols”
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

32. Pyramid Broadcasting NUS.SOC.CS5248-2010
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

33. Skyscraper Broadcasting
Observations:
storage requirement is affected by size of the largest chunk
So, let’s limit the size of the largest chunk!
The next broadcasting scheme we will see today is skyscrapper broadcasting. It is different from the previous scheme in that (1) it limits the size of a largest chunk, (2) the series is design in such a way to reduce channel bandwidth and client buffer. (3) the channel bandwidth is the same as the video bandwidth. (4) client have to downlaod from two channels at a time.
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

34. Pyramid Skyscraper NUS.SOC.CS5248-2010
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

35. Skyscraper Broadcasting
Uses series
… W W W
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

36. Skyscraper Example NUS.SOC.CS5248-2010
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

37. Skyscraper Example NUS.SOC.CS5248-2010
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

38. Comparisons Scheme Storage Server’s BW Client’s Pyramid 70% KBv
20%
(+p)KBv
2-3 Bv
Skyscraper
10%
KBv
1-2 Bv
Carter, Long and Paris
“Video on Demand Broadcasting Protocols”
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

39. Other schemes Pagoda Broadcasting 1 3 5 15 25 75 125 …
Harmonic Broadcasting
Equal segment size, varies bandwidth instead!
There are many other broadcasting schemes – just to name a few, pagoda broadcasting that uses a different series. Harmonic broadcasting that uses equal segment size, but varies the channel bandwidth instead.
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

40. Multicast Solution Batching Staggered Broadcast Periodic Broadcast
Sending rate ≥ playback rate
May need multiple channels
Need additional client buffer
Need to wait
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

41. Multicast Solution Batching Staggered Broadcast Periodic Broadcast
Patching
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

42. Patching Time mcast unicast Client Request
All periodic broadcast protocols requires client to wait before viewing video. This is sometimes called “near” voD. Patching is a “true” VoD protocol. Clients can start watching immediately after request, provided the server have enough channels.
The server multicast a new video, based on previous requests. Suppose a client wants to join and watch the same video. The server can unicast a patch stream to the client immediately. The client, will download the patched stream, and the multicast stream. The patched stream is played back immediately. The multicast stream is stored and when the patched stream is done playing, the client will continue playback from the multicast stream.
unicast
Client Request
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

43. Patching Patching Window: W Time mcast mcast Client Request
The patching window W is a threshold, if client request arrives within the patching window, a patch stream will be sent. If the patching window is large, in the worst case, the client may have to buffer a lots of data. If W is larger than client buffer, B, the server will have to start a new multicast stream.
mcast
Client Request
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

44. Grace Patching if W < B client buffer video[W .. end]
30 minutes video
1 client arrival per minute
Total data delivered =
This is call grace patching.
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

45. Scenario 1: B = 15mins 30 minutes video 1 client arrival per minute
Total data delivered =
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

46. Scenario 2: B = 5mins 30 minutes video 1 client arrival per minute
Total data delivered =
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

47. Scenario 3: B = 2mins 30 minutes video 1 client arrival per minute
Total data delivered =
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)

48. Summary Batching (User Centered) Staggered Broadcast (Data Centered)
Periodic Broadcast (Data Centered)
Patching (True VOD)
NUS.SOC.CS
Roger Zimmermann (based in part on slides by Ooi Wei Tsang)