Multi-Criteria Server Selection for Over-the-Top Video Streaming

Multi-Criteria Server Selection for Over-the-Top Video Streaming Octavian Catrina University Politehnica of Bucharest, Bucharest, Romania E-mail : octavian.catrina@elcom.pub.ro Abstract—A video streaming system with over-the-top delivery has to select the servers that handle the service requests such that the content is delivered with the desired quality and system resources are efficiently used. Server selection can be formulated as a multi-criteria optimization problem, but solving this problem requires dynamic information about system resources. In this paper, we study the performance achieved by service providers that deploy a resource monitoring infrastructure and optimize server selection using a Multi-Criteria Decision Algorithm (MCDA), and the performance achieved by lightweight service providers, using only static information and simpler selection methods. We implemented these methods in a simulator and compared their performance. The results show that MCDA offers important performance gains, justifying the costs of resource monitoring. Moreover, they motivate the search for server selection methods that could achieve similar performance with lower costs, by involving the clients in the selection process, using MCDA. Key words - content network; video streaming; server selection; multi-criteria decision algorithm. I. I NTRODUCTION The fast growth of the video streaming services and the evolution of their ecosystem require continuous innovation (new architectures, protocols, and algorithms), to improve their performance and efficiency, as well as the service quality. An important task of a video streaming system is to select the servers that deliver the content in a way that uses efficiently the network and server resources and provides the desired Quality of Experience (QoE) to service users. This task can be formalized as a multi-criteria optimization problem that takes into account various static and dynamic attributes of the system’s components (network, servers, clients). These problems are NP-complete, in general, but can be solved efficiently using heuristic methods, such as MultiCriteria Decision Algorithms (MCDA) [1]. These algorithms need information about current network and server resources, requiring an expensive resource monitoring infrastructure. We studied, by simulation, the performance achieved by service providers that have resource monitoring capabilities and can optimize server selection using MCDA, and compared it with the performance achieved by lightweight service providers, that have only static information about the system and hence can only use simpler selection methods. The motivation for this work was twofold: evaluate the performance gain offered by MCDA; then, on this basis, study alternative approaches that can achieve similar performance with lower costs, by splitting the selection process between Figure 1. Video streaming system: main components and interactions. service providers and clients, and enabling the clients to refine the selection using MCDA. The paper has the following structure. Section II introduces a generic video streaming model and Section III describes the server and path selection methods. We implemented these methods in a simulator, presented in Section IV. The results of the simulations are discussed in Section V, followed by a summary in Section VI. II. V IDEO S TREAMING S YSTEM We start with an overview of the simplified model of video streaming system used in this paper. Fig. 1 shows the main components of the system and the interactions between them. The clients request video content from a service provider (SP). The SP is responsible for managing the video streaming service. The video content is delivered to the clients by a collection of content servers (CS). One of the main functions of the SP is to select the content server when a client initiates a video streaming session. A session starts with the following interactions (Fig. 1): – The client sends an SP Request to the service provider, specifying the desired video content. – The SP runs a server selection algorithm and returns in SP Reply a ranked list of servers that could deliver the video content, or rejects the request, if it cannot be fulfilled. – The client asks one of the servers recommended by the SP to deliver the desired video content. The client may choose the first server in the list, or run its own selection algorithm, with additional information (obtained, e.g., from server state reports and/or connection probing). III. S ERVER AND PATH S ELECTION We evaluate and compare several server selection algorithms, corresponding to different capabilities of the service providers to obtain information about the current state of the system. These algorithms offer different tradeoffs between the complexity of the system and the optimality of the solution (e.g., different requirements for the information collected by the provider about the network and the servers). A. Multi-Criteria Decision Algorithms Figure 2. Network infrastructure. For example, if the service is implemented using Dynamic Adaptive Streaming over HTTP (MPEG-DASH) [2], the provider replies with a Media Presentation Description (MPD) file that contains information about the encoding of the video content (including available resolutions and data rates), as well as the URLs of the servers that can deliver it. Fig. 2 provides more details about the infrastructure used to deliver the video content. We assume over-the-top delivery, using video streaming over HTTP or a similar technology [2]. Therefore, we do not require special support from the underlying transport network (e.g., bandwidth reservation). The content servers are usually operated within a Content Delivery Network (CDN) [3]. We assume that the video content is stored on a collection of servers deployed in the Internet, each video file being available from several servers. We expect efficient operation of the CDN, with server placement and content replication adapted to the video streaming traffic. The video streaming service provider can use its own CDN or/and rely on services offered by one or more specialized CDN providers [4][5]. Moreover, it may own a transport network or obtain special support from network service providers. We assume that the main bottlenecks of the transport network are the links between the autonomous systems (AS) of the network service providers. Therefore, the network is modeled as a collection of interconnected nodes, corresponding to an AS-level, multi-tier network topology, similar to the topology of the Internet (as shown in Fig. 2). The clients and the content servers are attached to the nodes of this network. The Border Gateway Protocol (BGP), which is responsible for inter-AS routing in the Internet, determines a single best path between ASes, based on network service provider policies and path length [6]. Load balancing on multiple paths could be achieved using application-level overlays or routing protocol extensions and would help to allocate more efficiently the network resources to video streaming sessions [7]. We consider, therefore, this additional capability for some server selection algorithms. The selection of a server and a path in content delivery systems can be formulated as a multi-criteria optimization problem. Since these problems are NP-complete (in general), they are solved in practice using heuristics methods, such as Multi-Criteria Decision Algorithms (MCDA) [1]. The variant of MCDA used in this paper can be summarized as follows: – The decision maker (service provider) determines a set of candidate solutions (the decision space), S = {Si }i∈1,...,n , based on information about the service request and the content delivery system. A candidate solution is a vector of decision variables, Si = (vi,j )j∈1,...,m , representing characteristics of a server and a path that could deliver the requested content. For multiple paths between a server and a client, each pair consisting of a server and a path is considered a different solution. – For each candidate solution Si , the decision maker calculates the rank of each decision variable vi,j , Ri,j = (ri,j − vi,j )/(ri,j − ai,j ), where vi,j is the current value of the variable, while ri,j and ai,j are the reservation level and aspiration level for this variable, respectively. – For each solution Si , the decision maker calculates the rank of the solution, Ri = minj {Ri,j } and then determines the index of the best solution, argmini {Ri }. We use two decision variables: the available (unused) capacity of the server and the available capacity (unused bandwidth) of the path. For these variables, the reservation level is a lower bound for suitable solutions, and the aspiration level is an upper bound beyond which the preference of the solutions is similar. We set as aspiration level the maximum capacity of the server and of the path (allowed for this service) and as reservation level the amount of server capacity and path capacity consumed by a single session, respectively. B. Selection Process Using the algorithm described above, the provider answers a client’s request by indicating a single server [1]. We consider a more general approach, in which the provider answers with an ordered list of servers. The client can start the session by connecting to the first server in the list and use the others as back-up [5]. Moreover, by delivering a list of servers, the provider enables the client to refine the initial selection (e.g., by running its own selection algorithm, using additional information) and/or use certain adaptive streaming techniques (e.g., switch servers during the session). The selection process proceeds as follows: – The service provider maintains a resource database with the information about network and content servers that is Table I I NFORMATION USED FOR CONTENT SERVER SELECTION . Static or quasi-static information Lists of servers and video files. Mapping of video files to servers. Mapping of clients and servers to network nodes. Length of the paths between servers and clients (hops or delay). Dynamic information Admission control for servers. Available capacity of the servers. Admission control for paths between servers and clients. Available capacity of the network paths between servers and clients. Table II S ERVER SELECTION ALGORITHMS . Algorithm Random servers Closest servers Best servers MCDA Input Set of feasible solutions. Set of feasible solutions. Length of the paths from servers to client. Set of feasible solutions. Available capacity of the servers. Set of feasible solutions. Available capacity of the servers and the paths. Output (list of servers) Random server and shortest or random server-client path. Servers with the shortest paths to the client. Servers with the largest available capacity and shortest or random path. Servers in the solutions with the highest MCDA rank. necessary for server selection. The database contains the static information and some of the dynamic information listed in Table I, depending on the algorithm being used. – When a service request arrives, the provider determines an ordered list of suitable servers and delivers it to the client. The selection is based on information received in the service request (e.g., client and video ids) and information available in the resource database. Candidate solutions consist of a server that has a copy of the requested video file and a path from that server to the client. The selection algorithm takes as input a set of candidate solutions that (optionally) satisfy additional requirements. The algorithms used in our simulation experiments are listed in Table II. If the provider does not find any suitable server (e.g., the video is not available or the system is overloaded), the request is rejected (i.e., the list of servers is empty). – If the request is accepted, the client starts the video session by connecting to the first server in the list. In case of failure, the client can try the next servers, without having to ask the provider to recommend another server. C. Admission Control The server selection process has to take into account two main objectives: allocate efficiently the system’s resources and satisfy the performance requirements of video streaming. Continuous video playout requires timely data delivery, and hence a certain lower bound for the end-to-end data rate. It is important, therefore, to avoid overloading the system’s resources, by adding some form of admission control to the server selection process. This can be achieved by removing the solutions with fully loaded servers or paths from the set of candidate solutions given as input to the selection algorithms. Admission control is simpler for content servers. The available capacity can be estimated by a local monitoring applica- Figure 3. High-level architecture of the simulation software. tion and reported by the servers to the provider or the clients. A fully loaded server can reject additional client requests. This offers a basic admission control method, independent of the server selection process. On the other hand, it is more difficult to determine if the path from a server to a client can handle additional sessions. The service providers need for this purpose a network monitoring infrastructure that measures the throughput between certain network nodes. The server selection process can be extended with optional admission control as follows: – Find the candidate solutions, consisting of a server that has a copy of the requested video file and a path from that server to the client. – Find the feasible solutions, by removing the candidate solutions whose servers or paths are fully loaded. – Find the list of recommended solutions by running the selection algorithm with input the set of feasible solutions. Deliver the list of servers to the client, or reject the request, if the list empty. IV. S IMULATION S OFTWARE We evaluated and compared the server and path selection methods described in Section III by simulation. The simulation software developed for this purpose is written in C++ and uses the discrete event simulator OMNeT++ as basic simulation engine [8][9]. A. Architecture Figure 3 shows the main components of the simulator and the interactions between them. The class ResourceManager provides a resource database with information about the entire system infrastructure: network topology (including network nodes and links, link capacity and load), network paths, list of content servers (including server capacity and load), mapping of video content to servers, mapping of clients and servers to network nodes (Table I). The class RequestProcess generates the service requests, manages the video streaming sessions, and collects relevant statistics. When a session starts or ends, the RequestProcess notifies the ResourceManager, which updates accordingly the load of the server and the load of the links on the path from the server to the client. The server selection process is implemented by the classes ServiceProvider and ServiceClients, and obtains information about system resources from the ResourceManager. The class ServiceProvider handles the clients’ service requests and implements the server selection algorithms run by the service provider. The class ServiceClients implements the algorithms run by the clients to select from the provider’s list the server that will be used for the video streaming session. Finally, the OMNeT++ module is responsible for integrating the entire system in the OMNeT++ simulator, running the simulation experiments, and saving the results. B. Network Model The network model uses random topologies generated using the tool aSHIIP [10]. The network nodes are the autonomous systems (AS) of the network service providers (Figure 2). This high-level topology improves the scalability of the video streaming system model, and is sufficient for our purposes, assuming that the main bottlenecks are the inter-AS links. The network topologies have a multi-tier structure similar to the Internet. We assume that this structure corresponds to the usual business relations between network service providers: peering relations between nodes in the same tier, and customerprovider relations between nodes in different tiers, with the customer in the lower tier. The simulation software provides tools that compute multiple best paths for any pair of nodes, in the order of the path metric, starting with the shortest path. The paths used in the simulations are similar to the paths determined by BGP according to the relations between network providers (“valley-free”) [6]. The clients and the content servers of the video streaming system are attached to network nodes. Servers are deployed all over the network, in “well-connected” network nodes, “close to clients”, taking into account the number of links and their bandwidth. C. System Resources The resources consumed by the video streaming sessions are measured using a metric for server capacity and a metric for link capacity. In general, the sessions may consume different amounts of resources, depending on the video encoding. To simplify the analysis, we assume that a session needs 1 unit of server capacity and 1 unit of link capacity, to deliver the video content with the desired QoE. The video streaming system is provisioned by assigning a fixed maximum capacity to content servers and network links. Server and network resources are generally shared with other applications or services. We assume that the assigned capacity corresponds to the resources that the video streaming service can use (for the duration of a simulation experiment). Servers have the same capacity and are deployed in clusters; better connected nodes have larger clusters. The network is provisioned by assigning capacity to the links according to the hierarchical structure of the network, with higher capacity in upper tiers. Node (autonomous system) capacity is not limited, since the bottlenecks are the links between them. We assume that the video files are replicated according to their popularity, such that to maximize the number of requests that the servers can handle, i.e., at full load the fraction of the total server capacity used by a video is roughly equal to the probability of being requested. D. Performance Metrics The main performance metric used in the analysis of the server selection process is the success rate: the ratio between the number of successful requests and the total number of requests. A request is successful if the system has sufficient server and network resources to deliver the video content to the client, with the desired quality, for its entire duration. Failures can occur in the server selection phase or during the video streaming session. If admission control is available, a request is rejected when the selection process does not find a server and a path with sufficient unused capacity; the load of the system remains unchanged. Otherwise, a new session is created, which may overload the server and/or some links on the path from server to client. The RequestProcess monitors the current sessions and updates their state. If a session has been successful so far and does not have sufficient resources any more, its state changes from success to fail. V. P ERFORMANCE E VALUATION We analyzed by simulation the performance of the algorithms listed in Table II, with different settings for the selection algorithm, admission control and session management, network topology and size, server placement, etc. We summarize in this section the main results. The experiments use a network with 1000 nodes, structured into 4 tiers. The selection algorithms can choose among 3 precomputed shortest paths for any pair of nodes (additional paths do not significantly improve the performance). The total capacity of the servers is about 61500 sessions. Service requests are generated at random time intervals with exponential distribution. The mean duration of a session is 400 seconds. The network is provisioned such that the number of concurrent sessions can reach the total capacity of the servers, for an efficient server selection. We measure the session success rate as a function of the request rate. Table III lists the server selection configurations used in these experiments. These configurations correspond to a range of service provider capabilities and natural combinations of algorithms and admission control settings. Table III C ONFIGURATIONS USED FOR SERVER SELECTION . Name RandRand RandShrt NearSrv BestRand BestShrt MCDA Server and path selection algorithm Random servers, random paths Random servers, shortest paths Servers with shortest paths to client Servers with largest available capacity, random paths Servers with largest available capacity, shortest paths MCDA for available capacity of servers and paths Admission control Server reject Server reject Server reject AC for servers AC for servers AC for servers and paths Table IV E FFECT OF RANDOM PATH CHOICE IN EXPERIMENT WITH 5 PATHS . Path 45->18 45->18 45->18 45->18 45->18 Av.Cap. 41 -342 -250 -180 -250 Metric 100 150 175 175 175 Hops 2 4 5 5 5 Nodes 45:5:18 45:2:1:5:18 45:2:0:1:5:18 45:2:0:6:5:18 45:2:3:1:5:18 Tiers 2:1:2 2:1:1:2 2:1:1:1:2 2:1:1:1:1:2 2:1:1:1:1:2 Fig. 4 and Fig. 5 show the success rate for the initial server placement and two variants of session management. Service providers with server and network monitoring capability can use MCDA with admission control for servers and paths. This configuration offers the most efficient utilization of the system resources. The success rate remains equal to 1 for request rates up to 150 requests/second and about 60000 concurrent sessions, close to the total server capacity. Beyond this threshold, the success rate starts to drop because the system is fully loaded and some of the requests are rejected. Service providers that have only static information about the system (Table I) can select random servers or closest servers, without admission control (e.g., the configurations RandRand, RandShrt, NearSrv). The success rate drops rapidly, starting at lower request rates, because sessions fail due to congested network links or are rejected by fully loaded servers. Selecting the least loaded server (BestRand, BestShrt) does not improve the performance in these experiments, because the video files are replicated according to their popularity, and hence random server selection does a good job at distributing the load among the servers. Congested sessions may be aborted by clients or servers. The freed resources can then be used to start other sessions, which may be successful, e.g., because their paths do not include congested links. Fig. 4 and Fig. 5 show the success rate in two extreme cases: in Fig. 4 the congested sessions are aborted, while in Fig. 5 they are allowed to continue (with inferior QoE, e.g., lower resolution and data rate, if rate adaptation is available). Aborting congested sessions improves substantially the performance for randomly chosen servers and/or paths (RandRand, RandShrt, BestRand), while NearSrv is less affected, because the sessions always use the nearest server and the shortest path. Intuitively, the performance should improve when the load is distributed on multiple network paths. We observe, however, that using the shortest path offers better performance than randomly choosing from a list of 3-5 best paths (e.g., RandShrt versus RandRand in Fig. 4). This is due to the hierarchical Figure 4. Initial server placement, with session abort. Figure 5. Initial server placement, without session abort. structure of the network and the construction of the paths. In a multi-tier network with valley-free paths, the shortest path can avoid the core of the network, while the other paths are more likely to cross it (e.g., the paths between SC2 and CG2 in Figure 1). Thus, the random choice of the path concentrates the traffic in the network core. Table IV shows an example for an experiment with 5 paths: the shortest path from node 45 to node 18 does not cross the core and its available capacity is 41, while the other paths cross the core (links in tier 1) and are heavily overloaded. Therefore, when multiple paths are available, the selection algorithm should take into account the path load (e.g., using MCDA). For similar reasons, the performance improves if the provider selects the servers with the shortest paths to the client (NearSrv), instead of choosing the servers randomly (e.g., RandRand, RandShrt): the sessions use less network resources and the paths are more likely to avoid the core. Figure 6. Server placement optimized for NearSrv, with session abort. Service providers that cannot collect dynamic information about the resources have to use simpler selection methods, based on static and quasi-static information, e.g., mapping of content to servers, mapping of servers and clients to network nodes, and path lengths. The simulations show that these providers obtain the best results by selecting the nearest server. The server selection problem can be efficiently solved using MCDA. However, MCDA requires an expensive monitoring infrastructure, in order to estimate the available capacity of the servers and of the paths between servers and clients. The simulations show that server selection based on MCDA can offer an important performance gain, justifying the deployment of the system monitoring infrastructure. Moreover, to take advantage of multiple paths between servers and clients in a multi-tier network like the Internet, the selection algorithm has to take into account the path load (e.g., using MCDA). A prototype of this video streaming system, using MPEGDASH and MCDA server selection, was implemented during the DISEDAN project and is being evaluated [11]. On the other hand, these results motivate the exploration of other server selection methods, aiming to achieve performance levels close to those offered by MCDA, but with lower costs. The alternative approach we are studying (detailed in another paper) is to split the server selection process between the service provider and the client: the provider recommends a short list of servers, based on static or quasi-static information, and the client makes the final choice, by running its own selection algorithm (including MCDA), using additional information, obtained by interacting directly with these servers. ACKNOWLEDGEMENTS This work was partially supported by the Research Project DISEDAN, No.3-CHIST-ERA C3N, 2014-2015. R EFERENCES Figure 7. Server placement optimized for NearSrv, without session abort. Thus, an important performance gain can be achieved using only quasi-static information. However, the performance of NearSrv is very sensitive to server placement. This can be observed by comparing the results for the initial server placement, shown in Fig. 4 (and Fig. 5), and an improved server placement, shown in Figure 6 (and Fig. 7). The improved server placement consisted of moving about 20% of the total server capacity to better locations, according to server utilization measurements made with the initial server placement. There is a slight performance degradation for the other algorithms, because the number of server clusters was reduced during redeployment, while maintaining the system’s total server capacity. VI. C ONCLUSIONS Video streaming systems have to select the content servers such that to use efficiently the network and server resources, and provide the desired QoE to service users. [1] A. Beben, J. M. Batalla, W. Chai, and J. Sliwinski. Multi-criteria decision algorithms for efficient content delivery in content networks. Annals of Telecommunications, vol. 68, no. 3, pp. 153-165, Springer, 2013. [2] I. Sodagar. The MPEG-DASH standard for multimedia streaming over the Internet. IEEE Multimedia, vol. 18, no. 4, pp. 62-67. IEEE, 2011. [3] M. Hofmann and L. Beaumont. Content Networking. Architecture, Protocols, and Practice. Morgan Kaufmann, 2005. [4] V. K. Adhikari, S. Jain, Y. Chen, and Z. Zhang. Vivisecting YouTube: An Active Measurement Study. Technical Report TR 11-012, Department of Computer Science and Engineering, University of Minnesota, 2011. [5] V. K. Adhikari, Y. Guo, F. Hao, M. Varvello, V. Hilt, M. Steiner, and Z.L. Zhang. Unreeling Netflix: Understanding and improving multi-CDN movie delivery. IEEE INFOCOM 2012, pp. 1620-1628. IEEE, 2012. [6] L. Gao. On inferring autonomous system relationships in the Internet. IEEE/ACM Trans. on Networking, vol. 9, no. 6, pp. 733-745, IEEE, 2001. [7] Jiayue He and J. Rexford. Toward Internet-wide multipath routing. IEEE Network, vol. 22, no. 2, pp. 16-21, IEEE, 2008. [8] K. Wehrle, J. Gross, and M. Gnes. Modeling and Tools for Network Simulation. Springer, 2010. [9] A. Varga. OMNeT++ Discrete Event Simulator. http://www.omnetpp.org. [10] J. Tommasik and M.-A. Weisse. The inter-domain hierarchy in measured and randomly generated AS-level topologies. In IEEE International Conference on Communications (ICC2012). IEEE, 2012. [11] S.G. Obreja, R. Iorga, E. Borcoci, C. Cernat, M. Vochin, J.M. Batalla, D. Negru and J. Bruneau-Queyreix. Over-the-top content streaming adaptive system - Implementation and validation. 9th Int. Conf. on Communication Theory, Reliability, and Quality of Service (CTRQ 2016), IARIA, 2016.