Minimizing the In-Cloud Bandwidth for On-Demand Reactive and Proactive Streaming Applications

Abstract

Video streaming services are one of the most resource-consuming applications on the Internet. Thus, minimizing the consumed resources at runtime in general and the server/network bandwidth in particular are still challenging for researchers. Currently, most streaming techniques used on the Internet open one stream per client request, which makes the consumed bandwidth increases linearly. Hence, many broadcasting/streaming protocols have been proposed in the literature to minimize the streaming bandwidth. These protocols can be divided into two main categories, namely, reactive and proactive broadcasting protocols. While the first category is recommended for streaming unpopular videos, the second category is recommended for streaming popular videos. In this context, in this paper we propose an enhanced version of the reactive protocol Slotted Stream Tapping (SST) called Share All SST (SASST), which we prove to further reduce the streaming bandwidth with regard to SST. We also propose a new proactive protocol named the New Optimal Proactive Protocol (NOPP) based on an optimal scheduling of video segments on streaming-channel. SASST and NOPP are to be used in cloud and CDN (content delivery network) networks where the IP multicast or multicast HTTP on QUIC could be enabled, as their key principle is to allow the sharing of ongoing streams among clients requesting the same video content. Thus, clients and servers are often services running on virtual machines or in containers belonging to the same cloud or CDN infrastructure.

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 nondeployment of IP multicast on the Internet has blocked the implementation and wide use of these protocols. Nevertheless, the full control of large companies 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.

2. Related Work

In this section, we detail the considered cloud architecture serving as a background for this paper. Furthermore, we define the storage nodes and the streaming nodes and how they are interacting in the context of a cloud/CDN based streaming application. Then, we present the related work with a special focus on video broadcasting protocols.

2.1. Considered Cloud-Based Streaming Architecture

In this paper, we consider the commonly used architecture for cloud-based on-demand and live streaming applications (such as Amazon CloudFront media streaming [24], IBM Video Streaming [25], Microsoft Azure Media Service [26] and Google Video Streaming services [27]). The architecture allows the user of the service to create a streaming application by enabling a chain (or pipe) of video processing starting from the video supply (live or recorded content) until video streaming to the potential clients of the enabled application. The nodes in the chain are often deployed as virtual machines or containers in the cloud.

As illustrated in Figure 1, the different services (video reception, processing, storing and streaming) are often running in virtual machines or containers.

Figure 1. Cloud-Based Video Streaming Architecture.

A management tool is used to control and orchestrate the virtual machines (VMs)/containers involved in the application pipe/chain created in the cloud based on load balancing and VMs/containers health (processor load, memory load and network load) [24,25,26,27]. Streaming video nodes are often deployed on physical servers spread all over the world to be as close as possible to the final users. These nodes are connected to the main datacenter through private networks (most likely virtual private networks) often deployed on the Internet. Cloud companies have full control of routers, enabling private networks that allow multicast routing protocols to be activated over them to minimize the consumed bandwidth in the cloud backbone network. To avoid firewalls, HTTP-based streaming protocols are used where the video serves as small segments (chunks), such as web pages [5].

Generally, cloud-based streaming applications provide the client with a web page presenting the video catalog as HTML5 video tags, as done in YouTube, Dailymotion and Facebook video, for example. The links encoded on the page are generated to minimize the consumed resources in the cloud and offer the best possible user experience. The client is often redirected to the nearest video streaming node to him. As multicast routing is disabled on the Internet, each client is served through a unicast stream.

In this paper, we focus on minimizing the server node bandwidth as well as the consumed bandwidth in the network connecting the different nodes in the chain run by the cloud-based streaming application. This is portrayed as a set of interconnected network devices in the cloud/CDN of Figure 1.

2.2. 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 [32,37,38,39,40,41] considers the link load between the nodes involved in the deployment of an application 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. 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. In a recent work, the authors proposed reactive broadcasting protocols named slotted stream tapping (SST) [11,23]. This protocol performs like proactive protocols at a high workload and like reactive protocols at a low workload. It is based on the same ST Broadcasting scheme. The novelty of SST is to consider a slotted time axis where all clients arriving within one slot obtain their CS (or FTS) at the beginning of the next slot.

In Table 1, we summarize the principles and the performances (the consumed bandwidth) of the representative related works. Through, this table we can make the following observations:

Table 1. Summary of representative works, their principles and performances.

	Principle	Bandwidth	Implementation
Reactive
Unicast	Opens a stream for each client request.	$B=\lambda D$ $\lambda$ is the request rate, D is the video duration.	Easy.
ST [15]	Makes clients sharing one main stream (TS) and provides the missed part by an additional unicast stream (FTS).	$B=\sqrt{\lambda D+1}-1$	Medium.
SST [11,23]	In addition to what ST does, SST groups client request per slots to be served through the same streams.	$B=\sqrt{2D}-\frac{1}{2}$	Medium.
Dyadic [8]	Allows clients to share all opened streams in a pseudo-optimal way. The arrival sequence should be known in advance to be optimal.	No analytical expression.	Hard.
Proactive
SB [6,18,44,45,46]	Divides the movie into n equally-sized segment and broadcasts each segment repeatedly in a channel.	$B=n$	Easy.
Pyramid [6,16,20,22]	Divides the movie into n segments with size growing geometrically. Each segment is broadcast repeatedly in a channel.	$B=n(\sqrt[n]{\frac{D}{w}}-1)$, D is the video duration, w is the client waiting time.	Hard.
Harmonic [21,51]	Divides the movie into n equally-sized segment $S_1$, $S_2$, … $S_n$ and broadcast them such as $S_1$ is broadcast in channel 1 with rate b, $S_2$ in channel 2 with rate $\frac{b}{2}$,… $S_n$ in channel n with rate $\frac{b}{n}$.	$B={\sum }_{i=1}^n\frac{1}{i}$	Hard. It is rather used as lower bound benchmark.

