$S^{2}VC$: An SDN-based Framework for Maximizing QoE in SVC-Based HTTP Adaptive Streaming

As shown in [15, 16] DASH video players in clients are responsible for quality adaptation in order to optimize the QoE objectives, e.g., initial buffering time minimization, stalling minimization, and quality maximization. In [17, 18], the authors propose a general bit rate adaptation framework that consists of a set of methods striving to achieve a trade-off between video stability, fairness, and efficiency. A stateful bit rate selection heuristic algorithm is used to achieve a biased interaction between the bit rate and estimated bandwidth. However, this client-based quality adaptation leads to uneven bandwidth competition, which intensifies when a large number of clients use the shared network resources [19]. Moreover, resource fairness does not reduce QoE-fairness, specially in heterogeneous environment [20]. This unfair resource usage, coupled with unpredicted network traffic bursts, can cause frequent changes in the quality layers of clients (client quality oscillations), which significantly reduces QoE. Therefore, an optimization model should be developed to trade-off between different QoE parameters, such as the video quality maximization and minimization of bit rate changes, while also meeting network constraints.

In order to achieve this goal, various algorithms have been developed through the consideration of different parameters such as estimated network bandwidth, network throughput, and received network feedback signals (e.g., congestion occurrence) [21, 22, 23, 24]. Sieber et al. in [22] present an algorithm to achieve maximum QoE by reducing the quality switching frequency. The authors of [24] employ Markov Decision Process to determine an optimal streaming strategy. Their method is developed in a wireless network environment and aims to optimize the QoE in terms of video playback interruption, average playback quality, and playback smoothness. Additionally, [23] provides a technique to overcome network fluctuations, which is typical in mobile networks. These authors first prioritize the SVC layers. Then, the base layer (which has the most priority) is delivered to user via RTP flows. Thereafter, additional enhancement layers are delivered based on their priority. Further, [25] implements and compares different heuristic algorithms based on AVC and SVC. It is shown that AVC performs better than SVC in situations with high delay while, in networks with unpredictable interruptions, SVC has superior performance. Moreover, Lee et al. in [26] investigate the impact of cache storage and report that it can increase oscillation. They then propose a method to solve this. However, it is clear that, by using purely client-side sub-optimal adaptation decisions and also with the absence of a central controller for clients, the video quality changes frequently and QoE reduction ultimately occurs [15, 27]. Furthermore, with a central controller, it is possible to enforce different management policies, such as various subscription policies (e.g., Gold, Silver, Bronze) [28]. The following discussion explores quality adaption techniques assisted by a network element.

As we mentioned before, specific network elements can assist clients for client-based rate adaptation. Using the information provided by network elements, a client can enhance its quality adaptation procedure [12]. Petrangeli et al. in [29] utilizing an SDN controller with a holistic network view, assist client-side quality adaptation in an AVC-DASH streaming method. Additionally, in [30], the authors propose an SDN-based video streaming approach to fairly maximize the QoE of multiple competing clients in a shared network environment. Likewise, the proposed strategy in [31] is based on SDN. In fact, the authors of [31] employ two main approaches to optimize QoE in terms of number of quality changes and fairness. In the first approach, the SDN controller determines the video quality of the clients. In the second one, a queue for each client is developed to provide dynamic rate adaptations. Although these studies utilize some network elements to improve QoE, the determination of optimal adaptations is performed separately by clients. Thus, these strategies do not lead to efficient share usage of network resources. Bentaleb et al. in [19] address HAS scalability issues, including video instability, QoE-unfairness, and network resource under-utilization. To cope with these issues, they maximize the QoE per client. Moreover, [20] mitigates the main drawbacks of SDNDASH[19]: scalability , communication overhead, and the support of client heterogeneity.

There are some works however, that have mainly focused on QoS-aware video traffic routing [32, 33, 34, 35, 36, 37]. In fact, these studies have investigated the QoS-aware video flow routing in OpenFlow/SDN-enabled networks. Indeed, the base quality layer is considered as the flow with the maximum QoS priority, while other layers are transferred in the best effort manner [32, 33]. Thereafter, by considering the QoS priorities; the routing algorithm finds the shortest path between the media server and client. The authors extend their previous work in [36], in which they consider end-to-end QoS in multi-domain SDN networks. In addition, Egilmez et al. [34] design a QoS-aware controller to deliver multimedia flows in OpenFlow-enabled networks. In this approach, they classify input traffic based on data flow types. Then, multimedia flows are routed through QoS-guaranteed paths and other flows are delivered to the destination via the shortest paths. These studies do not discuss quality adaptation techniques. In addition, the authors of [37] provide a model to determine the $k$ shortest paths and to then assign these to each $k$ SVC layer. They extend their research in [35], in which they considered additional parameters, such as bandwidth and delay, and also enhance the model by using the max flow algorithm. Although these techniques can improve client-side decisions, these decisions are still sub-optimal as there is no independent central element for decision making. Furthermore, clients might not be able to perform the decisions made by the controller [31]. Therefore, central-based quality adaptation can be suggested.

