# Minimizing the In-Cloud Bandwidth for On-Demand Reactive and Proactive Streaming Applications
## 2 Related Work
### Previous Work  
Many research works have paid attention to the optimization of resource consumption in clouds. While some of them focused on the VM/container to physical node (server) placement (VMP) [28; 29; 30; 31] problem, other works investigated the virtual network embedding (VNE) [32] problem. Solving the VMP problem aims to efficiently use the physical processing nodes (servers) while deploying virtual nodes (VMs/containers) on the cloud infrastructure. Some works considered [28; 29; 30; 31] application needs in their optimization algorithms. However, other works targeted the trade-off between power consumption and cloud performance in fulfilling application needs [33; 34; 35; 36]. The VNE problem solving [37; 32; 38; 39; 40; 41] considers the link load between the nodes involved in the deployment of an application  
Figure 1: Cloud-Based Video Streaming Architecture. in the cloud (as well as Internet service providers (ISP) networks) in addition to the node load. The set of nodes and links builds a virtual network to be embedded on top of the physical datacenter's infrastructure. The main goal here is to ensure a balanced use of the available physical resources, namely, the processing (servers) and network (switchers, routers and links) nodes. Network slicing [42; 43] has been also considered in the cloud context to efficiently organize the bandwidth sharing among concurrent VMs hosted in the same physical node. While the works in this thematic (network slicing) deal with inter-slices optimization and efficient management, we rather consider in this work the intra-slice consumed bandwidth minimization. In this paper, we suppose the existence of the virtual network in the cloud datacenter, and we aim to optimize the way the SNs (streaming nodes) share the video streams requested through the storage nodes. As mentioned in the Introduction, proactive and reactive video broadcasting protocols have been proposed to minimize the servers and network bandwidth. Proactive protocols are subdivided into three subcategories. They are based on the same idea, which consists of dividing the video into many segments to be streamed through several channels. The size of each segment and the scheduling of the different segments among the various channels vary from one subcategory to another. The first subcategory is staggered broadcasting (SB) [6; 18; 44; 45; 46]. Given \(n\) channels and a movie of duration \(D\), SB divides the movie into \(n\) equally sized segments. The \(n\) instances of the same movie are broadcast on \(n\) separate channels repeatedly, where each instance is shifted from the previous instance by the size of one segment, namely, \(\frac{D}{n}\). The second subcategory is called pyramid broadcasting. Protocols in this subcategory are based on the pyramid broadcasting protocol (PB) [6; 16; 20; 22]. Having \(n\) channels, PB divides each movie into \(n\) segments with sizes growing geometrically with the parameter \(\alpha>1\). The first channel repeats broadcasting the first segment, the second channel repeats broadcasting the second segment, and so on for the remaining channels. The client must download data simultaneously from all channels to obtain a continuous fluid video display. Data must be downloaded at a rate equal to \(n\) times the playback (displaying) rate. A more efficient protocol named the Pagoda Broadcasting Protocol was proposed (PaB). PaB [6; 47; 48] uses a more complicated segment-to-channel scheduling algorithm. It distributes segments over the channels using the series {1,3,5,15,25}. Apart from the first channel where the first segment is broadcast repeatedly, PaB uses the remaining channels in a pairwise manner. The client also has to download data from all channels at once. PaB is better than all protocols of this subcategory in terms of the required server bandwidth while maintaining the same waiting time. A more efficient algorithm was proposed in [49]. Like PaB, it does not schedule segments to a channel in a sequential manner.