• In reactive protocols: Dyadic is outperforming Unicast, ST and SST techniques in terms of bandwidth consumption. But, it is very hard to implement as reported in [8]. This raises the following question: Could we assure a trade off between the bandwidth consumption and the implementation level of difficulty in the reactive category?
• In proactive protocols: modern HTTP streaming protocols are based on (1) dividing the video into equally-sized segments and (2) sending them to the client as fast as segments are ready. SB is the only protocol compliant with these two properties (of modern streaming protocols). Unfortunately, its segments to channels scheduling is not optimal in terms of the consumed bandwidth. This raises the following question: How could this scheduling problem be stated and solved?

To answer the aforementioned two questions, we propose in this paper new streaming techniques, namely, SASST as a reactive technique for unpopular video streaming and NOPP as a proactive optimal technique for popular video streaming. Both proposed techniques minimize the server and the internal cloud (or CDN) streaming bandwidth. Since only one quality (the highest) is considered by SASST and NOPP, we suppose that any video adaptation (transcoding) mechanism is done by the streaming nodes on the fly.

3. Optimizing Cloud-Based Streaming Internal Bandwidth: Case of an Unpopular Video

For unpopular content streaming, in this section we present a new variant of the protocol Slotted Stream Tapping called SASST. We consider the on-demand scenario (not the live scenario) where video and/or audio files stored in the cloud storage nodes are requested.

First, we describe the SASST principle. Then, we evaluate the performances of SASST in terms of the average consumed bandwidth for both cases of (1) a deterministic high load and (2) a Poisson load of SN request arrivals.

3.1. SASST Principle

As SST is the baseline of the SASST technique, we begin by being reminded of the SST principle; then, we detail how SASST varies from SST. We choose SST as the baseline, as it was proven in [11,23] to be competitive in terms of performance and ease of implementation with regard to the other reactive protocols.

3.1.1. SST Principle

Each streaming node (SN) acts as a proxy node that loads the stream (back-end stream) from the storage node in the cloud and forks it to the clients requesting it. When the first streaming node requests the back-end stream, the storage node begins streaming it internally in the cloud network through a multicast complete stream (CS). When another streaming node later requests the same back-end stream, it will be asked (by the storage node using a manifest file, for example) to share the CS with the first streaming node and will be assigned a new multicast FTS stream to recover the missed video part (as it comes later than the first SN). The video content downloaded from the shared CS is buffered in a circular buffer, while the video content downloaded from the FTS is immediately relayed to the front-end clients. When the missed part is completely recovered, the FTS is closed, and the streaming continues through the circular buffer. This is the principle of the original version of SST. Recall that a slotted time axis is considered where all the requests coming within the same slot are served through the same CS and/or FTS starting from the beginning of the next slot.

Figure 2 portrays the SST principle. It contains four subfigures numbered from 1 to 4 illustrating how SST deals with late requests. As shown in subfigure 1, the first SN is served through a CS.

Figure 2. Illustration of the SST principle and how it handles late requests. In (1) the first SN request arrives and gets a CS. In (2) the second SN request arrives late for two slots. In (3) the Streaming node opens a FTS for the second SN to get the two missed slots while sharing the CS with first SN. In (4) the FTS is closed and the second SN continues getting the video from its buffer.

Then, as portrayed in subfigure 2, the second SN comes two slots later than the first SN. The second SN is assigned, as portrayed in subfigure 3, an FTS to serve the missed video slots 1 and 2 while buffering video slots 3 and 4 in a circular buffer from the ongoing CS. Finally, as missed slots 1 and 2 are recovered, the FTS is closed, and video streaming to clients continues through the circular buffer, as shown in subfigure 4 of Figure 2.

The circular buffer serves clients from one end while being filled through the CS from the other end. In other words, it serves slot 3 while being filled with slot 5, it serves slot 4 while being filled by slot 6, and so on, until the end of the requested video file. Thus, the buffer size of the second SN illustrated in Figure 2 never exceeds 2 slots, which is equal to the missed slot duration.

3.1.2. SASST Variant

