A Novel Distributed Multi-Source Optimal Rate Control Solution for HTTP Live Video Streaming

HTTP live streaming delivers dynamically video content with varying bitrates to accommodate the dynamic real-time bandwidth fluctuations while considering diverse user preferences and device capabilities. Existing flow control solutions do not provide support for new features such as multi-source content transmission. In this paper, we propose a distributed multi-source rate control optimization algorithm (DMRCA) that maximizes the overall network bandwidth utility and improves viewer Quality of Experience (QoE). First, we model the rate control problem as a dual-optimized multi-source and multi-rate problem. Then, we decompose the problem into sub-problems of source rate selection and user rate adaptation and we prove that solving the original problem is equivalent to solving these two sub-problems. Furthermore, we propose DMRCA as a fully distributed algorithm to solve these sub-problems and derive an optimal solution and we discuss DMRCA’s complexity and convergence. Finally, through a series of simulation tests, we demonstrate the superiority of our proposed algorithm compared to alternative state-of-the-art solutions.


I. INTRODUCTION
L ATELY, there is a surge in the popularity of high quality multimedia streaming over the Internet [1], [2], [3], [4], enabled by its ability to provide timely, immersive, and personalized viewing experience.The video streaming market is forecasted to grow by $310.44 bn during 2022-2027, accelerating at a CAGR of 20.36% during the forecast period [5].The widespread adoption of smart devices and the heterogeneity of communication technologies (e.g., 5G and beyond, WiFi, Fiber) have offered video users various resolution capabilities, screen sizes, processing power and diverse access network bandwidth and delay, among other aspects [6].These support the provision of an unprecedented range of services to an increasing video viewing population.Diverse solutions were proposed which tailored video content to different presentations (i.e., bit-rate, resolution, etc.) and dynamically performed adaptive delivery to meet bandwidth fluctuations, diversity of device characteristics or other deployment-related requirements.For instance, the authors of [7] have proposed an user gaze-driven adaptive solution for omnidirectional video delivery, researchers of [8] have designed an energy-aware adaptive solution based on machine learning and QAVA [9] has introduced a quality-aware adaptive video bitrate solution based on smart edge computing.DQAMLearn [10] proposed a solution for educational video quality control on mobile devices with different features, authors of [11] discussed an innovative solution for virtual reality video streaming and researchers of [12] proposed a viewport reconstructionbased 360 • video caching solution for Tile-adaptive streaming.Authors of [13] have introduced a decentralised multicast adaptive solution, those of [14] have proposed a fuzzy logic solution for adaptive video streaming and researchers of [15] have proposed a new neural enhanced adaptive streaming framework for variable bit rate encoded videos, which is based on selective prefetching of video blocks.Among adaptive video streaming solutions, some researcher focus on HTTP Live Streaming [16], [17], [18], which supports users to enjoy high quality video streaming through the HTTP protocol.These solutions provide lightweight but effective algorithms that can be easily deployed in Web video applications.HTTP Live Streaming has emerged as a promising paradigm for video streaming in the context of future networks and services.
However, most studies related to HTTP live video streaming concentrate on how to allocate network bandwidth given a certain target bitrate suggested by an Adaptive Bit-rate (ABR) algorithm [19], [20], [21].While most ABR algorithms address the bit-rate selection issue at the client side, little attention is given to the rate control problem at the video provider's end.Nevertheless, it should be noted that this rate control issue directly impacts bandwidth utilization of links and improving network bandwidth utilization enables nodes within the network to transmit data at higher rates.As a result, there is a direct improvement in video transmission quality, which is desired.Unfortunately, most rate control algorithms do not consider key aspects of video transmission scenarios such as multi-source topology and multi-rate transmission [23], [24], [25], [26].
The consideration of these new aspects increases the complexity of both the solutions and network topology.A higher number of video source providers allows for content delivery by multiple node servers within the network, resulting in the possibility of a serving node switch during transmission, and thereby altering the transmission path [22].This makes it more challenging for servers to access comprehensive network information for performance improvement purposes.For instance, they may be able to utilize the information associated with their own node only for flow control.Therefore, there is a need to propose a distributed rate control strategy that specifically considers multi-source and multi-rate aspects during the video transmissions, in order to enhance network bandwidth utilization and optimize user experience.
In this context, this paper proposes an innovative distributed HTTP Live Streaming rate control mechanism, based on a mathematical investigation of the achievable global rate optimization in a multi-source multi-rate video delivery context.An important feature of the proposed distributed multi-source rate control optimization algorithm (DMRCA) is that it enables providers and video consumers to dynamically select optimal streaming rates individually, without relying on a centralized control.The effectiveness of the proposed algorithm is assessed via extensive simulation tests in comparison with alternative approaches.
In summary, this paper's main contributions are as follows: 1) Multi-source rate-adaptive problem: by theoretically modeling the HTTP Live Streaming, we formulate the optimal rate selection problem of HTTP Live Streaming as a multi-source rate-adaptive problem (MAP).We then introduce a linear relaxation of MAP and prove its concavity, which has unique optimal solutions.2) Problem decomposition: MAP is decomposed into a rate selection sub-problem (SRSP) and an user rate adaptive sub-problem (URAP).We prove the equivalence between the original MAP and the two sub-problems.Furthermore, we discuss the duality of the two subproblems in order to solve the rate control problem in a decentralized context.3) Distributed design: we propose a distributed optimization for the DMRCA algorithm to derive the global optimal rate control which enables providers and users to solve the rate control problem without central coordination.Moreover, the complexity, convergence and time varying adaptation aspects of DMRCA are also discussed.4) Performance evaluation: DMRCA was evaluated against other state-of-art solutions under different network topologies.The simulation tests show how the proposed algorithm outperforms existing solutions in terms of average bitrate and playback freeze frequency.The rest of the paper is organized as follows: Section II surveys related works.Section IV describes the network and QoE models.Section V analytically formulates MAP and its linear relaxation, and the problem is decomposed into two subproblems in Section VI.The DMRCA design is carried out in Section VII.Performance evaluation and conclusions are provided in Sections VIII and IX, respectively.

