1. Decentralized Resource Management for a Distributed Continuous Media Server Cyrus Shahabi and Farnoush Banaei-Kashani Presented by Leung Chi Kit

2. Outline Introduction Introduction Objectives Objectives Mechanism Mechanism Performance Evaluation Performance Evaluation Conclusion Conclusion

3. Introduction Many Multimedia applications Many Multimedia applications Clients are geographically dispersed Clients are geographically dispersed One large Centralized Continuous Media Server (CCMS) result in inefficient resource allocations One large Centralized Continuous Media Server (CCMS) result in inefficient resource allocations Proposed Distributed Continuous Media Server (DCMS) Proposed Distributed Continuous Media Server (DCMS)

4. DCMS Architecture Pure Hierarchy Pure Hierarchy One and only one root One and only one root Every node (except root) has one and only one parent node Every node (except root) has one and only one parent node Redundant Hierarchy (RedHi) Redundant Hierarchy (RedHi) At least two roots At least two roots Every node (except root) has at least two parent nodes Every node (except root) has at least two parent nodes

5. DCMS Architecture

6. Objectives The resource management include two orthogonal issues: The resource management include two orthogonal issues: Object Placement Object Placement Object Delivery Object Delivery This paper focus on object delivery This paper focus on object delivery Objective: design a object delivery scheme that are scalable, robust, low start-up latency and low resource management overhead Objective: design a object delivery scheme that are scalable, robust, low start-up latency and low resource management overhead

7. Mechanism Assumption of the object placement scheme: Assumption of the object placement scheme: All media objects are located at the root(s) All media objects are located at the root(s) When a object transfer to a client, the object is cached at all intermediate nodes based on the Least Recently Used caching policy. When a object transfer to a client, the object is cached at all intermediate nodes based on the Least Recently Used caching policy.

8. Mechanism Tasks in object delivery scheme Tasks in object delivery scheme Object location Object location Path selection Path selection Resource reservation Resource reservation This paper collapse the three tasks into a single delivery mechanism in order to minimize start-up latency and management overhead This paper collapse the three tasks into a single delivery mechanism in order to minimize start-up latency and management overhead

9. Mechanism Each node only stores the metadata relevant to the local resources (available bandwidth of the node and the adjacent links, the object stored in the node) Each node only stores the metadata relevant to the local resources (available bandwidth of the node and the adjacent links, the object stored in the node) Full decentralization results in optimal scalability and robustness Full decentralization results in optimal scalability and robustness

10. Mechanism Mechanism: Mechanism: Head-end receives a request from a client Head-end receives a request from a client The head-end generate a query packet and propagates it to the network. The head-end generate a query packet and propagates it to the network.

11. Mechanism Several propagation policies Several propagation policies

12. Mechanism Each instance of query packet incrementally evaluate the cost of the paths. Each instance of query packet incrementally evaluate the cost of the paths. The node with the object replica will send a response packet (cost of the path) back along the same path The node with the object replica will send a response packet (cost of the path) back along the same path When more than one response packet received, the node compare the responses. It select the path with the lowest cost. When more than one response packet received, the node compare the responses. It select the path with the lowest cost.

13. Mechanism Each node wait for at most two times the maximum RTT between it and the root for the response. It send back the response to the querier after time out occur Each node wait for at most two times the maximum RTT between it and the root for the response. It send back the response to the querier after time out occur After the best path was found, the head- end send a start packet along the best path and the object server start streaming the object to the client. After the best path was found, the head- end send a start packet along the best path and the object server start streaming the object to the client.

14. Mechanism Cost Function Cost Function P = N U L P = N U L

15. Mechanism Path selection: Path selection: Choose the path with the shortest path_length Choose the path with the shortest path_length If the path_length of two paths are the same, choose the path with more path_freeBW If the path_length of two paths are the same, choose the path with more path_freeBW

16. Resource Reservation Pessimistic: Pessimistic: To pre-reserve all resources that might possibly be required for the selected path (performed during query propagation) To pre-reserve all resources that might possibly be required for the selected path (performed during query propagation) To release the extra resources only after the path is actually selected To release the extra resources only after the path is actually selected Resource are over-reserved Resource are over-reserved

17. Resource Reservation Optimistic: Optimistic: To start reserving the required resources after path selection is finalized To start reserving the required resources after path selection is finalized The resources required for the selected path might have been pre-allocated to other concurrent requests The resources required for the selected path might have been pre-allocated to other concurrent requests

18. Resource Reservation Early Release Pessimistic (ERP) Early Release Pessimistic (ERP) Extra resources are released as soon as they are disqualified from being in the best path Extra resources are released as soon as they are disqualified from being in the best path Early Reserve Optimistic (ERO) Early Reserve Optimistic (ERO) Resources are reserved early during response processing Resources are reserved early during response processing

19. Performance Evaluation

21. Comparative evaluation of the optional techniques: Cost functionReservation policies

22. Performance Evaluation

23. With link failures

24. Performance Evaluation Latency and Communication Overhead Latency and Communication Overhead Worst case: communication overhead = 35KB/successfully request

25. Conclusion The decentralized resource management guarantees scalability, robustness, low start-up latency and low resource management overhead The decentralized resource management guarantees scalability, robustness, low start-up latency and low resource management overhead Best propagation: Inclusive Best propagation: Inclusive Best cost evaluation: path_freeBW average Best cost evaluation: path_freeBW average Best reservation techniques: Early Reserve Optimistic (ERO) Best reservation techniques: Early Reserve Optimistic (ERO) Start-up latency and communication overhead are negligible Start-up latency and communication overhead are negligible