The original version of SST does not consider FTS sharing between the latest streaming nodes. In this paper, we consider the sharing of FTS between them to further minimize the consumed bandwidth. Figure 3 represents the FTS handling with SST and SASST at a high workload where at least an SN request comes per slot. It can be seen that FTSs are shorter in the SASST case illustrated in Figure 3b than in the SST case shown by Figure 3a. Let’s take the example of the 8th SN node. As it arrives during the 7th time slot, using SST, it will be assigned a 7 slot FTS duration to serve the 7 missed slots. However, with SASST, it will only be assigned a 4 slot FTS duration (8th SN FTS), which saves 3 time slots compared to SST. This is because the 8th SN node obtains video slots 2, 4 and 6 through the 7th SN FTS and obtains video slots 1, 3, 5 and 7 through the 8th SN FTS. Hence, any late SASST SN node will share the FTS opened for the previous SN to further reduce the consumed bandwidth with regard to SST. Recall that SN requests that are received within the same time slots share the same FTSs.

Figure 3. Example of FTS handling with SST and SASST at a high workload. (a) SST FTS; (b) SASST FTS.

SASST could be easily implemented over IP multicast using Real Time Protocol (RTP) or multicast-HTTP over QUIC. The SN needs to know the currently opened CS and FTS through a session description or announcing mechanism. Session Description Protocol (SDP) or DASH like manifest files could be used in this context. Once done, it starts downloading the video slots through multicast channels as described in the previous paragraph. The storage node could push the video slots using RTP or HTTP/3 packets.

3.2. SASST Performance Evaluation: Case of a Deterministic High Load

As portrayed in Figure 3b, we consider in this subsection the deterministic high load scenario where we have at least one SN request per time slot.

Let l be the number of missed video slots by a late SN request, $a_s$ be the number of slots streamed through and FTS and $b_t$ be the number of slots tapped into (shared through) the FTS opened to the previous late SN request, as represented in boxes with orange color in Figure 3b.

We have

$$l=a_s+b_t$$

(1)

Let us recursively instantiate Equation (1) to each SN arrival of Figure 3b,

$$\begin{array}{c}\hfill \begin{array}{cc}\hfill 1& =1_s+0_t,\hfill \\ \hfill & 1_s:\mathrm{slot} 1 \mathrm{which} \mathrm{is} \mathrm{streamed} \mathrm{through} \mathrm{the} 2\mathrm{nd} \mathrm{SN} \mathrm{FTS}\hfill \end{array}\end{array}$$

(2)

$$\begin{array}{c}\hfill \begin{array}{cc}\hfill 2& =2_s+0_t,\hfill \\ \hfill & 2_s:\mathrm{slot} 1 \mathrm{and} \mathrm{slot} 2 \mathrm{are} \mathrm{streamed} \mathrm{through} \mathrm{the} 3\mathrm{nd} \mathrm{SN} \mathrm{FTS}\hfill \end{array}\end{array}$$

(3)

$$\begin{array}{c}\hfill \begin{array}{cc}\hfill 3& =2_s+1_t,\hfill \\ \hfill & 2_s:\mathrm{slot} 1 \mathrm{and} \mathrm{slot} 3 \mathrm{are} \mathrm{streamed} \mathrm{through} \mathrm{the} 4\mathrm{nd} \mathrm{SN} \mathrm{FTS}\hfill \\ \hfill & 1_t:\mathrm{slot} 2 \mathrm{is} \mathrm{tapped} \mathrm{through} \mathrm{the} 3\mathrm{nd} \mathrm{SN} \mathrm{FTS}\hfill \end{array}\\ \dots \hfill & \end{array}$$

(4)

$$\begin{array}{cc}\hfill n& ={(\frac{n}{2}+1)}_s+{(\frac{n}{2}-1)}_t \mathrm{if} n \mathrm{is} \mathrm{even}\hfill \\ \hfill or& \end{array}$$

(5)

$$\begin{array}{cc}\hfill n& ={\left(\frac{n+1}{2}\right)}_s+{\left(\frac{n-1}{2}\right)}_t \mathrm{if} n \mathrm{is} \mathrm{odd}\hfill \end{array}$$

(6)

At a given value of $l=n$, the storage node should decide to open a CS instead of an FTS to a new SN request to minimize the consumed bandwidth and then start a new cycle. The average bandwidth value denoted B is the same in each cycle and is stated as follows:

$$B\left(n\right)=\frac{S_{CS}\left(n\right)+S_{FTS}\left(n\right)}{n}$$

(7)

where $S_{CS}\left(n\right)$ denotes the number of video slots streamed through CSs and $S_{FTS}\left(n\right)$ denotes the number video slots streamed through FTSs during a cycle duration of n time slots.

At the stationary regime, the storage node opens a CS for each n slot. Thus,

$$S_{CS}\left(n\right)=\frac{D}{n}n=D$$

(8)

where D is the CS duration.

To determine $S_{FTS}$, let us first consider the case of n being even. By summing the first terms $a_s$ of Equations (2)–(5), we obtain

$$S_{FTS}\left(n\right)=1+2\sum _{i=2}^{\frac{n}{2}}i+(\frac{n}{2}+1)=\frac{n^2}{4}+\frac{n}{2}+1.$$

(9)

When n is odd, we obtain by summing the terms $a_s$ of Equations (2)–(6) (except Equation (5)),

$$S_{FTS}\left(n\right)=1+2\sum _{i=2}^{\frac{n+1}{2}}i=\frac{n^2}{4}+n-\frac{1}{4}.$$

(10)

