Post on 20-Dec-2015
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.
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)