Several works use a proxy/controller as a central rate adaptation decision-making authority [38, 39, 40]. In [38], the authors propose an approach that actually employs a proxy server to monitor video quality requests. In this approach, a proxy server periodically solves an optimization problem in order to determine the maximum segment quality levels which the clients can download. This is achieved based on the current network status and a specific objective function. In fact, whenever a client-based adaptation reduces overall fairness, the proxy server is able to replace its video quality decision with that of the client. Therefore, a certain level of QoE can be guaranteed among some or all clients. In addition, [41] suggest utilizing an intermediate node to perform the quality adaptation. Actually, this intermediate node acts as a gateway for clients. Practically, it uses the clients’ bandwidth estimation to determine the optimized video quality of SVC clients. Moreover, Mok et al. [39] design a proxy architecture to prevent frequent and drastic oscillations and to allow a specific amount of change in video quality in each step. Unlike ours, this approach is not scalable, since all the network traffic to the video server must pass through a proxy server. Furthermore, [40] presents reactive and proactive QoE optimization approaches. In the reactive method, client-based quality adaptation is achieved using network information. By considering client buffer utilization and quality adaptation in the controller, the second method provides a higher and fairer video quality to clients.

Only a few works [42, 43], however, have focused on jointly determining routing and providing quality adaptation. [42] proposes a method based on Markov Chains, which determines the quality adaptation in the controller and selects the optimal video quality of the clients. Their approach first determines the $N$ shortest-path routes and then, based on priorities, sends the video layer using one of the paths. In contrast, the approach in [43] utilizes the optimal paths instead of the shortest ones. However, in [42] and [43], the authors only determine an optimal data path and do not consider fairness in their proposed solution. By running the algorithm for each incoming client (or request), they find a solution regarding the available resources. Moreover, [42] and [43] do not target DASH video streaming since they focuse on the UDP protocol. Cetinkaya et al. [44] develop an optimization model to maximize video quality by the selection of optimal paths for different SVC layers over SDN. Finally, it informs clients about the selected bit rate to be applied by them. In addition, in [45], the authors propose an approach which delivers the base layer to clients via a lossless path and uses other paths to route the remaining layers.

As mentioned earlier, a DASH player first downloads the media presentation description (MPD) file that provides the segment information and then requests each segment layer individually. However, we assume that the DASH players can determine and send the maximum supported video quality, according to their resource capacity. Nevertheless, for each client, these values can be adjusted by $S^{2}VC$. In the proposed framework, the time for buffering a segment is considered fixed, even though it is possible that a DASH player suggests a deadline in which all requested layers of a segment must be downloaded.

To achieve better video quality, layers with higher data rates should be buffered by the DASH client. Many functions have been proposed to measure the quality of the received video files [8] as it has been shown that receiving layers with higher bit-rates can promote the quality of a video. Therefore, in this study, without loss of generality and for ease of explanation, the number of continuous buffered layers by a DASH client is considered as the achieved video quality. $S^{2}VC$ considers the following QoE metrics and QoE-fairness:

• •

  Start-up delay: The time period between sending a video request and starting to render the first frame.

• •

  Number of stalls: The stall phenomenon occurs when the buffer space of a client reaches its minimum threshold value (possibly be zero) during the playback of the requested video. At this time, the DASH player stops rendering and waits to download the current segment.

• •

  Average video quality: The average video quality of all received segments. In other words, the average number of buffered layers of each segment of a video file.

• •

  Average number of video quality switches: This metric is expressed as the average number of video quality switches between any successively received segments.

• •

  Average intensity of video quality switches: In addition to the average number of video quality switches, we take the average intensity of video quality oscillations into account. This metric indicates how much the quality of any two successive segments oscillates. In other words, this can be defined as the average difference between the number of downloaded layers of any successively received segments.

• •

  QoE-fairness: The variance of video quality received by clients at the same time.

The schematic communication topology of the proposed framework is illustrated in Fig. 1. In this architecture, by leveraging the SDN paradigm, we introduce an SVC flow optimizer (SFO) application module as the core part of $S^{2}VC$. In fact, the SFO is employed by the SDN controller to efficiently enable an SVC-based HTTP adaptive streaming service for responding to the requests of DASH clients. This communication model can be utilized in the network edge and the requests of DASH clients will be served by HTTP-media cache servers if the requests hit; otherwise they must be forwarded to the origin server located on the Internet. However, the present study assumes that all DASH client requests are served by the local HTTP-media servers.

To clarify and investigate the operation of the proposed approach, we also illustrate the three layer architecture model of $S^{2}VC$ which consists of the infrastructure, control, and application layer (see Fig. 2). As illustrated, OpenFlow (OF) switches, the SDN controller, and the SFO module are placed in the infrastructure, control, and application layer, respectively.

