# Minimizing the In-Cloud Bandwidth for On-Demand Reactive and Proactive Streaming Applications
## 2 Related Work
### Previous Work
It outperforms PaB because it is based on a more complicated heuristic to schedule segments to channels. In [50], the authors invented a new heuristic for segment-to-channel scheduling that enhances the performance of the version given in [49] in terms of the consumed bandwidth. The third subcategory is named the Harmonic Broadcasting (HB) HB [21; 51]. It is based on the harmonic broadcasting protocol proved to be the best protocol [18] in terms of the required server bandwidth. HB divides each movie into equally sized segments, where each segment is broadcast through a separate channel. The channel bit rates are in decreasing order: the first channel bit rate is equal to the playback (displaying) rate denoted \(b\), the second channel bit rate is equal to \(\frac{b}{2}\), the third is equal to \(\frac{b}{3}\), etc. The client must download data from all channels at the same time to obtain a smooth video display. Some proactive protocols use a sequential segment to channel scheduling, namely, SB, PB and HB, while others such as PaB use a different segment to channel scheduling. We can then categorize proactive protocols based on these criteria. On the other hand, some proactive protocols oblige clients to wait for a fixed delay before starting the video display. These protocols are called fixed delay broadcasting protocols [52]. Fixed delay pagoda broadcasting (FDPB) is considered the most efficient fixed delay protocol [52] in terms of the consumed network and server bandwidth. The most well-known reactive protocol is stream tapping (ST) [15]. ST assumes that each customer set top box (STB) includes a buffer capable of storing several minutes of video. This buffer allows the client to tap into the current streams originally created for previous clients having requested the same video. The first client receives the requested movie on a special stream called the complete stream (CS). Further late clients requesting the same movie are served through temporary streams called full tap streams (FTS) to download the missed part of the movie. While displaying this first part of the movie using an FTS, video from a chosen ongoing complete stream is stored in the buffer. When the frame to be displayed from the FTS is the same as the first frame stored from the CS stream, the client terminates his FTS and begins displaying from its buffer, which continues to be fed from the corresponding CS. Unfortunately, this protocol performs worse than proactive protocols at a high workload [18] as the consumed bandwidth increases very rapidly with the number of clients demanding the same movie. A more recent reactive protocol is the Split and Merge Protocol, SAM [12]. Upon the arrival of the first client, SAM initiates a predefined batch time interval. All clients arriving within this batch interval will be served by the same video stream, called the S stream (equivalent to the CS in ST but no FTS is used in SAM), which is opened at the end of this time interval. In addition, SAM is an interactive protocol; it handles interactive operations through special streams called interactive streams (I stream) and the use of a client (synchronized) buffer. When a client performs an interactive operation, he will be served through a new I stream until he can be merged to an ongoing S stream through his synchronized buffer. In [8], the authors proposed the Dyadic optimal algorithm in terms of the consumed bandwidth when the request arrival time sequence is known (optimal for offline scenario) beforehand. The optimal solution is determined by dynamic programming. It has been shown by the authors in [8] that optimal stream sharing algorithms (including Dyadic) are very complex to implement. Hence, a trade-off between the performance and the complexity of implementation should be assured when designing the broadcasting protocol. While proactive protocols are recommended to broadcast frequently requested movies, reactive protocols should be used when the client arrival rate is low.