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
Motivations for Hosting Services
• Hosting centers release people from
– Developing difficult expertise locally – Reinventing the complex wheel of supporting highperformance, highly available network services
• Hosting centers enable people to leverage
– The economies of scale – Statistical multiplexing for services
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
Hosting Service Content Content Revenue Service Providers Revenue End Clients
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
SLASH Architecture
Switch Edge Server Clients Switch Internet Switch
Edge Server
Edge Server
Switch
Clients
Clients
• Switches as a front-end interface of SLASH • Switches control resource allocation on edge servers
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
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 price is the profit loss due to shortage of deserved resources
Difficulty in Defining Penalties
• 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 Req for 300Kbps Req for 300Kbps Req for 300Kbps
300Kbps
Req for 100Kbps
Req for 100Kbps
Req for 100Kbps
Time • Requests for 100Kbps and 300Kbps streams arrive periodically • Accepting 100Kbps streams causes 300Kbps streams to be rejected
Defining Penalties
• Assume stream bitrates are multiples of a basic bandwidth 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
Penalties
Resources(Shares) Offered Load Reserved Resources Penalty Amount Penalty Area Trading Volume Offered Load Reserved Resources Resources(Shares)
Penalty Penalty Area Amount Trading Volume
0 penalty (, ) P * (min(, ) )
if min(, ), if min(, );
Offered Load () , Trading Volume () , Reserved Resources(), Penalty Price (P)
SLA Based Control
• For a single service, higher prices for high-quality streams
PRICE low quality PRICE high quality
• 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
PRICElow quality BWlow quality
PRICEhigh quality BWhigh quality
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
PRICElow quality BWlow quality
S1
S1
PENALTY
S2
PRICEhigh quality BWhigh quality
S2
S2
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
12
S1
12
BW=12
12
9 9 9 9 12 9 9 12 12
9 9 9 9 9 9 9-3 12 9-3 9-3 12
S2
12
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
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 7 shares 2 shares 2 shares 1 share 1 share 1 share 5 shares
13 shares 11 shares
10$ 10$ 9$ 9$ 7$ 7$ 7$
9$
59$ 57$
9$ 7$ 7$ 7$ 7$ 7$ 7$ 7$
9$ 9$ 7$ 7$ 7$
49$ 35$
-5$
• 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)
70 60 50 40 30 20 10 0 -10 0 57 49 35 Profit 59
Squeeze Resource Allocation Algorithm
– allocate resources to most profitable service (with highest gradient)
Revenue ($)
-5 5 7 11 13
Resource (Share)
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
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
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
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
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
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
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
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
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