II. RELATED WORKS
The stringent demands for high throughput and low latency associated with the latest video services dictate significant requirements in relation to the transmission rates.Diverse flow control mechanisms are employed to determine the rate at which data packets should be transmitted.By optimizing the flow control process, video content can be transmitted at a higher rate and lower loss, thereby enhancing the quality of presentation.This is equally performed for pre-recorded and live video streaming and the goal is to improving the viewers' Quality of Experience (QoE).Consequently, numerous research efforts have been focused on this issue, aiming to design innovative flow control algorithms to improve the performance of content delivery, including by maximizing the overall network bandwidth utilization.
In [23], a throughput control method that leverages the HTTP2 Flow Control mechanism is proposed.The author designs a video streaming framework, in which a manager is situated at the client side.This manager continuously monitors the bandwidth of the bottleneck network and manages the throughput by adjusting the flow control window size.The authors note that while some solutions utilize the TCP flow control to manage server sending rates, this approach may be susceptible to security concerns.Given that the flow control method in [23] is deployed at the application layer, it is considered to be a relatively straightforward solution to deploy and upgrade.
In the context of recent protocols such as QUIC, due to its implementation based on UDP, which itself does not have flow control, it implements its own native flow control strategy.The flow control of QUIC itself is based on restrictions, which mainly include two parts.The first part is to limit the amount of data that can be sent on each flow to prevent a single flow from occupying the entire receiving buffer of the connection.The second part is to limit the total number of bytes of stream data sent in stream frames across all streams.An enhanced flow control algorithm has been proposed to improve the original credit-based algorithm [24].This new algorithm modifies the threshold one packet ahead of the original flow control algorithm in QUIC.This change circumvent misjudgments of the flow control update signal's timing.Concurrently, the method for updating the maximum receive offset has been altered, thereby avoiding the potential sub-optimal behavior of the original scheme.The enhanced algorithm has been validated through simulation experiments and has been demonstrated to achieve the optimum performance in FC-limited scenarios.
Recently, machine learning techniqueswere employed to solve increasingly complex problems, including to address rate control issues.Iris [25] introduced an end-to-end statistical learning-based congestion control method for real-time video transmission.Within Iris, all streams maintain a small, fixed number of packet queues to ensure minimal latency and equitable bandwidth allocation.For rate control, a statistical learning approach is employed to dynamically adjust the transmission rate via online linear regression learning.This eliminates the need for the fixed-step adjustment strategy employed in traditional methods, resulting in accelerated convergence.In [26], a reinforcement learning-aided in-network congestion control scheme was proposed to address network volatility on a time scale of 10 to 100 milliseconds.The algorithm is directly deployed at the switches.The scheme leverages a multi-agent deep deterministic policy gradient (MADDPG) algorithm to enable a distributed execution during centralized training.A component within the training center gathers information regarding the behavior of all switches in the system and provides feedback, enabling the switches to complete the training process in a distributed manner.
In the field of dynamic bit rate encoded videos, some flow control strategies limit the amount of data from the encoding level.In recent research of [27], a 360 degree video encoding rate control (RC) algorithm based on virtual competitors is proposed, which combines game theory to propose a frame level bit allocation model based on virtual competitors.The algorithm provides a GOP level bit allocation scheme and designs an overall bit rate allocation scheme based on this to reduce the bit rate fluctuation of GOP.The scheme has been proven to have the optimal Rate Control error and bit rate fluctuation.Authors in [28] have proposed a quality control algorithm to replace the rate control algorithm in video transmission.The algorithm models the optimization problem of rate distortion based on the rate distortion model, and solves this continuous convex problem through the Karush-Kuhn-Tucker equation.The author combines the rate quality (R-Q) model to implement the proposed algorithm in versatile video coding (VVC), and conducts verification experiments to prove that the algorithm can achieve stable coding quality while ensuring coding performance.
However, multi-source capabilities represent a novel feature that cannot be overlooked when addressing flow control challenges.Performance-aware multi-source delivery solutions would benefit from information about the network.However, there is a lack of access to comprehensive network information, particularly needed when confronted with the increased complexity brought about by multi-source attributes.Implementing flow control algorithms across all nodes to achieve optimal overall bandwidth utilization poses significant difficulties.Consequently, distributed flow control algorithms are required to enable nodes to make rate decisions for global optimization in the absence of information from other nodes.To date, to the best of the authors' knowledge, previous research on the flow control problem in video streaming [4], [23], [24], [25], [26], [27], [28] has yet to demonstrate in practice the benefit of distributed algorithms.Therefore, an urgent need exists for a distributed rate control method that not only supports the multi-source feature but also provides optimal rate configuration for HTTP live streaming.