$S^{2}VC$ operates in a time slotted manner, in which, in each time slot $\tau$ SFO must be executed to determine an optimal solution. Both DASH clients and HTTP-media servers are connected to the SFO via OF switches and the SDN controller. DASH client request must be sent to the SDN controller for determining the optimal solution through SFO. Thus, to have the minimum overhead of OF switches, we configure that DASH clients connect to a default HTTP-media server with a specific IP and port address. Therefore, the client-side OF switch (the first hop OF switch of the DASH client) receiving a packet with destination IP and port address of the default HTTP-media server, is configured to be forwarded it to the SDN controller as a Packet-In. Considering the received requests and available resources, e.g. link bandwidth, SFO determines an optimal solution for the addressed problem. Thereafter, through the SDN controller, SFO configures the selected HTTP-media servers and OF switches in order to launch the data transmission process, which is achieved by sending a Packet-Out message to the OF switch. The message exchanges among these items are depicted in Fig. 3. The SFO is comprised of five components: the request analyzer, resource monitor, flow optimizer, flow setup, and data catalog component.

Request Analyzer Component (RAC): After receiving the Packet-In, the SDN controller forwards it to the RAC. RAC is responsible for receiving the DASH client requests at each time slot $\tau$, at which point it launches the flow optimizer component. In fact, each time slot $\tau$ is divided into three unequal intervals: the gathering, optimization, and configuration interval (see Fig. 4). The two short optimization and configuration intervals are allocated for running the flow optimizer component and configuring OF switches to start data transmission, respectively. According to the output of the flow optimizer component, it is possible that data transmission takes longer than the time slot. In the gathering interval, RAC buffers the received requests from the DASH clients and performs some pre-processing on the collected requests to prepare them as an input parameter for the flow optimizer component in the next time slot.

In the pre-processing step, RAC must extract some key values from the client requests. According to the received requests in each gathering interval, RAC creates two sets, namely $\mathbb{C}$ and $\mathbb{D}$. The first set, $\mathbb{C}$, includes of the client-side OF switches with their connected DASH clients, where $\mathcal{N}_{i}$ indicates the DASH clients connected to the client-side OF switch $i$ and $\mathbb{D}$ is the set of DASH clients that request to download desired layers of demanded segments. Since the flow optimizer component needs to take all gathered requests into account, RAC assigns a unique identification (ID) for each request by parsing the headers of transport and the application layers of the incoming packets, e.g. a combination of incoming sockets and the file name of the requested segment. Furthermore, RAC suggests $\theta_{c}$ as the deadline for buffering the requested segment (the waiting time of DASH client $c\in\mathbb{D}$ in the gathering interval can be taken into account) and $m_{c}$ as the maximum video quality layer of the segment determined by client $c\in\mathbb{D}$. We note here that the values of $\theta_{c}$ can be assumed as fixed. However, to achieve a more flexible model, it is possible these be determined by DASH players or RAC as appropriate. As illustrated in Fig. 4, the two clients, $i$ and $j$, send their requests in time slot $k-1$. Both clients must wait for the optimization interval of the next time slot (time slot $k$) to obtain an optimal solution. As shown, the deadlines for the requested video files in time slot $k-1$ are considered as being from the beginning of the next time slot or time slot $k$.

Resource Monitor Component (RMC): Before describing RMC, let us define graph $G=\{V,E\}$, where $V$ is the set of OF switches, DASH clients, and HTTP-media servers; and set $E$ represents the edges of $G$, where ${e_{ij}=1}$ if a direct communication link exists between the two entities of $i$ and $j\in V$. At the beginning of each time slot, RMC uses RESTful APIs to obtain the available links’ bandwidth from the SDN controller. The measured values are stored in a two-dimensional array $B$, in which $b_{ij}$ indicates the available bandwidth between $i$ and $j$ $\in V$. The connectivity among OF switches, DASH clients, and HTTP-media servers can easily be inferred from $B$. In fact, this component constructs graph $G=\{V,E\}$ and the available bandwidth among the nodes in $V$.

Data Catalog Component: This component provides critical meta-data about the available video files in HTTP-media servers. The meta-data includes the list of servers, stored file segments, layers, and their properties, such as: the size and bit-rate of each layer. We define $\mathbb{S}$ as the set of HTTP-media servers, in which at least one requested layer $l$ by DASH client $c\in\mathbb{D}$ is stored, where $l\leq m_{c}$. In fact, the data catalog component sets $a^{s}_{cl}=1$ if layer $l$ requested by $c$ is available in server $s$, else $a^{s}_{cl}=0$. The data catalog component also uses $\delta_{cl}$ to show the size of layer $l$ requested by DASH client $c\in\mathbb{D}$.

Flow Optimizer Component (FOC): In this component, we introduce a Mixed Integer Linear Programming (MILP) model to jointly determine optimal quality adaptation and data paths for delivering the requested data from HTTP-media servers to DASH clients, while maximizing the fairness and QoE. To find an optimal solution, a number of constraints must be satisfied. Before describing these, we define the input parameters as follows: $\mathbb{C},\mathbb{D},\text{ }\theta_{c}\text{, and }{m_{c}}$ provided by RAC; $B\text{ and graph }G$ prepared by RMC; and $\mathbb{S}\text{ and }{A}$ obtained from the data catalog component. Table I provides the main notations.
Let binary variable $\omega^{s}_{cl}$ determine whether server $s$ serves the requested layer $l$ by client $c$ ($\omega^{s}_{cl}=1$) or not ($\omega^{s}_{cl}=0$). Thus, the following constraint states that one server can serve the requested layer:

The next constraint states that if server $s$ has a copy of requested layer $l$, then it can be selected as a candidate to respond to that client:

The third constraint guarantees that each client $c\in\mathbb{D}$ buffers a valid sequence of layers. In other words, if client $c$ receives layer $l\leq m_{c}$ from any server, then all layers from 1 to $l-1$ must be transmitted to it. Thus, we have:

Let $t^{cl}_{ij}$ be a data rate at which $i\in V$ sends the $l^{th}$ layer requested by $c\in\mathbb{D}$ to $j\in V$ during $\theta_{c}$ units of time. To determine the data rates for transmitting all the requested layers from the optimal selected HTTP-media servers in $\mathbb{S}$ to the DASH clients in $\mathbb{D}$, the following constraints must be satisfied:

Constraint (III-B) covers three different cases: if $i$ is an HTTP-media server ($i\in\mathbb{S}$), the constraint (III-B) forces server $i$ to generate $\frac{1}{\theta_{c}}\delta_{cl}\omega^{i}_{cl}$ amount of traffic, where $\theta_{c}$ is the specified deadline by RAC for buffering each requested layer $l$ with size $\delta_{cl}$. In the second case, if $i$ is an OF switch, then $\forall\text{ }c\in\mathbb{D}\text{ and }l=1:m_{c}$, the total incoming traffic must be equal to its total outgoing traffic. Finally, the last case states that the all data of layer $l$ transmitting from server $s$ to client $c$ must be received by client-side OF switch $i$ if $(c\in\mathcal{N}_{i})$. The following bandwidth constraint specifies an upper bound for the generated traffic on each link:

To consider the QoE-fairness and QoE metrics in our proposed MILP model, a number of constraints should be satisfied. First, we shall focus on the QoE-fairness in serving DASH clients in each time slot. Note, in this study, the quality of the received segment is measured based on the number of its received layers. This index will be compared to other well-known quality measuring methods in the performance evaluation. Hence, to achieve a fair video quality among the various maximum supported video qualities of the clients, we present the following constraint:

In fact, Eq. (8) determines the biggest gap, denoted by $0\leq Q\leq 1$, between the supported maximum layer $m_{c}$ and the maximum of layer served by the network for each client $c$. It is obvious that, by decreasing $Q$ in the objective function, the variance of the video quality received by clients will reduce and consequently the QoE-fairness will increase. The impact of $Q$ on QoE-fairness is comprehensively investigated in the performance evaluation.

We note that the first two QoE metrics start up delay and number of stalls, are taken into account by selecting the appropriate value for $\theta_{c}$. In fact, $\theta_{c}$ forces the MILP model to forward the requested layer by determining the optimal data rates (see Eq. (III-B)). However, for the other QoE metrics, namely average video quality, number and intensity video quality switches, we need to keep track of their treatments in prior time slots. Let $\bar{\lambda}_{c}$ be the total video quality of the segments downloaded by the client $c$ from the time its first request is sent until the current time slot. Note that the number of downloaded layers for each segment is assumed to be the received video quality of that segment. Thus, the normalized average video quality of client $c$ from the beginning of its work until now, denoted by $T_{c}$, is obtained through the following constraint:

where $T_{max}=max\{\bar{\lambda}_{i}+m_{i}\mid\forall i\in\mathbb{D}\}$ and $\varphi_{c}$ and $\sum_{s\in\mathbb{S}}\sum_{l=1:m_{c}}\omega^{s}_{cl}$ are the total number of requested segments and the achieved layers of the video requested in the current time slot by client $c$, respectively.

Let $\bar{\mu}_{c}$ and $\bar{\nu}_{c}$ be the total intensity and the total number of video quality switches by DASH client $c$ while obtaining segments from the beginning of its operation until the current time slot, respectively. Hence, the normalized average intensity of video quality switches, $I_{c}$, for client $c$ can be obtained as follows:

where $I_{max}=max\{\bar{\mu}_{i}+m_{i}\mid\forall i\in\mathbb{D}\}$. In Eq.(10), $\mid\sum_{s\in\mathbb{S}}\sum_{l=1:m_{c}}\omega^{s}_{cl}-\bar{l}_{c}\mid$ shows the difference in video quality among the layers received in the previous time slot denoted by $\bar{l}_{c}$, and the achieved layers in the current time slot, as well as the notation $\mid.\mid$ indicating the absolute operation. Now, if $\mid\sum_{s\in\mathbb{S}}\sum_{l=1:m_{c}}\omega^{s}_{cl}-\bar{l}_{c}\mid>0$, we can conclude that the quality of the segment received in this time slot oscillates with respect to the perceived quality in the previous time slot. This statement can be formulated as follows:

where the defined binary variable $\nu_{c}$ determines whether the quality oscillation of the received segment occurs or not. Therefore, if $\nu_{c}=1$, the quality of the video oscillates else it remains unchanged. Thus, the normalized average number of video quality switches $N_{c}$ for client $c$ is obtained as follows:

where $N_{max}=max\{\bar{\nu}_{i}+1\mid\forall i\in\mathbb{D}\}$. Therefore, the MILP used in FOC can be represented as:

In each time slot, FOC runs the above MILP model to maximize both QoE metrics and QoE-fairness by determining the optimal quality adaptation and data rates to transmit the requested layers. In addition to maximizing the defined QoE metrics and QoE-fairness, the objective function Eq. (13) implicitly preventing the waste of network resources by decreasing the total generated traffic (the last term in the objective function). We can also set desirable priorities for these metrics using constant weights $\alpha,\text{ }\beta_{1c},\beta_{2c},\text{ and }\beta_{3c}$. For instance, $\beta_{1c}\text{ and }\beta_{2c}$ can assist us to determine how important client $c$ is to receive segments without any quality oscillation. The weights can be adjusted by the application policies in each time slot.

Theorem 1: The proposed MILP formulation (13) is an NP-complete problem.

Since the proposed MILP model (13) is an NP-complete problem and suffers from high time complexity [46], we propose a linear relaxation of the MILP model that can be centrally run by FOC. To do this, a virtual HTTP-media server is considered instead of set $\mathbb{S}$ by the assumption that all members of $\mathbb{S}$ are organized in a full mesh topology with no bandwidth restriction. Based on this assumption, the virtual HTTP-media server can serve all layers requested by DASH clients. Let $\chi_{c}\in\mathbb{R}_{\geq 0}$ show the fragmentation of the maximum supported quality ($m_{c}$) that can be served by a virtual HTTP-media server, where $\forall c\in\mathbb{D}$ and $\chi_{c}\leq m_{c}$. In fact, $\chi_{c}$ is the amount of requested data that the virtual HTTP-media can transmit to client $c$. Now, by performing some minor modifications on (13), the LP relaxation model can be represented as follows:

In constraints (VI-VII), $t^{c}_{ij}$ is defined as the data rate at which $i\in V$ sends video traffic requested by $c\in\mathbb{D}$ to $j\in V$ in $\theta_{c}$ units of time. Also, $\bar{\delta}_{c}$ is the average layer size of the segment requested by client $c$. By taking the floor of the fractional values of $\chi_{c}$, an approximate solution to the model (13) can be obtained. After determining the sub-optimal data rates and paths, the flow setup component is called.

Flow Setup Component (FSC): After determining the sub-optimal solution by FOC, a method should be developed and utilized to enable the network to support different data transmission rates. To achieve this, OF switches and HTTP-media servers should be configured accordingly.

As stated in [47], Open vSwitch (OVS) is able to provide desirable data rate calibration on each flow using its queuing feature. However, configuring different queues on all OF switches may be a simple, yet naive idea because of two reasons. First, there are numerous video files with different data rates that must be delivered in each time slot. Second, the probability of misconfiguration grows as the number of switches increases.

Therefore, we propose an agile and reliable method based on tagging the type of service (TOS) field of the data packets originated by the HTTP-media servers to the destination DASH clients. Generally, the tagging process can be performed by HTTP-media servers or server-side OF switches. However, to achieve a minimum overhead in OF switches, we delegate the tagging process to the HTTP-media servers.

The FSC operation for each requested layer can be divided into two main steps: (1) configuring the HTTP-media server to tag the outgoing packets, and (2) configuring OF switches to provide the determined data path and rates.

Step 1: In this step, FSC should determine the minimum required tags for the generated data packets and then configure the selected HTTP-media server to apply the tags. For ease of explanation, let us present an example illustrated in Fig. 5. Suppose all DASH clients are configured to send their request to a default HTTP-media server with IP=’X’ and port=’Y’. Thus, as illustrated in Fig. 5 (a), the client-side OF switch ’$v6$’ receives a request from DASH client ’$B$’ with destination IP ’X’ and port ’Y’. Then, it forwards this packet to the SDN controller as a PACKET-IN message. Upon receiving the PACKET-IN message, the SDN controller delivers it to its RAC component for analyzing the packet. After processing the request received by RAC, FOC selects the HTTP-media server ’$A$’ to serve DASH client ’$B$’ for layer ’$l$’ based on the optimal data path and transmission rates, (see Fig. 5 (b) for the given deadline $\theta_{B}=2$ seconds). Now, with the optimal data path and rate $t^{Bl}_{ij}$, the minimum number of tags must be calculated by FSC. In fact, a list of base data rates $\mathbb{B}_{Bl}=\{b_{1},b_{2},...,b_{n}\}$ must be produced, in which $\forall i,j\in V$, $t^{Bl}_{ij}$ is decomposing into $\mathbb{B}_{Bl}$. To determine the $\mathbb{B}_{Bl}$ values, we propose a simple recursive function named base_data_rates (see Alg. 1).

