Server selection in large-scale video-on-demand systems
Niklas Carlsson, Derek L. Eager
2010
ACM Transactions on Multimedia Computing, Communications, and Applications (TOMCCAP)
Video on demand, particularly with user-generated content, is emerging as one of the most bandwidth-intensive applications on the Internet. Owing to content control and other issues, some video-on-demand systems attempt to prevent downloading and peer-to-peer content delivery. Instead, such systems rely on server replication, such as via third-party content distribution networks, to support video streaming (or pseudostreaming) to their clients. A major issue with such systems is the cost of the
more »
... required server resources. By synchronizing the video streams for clients that make closely spaced requests for the same video from the same server, server costs (such as for retrieval of the video data from disk) can be amortized over multiple requests. A fundamental trade-off then arises, however, with respect to server selection. Network delivery cost is minimized by selecting the nearest server, while server cost is minimized by directing closely spaced requests for the same video to a common server. This article compares classes of server selection policies within the context of a simple system model. We conclude that: (i) server selection using dynamic system state information (rather than only proximities and average loads) can yield large improvements in performance, (ii) deferring server selection for a request as late as possible (i.e., until just before streaming is to begin) can yield additional large improvements, and (iii) within the class of policies using dynamic state information and deferred selection, policies using only "local" (rather than global) request information are able to achieve most of the potential performance gains. • 1:3 be the most suitable, recognizing that in practice the implemented policies are likely to have many details tailored to the specific system under consideration. We compare different classes of policies in the context of a simple, very abstract system model that allows us to accurately delimit the performance that may be achievable with policies from each class. The policy classes considered range from those with simple policies, using very limited state information, to classes with more complex policies, requiring much more state information. While it is obvious that policies with more state information should be able to outperform policies with less state information (at least when neglecting the overhead of collecting such information), the magnitudes of the performance differences are not obvious a priori. It is important to determine these magnitudes so that, in general, design and implementation efforts can be focused on the simplest policy classes that are able to yield most of the potential performance improvements. The first and most basic distinction that we consider is between server selection policies that use dynamic state information (for example, numbers of pending requests), and (simpler) policies that use only static (or semistatic) client-server proximity and average request rate information. Our results indicate that use of dynamic state information has the potential to yield large reductions in client startup delay, for fixed total delivery cost, in many cases by a factor of two or more. Among policies using dynamic state information, a second distinction can be made between policies that defer server selection decisions until just before streaming is to begin, and those (simpler) policies that make a server selection decision immediately upon request arrival. We find that deferred selection can potentially yield substantial performance improvements, again by a factor of two or more in some cases, although only for fairly narrow ranges of model parameter values. Finally, among policies using dynamic state information and deferred selection, a third distinction is between "local state" policies that base their server selection and scheduling decisions on the currently outstanding "local" client requests, and "global state" policies that use information concerning all current requests. We find that relatively simple local state policies appear able to achieve most of the potential performance gains. The remainder of the article is organized as follows. Our system model is described in Section 2. Section 3 addresses the question of whether use of dynamic state information can yield major performance improvements. Section 4 considers the extent to which performance can potentially be improved in dynamic policies by deferring server selection decisions, rather than making such decisions immediately upon request arrival. Section 5 focuses on the class of policies using dynamic state information and deferred selection, and considers the extent to which polices using only "local" state information can realize the full potential of this policy class. Supporting evidence for our conclusions, obtained using more detailed network topology models, is presented in Section 6. Conclusions are presented in Section 7. SYSTEM MODEL We consider a video-on-demand system with N servers. Clients are divided according to network location into M groups, such that all of the clients in a group can be considered to have approximately the same network proximity to each server. For simplicity, in the following we assume that M = N. Given this assumption, the client groups and servers are indexed such that for the clients of group i, the nearest server is server i. Server i is called the "local" server for client group i, while all other servers are called "remote" servers for this group. Each of the N servers is assumed to use a batching technique wherein the video streams for clients that make closely spaced requests for the same video are synchronized, so that the server is delivering data from the same position in the video file at each point in time to each of the clients in the batch. This synchronization is achieved by delaying service to some clients. A client cannot join a batch for which streaming of the video to the respective clients has already begun.
doi:10.1145/1671954.1671955
fatcat:i2mevpvyvncidjnbmrmlcd3pva