III. DISTRIBUTED FRAMEWORK
In the context of HTTP live streaming, users can access network services using a variety of devices and from various locations, as illustrated in Figure 1.The figure shows how some users employhigh end computing devices connected to the network via wired connections, thereby enjoying higher bandwidth.Conversely, other users leverage mobile devices to access the network through WiFi access points (AP) or 5G base stations (BS), resulting in comparatively lower bandwidth at the client side.
Concurrently, within the network, several provider nodes cache video resources.On the cloud side, high-performance resource servers are interconnected with edge servers situated closer to users through the core network.These servers are equipped with the capability to cache video resources and provide video transmission services.Along the link between edge servers and users, there may be several router nodes involved.The provider nodes offer various video bit-rates to cater to diverse network conditions and user preferences.For instance, when users encounter poor client-side network conditions leading to video stuttering or delays, they may opt to reduce the bit-rates to ensure smooth playback.
However, user nodes are unable to obtain the status information of the entire network.Although clients can estimate network congestion by calculating in real-time the network bandwidth, their source of information is limited to the links connected to the client.Information regarding congestion at other network nodes, such as congestion at router nodes and server loads, is inaccessible to the client.This makes it difficult determining the appropriate video rate to be requested.A similar information gap exists at service nodes; service nodes can also gather network-related information from the multiple links connected to them.However, within a large network topology, a single node remains unable to ascertain the overall network congestion.As a result, the provider nodes also face the issue of what rate they need to transmit the video data.In the context of the illustration from Figure 1, we consider a distributed framework in which each node deploys a distributed flow control algorithm such as the proposed DMCRA that determines the optimal bit rate selection solely based on information received from the connected link.

IV. SYSTEM MODEL
In this section, we present the network and QoE models to describe the HTTP live streaming system mathematically.Table I summarizes the notations used in the rest of the paper.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

A. Network Model
We consider a network of N nodes including source servers, node servers and users that communicate with each other over a given connected, undirected graph G = (V, L), where V and L ⊆ V × V denote the set of nodes and links between nodes, respectively.Let S = {1, . . ., S} ∈ V be set of video providers in the network and U = {1, . . ., U} ∈ V the set of end users.Due to the in-network caching, we assume that all the node servers are equipped with content repositories and thereby they can be also treated as video providers, namely, they belong to set S. Let p(i, j) denotes the order set of links of the path between the end user j and its provider i: where i, x k ∈ S, k = 1, 2, 3, . . ., n and j ∈ U .l x,y indicates the link between x and y.Assume the network is connected (i.e., all users in U are able to access content from any provider in S).
In our model, we consider the content is encoded by scaled video coding (SVC) [29] which encodes video into a base layer and several enhancement layers.Thus, video can either be decoded with only the base layer or with base and multiple enhancement layers; the more enhancement layers decoded, the better quality of video can be achieved.Let the video in G consist of one base layer and m enhancement layers, the bitrates of the base layer and each enhancement layer k are b 1 and h k , respectively.Accordingly, the types of representation of video v can be defined as To simplify the description, we assume that the required transmission rate of the video is equal to its playback bit-rates and all videos in G have equal B.

B. QoE Model
Currently, most adaptive streaming services support the HTTP-based DASH protocol [30].Along the traditional HTTP streaming, diverse video performance metrics are considered in DASH-based adaptation, including bitrate, stalling and startup delay.Consequently, diverse QoE models have been proposed for DASH with diverse explanations; their use may impact differently the final QoE estimation results.We extend the QoE model introduced in [31] according to our problem scenario: where x is the chosen bitrate and x max is the transmission rate of the best content representation b max .The factor F calculates the impact of stalling time and increases with the increase of the jamming frequency.The detailed calculation method is described in [31].In a HTTP live video streaming scenario, the occurrence of stalling is related to the bitrate.With the increase of bitrate, the possibility of congestion in the network gradually increases.This leads to higher frequency of stalling and lower QoE.However, the sending bitrate of the provider is not able to directly determine the stalling time of the video at the consumer side.In order to minimize the stalling time, we can control the bitrate to meet the following condition: where for a certain video quality level b m , the corresponding video segment data size is D b m and T denotes the time length of the video segment.This condition indicates that the sending time of the video segment should be less than its playback time.In this situation, the impact of stalling can be minimized and F can be regarded as a constant.Thus, we will focus on the rate control problem which mainly considers how to select the playback bitrate to optimize the network bandwidth utility and user QoE.
V. PROBLEM FORMULATION Let x j be user j's delivery rate and ∀j ∈ U , x j ∈ B. We refer to the vector x = {x 1 , x 2 , x 3 , . . ., x U } ∈ B U as the network rate configuration.Generally, we assume that S = x can be also rephrased as {x 1,1 , . . ., x i,j , . . ., x S,U }, where x i,j implies the delivery rate of user j that receives the video from provider i.We represent the capacity of links in L in terms of a vector c = {c 1 , c 2 , c 3 , . . ., c L }.The rate configuration problem of HTTP live video streaming can be described as follows: given a utility function f (x) varying with rate configuration x, how to select a x * so that f (x) is maximized under the link capacity constraints c.
In this paper, f (x) is defined as the overall sum of user QoE values, as follows: where J(•) is the QoE estimation function using the model described in eq. ( 1).Int hsi context, we refer to the rate configuration of HTTP live video streaming as a multi-source adaptive rate problem (MAP), which is outlined below: P1: where l(s) denotes the set of video providers that use link l.
The inequalities in constraints (3) ensure that for any link l, the total rate of providers that use l cannot exceed the capacity c l .Constraints (4) indicate the possible delivery rate of each user j is in B and constraints (5) control the bitrate to minimize the impact of stalling.Considering the form of (4), MAP is an integer programming problem which may be hard to solve.Instead, we consider a linear relaxation version of the MAP, which can be represented as follows: P2: where x ∈ [b min , b max ] U indicates the rate configuration which can be chosen from a continuous U-dimensional close space, which is considered as the relaxation of constraint (4) in P1.
Particularly, the following theorem holds for P2: Theorem 1: Given the J(x) is concave and twice differential as eq.( 1), the problem P2 is a concave optimization problem, namely there exists a unique rate configuration x which maximizes the (6) under constraint (7).
Proof: Intuitively, s∈S i∈s(u) J(x s,j ) is concave given that J(.) is concave and concave propagation propriety of the summation [32].For ∀x, y ∈ [b min , b max ] U and 0 < θ < 1, we have: This is because for ∀i-th component of x and y, x i , y i belong to the continuous interval [b min , b max ], we apparently have: Thus, the closure space [b min , b max ] U is a convex set.max j∈s i (u) l x i,j is a maximum function which is convex [32].Therefore, the relaxation version of MAP is a concave optimization problem [32] and has an unique x * that globally optimizes P2.
Remark: In spite of focusing on a network with the multisource feature, the relaxed MAP can be also easily generalized to other scenarios with minor modifications: 1) Provider with Multiple Video Flows Scenario: Instead of only delivering one video as we assumed in Section IV, providers in realistic environments may concurrently serve multiple videos.To be able to apply our proposed approach in this case, we split the provider i with n video flows into n virtual sources, each virtual source corresponding to a video flow and can be represented by following 4-tuple: where i k indicates the virtual source corresponding to flow k, L(i k ) is the link set used by video flow k and s i k (u) the group of users that access k from i. 2) Multi-path Scenario: A typical network in realistic environments also supports multi-path delivery.In this scenario, assuming end user j accesses content from [f 1 , f 2 , . . ., f M ] video sources, the corresponding delivery rate of each source f k is x i,j f k .Hence, the total delivery rate of user j: Then, the QoE function of u can be written as: Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

