Decentralized resource management for a distributed continuous media server

Cyrus Shahabi and Farnoush Banaei-Kashani

IEEE Transactions on Parallel and Distributed Systems

Outline Introduction

Distributed continuous media server (DCMS) Redundant hierarchy (RedHi)

Mechanisms Object location Path selection Resource reservation

Simulation results Conclusions

DCMS architecture Network topology

Designed with hierarchical network topology. Head-end

The nodes at the leaves. Clients are connected to the head-ends.

When a request for an object arrives at a head-end, the head-end serves the client if the object is available in its local storage.

Otherwise, the request will be forwarded to the higher levels of the hierarchy.

Resource management middleware Object placement Object delivery

RedHi Pure hierarchy: degree-1 parent. RedHi: Relax the degree-1 parent to degree-

2 or more. The redundancy in RedHi is not of bandwidt

h, but of number of links.

Design objectives Resource utilization optimization

Evaluate by client blocking ratio. Scalability

Allow extending the DCMS network. Robustness Start-up latency alleviation Resource management overhead

alleviation

Assumptions The entire set of objects are located at the

root initially. When an object is served through a path

from a server node to a head-end, the object is cached at all intermediate nodes on the path based on the LRU caching policy.

The state of system resources are fully distributed. (Each node only stores the state data relevant to the local resources.)

Mechanisms Object location

Locate all nodes that have the object stored locally.

Path selection Select one of those nodes as the object

server and select the “best” path. Resource reservation

Reserve required streaming resources along the selected path.

Object location

Minimum path cost

Reject

Flooding Merge query messages

Selective flooding Parent-only Inclusive Sibling

Path selection

Use a cost function to evaluate a path.

Parameters Length of the path (is compared first) Amount of free streaming resources

available along the path Bottleneck

Minimum amount of free bandwidth among nodes Average

Resource reservation General approaches

Pessimistic Preserving all resources that might be required

during the path selection. Releasing the extra resources after the path is

actually selected. Resources are over-reserved.

Optimistic Reserving the required resources after path

selection is finalized. The resource required for the selected path might

have been pre-allocated to other concurrent requests.

Moderate policies Early Release Pessimistic (ERP)

Resources are still preserved during query propagation.

The extra resources are released early during the path selection process.

Early Reserve Optimistic (ERO) Resources are reserved early during

response processing. (before path selection is finalized)

Average / Bottleneck

ERO / ERP

Topologies

Improvement

With link failure (RedHi vs pure hierarchy)

Improvement (RedHi/inclusive vs pure hierarchy/parent-only)

Startup-latency

Communication overhead