# Minimizing the In-Cloud Bandwidth for On-Demand Reactive and Proactive Streaming Applications
## 1 Introduction  
Video streaming consumes will exceed almost 80% of the total Internet traffic by 2023 [1]. Thus, designing streaming protocols that minimize the network and server consumed bandwidth is still a challenging task for researchers and industrial parties. Most of the current streaming techniques [2, 3, 4, 5] are based on unicast communication using HTTP or RTP/RTSP oriented streaming protocols, where one channel is opened per client request. This leads to a quick depletion of the available bandwidth when the video is requested by many viewers simultaneously [6]. To tackle this problem, many video (mainly video and/or audio) broadcasting protocols were proposed at the end of the 90s and the first decade of the current century to minimize the consumed bandwidth during video streaming. Most of these protocols are based on stream sharing implemented by using multicast channels. Unfortunately, the nondepployment of IP multicast on the Internet has blocked the implementation and wide use of these protocols. Nevertheless, the full control of largecompanies in their cloud/content delivery networks (CDNs) makes the deployment of IP multicast or HTTP multicast through QUIC [7] possible within their private networks. This encourages the reuse of broadcasting protocols proposed in the literature to optimize the consumed video streaming bandwidth between virtual machines/containers in their clouds/CDNs.  
The broadcasting protocols can be divided into two main categories, namely, reactive protocols [8; 9; 10; 11; 12; 13; 14; 15] and proactive protocols [6; 16; 17; 18; 19; 20; 21; 22]. In the first category, the server opens streams upon receiving client (Internet users' devices) requests. This is recommended for streaming videos with low request rate [15] which we qualify by unpopular video in this paper. However, in the second category, videos are divided into segments where the server repeatedly broadcasts them through a set of channels regardless of the number of clients requesting it. This category is recommended for streaming popular videos. As we are focusing on the cloud/CDN internal network, the clients and the servers are running in the same cloud datacenter infrastructure (or CDN infrastructure). The clients are front-end nodes, which could be containers, virtual machines or CDN proxy servers. These latter are the sources of video streams loaded by Internet users' devices. However, the servers are back-end nodes, which could be containers, virtual machines or back-end CDN servers connected to the video source. They perform all the necessary video preprocessing tasks (dividing the stream into segments, transcoding and storing) of the received streams. They supply the front-end nodes with the necessary videos to stream. Our main goal in this paper is to minimize the bandwidth induced by the streams internally opened between the back-end and the front-end nodes for streaming unpopular and popular videos.  
The main contributions of the current paper are:  
* to propose a new reactive protocol named Share All Slotted Stream Tapping (SASST) based on the technique Slotted Stream Tapping (SST) [11; 23] for unpopular video streams. It has been shown in [11; 23] to be competitive in performances and in ease of implementation than the rest of the reactive protocols,
* to propose a new proactive technique named the new optimal proactive protocol (NOPP) for popular video streams using optimal video segments to broadcast channels scheduling for known and unknown time horizon cases.  
The remainder of this paper is organized as follows: In the second section, we present the cloud architecture that we consider in this paper and the related work. The third and fourth sections are dedicated to the explanation and modeling of the reactive and proactive proposed techniques SASST and NOPP, respectively. Finally, we conclude the paper, and we cite some future works as a continuity to the current one.