This algorithm traverses the data path from the client-side OF switch ’$v6$’ to HTTP-media server ’$A$’ by calling function $base\_data\_rates$ (’$v6$’,’$A$’). This function stops calling itself when it meets the root of data path (HTTP-media server ’$A$’) (lines 1-3). In line 4, list $L$ is set to all incoming links of $n$ (i.e. $v3\rightarrow v6$, $v4\rightarrow v6$, and $v5\rightarrow v6$ for $n=v6$). For each link $l$ in $L$, we first define $\bar{L}$ as the list of incoming links to $p$ that have not been visited yet, where $p$ is the upstream peer for $n$ on link $l$. For instance, for $n=v6$, $l=v4\rightarrow v6$, $p=v4$, and $\bar{L}=\{v1\rightarrow v3\}$, if the algorithm finds a combination of data rates of $\bar{L}$ equal to the data rate of $l$, then all links in that combination are set as visited links and the for loop goes for the next link (lines 9-12). Consider Fig. 5(b) as an example, in which the condition of the If statement (line 9) is TRUE for link $l=v3\rightarrow v6$, since $data\_rate(l)=data\_rate(v1\rightarrow v3)$. As it can be seen in Fig. 5(b), for $n=v6$, the data rate from $v3$ to $v6$ is equal to the data rate from $v1$ to $v3$, hence $v1\rightarrow v3$ is set as the visited link.

However, for $n=v6$ and $l=v4\rightarrow v6$, there is not any combination of $\bar{L}=\{v1\rightarrow v4,v2\rightarrow v4\}$ that provides the same data rate as $v4\rightarrow v6$. In this case, we compare $data\_rate(l)$ with the maximum data rate of $\bar{L}$ (here $v1\rightarrow v4$ with 250 kbps). If $data\_rate(l)>max\_rate(\bar{L})$, then the function $update\_data\_rate\_I(l.\bar{L})$ (Alg. 2) is called. In this algorithm, a combination of unvisited links to $p$ (e.g., $v4$ for $n=v6$) is determined firstly, which provides the minimum data rate that is greater than $data\_rate(l)$ (lines 4-9). Then, virtual link $vl$, which is added to $\bar{L}$, and the extra data rate are allocated to it (lines 10-13). Refer to link $v4\rightarrow v6$ in Fig. 5 (c) which results in the addition of a virtual link $v1\rightarrow v4$ with data rate 50.

On the other hand, in the case of $data\_rate(l)<max\_rate(\bar{L})$, the next function, $update\_data\_rate\_II(l.\bar{L})$, executes (Alg. 3). Let $l2$ have the maximum data rate of $\bar{L}$ (for $n=v4$ and $l=v2\rightarrow v4$, we have $l2=HTTP-mediaserver$ ’$A$’$\rightarrow v2$). In this case, virtual link $vl$ with the same data rate $data\_rate(l)$ is added to $\bar{L}$. We also set $vl$ as the visited link (line 4). Since the data rate of $vl$ must equal $data\_rate(l)$, we then update the data rate of $l2$ to $data\_rate(l2)-data\_rate(l)$ (line 6). See link $v2\rightarrow v4$ in Fig. 5 (c) which results in the addition of a virtual link from HTTP-media server ’$A$’ to $v2$ with a data rate of 300). In line 20 of the $base\_data\_rates(n,m)$ algorithm, the function calls itself for each $n$’s upstream switches. Finally, the list of base data rates $\mathbb{B}_{Bl}$ is equal to the all outgoing data rates, including the data rates of virtual links. In this example, the obtained base data rates are $\{50kbps,50kbps,200kbps,200kbps,300kbps\}$ (refer to the outgoing links from HTTP-media server ’$A$’ in Fig. 5 (c)).

After the base data rates are calculated, FSC configures the HTTP-media server to tag the outgoing packets accordingly. To do this, FSC concatenates the following parameters to the URL address in the request packet: (1) base data rates, (2) deadline value $\theta_{c}$, (3) list of required tags, and (4) list of server-side OF switches connected to the selected HTTP-media server. Thereafter, FSC asks the SDN controller to send the outgoing packets back to the client-side OF switch as a PACKET-OUT message. Note that the destination address of the PACKET-OUT message is set to the selected HTTP-media server. The client-side OF switch now forwards the packet to the specified HTTP-media server (Fig. 5 (e)).

As depicted in Fig. 5 (d)-(e), for the obtained base data rates (i.e., $\{50kbps,50kbps,200kbps,200kbps,300kbps\}$), the FSC sets $tag=\{1,2,3,4,5\}$ and server-side OF switches=$\{v1,v1,v1,v2,v2\}$. This configuration signifies that the HTTP-media server ’$A$’ must send the amount of $\theta_{B}\times 50kbps$ data to server-side OF switch $v1$ with tag 1, the amount of $\theta_{B}\times 50kbps$ data to $v1$ with tag 2, and so forth.

Step 2: In this step, FSC installs the required rules in OF switches to forward packets according to the determined data path. Each rule filters incoming packets according to the ToS tag, source and destination IP and port addresses, and then specifies the output port (see Fig. 5(d)). For more transparency, the client-side OF switch replaces the source IP and port addresses of the incoming data packet from the HTTP-media server with the default IP and port addresses. (Fig. 5(e)).

