Service Level Agreement Based Distributed Resource Allocation for Streaming Hosting Systems

1. Service Level Agreement Based Distributed Resource Allocation for Streaming Hosting Systems Yun Fu and Amin Vahdat http://issg.cs.duke.edu Department of Computer Science Duke University

2. Motivations for Hosting Services • Hosting centers release people from • Developing difficult expertise locally • Reinventing the complex wheel of supporting high-performance, highly available network services • Hosting centers enable people to leverage • The economies of scale • Statistical multiplexing for services

3. Hosting Service Content Content Revenue Revenue Service Providers End Clients Challenges for Resource Control • Distributed hosting services, service providers and end clients constitute a profit ecosystem • The key question is how to arbitrate resources under constraint • Service Level Agreements (SLAs)are required to control resource allocation among service providers on a hosting service

4. SLASH • We design SLASH (Service Level Agreement based Streaming Hosting System) as a distributed resource allocation solution for hosting services • We propose Squeeze as the resource allocation algorithm for SLASH • Squeeze can dynamically allocate resources according to dynamically changing network conditions and access patterns • We construct prototypes on Solaris and Linux • The experimental results show that Squeeze can allocate resources according to SLAs

5. SLASH Architecture • Switches as a front-end interface of SLASH • Switches control resource allocation on edge servers

6. Challenges for Streaming Hosting • A streaming request can occupy system resources for an indefinite period of time • Different from web requests which only last for milliseconds • Resource reservation is necessary • Service providers can only specify their resource requirements for target level performance by carefully designing SLAs

7. Principles on designing SLAs • Resources specified in SLAs should reflect both space (bandwidth) and time (bandwidth consuming duration) • Difficult to estimate revenue loss if SLAs directly specify bandwidth allocation • Revenue prices and penalty prices in SLAs should be fair between service providers and the hosting service • The revenue price of a stream file is the profit earned per time unit for a connection • The penalty priceis the profit loss due to shortage of deserved resources

8. Difficulty in Defining Penalties Req for 300Kbps Req for 300Kbps Req for 300Kbps Req for 100Kbps Req for 100Kbps Req for 100Kbps • For a given request load and a certain amount of resources, possible throughput depends on the scheduling algorithm • It is not practical to determine if a single rejected request should be charged for a penalty 300Kbps Time • Requests for 100Kbps and 300Kbps streams arrive periodically • Accepting 100Kbps streams causes 300Kbps streams to be rejected

9. Defining Penalties • Assume stream bitrates are multiples of a basicbandwidth unit • For a given measurement interval (epoch), define a share as a bandwidth unit used during an epoch • E.g. 1 bandwidth unit = 100Kbps, 1 epoch = 60 seconds, 1 share = 100Kbps * 60 seconds • Shares are resource units specified in SLAs • Offered load (shares generated by customers) • Trading volume (shares sold by the hosting service) • Penalties should be based on the offered load and the trading volume generated during an epoch

10. Penalties Resources(Shares) Resources(Shares) Offered Load Reserved Resources Reserved Resources Offered Load Penalty Amount Penalty Amount Penalty Area Penalty Area Trading Volume Trading Volume Offered Load () , Trading Volume () , Reserved Resources(), Penalty Price (P)

11. SLA Based Control • For a single service, higher prices for high-quality streams • To use resources more efficiently, define the revenue price for each share of low-quality streams to be higher than high-quality streams • High-quality requests can be downgraded to low quality

12. SLA Based Control • For different services, higher prices cause SLASH to allocate more spare resources to a service • In case of a sudden request load burst (breaking news), a service can occupy another service’s resources • The service’s revenue prices in each share can be defined to be higher than the other service’s revenue price in each share plus the penalty

13. 9 9 9 9 9 9 9 9 9 9 9 12 9 9 9 9 9 9 9 12 12 9-3 9-3 9-3 12 12 12 12 12 12 12 Price Example • To allocate resources equally between two services, set their prices to be the same • PRICE low quality = 9 $/epc, BW low quality = 1 • PRICE high quality = 12 $/epc, BW high quality =3 • PENALTY = 3 $/share S1 BW=12 S2

