CS558a Syllabus & Progress

Skyscraper Broadcast Technique for Video on Demand

Reading material source:
- "Skyscraper Broadcasting: A New Broadcasting Scheme for Metropolitan Video-on-Demand Service", click here
- by: K. A. Hua and Simon Sheu
- published in: ACM SIGCOMM, 1997

Skyscraper Broadcasting

Approach taken by Pyramid broadcast:
- Given a number of video objects
- Choose the number of fragments K in which each video object will be divided.
- Divide each video object into K fragments where the size of fragment i+1 is:
- Based on various system parameters, we will choose f to be at most:
- The size of fragment i+1 is not easy to determine; since it is determined indirectly by first choosing the parameter K (and computing f using K)
- As a result, the sizes of the fragments resulting in the Pyramid Broadcasting method is unpredictable...

Approach taken by Skyscraper broadcast:

Given a number of video objects
"Choose" the number of fragments K in which each video object will be divided.
(I keep using the work "choose" because I want to relate to the Pyramid Broadcast method.
Yet, I put the word "choose" is in quotes, because, we don't really have a choice - we always have: K = B/M)
Divide video into K fragments

Unlike Pyramid Broadcasting, the relationship between the size of fragment i+1 and the size of the previous fragment i is pre-determined in Skyscraper Broadcasting :

D₁ = 1 * D₁
D₂ = 2 * D₁
D₃ = 2 * D₁
D₄ = 5 * D₁
D₅ = 5 * D₁
D₆ = 12 * D₁
D₇ = 12 * D₁
D₈ = 25 * D₁
D₉ = 25 * D₁
and so on... (this relationship will be discussed below)

Notice that in Skyscraper Broadcasting , we know the relative size in advance :

In Pyramid Broadcasting, the relative size is variable (f) - and it can change...
In Skyscraper Broadcasting, the relative size are constant (2, 5, 12, 25, etc) - and they CANNOT change...

Result: less surprise about the size of each fragment....
In Skyscraper Broadcasting, we have (almost) total control on how fast the fragment size grows.....

Advantages of Skyscraper Broadcasting
- Skyscraper Broadcasting has lower disk storage requirement than Pyramid Broadcasting
- Skyscraper Broadcasting has lower lower disk bandwidth requirement than Pyramid Broadcasting
Disadvantage of Skyscraper Broadcasting
- Channel efficiency is not as good as Pyramid broadcasting....
  (I.e., Skyscraper Broadcasting need to use more channels than Pyramid Broadcasting to broadcast the same set of videos
  (you don't get something for nothing, also known as "The Law of Conservation of Misery" in Mathematics)
(I personally find this technique exceptionally beautiful...)
Parameters of the Video on Demand system (recall):
- B = The bandwidth of the entire channel
- M = number of video objects
- D = length of one video object (all video objects have same length)
- B and D have been normalized to use as unit the consumption rate video (each unit is b bits/sec)

Partitioning of the video object in Skyscrapper broadcasting

Similar to Pyramid Broadcasting, each video object in Skyscrapper Broadcasting is also partitioned into K fragments
The fragments also have increasing sizes...
But the sizes do not increase exponentially, rather, "quasi" linearly:
Let D_i denotes the size of the video fragment i
Then:

More precisely, the size of fragment i is:

D_i = f(i) * D₁

where f(1) = 1 is defined as:

f(1) = 1
f(2) = 2
f(3) = 2
f(n) = 2 f(n-1) + 1, if n is divisible by 4
f(n) = f(n-1), if n-1 is divisible by 4
f(n) = 2 f(n-1) + 2, if n is even but not divisible by 4
f(n) = f(n-1), if n-1 is even but not divisible by 4

If you have a hard time with the formulas, just remember this sequence:

Start with 1, 2, 2, then repeat:
double it and add 1
same
double it and add 2
same
double it and add 1
same
double it and add 2
same
etc...

Result: 1, 2, 2, 5, 5, 12, 12, 25, 25, 52, 52, 105, 105, 212, 212, ...

The name Skyscraper Broadcasting
- Just a point of interets:
The Skyscraper Broadcasting Algorithm
- The Skyscraper Broadcasting method consists of:
  - Transmission algorithm used by the sender
  - Receive algorithm used by each receiver.
- Just like the Pyramid Broadcasting method, the Skyscraper Broadcasting method transmits each fragment in one single channel
  (And will therefore transmit the video object in K channels, since one video object is partitioned into K fragments)
Transmission method of skyscraper broadcasting - Part 1
- The transmission medium has a total bandwith of B (normally by the consumption rate b bps)
- The transmission medium is partitioned into B channels, each channel with a data rate of 1 (that means that each channel transmits at the consumption rate b bps)
  In other words:
  This is exactly the same as how cable/satelite channels likes to transmit the video !
- The B channels are divided evenly among the M video objects
- Thus each video object will receive:
  - B/M channels
  for its own use.
- To use up these B/M channel, each video object is divided into this number of fragments.
  In other words:
  fragments, and each fragment is sent on its own channel

Fragment Sizes in Skyscraper Broadcast

As I mentioned before, the number of fragments K is not chosen, but determined as K = B/M from the video parameters

Recall, that the sizes of the fragments are:

D₁ = 1 * D₁
D₂ = 2 * D₁
D₃ = 2 * D₁
D₄ = 5 * D₁
D₅ = 5 * D₁
D₆ = 12 * D₁
D₇ = 12 * D₁
D₈ = 25 * D₁
D₉ = 25 * D₁
....
D_K = ... (stop at K because there are K fragments

The length of the first fragment can be determined from the following relation:
Each of the variables D_i can be expressed as some multiple of D₁,
By substituing all D_i as some multipl of D₁, we can find D₁ (because D is given - it is a parameter of the problem)

Transmission method of skyscraper broadcasting - Part 2
- After dividing each video object into K = B/M fragments, each fragment will be broadcast repeatedly on its own channel (just like Pyramid Broadcasting)
- Example:
  1. The example shows one video object divided into 5 fragments
  2. Fragement 1 has a certain size (computed as decribed above)
  3. Fragement 2 and 3 has a size that is twice that of fragment 1
  4. Fragement 4 and 5 has a size that is five times that of fragment 1
    (For clarity, I have display a scale at top that has a unit the size of video fragment 1.)
Odd and Even sized Fragments
- The fragments:
  are called odd sized fragments (because they are an odd multiple of D₁).
- The fragments:
  are called even sized fragments (because they are an even multiple of D₁).
Receive process for skyscraper broadcasting
- The Skyscraper receiver consists of 3 independent processes:
  1. An odd loader that tunes to channels that broadcast odd sized fragments.
    The odd loader downloads odd sized fragments one after the other in sequence.
  2. An even loader that tunes to channels that broadcast even sized fragments.
    The even loader downloads even sized fragments one after the other in sequence.
  3. A video player that plays out the fragments in the proper order
    (this component will not be discussed, the key to the operation of Skyscraper Broadcasting are the "odd" and "even" loaders)
- NOTES:
  1. The odd loader and the even loader operate independently
    The skyscraper receiver can simultaneously download from 2 channels (while at the same time playing out the video).
  2. Because the odd loader and the even loader are independently, an odd sized fragment and an even sized fragment can start their download simultaneously
  3. Since there is only ONE odd loader and ONE even loader, TWO odd sized fragments or TWO even sized fragments CANNOT start their download simultaneously
  4. A fragment in Skyscraper Broadcast can only be received starting from the beginning (i.e., not from the middle) - this simplifies the download method

Does the Skyscraper Broadcast method work ???

If you are already convinced that the Skyscraper works, then I have a bridge for sale :-).

The $64,000 question that we have to ask is:

Can the receiver download and display the entire video object uninterrupted ?

By that we mean: once the receiver start downloading fragment 1 of the video, can he download fragment 2 in time, and then fragment 3, and so on ?

To obtain the entire video uninterrupted, the data of the next fragment must be available (either it has been pre-fetched or it can be downloaded immediately) when the current segment is completely played out...
Before I show the formal proof (from the paper click here ), I will give you some idea what the scheme is doing using various scenarios....

Receive Example 1:
- The following picture shows a receiver that starts downloading the video between "times" 4 and 5:
  1. Both the odd loader and the even loader begin searching for their fragments at the start time.
  2. The odd loader starts downloading fragment D₁ (and the player start displaying) at time 5.
  3. The even loader starts downloading fragment D₂ at time 6.
    At time 6, odd loader starts looking for fragment fragment D₄ (which it finds at time 10).
  4. The even loader finished downloading fragment D₂ at time 8 and immediately starts downloading fragment D₃ (because the start of fragment D₃ coincides with the end of fragment D₂ - this is planned because these pairs of fragments have the same size !!!)
  5. The even loader finished downloading fragment D₃ at time 10 and luckily the odd loader starts downloading fragment D₄ at time 10
    The viewing of the video is uninterrupted
Receive Example 2:
- The following picture shows a receiver that starts downloading the video between "times" 0 and 1:
  1. Both the odd loader and the even loader begin searching for their fragments at the start time.
  2. The odd loader starts downloading fragment D₁ (and the player start displaying) at time 1.
  3. The even loader starts downloading fragment D₂ at time 2.
    Also, at time 2, odd loader finished downloading fragment D₁ and starts looking for fragment fragment D₄ (which it finds at time 5).
  4. The even loader finished downloading fragment D₂ at time 4 and immediately starts downloading fragment D₃ (because the start of fragment D₃ coincides with the end of fragment D₂ - this is planned because these pairs of fragments have the same size !!!)
  5. The even loader finished downloading fragment D₃ at time 6 and luckily the odd loader started downloading fragment D₄ at time 5 - some video will be buffered as depicted in the following figure:
    The viewing of the video is again uninterrupted
  (The pre-fetch technique is not new, we have seen that in Pyramid broadcasting...)

Receive Example 3:

The following picture shows a receiver that starts downloading the video between "times" 1 and 2:
1. Both the odd loader and the even loader begin searching for their fragments at the start time.
2. The odd loader starts downloading fragment D₁ (and the player start displaying) at time 1.
  The even loader also starts downloading fragment D₂ (and the player start displaying) at time 1 (video fragment will be buffered).
3. At time 2, odd loader finished downloading (and displaying) fragment D₁ and starts looking for fragment fragment D₄ (which it finds at time 5).
  Meanwhile, stored video from fragment D₂ are shown.
4. The even loader finished downloading fragment D₂ at time 4 and immediately starts downloading fragment D₃ (because the start of fragment D₃ coincides with the end of fragment D₂ - this is planned because these pairs of fragments have the same size !!!)
5. The even loader finished downloading fragment D₃ at time 6 and luckily the odd loader started downloading fragment D₄ at time 5 - some video will be buffered as depicted in the following figure:
  
  The viewing of the video is again uninterrupted
(The pre-fetch technique is not new, we have seen that in Pyramid broadcasting...)

OK, after seeing 3 scenarios, let us go back to the $6,000,000 question is:

Is the receiver always able to obtain the next fragment when the current fragment is finished ???
In other words:
- Will the start of the next fragment always be broadcast during the playback period of the current fragment ?
The above question must be answered before the technique is deem correct
(If there is a possibility that a receiver cannot playout the video continuously, the method is flawed and nobody will use it... reason is simple, you will lose customers and enter bankruptcy court faster than Speedy Gonzales...)

Outline of the Proof of correctness for Skyscrapper Broadcasting
- The proof that the receiver in Skyscrapper Broadcasting can always receive the video uninterrupted once it start downloading is not as "clean" as the pyramid scheme
- The proof has to consider many different cases - so I want to prepare you for the proof with an overview of the case considered.
- The cases considered are:
  1. Getting fragment fragment D₁
  2. Getting fragment fragment D₂
  3. Getting the second fragment in a fragment pair
  4. Getting the first fragment in a fragment pair
    - Case 1: even size fragment --> odd size fragment
    - Case 2: odd size fragment --> even size fragment
Obtaining fragment D₁
- Simply wait until the start of the next time that the first fragment will be broadcast.
- This is also the access time of the video
Obtaining fragment D₂
- Fact: The size of fragment D₂ is always twice the size of fragment D₁
- Assuming that the transmission of the fragments starts at time 0 and a "slot unit" is the time to transmit fragment D₁, then:
  Example:
- Because the size of fragment D₂ is twice as large as fragment D₁, there are exactly two different ways to transit from fragment 1 to fragment 2:
  Case 1: Request arrives after an even "time" point but before an odd "time" point
  - Both the odd and even loader will start before an odd "time" point
  - The next "time" point reached will be odd and the odd loader will start downloading (and displaying) fragment D₁
    The even loader will not start yet.
  - The odd loader will finish at the next "even" time point, at which time the even loader will also find and download the start of fragment D₂
  - So no break when during the transition from fragment D₁ to fragment D₂
  Case 2: Request arrives after an odd "time" point but before an even "time" point
  - Both the odd and even loader will start before an even "time" point
  - The next "time" point reached will be even , so:
    - the odd loader will start downloading (and displaying) fragment D₁ because fragment D₁ is started on every "time" point
    - the even loader will also start downloading (and buffering) fragment D₂ because fragment D₂ is started on every even "time" point
  - So no break when during the transition from fragment D₁ to fragment D₂
Obtaining the second fragment in the fragment pairs...
- If you look carefully at the relative fragment sizes:
  1, 2, 2, 5, 5, 12, 12, 25, 25, 52, 52, 105, 105, 212, 212, ....
  you see that:
  - Except for fragment 1, all other fragments are in pairs
  - Fragment pairs have equal length (and both are odd sized or both are odd sized)
- It is easy to see that when the odd or even loader has finished downloading the first fragment of a pair, then the same loader can download the second fragment of the pair, without any delay:
  (because the time of the end of the first fragment is also the start of the next fragment !!!)
- So the second fragment of the pair can be downloaded and displayed without break.
  So we have covered these fragments:
```
    1, 2, 2, 5, 5, 12, 12, 25, 25, 52, 52, 105, 105, 212, 212, ....
          ^     ^       ^      ^       ^        ^         ^
	  |     |       |      |       |        |         |
          These fragments can surely be displayed without break.
 
```

Obtaining the first fragment in a fragment pair

There are 2 different video stream transition situations that we need to consider:
Current stream Next stream Example -------------- ----------- ------- even size odd size 2, 2, -> 5, 5, ..., 12, 12, -> 25, 25 odd size even size 5, 5, -> 12, 12, ..., 25, 25, -> 52, 52
We will look at each of the cases separately...

Transition from even size fragment to odd size fragment:

The following figure depicts a transition situation where:

The receiver has just finish playing the second fragment of an even sized fragment pair
Question:

Important observation:

If the even sized fragment is A, the size of the odd sized fragment is 2A + 1
The receiver will be able to get the odd sized fragment, it the start of the odd sized fragment is broadcasted sometime during the playback period of the current even sized fragment or the previous even sized fragment !
(Fragments that we are considering comes in PAIRS. Both (even) pairs are of the same size and will be downloaded by the even loader. While the even loader is downloading the 2 even fragments, the odd loader will be on the look out for the next odd fragment !)

Let us explore if (and how) the receiver in general that has finished playing an even size fragment pair will be able to obtain the next odd value size segment in time...

Definition:
Let t denote the playout time of the first fragment of the even value size fragment pair.
I.e., the video from the first fragment of the even fragment pair will be displayed at time t

The following figure shows the possible broadcast times of the odd size fragment during the period when the even fragment pair are being displayed:

We can see that the start of fragment 2A+1 is encountered (exactly) once during the playout period of the two even (A) fragments:

In all cases, except one, the odd fragment 2A+1 need to be pre-fetched.
If the odd fragment 2A+1 is broadcast at time t+2A, the receiver can download the fragment and playout immediately (no pre-fetch).

Further comments:
- Note: just to make sure you understand what I meant by "need pre-fetching", the following example shows how the 2A+1 fragment is pre-fetched:
- NOTE: to make sure you understand what's going on, here is a hypothetical situation where the receiver cannot obtain the next fragment (I need to use a longer fragment (2A+2) to make the point):
  - Note in the figure that there exists the possibility that the start of the 2A+2 fragment does not begin within the playout period of the prior even fragment pair.
    In such case, the receiver would not be able to obtain the next fragment when it starts playing the current fragment.

Transition from odd size fragment to even size fragment

The following figure depicts an example of a transition where:

The receiver has just finish playing the second fragment of an odd sized fragment pair
The next fragment (must) have a even value size

Important observation:

If the odd sized fragment is A, the size of the even sized fragment is 2A + 2
The receiver will be able to get the even sized fragment, it the start of the even sized fragment is broadcasted sometime during the playback period of the current odd sized fragment or the previous odd sized fragment !
(Again, fragments that we are considering comes in PAIRS. Both (odd) pairs are of the same size and will be downloaded by the odd loader. While the odd loader is downloading the 2 odd fragments, the even loader will be on the look out for the next even fragment !)
The total amount of time to play out a PAIR of odd sized fragment is always even !!!
The start time of the even fragment that the even loader is looking for is always an even time (e.g., 2, 4, 6, 8, etc) !!!

Let us now explore if (and how) the receiver in general that has finished playing an odd sized fragment pair will be able to obtain the next even sized segment in time...

Again, let t be the starting display time of the first fragment of the odd sized fragment pair...

An early analysis...
If you followed the last discussion on how we tried to start the next fragment on all possible times within the transmission time of the fragment pair, you would think that in this case (when the receiver is receiving an odd sized pair and looking for an even sized pair), the receiver may not be able to download the even sized fragment in time....
Since the size of the even sized fragment is equal to 2A + 2, the following would be a situation where this 2A + 2 fragment does not begin within the playout time of the previous fragment pair:
To show that the receiver can always obtain the even fragment after the odd fragment pair, we have to consider t = even and t = odd separately.
Case 1: t = even
- The following figure shows the possible broadcast times of the even size fragment during the period when the odd fragment pair are being displayed if t = even:
- Note that the starting time of the broadcast of an even fragment is always even !!!
- There are A possible times that the 2A+2 can start (CHECK this fact ! --- length is 2A+2, always begin at even time)
- We can see from the figure above that for every possible starting time of the fragment 2A+2, the start of a fragment 2A+2 is encountered (exactly) once during the playout period of the two odd (A) fragments.
Case 2: t = odd
- The following figure shows the possible broadcast times of the even size fragment during the period when the odd fragment pair are being displayed if t = odd (t-1 = even):
- Note again that the starting time of the broadcast of the first fragment of the even sized fragment pairs is always even...
- There are again A possible times that the 2A+2 can start (CHECK this fact ! --- length is 2A+2, always begin at even time)
- We can see from the figure above that for every possible starting time EXCEPT ONE of the fragment 2A+2, the start of a fragment 2A+2 is encountered (exactly) once during the playout period of the two odd (A) fragments.
- So in those A - 1 cases, the receiver will have no problem downloading the 2A+2 fragment in time.
- But there is one case where the start of the first fragment of the even sized fragment pairs is NOT encountered during the transmission of the odd fragment pair, we would have a BREAK in video...
  Is our goose cooked in this case ?????
  If not, how can be handle this particular situation.... ???

How to handle the problem case in transition from odd size fragment to even size fragment
- Recall the problem case in transition from odd size fragment to even size fragment:
- The special case when the broadcast time of the even fragment is t - 1 can be handled as follows:
  - First: note that we are currently downloading an odd sized pair and try to switch to an even sized pair.... so there must have been a preceeding even pair that the even loader has downloaded:
```
    1, 2, 2, 5, 5, 12, 12, 25, 25, 52, 52, 105, 105, 212, 212, ....
             ^^^^          ^^^^^^          ^^^^^^^^
 
```
  - The operation of the even loader (and the odd loader also) is such that after finishing downloading an even sized fragment, it can immediately tune to the the next channel and download another an even sized fragment....
  - The transmission time for even sized fragment pairs not only starts at an even time but also always ends at an even time
  - Consider now the latest possible time that the even loader finishes loading the second fragment in the previous even sized fragment pair:
    - The picture above depicts some ending times for downloading the "previous" even sized fragment.
    - We know for sure that the ending time is even
    - We also know that is the ending time for downloading the "previous" even sized fragment is t + 1 or later, then there will be a break in the video.
      Why ? Well, the starting time to display the odd sized fragment A is t.
      So, if the previous fragment did not complete downloading before time t (which would be the case if the ending time for downloading the "previous" even sized fragment is t + 1 or later), the video will surely not show up in time at time t !!!
    - That's why the $6,000,000 question is: can the ending time for downloading the "previous" even sized fragment is t + 1 or later ???
      If the answer is "yes", our goose is cooked and we can pack up and go home...
      If the answer is "no", you better convince the buyer of your system that it is so...
    - The answer is of course "yes", and the convincing argument goes as follows:
      - The size of the magenta color stream is even
      - The size of the yellow color stream is odd
      - So the situation we are looking at is: whether there is a break in video when we are receiving an even sized stream and transitioning to an odd stream
      - We have proved that in such a case, there is no break in video delivery, see: click here
      - Therefore, the even loader must have finished downloading the "previous" even sized fragment at time t - 1 or earlier
        In any case, the even loader has finished in time to download the 2A+1 fragment that starts at time t - 1 !!!
  - Therefore, the even loader can switch in time to download the next even fragment despite the fact that the beginning of the first fragment of the even sized fragment pair falls outside the display time interval of the odd-sized fragment pair.
Maximum disk bandwidth in Skyscraper Broadcast
- From the description of the skyscraper receiver, we can calculate the maximum disk bandwidth needed...
- Recall that data rate of each channel is b bits/sec, which is the same as the consumption rate (so video source sends at the rate that is being consumed, just like cable/satelite)
- Therefore, the maximum disk bandwidth in Skyscraper is 3 x b bits/sec (writing 2 video streams while playing out video from disk)
GRANT Conclusion:
- Receivers in skyscraper broadcast will be able to display the video without interruption.
Homework questions will enforce this method's performance....