According to the buffering deadline ’$\theta_{c}$’ and the requested segment duration, we can eliminate the stalling phenomenon in clients by setting $\theta_{c}\leq$ $(segment\_duration)-(time\_slot\_duration$ $\tau)$. The transmission delay can also be considered when determining the $\theta_{c}$ value. Thus, by choosing $\theta_{c}\leq 3s$, model can guarantee that stalling phenomenon never happened. The next QoE parameter, start-up delay, depends on $\tau$ and $\theta_{c}$ too. In fact, in the worst case, a client may join the network exactly at the beginning of when the optimization algorithm is run. In this case, the client has to wait for $\tau+\theta_{c}$ seconds to receive the video. On the other hand, in the best case, the client’s request is submitted exactly before the optimization algorithm is run and the video is delivered after $\theta_{c}$ seconds. Notably, the average waiting time for clients may be expressed as $\theta_{c}+\frac{\tau}{2}$. The empirical results proved these statements.

In the first experiment, we focus on the video quality received by clients. To measure this parameter, we employ the Structural Similarity Metric (SSIM) [48]. In fact, SSIM can be utilized to assess the mean delivered video quality to clients in each time slot (Fig. 8). As mentioned in the proposed model, we set the video quality of a segment equal to the number of its received layers. Now, by comparing Fig. 8 and Fig. 9(a), it can be concluded that both methods follow the same approach. Thus, this proves that considering the number of received layers for a segment can be mapped as an index for measuring video quality. In our next experiment, we measure the changing weight of client 2 to show the capability of the system to apply different policies.

We therefore evaluate the impact of changing the $\beta_{3c}$ value for $c=2$. This value is related to parameter $T_{c}$ in model (13), which shows the average video quality of each client $c$ from the beginning to the present time. With the increase of $\beta_{32}$, it is expected that client 2 receives a higher video quality in comparison to others. In Fig. 9(a), the behavior of the system with the default value of $\beta_{32}$ is depicted. As shown in Fig. 9(b), by doubling the value of this parameter, the delivered video quality for client 2 increases in time slots 7 and 10. Moreover, by considering the bandwidth limitation, it can be seen that, due to the higher video quality of $C_{2}$, the video quality of $C_{3}$ and $C_{5}$ lowers. When bringing the $\beta_{32}$ value further up to 3. Fig. 9(c) shows that the video quality of $C_{2}$ improves in time slot 6. Therefore, by raising the $\beta_{32}$ value to higher values, we can guarantee the maximum quality for client 2 during all time slots.

In the next experiment, we investigate the impact of changing $\theta_{c}$ in the delivered quality layers. As a reminder, $\theta_{c}$ is defined as the video delivery deadline for client $c$. $\theta_{c}$ is assumed to be identical for all clients. Obviously, by increasing the value of $\theta_{c}$, resource utilization can decrease and a higher video quality may be delivered to clients. This is because the proposed model has more time to deliver the requested video and consequently it is able to send higher video quality at a lower transmission data rate. The treatments of the model for different values of $\theta_{c}$ are illustrated in Fig. 10. The normal status of the network ($\theta_{c}=1$) is shown in Fig. 10 (b). As seen, by increasing the $\theta_{c}$ value from 1 to 1.7, the maximum video quality (i.e. $m_{c}$) can be delivered to clients (see Fig. 10 (c)). Although raising $\theta_{c}$ promotes the overall quality of the delivered video, the possibility of stalling occurring for clients grows. In fact, the stalling phenomenon specifies an upper bound for $\theta_{c}$. Basically, the proposed framework can centrally offer an appropriate $\theta_{c}$ by considering the total duration of delivering video to client $c$. We will elaborate on this in a future study. Notably, by choosing a smaller value for $\theta_{c}$ (Fig. 10 (a)), we can force the model to immediately fill the buffer of the clients; in this case, the model has to send the highest possible quality to the clients at high data rate. Therefore, as for limited bandwidth, it is obvious that some clients will be deprived of obtaining more quality (see Fig. 10 (a) for $\theta_{c}=0.6$).

In the next experiment, we evaluate the impact of changing the values of the other two weights in our model: $\beta_{1c}$ and $\beta_{2c}$. By increasing the values of these weighting factors for $C_{2}$, it is expected that the number and intensity of quality changes shall decrease. Fig. 11 (a) presents the system behavior with the default settings. In the first step, we increase the value of $\beta_{12}$ and $\beta_{22}$ to $1$. As seen in Fig. 11(b), the controller tries to reduce number of the quality changes, which increases the video quality in time slot 10. Also, to raise the video quality of $C_{2}$, the controller has to reduce the video quality of other clients. For example, in the 10th time slot, the MILP model lowers the quality of $C_{3}$ to boost the video quality of $C_{2}$ (see Fig. 11 (b)).

As presented in Fig. 9 (a) and 11 (a) (default cases), the requested quality was not completely delivered in time slots 6, 7, 8 and 10. To clarify the reason for this treatment, we measure the total volume of requested layers by the clients and the amount of sent data by MILP in each time slot. In fact, due to the bandwidth limitation, the MILP model can not deliver the total amount of requested layers in some time slots 6, 7, 8, and 10. Although the number of delivered quality layers lowered in time slots 6, 8 and 10, the amount of sent data in these slots is reasonable when considering the bandwidth limitation. This phenomenon occurs in other scenarios (see Fig. 9 (b,c) and 11 (b)).

Parameter $\alpha$ is responsible for providing video quality fairness in the network (see the proposed model (13)). Fig. 12(c) presents the status of the system in default mode ($\alpha=1$). As depicted in Fig. 12, by decreasing the value of $\alpha$ from $1$ to $0.5$ and also lowering it to $0.1$, the MILP model does not try to serve all requested clients.