14. Squeeze Resource Allocation Algorithm • We propose Squeeze as the resource allocation algorithm for SLASH • Squeeze allocates resources according to the estimated request load for each service • Squeeze periodically adjusts resource allocation to all services • A utility gradient-based resource allocation algorithm • Allocate resources to the most profitable service considering possible penalties based on SLAs

15. 13 shares 59$ 10$ 57$ 11 shares 9$ 10$ 9$ 7 shares 49$ 7$ 9$ 9$ 7$ 35$ 7$ 9$ 9$ 7$ 7$ 7$ 7$ 7$ 7$ 7$ 7$ 7$ 7$ Squeeze Resource Allocation Algorithm • For a certain request load, determines the profit for each newly allocated share • 3 different quality streams: 1, 2 and 3 bandwidth units, 1 epoch long • Prices are 7$, 9$ and 10$ respectively • Penalty: 1$ for 1 share; Reservation: 5 shares 3 shares 3 shares 2 shares 5 shares 2 shares 1 share 1 share 1 share -5$

16. Squeeze Resource Allocation Algorithm • For each service, we have a concave profit increase graph according to its current offered load • Repeatedly compare all service’s current profit increase (per unit resource) • allocate resources to most profitable service (with highest gradient)

17. Experiments • We implement SLASH on Solaris and Linux • Supports VOD/AOD by RTSP/RTP • Compare Squeeze with other resource allocation algorithms to show the ability to • Reserve resources according the offered load and the SLA • Dynamically downgrade stream quality and adjust resource allocation among services • The major criterion for evaluating resource allocation schemes is the net revenue obtained by the hosting service

18. Experimental Setup • 1 switch and 4 servers • Server capacity: 90 bandwidth units (128kbps) for each server, • Total of 360 bandwidth units for the system • 2 services: server 1 and service 2 • Each service’s SLA reserves 180 shares • Each service has a low-bitrate (1 bandwidth unit) and a high-bitrate (3 bandwidth units) stream with same prices • Streams are 4 epochs long (10 second epoch) • Prices: 9 for low-quality, 12 for high-quality streams • The penalty price is 4 per share

19. Resource Reservation • SLASH allocates resources according to offered load • Thus can generate smoother throughput and higher net profit • A First-Come-First-Serve (FCFS) solution admits all requests to the cluster without resource reservation • May reject many requests when all resources are consumed and cause higher penalties

20. Revenue by Resource Reservation • Constant request loads: • 15 requests/epoch for service 1’s high-quality stream • 45 requests/epoch for service 2’s high-quality stream • The net profit of SLASH is 60% higher than FCFS Revenue without penalties Revenue with penalties

21. Dynamic Resource Adjustment • Squeeze is able to downgrade stream quality and dynamically adjust resource reservation • Compared with a static solution and a greedy algorithm • Static reservation • Reserves resources strictly according to SLAs • One service does not use the other service’s resources even if its request load is high • Avoids penalties • Greedy algorithm • Always downgrades the quality of streams to the lowest quality to obtain the maximum benefit for each share

22. Request Load • Constant request load for service 1 • 15 requests/epoch • Increasing request load for service 2 • 15 requests/epoch in the beginning • Constantly increases by 10 requests/epoch every 4 epochs

23. Revenue by Resource Adjustment • Squeeze can always maintain the optimal resource allocation between the other two solutions • The static reservation does not fully utilize resources • The greedy algorithm wastes resources and pays the penalty in the beginning Revenue without penalties Revenue with penalties

24. Squeeze Resource Allocation • Resources are allocated for high-quality streams in the beginning • With the increase of the request load for service 2, more resources are allocated for the low-quality steams of service 2 • After consuming all service 2’s resources, downgrades service 1’s request quality and releases resources for service 2

25. Conclusions • Propose principles for SLA design • Price and penalty design • Squeeze algorithm to allocate resources for SLASH according to SLAs • The price and penalty design ensures each service has a concave profit increase graph • Squeeze can dynamically maintain an optimal resource allocation • We have built and evaluated a working prototype of SLASH with the Squeeze algorithm