Decentralized resource management for a distributed continuous media server

Abstract

Distributed continuous media server (DCMS) architectures are proposed to minimize the communication-storage cost for those continuous media applications that serve a large number of geographically distributed clients. Typically, a DCMS is designed as a pure hierarchy (tree) of centralized continuous media servers. In an earlier work, we proposed a redundant hierarchical topology for DCMS networks, termed RedHi, which can potentially result in higher utilization and better reliability over pure hierarchy. In this paper, we focus on the design of a resource management system for RedHi that can exploit the resources of its DCMS network to achieve these performance objectives. Our proposed resource management system is based on a fully decentralized approach to achieve optimal scalability and robustness. In general, the major drawback of a fully decentralized design is the increase in latency time and communication overhead to locate the requested object. However, as compared to the typically long duration and high resource/ bandwidth requirements of continuous media objects, the extra latency and overhead of a decentralized resource management approach become negligible. Moreover, our resource management system collapses three management tasks, 1) object location, 2) path selection, and 3) resource reservation, into one fully decentralized object delivery mechanism, reducing the latency even further. In sum, decentralization of the resource management satisfies our scalability and robustness objectives, whereas collapsing the management tasks helps alleviate the latency and overhead constraints. To achieve a high resource utilization, the object delivery scheme uses our proposed cost function, as well as various object location and resource reservation policies to select and allocate the best streaming path to serve each request. The object delivery scheme is designed as an application layer resource management middleware for the DCMS architecture to be independent of the underlying telecommunication infrastructure. Our experiments show that our resource management system is successful in realization of the higher resource utilization for the DCMS networks with the RedHi topology.Index Terms-Distributed continuous media servers, decentralized resource management, distributed multimedia systems, content delivery networks, distributed information systems, video-on-demand. ae 710

Efficient algorithms of video replication and placement on a cluster of streaming servers

“…Recent work on streaming applications focused on scalability and reliability issues on distributed servers (Anastasiadis et al, 2002;Chou et al, 2000;Gafsi and Biersack, 2000;Golubchik et al, 2001;Lee and Wong, 2000;Shahabi and Banaei-Kashani, 2002;Wu et al, 2001;Zhang et al, 2000). Video streams require huge amount of bandwidth in disk I/O and network-I/O interfaces.…”

“…The relative popularity of a video is supposed to be known before the replication and placement, which could be obtained from the rental history of video stores. Like work in Aggarwal et al (2001), Shahabi and Banaei-Kashani (2002), Venkatasubramanian and Ramanathan (1997) and Wolf et al (1997), we consider the relative popularity of videos follows Zipf-like distribution with a skew parameter of y, 0:271pyp1. The probability of choosing the ith video is p i ¼ i Ày = P m j¼1 j Ày .…”

Proxy-assisted periodic broadcast for video streaming with multiple servers

“…However, certain characteristics of the multimedia objects such as high I/O bandwidth requirements and duration of the transmission, pose additional challenges. Our approach to video delivery in a distributed multi-server system is based on the framework combining proxy caching with periodic broadcast, and as such differs from other distributed multimedia systems [5][6][7].…”

Exploiting Traffic Balancing and Multicast Efficiency in Distributed Video-on-Demand Architectures

“…To obtain the maximum system streaming capacity, we saturated the system using a high request ratio (10 req/min by network) and simulated the system behavior until the aggregate bandwidth is exhausted. When there is no bandwidth available, the system achieves its maximum streaming capacity and we evaluate the system performance (effective bandwidth using unicast and patching [12]) .…”