VI. PROBLEM DECOMPOSITION
The distributed aspect of the network and the large numbers of end users make it difficult to maintain a central controller to configure the delivery rate for all end users.Consequently, a distributed method which enables nodes to select the delivery rate using the information about the delivery path rather than some global information based on the interaction with other users is more appropriate.In order to design such a distributed rate configuration method for HTTP live video streaming, in this section we decompose P2 into two sub-problems: a provider rate selection problem (PRSP) and an user rate adaptive problem (URAP), and consider both of them.

A. Provider Rate Selection Problem
By observing P2, we can easily find that providers can be separated according to eq. ( 6) yet coupled according to eq. ( 7).Hence, directly solving P2 requires a centralized method coordinating all providers.First we consider the following equivalence problem of P2, which converts the constraints (7) into a set of linear combinations as follows: P3: where |.| indicates the cardinality of set and 1 T l is a |l(s)| dimension 1-vector whose all elements are 1.We denote matrix X l = (x l ji ) N l ×|l(s)| and x l ji ∈ {x j,i |x j,i ∈ s j (u) l , j ∈ l(s)}.Accordingly, each row of the X l indicates a user rate combination of providers that use link l, and X l lists all N l possible combinations.The number of all possible combinations N l corresponding to link l is equal to: For instance, assume a network with 3 sources s 1 , s 2 and Then, we can introduce the following proposition: Proposition 1: Let x * be the optimal value of P2; then exists a group of Lagrange multipliers λ * = (λ 11 , . . ., λ L×N ) and it can be shown that (i) (ii) for all l ∈ L and j = {1, . . ., N l }, x l ki * otherwise, λ * ji = 0. Proof: Defining the Lagrangian L(x, λ) of P3: and corresponding Lagrange function of eq. ( 12): the dual problem of P3 is expressed as: D1: Because the primal problem P3 is concave and constraints (10) satisfy the Slater condition [32], the optimal value of primal problem P3 is equal to its dual D1.This means given the x * and λ * as the optimal solution of primal and dual problem, respectively, we have f (x * ) = D(λ * ).Besides, as the constraints ( 9), ( 10) are continuous and differential and according to the Karush-Kuhn-Tucker condition [33], for the optimal rate configuration x * , there exists an unique Lagrange multiplier λ * = (λ * 11 , λ * 12 . . ., λ * L×N ), such that: In addition, recalling that f (x * ) = D(λ * ), we have: according to the complementary slackness [32], we have: Intuitively, for each link l, we have hence, P1 is proved.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.Now we will discuss how to enable each provider to determine the sending rate individually.Recall that L(i) denotes the link set of provider i.We rewrite eq. ( 12) as follows: Note that the first term of ( 18) is separable in terms of provider.
We define the user with max j∈s i (u) x s,j as the main user and the other users are called sub user.Importantly, the sending rate M i of provider i is equal to the rate of the main user.Therefore, for each provider i, there definitely exists a main path from provider i to its main user with link set P M (i), where max x i,j , ∀l ∈ P M (i) We define the link belonging to P M (i) as the main link of i, and the other links in L(i) as sub links.Figure 2 illustrates a scenario of two providers delivering two videos to a set of users.{l 1 , l 2 , l 3 } and {l 4 , l 5 , l 6 , l 7 , l 8 } are the main path of provider s 1 and s 2 , respectively.The delivery rate over the main path of s 1 , s 2 are equal to the main users x 3 and x 4 .The lines with arrows colored in orange and cyan denote the flows to the sub users of s 1 and s 2 , respectively.The delivery rates for providers over their sub links are equal to the maximum rates of the users that use these links, which may be less than the rate of the main user.For example, l 6 is the main link of s 1 , and sub link of s 2 .Hence, the total rate of link l 6 is M 2 + max{x 1 , x 2 }.Based on the definition of main path and main user, eq. ( 18) can be further rephrased as: where i denotes the main user of provider i. Note, for ∀i ∈ S, M * i ∈ max{x * i,j |j ∈ s i (u) l }.According to eq. ( 15) and eq.( 11) in Proposition 1, we have ∂L(x * ,λ * ) ∂M * i = 0, and therefore: For each source i, p i = l∈P M (i) λ * l and M i (p i ) denotes the delivery rate of provider as a function of p i , according to eq. ( 20), the provider rate M i (p i ) is given by: λ * l (l ∈ P M (i)) of the dual problem D(λ) can be derived by the gradient projection descend method [34] which iteratively approximates the optimal value λ * along the gradient direction ∇D(λ).Specifically, for each link l, a sequence of {λ(t)} n is generated according to: where the γ is the stepsize of each iteration.Since the ∇D(λ * ) = 0, the stop criterion λ * l = λ l (t) holds only when λ l (t) = λ l (t − 1).
As λ * l ≥ 0, λ * l corresponding to the terms S j=1 x l ji * r j − c l in eq. ( 12) is equal to zero, according to the Proposition 1.
Namely, we only need to calculate λ l corresponding to substituting eq. ( 23) into eq.( 22), the descend rule of gradient projection for λ l is as follows: Since c l and for ∀i ∈ l(s) x l i are local information for each link l, eq. ( 24) can be solved by each link locally and hence, a distributed algorithm can be applied.However, solving λ l may require the rate of sub users since max j∈s(u) l x i,j may not equal to M i .In the next section, we will discuss the rate selection problem of sub users.

