fu by shimeiyan


									Service Level Agreement Based Distributed Resource
      Allocation for Streaming Hosting Systems

               Yun Fu and Amin Vahdat

            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 high-
     performance, 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
   – Service Level Agreements (SLAs) are required to control
     resource allocation among service providers on a hosting

                                        Hosting Service

                        Service Providers               End Clients
• 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
• We construct prototypes on Solaris and Linux
   – The experimental results show that Squeeze can
     allocate resources according to SLAs
               SLASH Architecture


          Edge Server                       Internet

Clients                 Switch                         Switch

    Edge Server                  Edge Server

          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
   – 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
   – 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

Req for 100Kbps      Req for 100Kbps       Req for 100Kbps

 • 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
Resources(Shares)                        Resources(Shares)

    Offered Load
                    Reserved Resources                       Reserved Resources

                                             Offered Load
              Amount                                    Penalty
                          Penalty Area                  Amount    Penalty Area
                Trading                                   Trading
                Volume                                    Volume

                                0                      if   min(, ),
      penalty (, )  
                       P * (min(, )  )             if   min(, );

                              Offered Load () , Trading Volume () ,
                              Reserved Resources(), Penalty Price (P)
                  SLA Based Control
• For a single service, higher prices for high-quality

         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         PRICEhigh quality
          BWlow 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
   – 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

                        S1                                         S2
 PRICElow quality                          PRICEhigh quality
                              PENALTY 
   BWlow quality                             BWhigh quality
                          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
                                            9                 9
                     12                     9                 9
   S1                                       9                 9
                                            9                 9
                     12                     12
                                            9                 9
                                            9                 9
                     12                     12                12
   S2                                                          9-3
                     12                     12                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
                                        13 shares                        59$
3 shares                                                  10$
                           11 shares     9$                              57$
3 shares                                 9$               10$
                      7$                                                 49$
2 shares              7$                 9$                9$
             5                                                           35$
2 shares              7$                 9$                9$
           shares     7$
 1 share              7$                 7$                7$
 1 share              7$                 7$                7$
 1 share              7$                 7$                7$
 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
                         60                                57    59
                         50                          49
           Revenue ($)

                         30                                           Profit
                               0        5        7        11    13
                                        Resource (Share)
• 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
                 Experimental Setup
• 1 switch and 4 servers
   – Server capacity: 90 bandwidth units (128kbps) for each
   – 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

• 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
• 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
• We have built and evaluated a working prototype
  of SLASH with the Squeeze algorithm

To top