For example, in the cases of $\alpha=0.5$ (Fig. 12 (b)) and $\alpha=0.1$ (Fig. 12 (a)), the Flow Optimizer component (FOC) decides to respond to $C_{3}-C_{5}$ after the 6th and 8th time slots, respectively. As a result, lowering $\alpha$ can reduce the overall QoE-fairness. Moreover, by considering different values for $\alpha$, we measure the variance of normalized received quality layers in each time slot and also the maximum gap between the maximum supported video quality layer $m_{c}$ and the delivered layer that is equal to $max\{m_{c}-\sum_{l}\omega_{cl}\mid\forall c\}$ (refer to Fig. 13). As seen, this difference grows dramatically in the 6th time slot for $\alpha=0.1$ and $\alpha=0.5$; however, it reduces after $\alpha$ increases. An identical treatment showing variance in Fig. 13. Furthermore, we use the QoE-fairness index introduced by Hossfeld et al. [54] as follows:

By employing the proposed framework in [55], we compare our introduced MILP model with three network-based methods: QoE-FF framework[30], SPM[56], and NADE[57]. As it is depicted in Fig. 14, our proposed model is able to outperform other approaches in term of start-up delay. NADE proposed a video control plane which enforces video quality fairness among concurrent video flows generated by heterogeneous client devices. Also, it can be seen that NADE yields the highest fairness among all the approaches. Nevertheless, our proposed model performs almost the same as NADE. On the other hand, QoE-FF outperforms NADE, SPM, and our proposed model in term of quality switches. The reason is NADE is not designed to foresee the occurrence of video freezes and avoid them. However, as it appears in Fig. 14, our proposed model produces acceptable results for this parameter. QoE-FF seeks to optimize the QoE by taking into account two main constraints: the devices resolution and current available bandwidth. However, it does not consider the current buffer occupancy. Thus, for both QoE-FF and NADE mechanisms, decreasing the available bandwidth can significantly increase the stalling phenomenon. As a result, in these approaches, clients may be subject to buffer starvation. Meanwhile, our proposed model guarantees that stalling will never happen. Moreover, QoE-FF framework does not support large number of clients, since it generates high overhead which can degrade the overall performance. Finally, Fig. 14 shows that all the studied frameworks produce almost the same results for both min and mean SSIM.

Before discussing the comparison of the proposed models, let us provide a brief overview of the number of generated OF commands for configuring the network switches. We conduct experiments with default (D) topology (Fig. 7) then enrich our experiments with extended (E) topology (Fig. 15) (by increasing the number of switches to 12) and measure the number of OF commands for all the active switches in each time slot. After a traffic flow finishes, each flow table entry will be removed from the switch. As seen in Table II, by increasing the number of clients, the number of OF commands moderately increases, because of dividing traffic and utilizing more data paths to the destination.

In the next step, we present the performance evaluation of the proposed MILP and LP-relaxed models with respect to different metrics. At first, we compare the execution time of the models written in Python and Pulp library [58]. Employing the default and extended network topology and increasing the switch links bandwidth from 8 to 100 Mbps, we run experiments with 10, 20, 30, and 40 clients, with the results showing the practical applicability of the algorithm (refer to Table II). As seen in Table II, our MILP model has a significantly higher execution time. With the growth of network size, this difference can be even higher. On the other hand, the results show that for limited number of clients and switches, the relaxed model is more applicable than the MILP and can be used in bigger networks. We extend the investigation by comparing the measured values of objective functions in both models according to the default topology. As presented in Fig. 16, the obtained objective values of our LP-relaxed model are lower than those of MILP in some time slots (e.g. 6, 7, 8, and 10). The average of delivered quality layer ($T_{c}$) and quality switches ($I_{c}$) in each time slot are given in Fig. 16. As we observe, the average of the delivered quality layer and also the quality switches obtained by the LP-relaxed model report a lower performance in comparison with the MILP model in some time slots. The first possible reason for this is the rounding down of variable $\chi_{c}$ in Eq.14. Another explanation can be the calculation of $\bar{\delta}_{c}$ as the average segment size of the video requested by client $c$. Moreover, with the default parameters, the values of the delivered quality layer obtained by the LP-relaxed and MILP models are shown in Fig. 17 (a) and (b), respectively. Although the MILP and LP-relaxed models have different treatments in delivering quality layers, especially in time slots $6,7,8,$ and $10$, the amount of sent data in these time slots are almost equal (See Fig. 18). In the final experiment, we compare the maximum received quality to its maximum supported value $m_{c}$ for the MILP and LP-relaxed models. We show these parameters as $max\{m_{c}-\sum_{l}\omega_{cl}\mid\forall c\}$ and $max\{m_{c}-\chi_{c}\mid\forall c\}$, respectively (see Fig. 19 (a)). Although Fig. 19 (a) shows identical behavior, the LP-Relax model surpasses MILP in the variance of the delivered quality layer (see Fig. 19 (b)). Note that the variances are measured based on the normalized values of the delivered quality layers.