B. User Rate Adaptation Problem
In order to determine the rate of each user x i,j , we decompose P2 in terms of users and the corresponding sub-problem can be formulated as follows: U1: x k,j + x i,j ≤ c l , l ∈ p j (26) x i,j ≤ max where p j indicates the link set used by user j.Constraint (26) indicates that for each link l used by j, the rate of j should Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
not exceed the minimum residual link capacity, and eq.( 27) says that the playback rate of j cannot exceed the delivery rate of provider i over l.To illustrate the equivalence between U1 and P2, we introduce the following theorem.Theorem 2: For each user j ∈ U , the corresponding optimal value x * j in P2 can be derived equally by solving the problem U1.Namely, ∀j, x * j of P2 and U1 are equal.Proof: By introducing the following parameters x i,j ≤ x l i , i ∈ S, j ∈ s i (u), l ∈ p i , (30) Denote the optimal solution of P2:opt as x * .To derive the optimal value x * of U1, we aggregate U1 of all users j and represent it as follows: Importantly, the theorem holds when x * = x * .Now we prove x * = x * .Given an utility function such as the one from eq. ( 1), eqs.( 28)-( 33) are differential and continuous, thus according to the Karush-Kuhn-Tucker condition, we have eqs.(53) and (54) shown at the bottom of p. 11. for P2:opt and U1:A, respectively.According to Proposition 1, i∈S j∈s(u) Recall that P3 is equivalent to P2:opt, so substituting eq. ( 34) into eq.( 53), we have: And because slackness complementary condition, there is: Using x * to replace x * in eq. ( 54), we have: For the case of k∈l(s)/j x l k * + x * i,j < c l , the corresponding λ * ijl = 0.This can be proved by contradiction.Assuming there exists a λ This means there exists a x * such that: This contradicts with x * being the maximum value.
For the case of k∈l(s)/j x l k * + x * i,j = c l , we have: l(s)/j x l k * = k∈l(s)/j x l k * and x * i,j = x * i,j .Hence, in the above two cases, we have: As a result, eq. ( 54) is also equal to zero when replacing x * with x * , and considering the minimum value of U1:A is unique due to the concaveness, therefore, we have x * = x * and the theorem is proved.
To derive the optimal x * i,j of U1, we consider the corresponding dual problems.
The Lagrangian of U1 is: The Lagrange dual function is: L u x i,j , λ p j , υ p j (38) Then, the dual problem is: U1:D: As U1:A is a concave optimization problem and satisfies the Slater condition [32], the strong duality holds.Namely, the optimal values of the primal and dual problems are equal.Thus, the primal optimal solution x * i,j can be recovered from the dual optimal point (λ * p j , υ * p j ): Let x i,j (p j ) be the unique maximizer of L u (x i,j , λ p j , υ p j ).If the inverse of J(.) exists, according to the Karush-Kuhn-Tucker condition of U1:A, x i,j (p j ) can be derived as follows: Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
Because D u (λ p j , υ p j ) is continuous and differential for (λ p j , υ p j ), for each λ l , υ l , the corresponding partial differential is: Therefore, based on eqs.( 41), ( 42), ( 43), the dual problem U1:D can be solved by the following dual descend method, which is iteratively updated as follows: Because the flows of l(s) and user j are delivered over link l, for each link l, x l i and x i,j can be obtained locally.

