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 bandwidth, 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