Replacing $S_{CS}\left(n\right)$ and $S_{FTS}\left(n\right)$ in Equation (7) by their expressions determined in Equations (8)–(10), respectively, gives

$$B\left(n\right)=\left\{\begin{array}{cc}\frac{D+1}{n}+\frac{n}{4}+\frac{1}{2},\hfill & \mathrm{if} n \mathrm{is} \mathrm{even}\hfill \\ \frac{D-\frac{1}{4}}{n}+\frac{n}{4}+1,\hfill & \mathrm{if} n \mathrm{is} \mathrm{odd}.\hfill \end{array}\right.$$

(11)

Plotting B for three different values of video duration $D=50$, $D=100$ and $D=150$ shows that we can optimize B with regard to n, as portrayed in Figure 4.

Figure 4. SASST average bandwidth variation as a function of n.

The optimal value of n denoted as $n^{*}$ could be determined by resolving $\frac{dB}{dn}=0$, which gives

$$n^{*}=\left\{\begin{array}{cc}2\sqrt{D+1},\hfill & \mathrm{if} n \mathrm{is} \mathrm{even}\hfill \\ 2\sqrt{D-\frac{1}{4}},\hfill & \mathrm{if} n \mathrm{is} \mathrm{odd}.\hfill \end{array}\right.$$

(12)

Thus, we can determine the optimal average bandwidth value denoted as $B^{*}$ by replacing $n^{*}$ in Equation (11),

$$B^{*}\left(n\right)=\left\{\begin{array}{cc}\sqrt{D+1}+\frac{1}{2},\hfill & \mathrm{if} n^{*} \mathrm{is} \mathrm{even}\hfill \\ \sqrt{D-\frac{1}{4}}+1,\hfill & \mathrm{if} n^{*} \mathrm{is} \mathrm{odd}.\hfill \end{array}\right.$$

(13)

3.3. SASST Performance Evaluation: Case of a Probabilistic Load

In this case, we suppose that the SN request interarrival follows a random variable. Let us denote the average time slots separating two successive requests by y. By applying a recursive Equation (1) to each SN arrival, we obtain

$$\begin{array}{cc}\hfill y& =y_s+0_t\hfill \end{array}$$

(14)

$$\begin{array}{cc}\hfill 2y& =2y_s+0_t\hfill \end{array}$$

(15)

$$\begin{array}{cc}\hfill 3y& =2y_s+1y_t\hfill \\ \hfill \dots & \end{array}$$

(16)

$$\begin{array}{cc}\hfill ny& =(\frac{n}{2}+1)y_s+(\frac{n}{2}-1)y_t \mathrm{if} n \mathrm{is} \mathrm{even}\hfill \\ \hfill or& \end{array}$$

(17)

$$\begin{array}{cc}\hfill ny& =\left(\frac{n+1}{2}\right)y_s+\left(\frac{n-1}{2}\right)y_t \mathrm{if} n \mathrm{is} \mathrm{odd}.\hfill \end{array}$$

(18)

By following the same steps as in Section 3.2 (i.e., summing the $a_s$ of Equations (14)–(17) if n is even and to (18) if n is odd), we can determine the total FTS slot number denoted as $S{y}_{FTS}$ for n being even and odd as follows:

$$S{y}_{FTS}\left(n\right)=\left\{\begin{array}{c}\begin{array}{cc}\hfill y[1+2\sum _{i=2}^{\frac{n}{2}}i+(\frac{n}{2}+1)]=& y[\frac{n^2}{4}+\frac{n}{2}+1],\hfill \\ & \mathrm{if} n \mathrm{is} \mathrm{even}\hfill \end{array}\hfill \\ \begin{array}{cc}\hfill y[1+2\sum _{i=2}^{\frac{n+1}{2}}i]=& y[\frac{n^2}{4}+n-\frac{1}{4}],\hfill \\ \hfill & \mathrm{if} n \mathrm{is} \mathrm{odd}.\hfill \end{array}\hfill \end{array}\right.$$

(19)

Hence, we can deduce the expression of the average bandwidth value, denoted as $B_y$, consumed by a storage node as follows:

$$B_y\left(n\right)=\left\{\begin{array}{cc}\frac{\frac{D}{y}+1}{n}+\frac{n}{4}+\frac{1}{2},\hfill & \mathrm{if} n \mathrm{is} \mathrm{even}\hfill \\ \frac{\frac{D}{y}-\frac{1}{4}}{n}+\frac{n}{4}+1,\hfill & \mathrm{if} n \mathrm{is} \mathrm{odd}.\hfill \end{array}\right.$$

(20)

After Resolving $\frac{d{B}_y}{dn}=0$, we obtain,

$$n^{*}=\left\{\begin{array}{cc}2\sqrt{\frac{D}{y}+1},\hfill & \mathrm{if} n \mathrm{is} \mathrm{even}\hfill \\ 2\sqrt{\frac{D}{y}-\frac{1}{4}},\hfill & \mathrm{if} n \mathrm{is} \mathrm{odd}.\hfill \end{array}\right.$$

(21)

Let us replace $n^{*}$ in $B_y$; then we obtain the optimal value of $B_y$ denoted $B_y^{*}$,

$$B_y^{*}\left(n^{*}\right)=\left\{\begin{array}{cc}\sqrt{\frac{D}{y}+1}+\frac{1}{2},\hfill & \mathrm{if} n^{*} \mathrm{is} \mathrm{even}\hfill \\ \sqrt{\frac{D}{y}-\frac{1}{4}}+1,\hfill & \mathrm{if} n^{*} \mathrm{is} \mathrm{odd}.\hfill \end{array}\right.$$

(22)

Assume that the SN request interarrival is an exponential random variable. We can conclude the probability $p_0$ of having zero arrival per time slot s as follows:

$$p_0=e^{-\lambda s}$$

(23)

where $\lambda$ is the Poisson average arrival rate.

Let Y be a random variable denoting the number of slots k between two Poisson successive requests, defined by

$$P[Y=k]=p_0^{k-1}(1-p_0)$$

(24)

As y is the average interarrival slot number between two successive requests, we can then express it as follows using Equations (23) and (24):

$$y=\sum _{k=1}^{+\infty }kP[Y=k]=\frac{1}{1-e^{-\lambda s}}.$$

(25)

Replacing y by its expression in Equation (22) gives the following:

$$B_y^{*}\left(\lambda \right)=\left\{\begin{array}{cc}\sqrt{\frac{D}{\frac{1}{1-e^{-\lambda s}}}+1}+\frac{1}{2},\hfill & \mathrm{if} n^{*} \mathrm{is} \mathrm{even}\hfill \\ \sqrt{\frac{D}{\frac{1}{1-e^{-\lambda s}}}-\frac{1}{4}}+1,\hfill & \mathrm{if} n^{*} \mathrm{is} \mathrm{odd}.\hfill \end{array}\right.$$

(26)

As $\underset{\lambda \to \infty }{lim}y=1$, we can deduce the asymptotic values of $n^{*}$ and $B^{*}$ as follows:

$$\underset{\lambda \to \infty }{lim}{n}^{*}\left(\lambda \right)=\left\{\begin{array}{cc}2\sqrt{D+1},\hfill & \mathrm{if} n \mathrm{is} \mathrm{even}\hfill \\ 2\sqrt{D-\frac{1}{4}},\hfill & \mathrm{if} n \mathrm{is} \mathrm{odd}.\hfill \end{array}\right.$$

(27)

$$\underset{\lambda \to \infty }{lim}{B}^{*}\left(\lambda \right)=\left\{\begin{array}{cc}\sqrt{D+1}+\frac{1}{2},\hfill & \mathrm{if} n^{*} \mathrm{is} \mathrm{even}\hfill \\ \sqrt{D-\frac{1}{4}}+1,\hfill & \mathrm{if} n^{*} \mathrm{is} \mathrm{odd}.\hfill \end{array}\right.$$

(28)

This shows that the deterministic high load performances done in Section 3.2 are upper bounds of the probabilistic performances of SASST. Another important result achieved through Equation (28) is that the average bandwidth of SASST is less than the average bandwidth of SST, which was expressed in [11,23] as $B_{SST}^{*}=\sqrt{2D}-\frac{1}{2}$ for long videos where $D>3.5$ when $n^{*}$ is even and for $D>4.5$ when $n^{*}$ is odd. Recall that SST was proven to outperform ST in terms of the average consumed bandwidth in [11,23].

3.4. SASST Performance Evaluation: Numerical Analysis

In this subsection, we compare SASST to SST, ST and Dyadic in terms of the average consumed bandwidth as a function of the SN request rate denoted as $\lambda$. As we can see in Figure 5a, SASST outperforms SST and ST in terms of the average bandwidth except for request rates smaller than 0.06, where the performances are very close to one other. Note here that the video size $D=100$ and one slot $s=1$.

Figure 5. Comparison of bandwidth and bandwidth reduction between SASST, SST, ST and Dyadic as a function of the request arrival rate $\lambda$, respectively. (a) Bandwidth; (b) Bandwidth Reduction.

However, Dyadic requires a lower bandwidth than SASST. The maximum difference between them reaches 1.65 streams for an arrival rate equal to 1. In fact, having one or many requests per slot does not affect the performance in terms of the consumed bandwidth. Thus, SASST is very competitive in terms of the consumed bandwidth while being simpler than Dyadic with regard to the complexity of implementation.

The bandwidth reduction of SASST, SST and Dyadic compared to ST is plotted in Figure 5b. As we can see in this figure, SASST ranks second after Dyadic. At a high request rate ($\lambda \ge 1$), the bandwidth reduction values are almost equal to 50%, 39% and 18% for Dyadic, SASST and SST, respectively. Note that ST bandwidth is taken as reference.

To obtain more insight into the optimal value of ($n^{*}$) with regard to the video size D using SASST, in Figure 6 we plot $\frac{n^{*}}{D}$ for odd and even cases of $n^{*}$ where $D\in \{10,11,\dots 1000\}$. As can be seen, as the video size increases, the storage node decides to open CS more frequently than if the video size is smaller. This could be explained by the rapid growth of cumulative FTS sizes that quickly reach the size of the video, which encourages opening a new CS rather than an FTS for the current late SN request. Indeed, serving late requests with a smaller FTS if a new CS is opened is better than serving the late requests with very long FTSs in terms of bandwidth minimization.

Figure 6. Percentage of $n^{*}$ as a function of the total video size D for $n^{*}$ even and odd, respectively. (a) $n^{*}$ even; (b) $n^{*}$ odd.

4. Optimizing Cloud-Based Streaming Internal Bandwidth: Case of Popular Video

In this section, we study the case of a high SN request rate where it is recommended to use a proactive streaming protocol. Unlike the reactive protocols (such as SASST presented in the previous section), the storage node divides the video into equally-sized segments and broadcasts the them repeatedly on a set of multicast channels regardless of the SN requests using a schedule that allows the SN to obtain all video segments. We aim to determine the optimal segments-to-channels scheduling in terms of consumed bandwidth. This scheduler will be used in the context of NOPP.

In the rest of the current section, we analyze how SASST could be approximated by the proactive protocol staggered broadcasting. Although it is out of the scope of this paper, this approximation helps in implementing a smooth transition from using reactive protocol a proactive one when the video becomes popular at runtime. Then, we detail the formulation and solving process of the bandwidth optimization problem which leads to NOPP optimal scheduling of segments to broadcasting channels. Two version are considered: (1) minimizing the bandwidth when the streaming period of a given video is known in advance (known time horizon) and (2) when it is not (periodic).

4.1. Approximating SASST by SB

When the system is in a stationary regime, the storage node opens a new CS each $n^{*}$ slots of time. Thus, we can see the CS streaming channels as portrayed in Figure 7a. If we consider each $n^{*}$ in a given CS as a video segment and we name it $segmen{t}_i$ where $i\in \{1,2,3,\dots ,N\}$ (we assume here that $\frac{D}{n^{*}}=N$), then we obtain the same broadcasting schema as SB [6,18]. Each channel broadcasts one instance of the video shifted by the size of one segment from the previous and the next adjacent channels. This means that one instance of the entire video is broadcast across all channels in each segment duration period. Hence, any SN can download the entire video if it connects to all the channels at the same time after one time slot. Using SB, any SN could download the entire video by connecting to only one channel during the CS duration to download the video segments one by one.

Figure 7. From proactive SASST to optimal scheduling of 17 segments. (a) SASST as SB; (b) Optimal Scheduling with 17 segments.

The question is how to minimize the number of broadcasting channels while allowing the SN to download the video without missing any segment. The key scheduling answer to this question is to broadcast each segment i at least once on any of the channels each i time slots. By time slot, we mean one segment duration (i.e., equal to $n^{*}$ slots). This property is inherited from the playback continuity property, where a video player must find segments i available for playback immediately after playing the $i-1$ previous segments. In other words, segment i should be downloaded during the playback period of the previous segments or should be immediately available on one of the channels for playback. Figure 7b shows an optimal scheduling of the 17 segments initially broadcast by SASST. As portrayed in Figure 7a, the streaming bandwidth drops from 17 to 4 broadcasting channels for the same video.

This scheduling problem has been proven to be NP-hard in [50]. Nevertheless, for a fixed video broadcasting time horizon, we can afford to solve the scheduling problem through an exact method using a linear program formulation. Through a fixed time horizon, we mean that we know for how long we will keep streaming (broadcasting) the video. The optimization problem formulation is presented in the next subsection. For the case of an unknown time horizon, we propose in Section 4.3 a different formulation of the problem to preserve a reasonable solving cost with regard to the formulation of the fixed time horizon described in Section 4.2. NOPP is based on the two proposed versions of optimal schedules (known and unknown time horizons).

4.2. Linear Program Formulation for a Fixed Time Horizon

Let C be the fixed broadcasting time horizon and N be the total number of equally sized segments of the media. Generally, C is equal to $n*N$ with ($n>1$). Let $x_{ij}$ be a Boolean variable indicating whether or not segment i can be scheduled within time slot j ($x_{ij}=1$) ($x_{ij}=0$) and B be the total number of broadcasting network channels, which is the total consumed bandwidth (expressed in number of channels) used by NOPP.

Our Linear Program (LP) can be stated as follows:

$$\begin{array}{cc}\hfill & \mathrm{Minimize} B\hfill \end{array}$$

(29)

$$\begin{array}{c}\mathrm{Subject} \mathrm{to}:\hfill \end{array}$$

$$\begin{array}{ccc}\hfill & \sum _{j=1}^N{x}_{jt}\le B,t\in \{1,2,\dots ,C\}\hfill & \\ \hfill & \sum _{k=t}^{t+j-1}{x}_{jk}\ge 1,j\in \{1,2,\dots ,N\}\hfill & \end{array}$$

(30)

$$\begin{array}{ccc}\hfill & \mathrm{and} t\in \{1,2,\dots ,C-j+1\}\hfill & \end{array}$$

(31)

$$\begin{array}{ccc}\hfill & \sum _{i=1}^N\frac{1}{i}\le B\le N\hfill & \\ \hfill & x_{j,t}\in \{0,1\},j\in \{1,2,\dots ,N\}\hfill & \end{array}$$

(32)

$$\begin{array}{ccc}\hfill & \mathrm{and} t\in \{1,2,\dots ,C\}\hfill & \end{array}$$

(33)

$$\begin{array}{cc}\hfill & B\in {\mathbb{N}}^{*}\hfill \end{array}$$

(34)

Constraint (30) means that the number of scheduled segments for any time slot cannot exceed the total number of channels. Constraint (31) means that each segment i must be scheduled at least once for any time window of size i slots. The lower bound used in constraint (32) has been determined in [18,50].

Solving the LP using the Gurobi solver [53] for $N=C,N\in \{2,3,\dots ,50\}$ gives the results summarized in Table 2. Note that the solver was installed on a 16 processors Linux workstation with 2.4 GHz speed each.

Table 2. Optimal bandwidth $B^{*}$ for 49 instances of $N=C$.

N	${\mathit{B}}^{*}$	t (s)	N	${\mathit{B}}^{*}$	t (s)	N	${\mathit{B}}^{*}$	t (s)	N	${\mathit{B}}^{*}$	t (s)
2	2	0.00040	15	4	0.00462	28	4	0.03661	41	5	0.05058
3	2	0.00348	16	4	0.00535	29	4	0.05818	42	5	0.05389
4	3	0.00021	17	4	0.00585	30	4	0.04598	43	5	0.05724
5	3	0.00118	18	4	0.00658	31	5	0.02178	44	5	0.06411
6	3	0.00139	19	4	0.00706	32	5	0.02313	45	5	0.08320
7	3	0.00134	20	4	0.00836	33	5	0.02594	46	5	0.06859
8	3	0.00157	21	4	0.00883	34	5	0.02769	47	5	0.07418
9	3	0.00189	22	4	0.01036	35	5	0.03048	48	5	0.07737
10	3	0.00308	23	4	0.01498	36	5	0.03213	49	5	0.09644
11	4	0.00229	24	4	0.01350	37	5	0.03544	50	5	0.11897
12	4	0.00255	25	4	0.02127	38	5	0.03567
13	4	0.00396	26	4	0.01838	39	5	0.04350
14	4	0.00393	27	4	0.03915	40	5	0.04664

The main drawback with fixed time horizon scheduling is the obligation to stop serving SN requests before a period of time equal to the size of a video instance (only the SN arriving within C-N are served). Indeed, the requests coming during the streaming time of the last instance of the video will not be able to download the entire segments. As shown in Figure 8, a request coming during the third time slot will miss segment 10. An additional time slot is therefore needed to schedule it (segment 10). We need to add an increasing number of time slots to schedule as many missed segments as we have new requests during this last instance of the media.

Figure 8. An example of an optimal scheduling for $N=C=10$ and $B^{*}=3$. The request arrival slot is illustrated in black. The green video segments are successfully downloaded. The red video segment is missed.

Unfortunately, this is not obvious, as the repetition of the same optimal schedule does not guarantee a feasible schedule.

As we can see in Figure 9, the distance between two successive occurrences of each of the segments 6, 7, 8 and 9 is equal to 10 (one occurrence is counted in the distance), which violates the playback property where segment i must be scheduled at least once in any i successive slots. As portrayed in the figure, only 3 segments among 4 could be scheduled in the free places (in green), which means that the obtained scheduling is not feasible.

Figure 9. An optimal scheduling for $N=C=10$ repeated twice. The distance between the two successive occurrences in red of video segment 6 is equal to 11. The distance between the two successive occurrences in orange of video segment 7 is equal to 11. The distance between the two successive occurrences in cyan of video segment 8 is equal to 10. The distance between the two successive occurrences in magenta of video segment 9 is equal to 10. They are all violating the playback property. Some free slots that could be assigned to some video segments are colored in green.

To overcome this problem, we propose in the next subsection a new LP model that allows us to obtain an optimal schedule that could be repeated as many times as we have new requests without violating the playback propriety.

4.3. Linear Program Formulation for an Unknown Time Horizon

The main change in the new LP model with regard to the fixed time horizon model is the periodicity constraint. This guarantees the playback property when repeating the optimal schedule. The LP formulation is stated as follows:

$$\begin{array}{cc}\hfill & \mathrm{Minimize} B\hfill \end{array}$$

(35)

$$\begin{array}{ccc}\hfill & \mathrm{Subject} \mathrm{to}:\hfill & \hfill \end{array}$$

$$\begin{array}{ccc}\hfill & \sum _{j=1}^N{x}_{jt}\le B,t\in \{1,2,\dots ,C\}\hfill & \\ \hfill & \sum _{k=t}^{t+j-1}{x}_{jk}\ge 1,\hfill & \hfill \end{array}$$

(36)

$$\begin{array}{ccc}\hfill & j\in \{1,2,\dots ,N\}\mathrm{if} t\le C-j+1\hfill & \\ \hfill & \sum _{k=t}^C{x}_{jk}+\sum _{k=1}^{j-(C-t+1)}{x}_{jk}\ge 1,\hfill & \end{array}$$

(37)

$$\begin{array}{ccc}\hfill & \mathrm{if} C-j+1\le t\le C\hfill & \end{array}$$

(38)

$$\begin{array}{ccc}\hfill & \sum _{i=1}^N\frac{1}{i}\le B\le N\hfill & \\ \hfill & x_{j,t}\in \{0,1\},j\in \{1,2,\dots ,N\}\hfill & \end{array}$$

(39)

$$\begin{array}{ccc}\hfill & \mathrm{and} t\in \{1,2,\dots ,C\}\hfill & \end{array}$$

(40)

$$\begin{array}{cc}\hfill & B\in {\mathbb{N}}^{*}\hfill \end{array}$$

(41)

All the constraints are the same as the previous LP, except constraints (37) and (39), where we consider circular scheduling. They guarantee that a segment i is scheduled at least once in any successive i slots from slot j to slot C and from slot 1 to slot $i-(C-j+1)$. Note here that the minimum time horizon C for a circular schedule is equal to the video size N.

Solving the periodic LP for $N=C=10$ using a Gurobi solver [53] gives the optimal circular schedule portrayed by Figure 10.

Figure 10. An example of optimal circular scheduling for $N=C=10$. $B^{*}=4$.

Table 3 summarizes the solving results of the periodic LP for $N\in \{2,3,\dots ,48\}$.

Table 3. Optimal bandwidth $B^{*}$ for 47 instances of $N=C$.

N	${\mathit{B}}^{*}$	t (s)	N	${\mathit{B}}^{*}$	t (s)	N	${\mathit{B}}^{*}$	t (s)	N	${\mathit{B}}^{*}$	t (s)
2	2	0.00024	14	4	0.00671	26	5	0.54185	38	5	0.17875
3	2	0.00260	15	4	0.00784	27	5	0.57136	39	5	0.12900
4	3	0.00023	16	4	0.01246	28	5	0.51263	40	5	0.22479
5	3	0.00128	17	4	0.01099	29	5	0.44969	41	5	0.62120
6	3	0.00144	18	4	0.01755	30	5	0.72769	42	5	0.20406
7	3	0.00214	19	5	149.31110	31	5	0.04119	43	5	0.96535
8	3	0.00242	20	4	0.07884	32	5	0.04682	44	5	0.90229
9	4	0.03365	21	5	0.81072	33	5	0.05502	45	5	1.16545
10	4	0.02758	22	5	0.92566	34	5	0.05346	46	5	1.16282
11	4	0.00388	23	5	0.92439	35	5	0.06545	47	5	1.46099
12	4	0.00496	24	5	1.01415	36	5	0.08506	48	5	1.68586
13	4	0.00744	25	5	0.38786	37	5	0.09712

Using the circular optimal schedule, the storage node allocates one more time slot to stream the segments indicated by the optimal schedule on the broadcasting channels for any newly arriving SN request where the distance between the newly allocated slot and the arrival slot is equal to N. As shown in Figure 10, a request arriving at slot 1 induces allocating slot 11 to broadcast segments 1, 2, 6 and 10.

The plots in Figure 11 show that fixed time schedules could be naturally periodic (circular). The optimal bandwidth value $B^{*}$ is the same for many configurations considered in fixed time and circular schedules. This proves that at least one optimal schedule exists for a fixed time horizon version that is naturally periodic.

Figure 11. $B^{*}$ as a function of N for circular and fixed time scheduling.

Through Figure 11 plots, we can observe that in the time horizon value $C=20$, the optimal bandwidth value $B^{*}$ decreases by 1. Thus, we can ask the following open question: what are the time horizon values of C that minimize the bandwidth B for a given video size N?

4.4. NOPP Deployment

To deploy NOPP, the following tasks should be performed::

• The administrator of the streaming system should set (1) the number of segments of the video and (2) the streaming time horizon. in the system ggraphical interface If he wants to use a periodic scheduling, then he should indicate that instead of the time horizon.
• The system solves either the first version (with fixed time horizon) or the second version (periodic) of the LP. A manifest file containing the optimal scheduling is then generated and stored in the storage node with video segments.
• The SN starts by requesting the manifest (of the session description) file from the storage node to know how to reorder the arriving segments. Then, it starts the download of video segments, the reordering and the streaming to the Internet users’ devices. The storage node could use RTP or HTTP/3 to push the video segments.

5. Conclusions

In this paper we proposed cloud streaming bandwidth optimization techniques. For unpopular video cases, we presented a new variant of the Slotted Stream Tapping (SST) protocol called Share All SST (SASST). We analytically proved that SASST reduces the storage node bandwidth by almost 30% and 20% compared to stream tapping (ST) and SST, respectively. However, Dyadic further reduces the bandwidth by almost 10% compared to SASST while being harder to implement, as shown in [8]. We discussed how SASST could be smoothly turned on a proactive protocol to also serve popular videos. To minimize the bandwidth, we proposed two LP formulations to obtain the optimal segments to channel schedules for known and unknown time horizons. We showed how the optimal schedule for the unknown time horizon case could be repeated infinitely to serve new incoming requests. We called the new broadcasting protocol based on these optimal schedules the New Optimal Proactive Protocol (NOPP). As it is optimal, it outperforms the rest of the proactive broadcasting techniques of the literature in terms of the consumed server and network bandwidth. In the future, we plan to bring the proposed techniques into practice, which requires studying in depth the possible ways to change segment-based streaming protocols, such as HLS, to minimize the steaming bandwidth in a multicast enabled network.