VII. DISTRIBUTED MULTI-SOURCE RATE CONTROL OPTIMISATION ALGORITHM (DMRCA)
Based on the already-presented decomposed sub-problems, in this section we introduce the distributed multi-source rate control optimisation algorithm (DMRCA) for HTTP live video streaming.We will also analyse the complexity, convergence and time adaptation of our proposed method.

A. Algorithm Design
The DMRCA design has two major parts: processing at the user and processing at the provider, which are described next.
Processing at the user: Recall that URAP can be solved by iteration of eqs.( 44), ( 45), (46).Specifically, eq. ( 44) is separable in terms of users while eqs.( 45), (46) can be processed locally at each link.Consequently, the process at the user side can be described as follows: in each iteration t, user solves the corresponding eq. ( 44) to derive x i,j (t) by collecting λ l (t − 1) and υ l (t − 1) from links over its delivery path p j , and communicates x i,j (t) to all the links over p j .Link l receives the x i,j (t) of all users that use l and selects max j∈s i (u) l x ij (t) as x l i (t) for each source s in l(s).Then, link l uses x l i and x i,j to compute λ l (t + 1) and υ l (t + 1) according to eqs.(45), (46).The derived λ l (t + 1), υ l (t + 1) will be delivered to user j for computing the new x i,j .The above-described process is repeated until the results reach the iteration criterion, x i,j (t + 1) = x i,j (t).The above process is fully distributed and does not require extra communication resources, since the information of x i,j (t),λ l (t),υ l (t) is small enough and can be smuggled into data packets.
Processing at the provider: Similarly, at the provider side, each provider first determines the main path according to l∈p λ l of each path in the broadcast tree s i (l).As indicated by (21), the path with the minimum value of l∈p j λ l will be set the mainpath.After determining M i , provider i will send out a video with rate arg min b i ∈B b i − M i .Each link calculates λ l according to eq. ( 24).As eq. ( 24) is equal to calculating eq. ( 45) with max j∈s i (u) l x i,j which is already computed as part of the processing at the user, (λ) can be derived directly by the following recursion process: let lp(l, j) denote the link set between l to user j.The link l selects min j∈s i (u) l k∈lp(l,j) λ k , aggregates it with its own λ l and sends this min j∈s i (u) l k∈lp(l,j) λ k + λ l to the upstream node.The upstreaming link repeats the above-described process until the provider is reached, when it stops.
The above processes at users and providers suggest treating users and node servers as processors in a distributed processing system, and the optimal rate of each user and provider can be derived only by communicating with links over the delivery path, without the need for coordination with other users or providers.This communication can be easily implemented by smuggling information into the data packets.Consequently, the proposed DMCRA is a fully distributed, lightweight and bitrate optimized solution.The DMRCA pseudo-code is given in Algorithm 1.

B. Complexity Analysis
According to Algorithm 1, the complexity of links is mainly determined by the loop of the descend method and the number of providers and users that use each link.Let the descend method iterate N times, and the number of users and providers go through link l be U l and S l , respectively.Thus, the complexity of the algorithm from a link perspective is: From an user and provider perspective, the corresponding complexity is mainly determined by the number of iterations of eqs.( 44), (21), which are both N according to the descend method at the link.Therefore, the algorithm complexity is: Based on this analysis, the complexity of the user and provider is dependent on the iteration, which is independent of the number of nodes.Thus, the algorithm has no scalability issue since the growing number of users will not significantly affect the efficiency of the algorithm.

C. Convergence Analysis
The proposed distributed DMRCA algorithm generates a sequence of {x(t)} approaching the optimal rate configuration x * .Naturally, there is the issue of whether the generated sequence converges to the optimal rate or not.Namely, for any ε > 0, there exists a T, such as we have: Next we discuss the condition of algorithm convergence.Let L max p j ∈P |p j |, where P is the set of all possible paths in the network and S = max l∈L |l(s)|.We have following theorem: Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.receives the sum of l∈p j (λ l (t) + υ l (t)) from the links over its path;

24
communicates the x i,j (t + 1) to links l ∈ p j ; 25 end 26 x * j = x i,j (t); 27 return x * j ; 28 provider i's algorithm: while M i (t)! = M i (t − 1) do 29 receives the sum of l∈P M (i) λ l (t + 1) from the broadcast tree; determines the new broadcasting rate Theorem 3: Suppose J(x) is twice differential and for all x ∈ [b min , b max ], the corresponding −J (x i,j ) ≥ 1 α j , where a > 0.Then, when step size 0 < γ < 1  A L S , where A = max j∈U α j and from any initial point x(0), the (x * , λ * , υ * ) generated by Algorithm 1 is dual optimal, namely, x * is the optimal rate configuration for P2.
To prove this theorem with J(x) formulated in eq. ( 1), we first introduce the following lemma.
= max Therefore, ∇D u is Lipschitz with: Thus, the sequence of {λ(t), υ(t)} generated by the gradient method is dual optimal.In addition, according to eq. ( 41), the primal optimal of x * i,j = J −1 ( l∈p j (λ * l + υ * l )).Because J(.) is continuous and can be decoupled in terms of x i,j , hence, x i,j (p j ) is continuous and therefore: , and the theorem is proved.Another important issue is the convergence rate of the algorithm.In our algorithm, the optimal value is iteratively derived by the descend method.Let p(t + 1) be the sequence generated by the gradient descend method with p(t + 1) = p(t) − γ ∇D u , and p * be the optimal value.We then have: from which we obtain by applying the 2-norm . 2 : Thus, the convergence rate is bounded by:

D. Time Varying Adaptation
Although in problem formulation, the objective function, video providers and routing are given and unchanged during the process, we can still directly extend our algorithm to an environment with time variable features such as dynamic caching and routing, and a time-dependent objective function.Importantly, the algorithm can still converge to the optimal solution when the network conditions change.
To cope with the time varying scenarios, the objective function P2 can be re-formulated as f (x, t) = i∈S(t) j∈s i (u,t) J(x i,j ), where s(t) and s i (u, t) are the set of providers and user set of provider i at time t, respectively.l(s) in constraint (7) is replaced by l(s, t), which is the time variant provider set that use link l.Based on the above changes, each end users still executes the same user algorithm as in Algorithm 1, except for computing p(j, t) in the place of (j) in eq. ( 44).Each link executes the same link algorithm as in Algorithm 1 with the minor change of replacing l(s) in eq. ( 45) with l(s, t).Intuitively, if the change in link routing and providers is relative slower than the convergence rate of the algorithm we discussed, the algorithm still can converge to the optimal rates x * .We will illustrate this aspect in the experimental tests in Section VIII.

VIII. PERFORMANCE EVALUATION
The performance of HTTP live video streaming with DMRCA is evaluated using ndnSIM 2.0 [35], a simulation tool based on Network Simulator 3 (NS-3).First, we present the simulation set-up in terms of network, video and user behaviors.Then, we describe the two scenarios considered.In the first scenario, we evaluate the bandwidth utilization and algorithm convergence at each link in a treebased topology.The second scenario considers the American backbone topology, in which there are multiple sources and variable users.Users can obtain requested videos from multiple video providers, so the transmission path is also different.We compare our algorithm to the state-of-art solution HAVS-CCN and a traditional buffer-based adaptation method.HAVS-CCN optimizes the hop-by-hop content transmission in HTTP streaming.It directly adjusts video quality when DASH inaccurately estimating network throughput.We use the buffer-based approach provided by DASH as the traditional adaptation method.This algorithm raise the bit-rate when the buffer size reaches certain level.Our experiment measures the bandwidth utilization on different links in video transmission networks and the convergence value of the video bit rate during the video request process, which can be used to represent the user QoE.

A. Simulation Setup
In the simulation network, forwarding and content caching are the two main components, different forwarding and caching strategy may influence the performance significantly.Hence, we unify the forwarding and caching strategy that used in simulation.We select BestRoute as our forwarding strategy.In this strategy, each router maintains a routing table Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
We set a group of users varies from 1 to 5 to start ask the same request at the same time.The arrival rate of users group follows the Poisson distribution with λ = 0.1.Each user group randomly select a video to request by a Zipf distribution.Specifically, the probability of requesting m-th popular video: where α is the Zipf parameter with a value of 0.8, M denotes the total number of videos, which is 5 in our simulation.After determining the video to ask, end users will request the chunks of video in sequence and re-select a new video to request after requesting all chunks of the current video.

B. Experimental Results
Scenario 1 (Link Utilization Analysis): We focus on a treebased network whose topology and link bandwidth are shown in Figure 3.In this topology, user groups {U1, U2, U3, U4} only connect to the edge routers and each user group consists of 5 users.We consider two cases of user video requesting behaviors: Case I, all users start to request the video streaming at simulation starting time t = 0 and request the same video; Case II, each user group concurrently requests different videos at simulation start time t = 0.
Figure 4 shows the average link utilization in the two cases in comparison with the theoretical optimal value and actual link capacity.The theoretical value is computed by implementing our algorithm in MATLAB.As Figure 5 shows,  for Case I, links l 1 , l 2 , l 3 , and l 5 are the bottleneck links and thereby achieve full utilization.Because l 4 and l 5 are not bottleneck links, their bandwidth utilization are limited by the upstream links l 1 and l 2 , respectively.For Case II, link l 1 , l 2 and l 5 are still bottleneck links.However, due to the different videos each user group requested, the utilizations of l 3 , l 4 and l 6 reduce to 7.5 Mbps, 7.5 Mbps and 15 Mbps, respectively.Figure 5 shows the comparison between theoretical and actual convergence rate at each link in both cases.As expected, in both cases, the proposed DMRCA algorithm also converges to the optimal values.However, it can be observed that DMRCA converges slower than theoretically.This is mainly because the iteration results exchange between users and links in realistic conditions experience a transmission delay.In addition, the iteration results are smuggled in Interest and data packets in our deployed algorithm, introducing an extra delay before sending.These delays slow down the convergence rate of the algorithm.In theoretical optimal computing, these delays are neglected and the convergence rate is only influenced by the iteration times and processing speed.
Scenario 2 (Performance Comparison): We consider the American backbone network topology as illustrated in Figure 6 for the performance comparison.In this network topology, each edge router builds links with 4 end users, and provides 1, 3, 5 and 10Mbps access bandwidth to each user, respectively.There are multiple video providers in this topology, which are illustrated as source 1 to source 3 in the figure.In this situation, a group of users are randomly selected to request the same video synchronously, while the request distribution of the user group follows the Zipf law as  in eq. ( 54) and the grouped requests arrive asynchronously according to a Poisson distribution.
We use various metrics to measure the performance of the algorithm, which are link utilization, bitrate and stalling.Link utilization reflects the actual utilization rate of network bandwidth under the regulation of algorithm, which determines the video transmission rate in the system, and further affects the following two metrics.Bitrate and stalling are the core factors affecting user experience.Bitrate determines the quality level of the video.Users can enjoy higher definition and smoother video content in the case of high bitrate.In the process of playing, if stalling occurs, it will have a direct negative impact on user experience.Therefore, the less stalling in the process of playing means the better user experience.
1) Link utilization convergence analysis: Figure 7 shows the link convergence of (R8,R9), (R5,R4), (R1,R2) and (R1,R0) in the American backbone topology.Note that in the topology figure, the links we select are bottleneck links and the total delivery rate of these links should equal to their link capacity.We note that the simulation behaved as expected, the delivery rate of each link converges to the theoretical optimal value, which is equal to the link capacity.In addition, from the convergence results, we also find that even when the network conditions vary (i.e., new users join in the network or caching on-path), the links still converge to the optimum value.
2) User rate convergence analysis: Figure 8 shows the rate convergence of users at router R7 in the American backbone topology.As the figure shows, the rate converges well to the theoretical results.Specifically, the variation of user rates can be explained as follows: user U1 first requests the video from R6.Because there are no other video flows, it can exclusively use the link (R6, R7) achieving a maximum delivery rate of 10Mbps.When U2 joins the video distribution system, it accesses the video from (R7, R8) and since there is a near copy of the asked content at R8, it does not influence the rate of U1.At 66s, when other flows from U3 pass over the link (R6, R7), the link bandwidth of (R6, R7) is used by two flows simultaneously and the rate of U1 decreases to 5Mps.
3) Average bit rate (ABR) comparison: we define the ABR as the arithmetic mean of average bit-rate of overall users, we calculate the ABR at time T by: where U is the total number of users and BR u (u) indicates the bit-rate of user u at time t. Figure 9(a) depicts the ABR in the American backbone topology.As the figure shows, the ABRs of the three solutions compared experience an increasing trend at the beginning.After 200s, all solutions decrease their rates and then enter a periodical vibration phase.This phenomenon can be explained as follows.Initially, the network load is low, allowing the link to accommodate all high bitrate video requests.However, as the number of end users increases, the link's capacity restricts the growth of the average user throughput, leading to a decrease in ABR.In the latter half of the simulation, frequent user joining and leaving activities causes ABR to dynamically fluctuate with the number of active users.
The results of Figure 9(a) suggest an increase of 30% and 41% of ABR in favor of DMRCA when compared with the other two solutions.In DMRCA, the overall bitrate is distributively optimized and converges to the theoretical optimal, hence, providing the best performance among the three solutions.HAVS-CCN adjusts the data rate at each hop locally, and fails to optimize the overall user bitrate.Each client in DASH-CCN greedily requests higher bitrate videos in order to maximize their own bitrate, which aggravates the network congestion when the network is already in a high load condition.Therefore, DASH-CCN has the worst performance in terms of ABR.

4) Playback freeze frequency (PFF) comparison:
We define PFF as the average occurrence of freeze per second during the simulation.The lower PFF is, the smoother playback experienced by the client is. Figure 9(b) shows PFF in tests with the American backbone topology.The results show that when DMRCA is employed, PFF decreases with about 20% and 25% in comparison with the values experience by the other two solutions.As mentioned, DMRCA uses a distributed optimization method in order to fully use the link bandwidth while also avoiding the network congestion by limiting the total delivery rate to the link capacity and hence achieves a smoother playback.HAVS-CCN also limits the data rate to the link capacity at each hop, hence avoiding the network congestion.DASH-CCN using a greedy method to request video content with a high risk of playback freeze when the available bandwidth is not enough to support smooth playback of high bitrate videos.

C. Discussion
DMRCA is a distributed rate control algorithm, so it needs to be deployed at every node in the network.In general this is associated with a large system deployment cost.Therefore, for simple network architectures with fewer distributed nodes, the optimization introduced by a possible deployment of DMRCA is limited, considering the deployment cost.However, for large deployments, the benefit of employing DMRCA is significant.Therefore, an interesting research avenue is to explore for what range of network topologies DMRCA is most suitable, and consider the deployment decision from both deployment cost and bandwidth utilization optimization points of view.
In addition, DMRCA is designed to select bitrate solely based on information received from the connected link.Therefore, it is obviously optimized for certain use cases, but it is not necessary for all use cases.If there is a central server in the network structure that provides information about network links such as congestion status and available bandwidth to all network nodes in a low-cost manner, the DMRCA calculation process can actually be replaced by this mechanism, because the core focus of DMRCA is to infer the optimal bit rate selection from link usage.In a centralized structure, the rate selection of each node can be uniformly performed by the central node.

IX. CONCLUSION AND FUTURE WORK
This study introduced an innovative distributed multi-source optimal bitrate control algorithm (DMRCA) for adaptive video streaming.It includes a formulation of the rate control problem as a concave MAP, which was decomposed into two sub-problems, PRSP and URAP.Following a demonstration of the equivalence between the original problem and the two sub-problems, DMRCA was proposed as a distributed optimal solution that enables users and providers to communicate through links and achieve optimal rate control.The paper discussed the complexity, convergence, and time-varying adaptability of the proposed algorithm.Simulation results demonstrated the superiority of DMRCA over other state-ofart solutions.Future work will involve designing an online asynchronous algorithm to facilitate deployment in highlydynamic mobile environments.

Fig. 2 .
Fig. 2.An illustration of network with two provider s 1 and s 2 provider videos to users.

Fig. 7 .
Fig. 7. Convergence analysis of links in American backbone topology.