Autonomic Metered Pricing for a Utility Computing Service

Chee Shin Yeo, Srikumar Venugopal, Xingchen Chu, Rajkumar Buyya ∗Grid Computing and Distributed Systems Laboratory, Department of Computer Science and Software Engineering,

The University of Melbourne, VIC 3010, Australia

Abstract

An increasing number of providers are offering utility computing services which require users to pay only whenthey use. Most of these providers currently charge users for metered usage based on fixed prices. In this paper,we analyze the pros and cons of charging fixed prices as compared to variable prices. In particular, charging fixedprices do not differentiate pricing based on different user requirements. Hence, we highlight the importance ofdeploying an autonomic pricing mechanism that self-adjusts pricing parameters to consider both application andservice requirements of users. Performance results observed in the actual implementation of an enterprise Cloud showthat the autonomic pricing mechanism is able to achieve higher revenue than various other common fixed and variablepricing mechanisms.

Key words: Service Pricing, Autonomic Management, Advanced Reservation, Quality of Service (QoS), Utility Computing,Cloud Computing

1. Introduction

The next era of computing is envisioned to bethat of utility computing [1]. The vision of utilitycomputing is to provide computing services to userson demand and charge them based on their usageand Quality of Service (QoS) expectations. Users nolonger have to invest heavily in or maintain theirown computing infrastructure. Instead, they employcomputing services offered by providers to executetheir applications. This commoditized computingmodel thus strengthens the case to charge users viametered usage [2], just like in real-world utilities. Inother words, users only have to pay for what theyuse.

∗ Corresponding author.Email addresses: csyeo@csse.unimelb.edu.au (Chee

Shin Yeo), srikumar@csse.unimelb.edu.au (SrikumarVenugopal), xchu@csse.unimelb.edu.au (Xingchen Chu),raj@csse.unimelb.edu.au (Rajkumar Buyya).

The latest emergence of Cloud computing [3] isa significant step towards realizing this utility com-puting model since it is heavily driven by indus-try vendors. Cloud computing promises to deliverreliable services through next-generation data cen-ters built on virtualized compute and storage tech-nologies. Users will be able to access applicationsand data from a “Cloud” anywhere in the worldon demand and pay based on what they use. Asmore providers are starting to offer pay-per-use util-ity computing services using Cloud infrastructure,the issue of how to determine the right price forusers is now becoming increasingly critical for theseproviders. This is because pricing is able to regu-late the supply and demand of computing servicesand thus affects both providers (who supply the ser-vices) and users (who demand the services) respec-tively. When the right price is set, a provider can notonly attract/restrict a sufficient number of users tomeet its revenue target, but also provide computingservices more effectively and efficiently to meet the

Preprint submitted to Elsevier 14 May 2009

service needs of users. Hence, the aim of this paperis to justify the need for an autonomic pricing mech-anism that can set this right price for a provider.In particular, this paper focuses on how a providercan charge commercial users or enterprises whichmake heavy demands on computing resources, ascompared to personal users or individuals with con-siderably lower requirements.

Currently, providers follow a fairly simple pricingscheme to charge users – fixed prices based on var-ious resource types. For processing power (as of 15October 2008), Amazon [4] charges $0.10 per virtualcomputer instance per hour (Hr), Sun Microsystems[5] charges $1.00 per processor (CPU) per Hr, andTsunamic Technologies [6] charges $0.77 per CPUper Hr. Instead of charging fixed prices for theseheavy users, we advocate charging variable pricesand provide guaranteed QoS through the use of ad-vanced reservations. Advance reservations are book-ings made in advance to secure an available item inthe future and are used in the airline, car rental, andhotel industries. In the context of utility comput-ing, an advance reservation is a guarantee of accessto a computing resource at a particular time in thefuture for a particular duration [7].

Charging fixed prices in utility computing is notfair to both the provider and users since differentusers have distinctive needs and demand specificQoS for various resource requests that can changeanytime. In economics, a seller with constrained ca-pacity can adjust prices to maximize revenue if thefollowing four conditions are satisfied [8]: (i) demandis variable but follows a predictable pattern, (ii) ca-pacity is fixed, (iii) inventory is perishable (wastedif unused), and (iv) seller has the ability to adjustprices. Thus, for utility computing, providers cancharge variable prices since: (i) demand for comput-ing resources changes but can be expected using ad-vanced reservations [7], (ii) only a limited amount ofresources is available at a particular site owned by aprovider, (iii) processing power is wasted if unused,and (iv) a provider can change prices.

The main aim of providers charging variableprices is to maximize revenue by differentiating thevalue of computing services provided to differentusers. Since providers are commercial businessesdriven by profit, they need to maximize revenue.Profitable providers can then fund further expan-sions and enhancements to improve their utilitycomputing service offerings. Charging variableprices is also particularly useful for resource man-agement as it can result in the diversion of demand

from high-demand time periods to low-demand timeperiods [8], thus maximizing utilization for a utilitycomputing service. Higher prices increase revenueas users who need services during high-demand timeperiods are willing to pay more, whereas others willshift to using services during low-demand periods.The latter results in higher utilization during theseotherwise underutilized low-demand periods andhence leads to higher revenue.

In general, fixed prices are simpler to understandand more straightforward for users as compared tovariable prices. However, all users do not have thesame need. Hence, it is not fair for all users to becharged the same fixed price since not all users mayafford the same price. Fixed prices also do not al-low price-sensitive users to benefit from lower priceswhich they prefer to accept in exchange of certainrestrictions. Moreover, fixed prices do not permit aprovider to give specific incentives via differentiatedpricing based on distinct user requirements, whichis the emphasis of this paper. In this paper, we pro-pose charging variable prices with advanced reserva-tions so that users are not only able to secure theirrequired resources in advance, but also know the ex-act expenses which is computed during the time ofreservation (even though they are based on variableprices). This will continue to enable users to performbudgeting with known variable prices in advance asin the case of fixed prices.

This paper proposes an autonomic pricing mecha-nism for a utility computing service which automat-ically adjusts prices when necessary to increase rev-enue. In particular, we highlight the significance ofconsidering essential user requirements that encom-pass application and service requirements. Pricingcomputing resources according to user requirementsbenefits the utility computing service since differentusers require specific needs to be met and are will-ing to pay varying prices to achieve them. The keycontributions of this paper are to:– Consider two essential user requirements for au-

tonomic metered pricing: (i) application and (ii)service.

– Describe how metered pricing can be imple-mented in an enterprise Cloud with advancedreservations.

– Analyze the performance of various fixed and vari-able pricing mechanisms through experimental re-sults to demonstrate the importance of autonomicmetered pricing.This paper is organized as follows: Section 2 dis-

cusses related work. Section 3 examines economic

2

aspects of a utility computing service. Section 4describes the implementation of metered pricing us-ing a service-oriented enterprise Cloud technologycalled Aneka [9]. Section 5 explains the evaluationmethodology and experimental setup to assess theperformance of various fixed and variable pricingmechanisms with respect to the application andservice requirements of users. Section 6 analyzes theperformance results. Section 7 presents conclusionsand future work.

2. Related Work

Many market-based resource management sys-tems have been implemented across numerous com-puting platforms [10] including clusters, distributeddatabases, Grids, parallel and distributed systems,peer-to-peer, and the World Wide Web. To manageresources, these systems adopt a variety of economicmodels [11], such as auction, bargaining, bartering,commodity market, bid-based proportional resourcesharing, posted price, and tendering/contract-net.In this paper, we examine metered pricing which isapplicable in commodity market and posted pricemodels.

Recently, several works have discussed pricing forutility or on-demand computing services. In par-ticular, these works have identified and addressedvarious distinguished features of utility computingwhich is different from traditional pricing mecha-nisms in economics. Price-At-Risk [12] considers un-certainty in the pricing decision for utility comput-ing services which have uncertain demand, high de-velopment costs, and short life cycle. Pricing modelsfor on-demand computing [13] have been proposedbased on various aspects of corporate computinginfrastructure which include cost of maintaininginfrastructure in-house, business value of infrastruc-ture, scale of infrastructure, and variable costs ofmaintenance. Another work [14] considers economicaspects of a utility computing service whereby highprices denote higher service level for faster compu-tation. But, these works do not consider autonomicpricing that addresses users’ application require-ments (such as parallel applications) and servicerequirements (such as deadline and budget).

Setting variable prices is known as price discrim-ination in economics [15]. Sulistio et al. [16] haveexamined third degree price discrimination by usingrevenue management [8] to determine the pricing ofadvanced reservations in Grids. It evaluates revenue

performance across multiple Grids for variable pric-ing based on the combination of three market seg-ments of users (premium, business, and budget) andthree time periods of resource usage (peak, off-peak,and saver). Hence, it does not derive fine-grainedvariable prices that differentiate specific applicationand service requirements of individual users.

Chen et al. [17] have proposed pricing-basedstrategies for autonomic control of web servers.It uses pricing and admission control mechanismsto control QoS of web requests such as slowdownand fairness. However, this paper focuses on high-performance applications and user-centric servicerequirements (deadline and budget).

In our previous work, we have presented Li-bra [18] as a market-based solution for deliveringmore utility to users in clusters compared to tradi-tional scheduling policies. As Libra only computesa static cost, an extension called Libra+$ [19] usesan enhanced pricing function that satisfies fouressential requirements for pricing of resources toprevent workload overload: (i) flexible, (ii) fair,(iii) dynamic, and (iv) adaptive. In this paper, wepropose an autonomic version of Libra+$ calledLibra+$Auto which is feasible as demonstratedthrough its actual implementation in an enterpriseCloud.

Libra+$Auto has a number of pros compared toLibra+$ and Libra. First, Libra+$Auto is able toautomatically adjust pricing parameters and hencedoes not rely on static pricing parameters to be con-figured manually by the provider in the case of bothLibra+$ and Libra. Second, Libra+$Auto considersthe current workload across nodes when computingprices, whereas Libra+$ only consider the currentworkload within a node and Libra does not considerany current workload at all. Third, Libra+$Autocan exploit the budget limits of users to improvethe revenue of the provider by automatically adjust-ing to increase prices when there are fewer avail-able compute nodes and reduce prices when thereare more available nodes. Fourth, Libra+$Auto of-fers more precise incentives to individual users whichcan promote user demand and in turn improve rev-enue, since it dynamically changes prices in a morefine-grained manner than both Libra+$ and Libravia expected workload demand and availability ofnodes. On the other hand, Libra+$Auto has onlyone con compared to Libra+$ and Libra, which isrequiring more computation time to determine theavailability of nodes and adjust prices depending onthe acceptance of previous requests.

3

3. Economic Aspects of a Utility ComputingService

This section examines various economic aspectsof a utility computing service including: (i) variablepricing with advanced reservations, (ii) pricing is-sues, and (iii) pricing mechanisms. We consider ascenario wherein a provider owns a set of resourcesthat we term as compute nodes. Each node can besubdivided into resource partitions and leased tousers for certain time intervals.

3.1. Variable Pricing with Advanced Reservations

The use of advanced reservations has been pro-posed to provide QoS guarantees for accessing var-ious resources across independently administeredsystems such as Grids [7]. With advanced reserva-tions, users are able to secure resources required inthe future which is important to ensure successfulcompletion of time-critical applications such as real-time and workflow applications or parallel applica-tions requiring a number of processors to run. Theprovider is able to predict future demand and usagemore accurately. Using this knowledge, the providercan apply revenue management [8] to determinepricing at various times to maximize revenue. Oncethese prices are advertised, users are able to decidein advance where to book resources according totheir requirements and their resulting expenses.

Having prior knowledge of expected costs is highlycritical for enterprises to successfully plan and man-age their operations. Resource supply guarantee alsoallows enterprises to contemplate and target futureexpansion more confidently and accurately. Enter-prises are thus able to scale their reservations ac-cordingly based on short-term, medium-term, andlong-term commitments.

Users may face the difficulty of choosing the bestprice for reserving resources from different utilitycomputing services at different times. This difficultycan be overcome by using resource brokers [20] whichact on the behalf of users to identify suitable utilitycomputing services and compare their prices.

3.2. Pricing Issues

For simplicity, we examine metered pricing withina utility computing service with constrained capac-ity and do not consider external influences that canbe controlled by the provider, such as cooperating

Table 1Pricing for processing power.

Name Configured Pricing Parameters

FixedMax $3/CPU/Hr

FixedMin $1/CPU/Hr

FixedTimeMax $1/CPU/Hr (12AM–12PM)

$3/CPU/Hr (12PM–12AM)

FixedTimeMin $1/CPU/Hr (12AM–12PM)

$2/CPU/Hr (12PM–12AM)

Libra+$Max $1/CPU/Hr (PBasej), α = 1, β = 3

Libra+$Min $1/CPU/Hr (PBasej), α = 1, β = 1

Libra+$Auto same as Libra+$Min

with other providers to increase the supply of re-sources [21] or competing with them to increase mar-ket share [22]. Price protection and taxation regula-tions from authorities and inflation are beyond thecontrol of the provider. We assume that users have topay in order to guarantee reservations. Thus, a util-ity computing service requires payment from userseither at the time of reservation or later dependingon payment agreements so as to reserve computingresources in advance.

We also assume that the execution time periodof applications will be within the reservation timeperiod. In order to enforce other scheduled reser-vations, a utility computing service will terminateany outstanding applications that are still execut-ing once the time period of reservation expires. Thisimplies that users must ensure that time periods ofreservations are sufficient for their applications tobe completed. Therefore, users may have to reservemore time to protect their applications from forcedtermination if they are uncertain whether their ap-plications will take more time to execute than esti-mated. Although this restriction is unfavorable forusers, users can try to minimize its impact by usingruntime prediction models [23][24] to estimate theirapplication runtimes more accurately. Users are alsopersonally responsible for ensuring that their appli-cations can fully utilize the reserved resources. It isthus disadvantageous to the users if their applica-tions fail to use the entire amount of reserved re-sources that they have already paid for.

3.3. Pricing Mechanisms

We compare three types of pricing mechanisms:(i) Fixed, (ii) FixedTime, and (iii) Libra+$. As listed

4

in Table 1, each pricing mechanism has maximumand minimum types which are configured accord-ingly to highlight the performance range of the pric-ing mechanism. Fixed charges a fixed price for perunit of resource partition at all times. FixedTimecharges a fixed price for per unit of resource parti-tion at different time periods of resource usage wherea lower price is charged for off-peak (12AM–12PM)and a higher price for peak (12PM–12AM).

Libra+$ [19] computes the price Pij for per unitof resource partition utilized by reservation requesti at compute node j as: Pij = (α ∗ PBasej) +(β ∗ PUtilij). The base price PBasej is a staticpricing component for utilizing a resource partitionat node j which can be used by the provider tocharge the minimum price so as to recover the op-erational cost. The utilization price PUtilij is a dy-namic pricing component which is computed as afactor of PBasej based on the availability of the re-source partition at node j for the required deadlineof request i: PUtilij = RESMaxj/RESFreeij ∗PBasej . RESMaxj and RESFreeij are the maxi-mum units and remaining free units of the resourcepartition at node j for the deadline duration of re-quest i respectively. Thus, RESFreeij has been de-ducted units of resource partition committed forother confirmed reservations and request i for itsdeadline duration.

The factors α and β for the static and dynamiccomponents of Libra+$ respectively, provide theflexibility for the provider to easily configure andmodify the weight of the static and dynamic compo-nents on the overall price Pij . Libra+$ is fair sincerequests are priced based on the amount of differentresources utilized. It is also dynamic because theoverall price of a request varies depending on theavailability of resources for the required deadline.Finally, it is adaptive as the overall price is adjusted(depending on the current supply and demand ofresources) to either encourage or discourage requestsubmission.

Fixed, FixedTime, and Libra+$ rely on staticpricing parameters that are difficult to be accu-rately derived by the provider to produce the bestperformance where necessary. Hence, we proposeLibra+$Auto, an autonomic Libra+$ that automat-ically adjusts β based on the availability of computenodes. Libra+$Auto thus considers the pricing ofresources across nodes, unlike Libra+$ which onlyconsiders pricing of resources at each node j via Pij .

Algorithm 1 shows the pseudocode for adjusting βin Libra+$Auto. First, the previous dynamic factor

Algorithm 1: Pseudocode for adjusting β in Li-bra+$Auto.

βPrev ← (∑nprev

i=1βi for previous request) / n ;1

maxNodes ← maximum number of nodes ;2foreach node i allocated to new request do3

freeNodes ← free number of nodes for4proposed time slot at this node i;reservedNodes ← maxNodes − freeNodes ;5if freeNodes = 0 then6

freeNodes ← 1 ;7

endif8ratioFree ← maxNodes / freeNodes ;9if reservedNodes = 0 then10

reservedNodes ← 1 ;11

endif12ratioReserved ← reservedNodes / maxNodes ;13if previous request meets budget then14

βi ← βPrev ∗ ratioFree ;15

else16βi ← βPrev ∗ ratioReserved ;17

endif18

endfch19

βPrev is computed as the average of dynamic fac-tors β at nprev number of allocated compute nodesfor the previous reservation request (line 1). Initially,when adjusting β for the first request, βPrev usesa default value that is given by the provider. Themaximum number of nodes is also assigned (line 2).Then, the free and reserved number of nodes is deter-mined for the proposed time slots at various nodesto be allocated for the new reservation request (line3–5). After that, the new dynamic factor βi for thenode i is updated depending on the outcome of theprevious request. βPrev is increased to accumulatemore revenue if the previous request meets the user-defined budget, otherwise it is reduced (line 14–18).For increasing βPrev, a larger increase is computedwhen there are less free nodes left for the proposedtime slot so as to maximize revenue with decreasingcapacity (line 6–9). Conversely, for reducing βPrev,a larger reduction is computed when there are morefree nodes left for the proposed time slot in ordernot to waste unused capacity (line 10–13).

Assuming that the previous reservation requestwants to reserve nprev number of nodes, it takesO(nprev) time to compute the previous dynamic fac-tor βPrev (line 1). In addition, it takes O(nnew)time to compute the new dynamic factor βi at eachnode i for nnew number of nodes required by the newreservation request (line 3–19). When there is max-imum m number of nodes that can be possibly allo-cated and searching through the entire data struc-

5

ture containing all reserved time slots takes O(ts)time in the worst case (depending on the type of datastructure which is used), it takes O((m− 1).O(ts))time to determine the free number of nodes for theproposed time slot at node i (line 4). Hence, adjust-ing β in Libra+$Auto can take O(nprev +nnew.(m−1).O(ts)) time in the worst case.

4. System Implementation

This section describes how metered pricing for autility computing service can be implemented us-ing a .NET-based service-oriented enterprise Cloudtechnology called Aneka [9]. Our implementation inAneka uses advanced reservations to guarantee ded-icated access to computing resources for requiredtime periods in the future.

4.1. Aneka: Enterprise Cloud Technology

Aneka [9] is designed to support multiple applica-tion models, persistence and security solutions, andcommunication protocols such that the preferred se-lection can be changed at anytime without affectingan existing enterprise Cloud. To create an enterpriseCloud, the provider only needs to start an instanceof the configurable Aneka container hosting requiredservices on each enterprise Cloud node.

The purpose of the Aneka container is to initial-ize services and acts as a single point for interac-tion with the entire enterprise Cloud. To supportscalability, the Aneka container is designed to belightweight by providing the bare minimum func-tionality needed for an enterprise Cloud node. It pro-vides the base infrastructure that consists of servicesfor persistence, security (authorization, authentica-tion and auditing), and communication (messagehandling and dispatching).

The Aneka container can host any number ofoptional services that can be added to augment thecapabilities of an enterprise Cloud node. Examplesof optional services are information and indexing,scheduling, execution, and storage services. Thisprovides a flexible and extensible framework or in-terface for the provider to easily support various ap-plication models, including MapReduce [25] whichis often associated with Cloud computing systems.Thus, resource users can seamlessly execute differ-ent types of application in an enterprise Cloud.

To support reliability and flexibility, services aredesigned to be independent of each other in a Aneka

container. A service can only interact with otherservices on the local node or other nodes throughknown interfaces. This means that a malfunctioningservice will not affect other working services and/orthe Aneka container. Therefore, the provider caneasily configure and manage existing services or in-troduce new ones into a Aneka container.

4.2. Resource Management Architecture

We implement a bi-hierarchical advance reser-vation mechanism for the enterprise Cloud with aReservation Service at a master node that coordi-nates multiple execution nodes and an AllocationService at each execution node that keeps track ofthe reservations at that node. This architecture waspreviously introduced by Venugopal et al. [26]. Fig-ure 1 shows the interaction between the user/broker,the master node and execution nodes in the en-terprise Cloud. To use the enterprise Cloud, theresource user (or a broker acting on its behalf) hasto first make advanced reservations for resourcesrequired at a designated time in the future.

During the request reservation phase, theuser/broker submits reservation requests throughthe Reservation Service at the master node. TheReservation Service discovers available executionnodes in the enterprise Cloud by interacting withthe Allocation Service on them. The AllocationService at each execution node keeps track of allreservations that have been confirmed for the nodeand can thus check whether a new request can besatisfied or not.

By allocating reservations at each execution nodeinstead of at the master node, computation over-heads arising from making allocation decisions aredistributed across multiple nodes and thus mini-mized, as compared to overhead accumulation at asingle master node. The Reservation Service thenselects the required number of execution nodes andinforms their Allocation Services to temporarily lockthe reserved time slots. After all the required reser-vations on the execution nodes have been temporar-ily locked, the Reservation Service returns the reser-vation outcome and its price (if successful) to theuser/broker.

The user/broker may confirm or reject the reser-vations during the confirm reservation phase. TheReservation Service then notifies the AllocationService of selected execution nodes to lock or re-move temporarily locked time slots accordingly. We

6

Request Available ConfirmedAccepted

AvailableTemp.Locked

Confirmed

ReservationService

AllocationService

Submit Confirmed

Lock

Confirm

SchedulingService

Submit

Dispatch Executed

Executed

ExecutionService

Executed

ExecutionNodes

MasterNode

User/Broker

Confirm Reservation PhaseRequest Reservation Phase Execution Phase

Fig. 1. Sequence of events between enterprise Cloud nodes for a successful reservation request.

assume that a payment service is in place to ensurethe user/broker has sufficient funds and can suc-cessfully deduct the required payment before theReservation Service proceeds with the final confir-mation.

During the execution phase when the reservedtime arrives, the user/broker submits applications tobe executed to the Scheduling Service at the masternode. The Scheduling Service determines whetherany of the reserved execution nodes are availablebefore dispatching applications to them for execu-tion, otherwise applications are queued to wait forthe next available execution nodes that are part ofthe reservation. The Execution Service at each exe-cution node starts executing an application after re-ceiving it from the Scheduling Service and updatesthe Scheduling Service of changes in execution sta-tus. Hence, the Scheduling Service can monitor exe-cutions for an application and notify the user/brokerupon completion.

4.3. Allocating Advanced Reservations

Figure 2 shows that the process of allocating ad-vanced reservations happens in two levels: the Allo-cation Service at each execution node and the Reser-vation Service at the master node. Both services aredesigned to support pluggable policies so that theprovider has the flexibility to easily customize andreplace existing policies for different levels and/ornodes without interfering with the overall resourcemanagement architecture.

The Allocation Service determines how to sched-

ule a new reservation at the execution node. For sim-plicity, we implement the same time slot selectionpolicy for the Allocation Service at every executionnode. The Allocation Service allocates the requestedtime slot if the slot is available. Otherwise, it assignsthe next available time slot after the requested starttime that can meet the required duration.

The Reservation Service performs node selectionby choosing the required number of available timeslots from execution nodes and administers admis-sion control by accepting or rejecting a reservationrequest. It also calculates the price for a confirmedreservation based on the implemented pricing pol-icy. Various pricing policies considered in this paperare explained in Section 3.3. Available time slots areselected taking into account the application require-ment of the user.

The application requirement considered here isthe task parallelism to execute an application. A se-quential application has a single task and thus needsa single processor to run, while a parallel applica-tion needs a required number of processors to con-currently run at the same time.

For a sequential application, the selected timeslots need not have the same start and end times.Hence, available time slots with the lowest pricesare selected first. If there are multiple available timeslots with the same price, then those with the ear-liest start time available are selected first. This en-sures that the cheapest requested time slot is allo-cated first if it is available. Selecting available timeslots with the lowest prices first is fair and realistic.In reality, reservations that are confirmed earlier en-joy the privilege of cheaper prices, as compared to

7

User/Broker

Reservation

Store

Task

Store

Node

Selection

Policy

Pricing

PolicyMembership

Store

Execution Node

Task

Store

Reservation

Store

Time Slot

Selection

Policy

Execution

Service

Membership

Service

Scheduling

ServiceReservation Service

Allocation Service

Master Node

Execution

Node

Execution

Node

SLA Negotiation

Fig. 2. Interaction of services in enterprise Cloud.

reservation requests that arrive later.But, for a parallel application, all the selected time

slots must have the same start and end times. Again,the earliest time slots (with the same start and endtimes) are allocated first to ensure the requestedtime slot is allocated first if available. If there aremore available time slots (with the same start andend times) than the required number of time slots,then those with the lowest prices are selected first.

The admission control operates according to theservice requirement of the user. The service require-ments examined are the deadline and budget tocomplete an application. We currently assume bothdeadline and budget are hard constraints. Hence, aconfirmed reservation must not end after the dead-line and cost more than the budget. Therefore, areservation request is not accepted if there is insuf-ficient number of available time slots on executionnodes that ends within the deadline and the totalprice of the reservation costs more than the budget.

5. Performance Evaluation

Figure 3 shows the enterprise Cloud setup used forperformance evaluation. The enterprise Cloud com-prises 33 PCs providing dedicated access to comput-

17 Execution Nodes

Lab011211 Execution Nodes

Lab0111

4 Execution Nodes

Lab0113

Master Node

Users/

Brokers

Fig. 3. Configuration of enterprise Cloud.

ing resources through 1 master node and 32 execu-tion nodes located across 3 student computer lab-oratories in the Department of Computer Scienceand Software Engineering, The University of Mel-bourne. Synthetic workloads are created by utilizing

8

trace data.We use Feitelson’s Parallel Workload Archive [27]

to model the reservation requests because trace dataof Cloud applications are currently not released andshared by any commercial Cloud service providers.But, for a scientific research paper, it is extremelyimportant to have publicly accessible trace data sothat our experiments can be reproducible by otherresearchers. Moreover, this paper focuses on study-ing the application requirements of users in the con-text of High Performance Computing (HPC). Hence,the Parallel Workload Archive meets our objectiveby providing the necessary characteristics of realparallel applications collected from supercomputingcenters. Unfortunately, since the Parallel WorkloadArchive is not based on paying users in utility com-puting environments, it is possible that the tracepattern of these archived workloads will be differentfrom those with paying users.

Our experiments utilize 238 reservation requestsin the last 7 days of the SDSC SP2 trace (April 1998to April 2000) version 2.2 from the Parallel Work-load Archive. The SDSC SP2 trace from the SanDiego Supercomputer Center (SDSC) in USA is cho-sen due to the highest resource utilization of 83.2%among available traces to ideally model a heavyworkload scenario. The trace only provides the inter-arrival times of reservation requests, the number ofprocessors to be reserved as shown in Figure 4(a)(downscaled from a maximum of 128 nodes in thetrace to a maximum of 32 nodes), and the durationto be reserved as shown in Figure 4(b). Service re-quirements are not available in this trace. Hence,we use a methodology proposed by Irwin et al. [28]to synthetically assign service requirements throughtwo request classes: (i) Low Urgency (LU) and (ii)High Urgency (HU). Figure 4(b) and 4(c) show thesynthetic values of deadline and budget for the 238requests respectively.

A reservation request i in the LU class has a dead-line of high deadlinei/durationi value and budgetof low budgeti/f(durationi) value. f(durationi) is afunction representing the minimum budget requiredbased on durationi. Conversely, each request in theHU class has a deadline of low deadlinei/durationi

value and budget of high budgeti/f(durationi)value. This is realistic since a user who submitsa more urgent request to be met within a shorterdeadline offers a higher budget for the short notice.Values are normally distributed within each of thedeadline and budget parameters.

For simplicity, we only evaluate the performance

of pricing for processing power as listed in Ta-ble 1 with various combinations of application re-quirements (sequential and parallel) and requestclasses (LU and HU). However, the performanceevaluation can be easily extended to include otherresource types such as memory, storage, and band-width. Both LU and HU classes are selected so asto observe the performance under extreme cases ofservice requirements with respective highest andlowest values for deadline and budget. We also cur-rently assume that every user/broker can definitelyaccept another reservation time slot proposed bythe enterprise Cloud if the requested one is notpossible, provided that the proposed time slot stillsatisfies both application and service requirementsof the user.

6. Performance Results

We analyze the performance results of seven var-ious pricing mechanisms (listed in Table 1) over oneweek with respect to the application and service re-quirements of users. The three performance metricsbeing measured are: (i) the accumulated revenue ofconfirmed reservations in $, (ii) the current averageprice of confirmed reservations in $/CPU/Hr, and(iii) the accumulated number of confirmed reserva-tions. The performance results of all three metricshave been normalized to produce standardized val-ues within the range of 0 to 1 for easier relativecomparison. The revenue (in $) of a confirmed reser-vation is the total sum of revenue across all its re-served nodes calculated using the assigned price (de-pending on the specific pricing mechanism) and thereserved duration at each node. Then, the averageprice (in $/CPU/Hr) of a confirmed reservation iscomputed to reflect the standard price across all itsreserved nodes.

6.1. Fixed Prices

Based on the configured pricing parameters ofthe four fixed pricing mechanisms listed in Table 1,we can observe that FixedMax charges the highestcurrent average price, followed by FixedTimeMax,FixedTimeMin, and FixedMin (Figure 5(b), 6(b),7(b), and 8(b)). FixedMax acts as the maximumbound of the fixed pricing mechanisms by charg-ing the highest price of $3/CPU/Hr for process-ing power, while FixedMin acts as the minimumbound by charging the lowest price of $1/CPU/Hr.

9

0

5

10

15

20

25

30

0 1 2 3 4 5 6 7

Num

ber

of P

roce

ssor

s

Day

Processor

(a) Number of processors (from trace)

0

50

100

150

200

250

300

350

0 1 2 3 4 5 6 7

Tim

e (H

r)

Day

Low Urgency (LU) DeadlineHigh Urgency (HU) Deadline

Duration

(b) Duration (from trace) and deadline (synthetic)

0

2

4

6

8

10

12

14

16

18

20

0 1 2 3 4 5 6 7

Bud

get (

$/C

PU

/Hr)

Day

High Urgency (HU) BudgetLow Urgency (LU) Budget

(c) Budget (synthetic)

Fig. 4. Last 7 days of SDSC SP2 trace (April 1998 to April 2000) with 238 requests.

10

FixedMaxFixedMax

FixedMinFixedMin

FixedTimeMaxFixedTimeMax

FixedTimeMinFixedTimeMin

Libra+$MaxLibra+$Max

Libra+$MinLibra+$Min

Libra+$AutoLibra+$Auto

0

0.2

0.4

0.6

0.8

1

0 1 2 3 4 5 6 7

Nor

mal

ized

Rev

enue

($)

Day

(a) Accumulated Revenue

0

0.2

0.4

0.6

0.8

1

0 1 2 3 4 5 6 7

Nor

mal

ized

Pric

e ($

/CP

U/H

r)

Day

(b) Current Average Price

0

0.2

0.4

0.6

0.8

1

0 1 2 3 4 5 6 7

Nor

mal

ized

Res

erva

tions

Day

(c) Accumulated Reservations

Fig. 5. Squential application requests: Low Urgency (LU).

11

FixedMaxFixedMax

FixedMinFixedMin

FixedTimeMaxFixedTimeMax

FixedTimeMinFixedTimeMin

Libra+$MaxLibra+$Max

Libra+$MinLibra+$Min

Libra+$AutoLibra+$Auto

0

0.2

0.4

0.6

0.8

1

0 1 2 3 4 5 6 7

Nor

mal

ized

Rev

enue

($)

Day

(a) Accumulated Revenue

0

0.2

0.4

0.6

0.8

1

0 1 2 3 4 5 6 7

Nor

mal

ized

Pric

e ($

/CP

U/H

r)

Day

(b) Current Average Price

0

0.2

0.4

0.6

0.8

1

0 1 2 3 4 5 6 7

Nor

mal

ized

Res

erva

tions

Day

(c) Accumulated Reservations

Fig. 6. Squential application requests: High Urgency (HU).

12

FixedMaxFixedMax

FixedMinFixedMin

FixedTimeMaxFixedTimeMax

FixedTimeMinFixedTimeMin

Libra+$MaxLibra+$Max

Libra+$MinLibra+$Min

Libra+$AutoLibra+$Auto

0

0.2

0.4

0.6

0.8

1

0 1 2 3 4 5 6 7

Nor

mal

ized

Rev

enue

($)

Day

(a) Accumulated Revenue

0

0.2

0.4

0.6

0.8

1

0 1 2 3 4 5 6 7

Nor

mal

ized

Pric

e ($

/CP

U/H

r)

Day

(b) Current Average Price

0

0.2

0.4

0.6

0.8

1

0 1 2 3 4 5 6 7

Nor

mal

ized

Res

erva

tions

Day

(c) Accumulated Reservations

Fig. 7. Parallel application requests: Low Urgency (LU).

13

FixedMaxFixedMax

FixedMinFixedMin

FixedTimeMaxFixedTimeMax

FixedTimeMinFixedTimeMin

Libra+$MaxLibra+$Max

Libra+$MinLibra+$Min

Libra+$AutoLibra+$Auto

0

0.2

0.4

0.6

0.8

1

0 1 2 3 4 5 6 7

Nor

mal

ized

Rev

enue

($)

Day

(a) Accumulated Revenue

0

0.2

0.4

0.6

0.8

1

0 1 2 3 4 5 6 7

Nor

mal

ized

Pric

e ($

/CP

U/H

r)

Day

(b) Current Average Price

0

0.2

0.4

0.6

0.8

1

0 1 2 3 4 5 6 7

Nor

mal

ized

Res

erva

tions

Day

(c) Accumulated Reservations

Fig. 8. Parallel application requests: High Urgency (HU).

14

The remaining FixedTimeMax and FixedTimeMinfalls within the maximum and minimum bounds bycharging the same price as FixedMin ($1/CPU/Hr)for off-peak (12AM–12PM), and charging either thesame price as ($3/CPU/Hr for FixedTimeMax) ora lower price ($2/CPU/Hr for FixedTimeMin) thanFixedMax for peak (12PM–12AM).

Given these current average price observa-tions, one may infer that FixedMax should alwaysprovide the highest accumulated revenue (maxi-mum bound), followed by FixedTimeMax, Fixed-TimeMin, and FixedMin with the lowest accumu-lated revenue (minimum bound). However, ourperformance results show that this inference is onlyvalid for three of our tested scenarios (Figure 5(a),6(a), and 8(a)). For LU parallel application re-quests (Figure 7(a)), FixedTimeMin and FixedMinprovide the highest accumulated revenue, insteadof FixedMax and FixedTimeMax. This is becauseboth FixedMax and FixedTimeMax charge sig-nificantly higher current average prices (45% and0%–45% more than FixedMin for FixedMax andFixedTimeMax respectively in Figure 7(b)) thatmostly exceed the budget of LU parallel applica-tion requests, and can thus only accept a lowernumber of requests (52% and 31% less than Fixed-Min for FixedMax and FixedTimeMax respectivelyin Figure 7(c)). In contrast, both FixedMax andFixedTimeMax only charge current average pricesthat are not more than 31% higher than FixedMinfor the other three scenarios (Figure 5(b), 6(b), and8(b)). This thus demonstrates the dilemma facedby providers on how to set the best price for fixedpricing mechanisms in order to achieve the bestrevenue performance across all various scenarios.

We now determine whether Fixed or FixedTimeis a better fixed pricing mechanism across all var-ious scenarios. We first compare FixedMax andFixedTimeMax based on their improvement in rev-enue compared to FixedMin (shown in Table 2for Figure 5(a), 6(a), 7(a), and 8(a)) because theyreflect the same price difference of $2/CPU/Hr.FixedMax charges $3/CPU/Hr, while FixedMincharges $1/CPU/Hr. Likewise, FixedTimeMaxcharges $1/CPU/Hr for off-peak (12AM–12PM)and $3/CPU/Hr for peak (12PM–12AM), whileFixedMin charges the same $1/CPU/Hr for bothoff-peak and peak.

Table 2 shows that FixedMax has a significantlyhigher standard deviation (SD = 58.01) of improve-ment in revenue compared to FixedMin, which isabout 2.5 times more than that of FixedTimeMax

Table 2Improvement in revenue compared to FixedMin.

Pricing Sequential Parallel SD

LU HU LU HU

FixedMax 61% 26% -72% 33% 58.01

FixedTimeMax 36% 13% -18% 21% 22.76

FixedTimeMin 20% 7% 4% 19% 8.19

Libra+$Max -17% 70% -89% 43% 70.59

Libra+$Min 48% 24% -56% 24% 45.43

Libra+$Auto 24% 87% -8% 42% 39.65

Table 3Gap in revenue compared to the upper bound.

Pricing Sequential Parallel SD

LU HU LU HU

FixedMax 31% 81% 23% 57% 26.36

FixedMin 75% 94% 43% 73% 21.08

FixedTimeMax 52% 87% 27% 64% 24.99

FixedTimeMin 63% 91% 33% 66% 23.75

Libra+$Max 21% 60% 14% 34% 20.27

Libra+$Min 41% 82% 26% 62% 24.46

Libra+$Auto 48% 49% 45% 52% 2.89

(SD = 22.76). But, FixedTimeMin (which charges$2/CPU/Hr for peak) has an even lower standarddeviation (SD = 8.19) than that of FixedTimeMax(SD = 22.76). This means that setting the idealprice correctly for various time periods of resourceusage to satisfy different types of application andservice requirements is not easy. Still, out of thesefour fixed pricing mechanisms, the FixedTime mech-anisms are easier to derive and more reliable thanthe Fixed mechanisms since they support a range ofprices across various time periods of resource usageand are observed to have less revenue fluctuationsthan Fixed mechanisms respectively.

Table 3 shows the gap in revenue from the upperbound of revenue. This upper bound is computedas the total budget of requests which are accepted.Thus, pricing mechanisms can have different upperbound values since they may not accept the samerequests. Defining this upper bound enables us toknow how optimal the pricing mechanisms are interms of maximizing the revenue out of the budgetgiven by the user. Hence, it is better to have a lowerpercentage gap in Table 3 since it means that thepricing mechanism is able to achieve more revenueout of the maximum budget.

15

As listed in Table 3, all four fixed pricing mecha-nisms achieve a much worse percentage gap for HUrequests (57%–94%) than for LU requests (23%–75%). But, FixedMin is the most optimal out ofthem with the lowest standard deviation (SD =21.08), followed by FixedTimeMin (SD = 23.75),FixedTimeMax (SD = 24.99), and FixedMax (SD= 26.36). This further reinforces that FixedTimemechanisms are easier to derive and more reliablefor the provider compared to Fixed mechanisms.

6.2. Variable Prices

We analyze the three variable pricing mechanismswhich are based on Libra+$ as listed in Table 1: Li-bra+$Max, Libra+$Min, and Libra+$Auto. Unlikethe previously discussed four fixed pricing mecha-nisms, Libra+$ considers the service requirement ofusers by charging a lower price for a request withlonger deadline as an incentive to encourage users tosubmit requests with longer deadlines that are morelikely to be accommodated than shorter deadlines.The difference in prices charged by Libra+$Max,Libra+$Min, and Libra+$Auto is primarily depen-dent on the β factor for the dynamic pricing com-ponent of Libra+$ as explained in Section 3.3 – ahigher β factor means that Libra+$ will charge ahigher price.

Table 1 shows that Libra+$Max and Libra+$Minhas a β value of 3 and 1 respectively, thus Li-bra+$Max always charges a higher price thanLibra+$Min (Figure 5(b), 6(b), 7(b), and 8(b)).However, Libra+$Max only provides higher accu-mulated revenue than Libra+$Min for HU requestswith short deadline and high budget (Figure 6(a)and 8(a)). For LU requests with long deadline andlow budget (Figure 5(a) and 7(a)), Libra+$Maxinstead provides the least accumulated revenue outof all seven fixed and variable pricing mechanisms,even though it charges the highest prices at varioustimes (Figure 5(b) and 7(b)). This highlights theinflexibility of static pricing parameters to maxi-mize revenue for different service requirements. Inthis case, β of Libra+$Max is set too high such thatrequests are rejected due to low budget.

On the other hand, Libra+$Auto is initiallyconfigured with the same pricing parameters as Li-bra+$Min, but will automatically adjust β based onthe availability of compute nodes over time. SinceLibra+$Auto does not have a statically defined βvalue, it has the flexibility to charge prices that are

higher (Figure 6(b)) or lower (Figure 5(b), 7(b),and 8(b)) than Libra+$Max and Libra+$Min. Inparticular, Libra+$Auto is able to exploit the highbudget of users by automatically adjusting to ahigher β to increase prices and maximize revenuewhen the availability of nodes is low. This can beobserved for HU sequential application requests(Figure 6(b)) wherein Libra+$Auto continues in-creasing prices to higher than that of Libra+$Maxand other pricing mechanisms when demand is highsuch as during the later half of day 1, 2, 3, and 5.

Conversely, Libra+$Auto also adjusts to a lower βto decrease prices when demand is low to accommo-date users with lower budgets. Thus, Libra+$Autocan continue to generate revenue, but at a slowerrate when demand is low (i.e., when there are moreunused nodes which will otherwise be wasted). Thiscan again be observed for HU sequential applicationrequests (Figure 6(b)), when demand is low suchas during the early half of day 2, 3, 5, and 6, Li-bra+$Auto keeps reducing prices to lower than thatof Libra+$Max to accept requests that are not will-ing to pay more.

With this autonomic pricing feature, we can ob-serve that Libra+$Auto is able to generate themost highest (Figure 6(a)) and second highest(Figure 8(a)) revenue for sequential and parallelapplications of HU requests respectively. In partic-ular, Libra+$Auto is able to achieve these highestrevenues by accepting an almost similar numberof HU requests as most other pricing mechanismsfor both sequential and parallel applications (Fig-ure 6(c) and 8(c)). A similar number of HU requestsare accepted since nodes are less likely to be avail-able for short deadlines. Thus, it demonstrates thatLibra+$Auto adjusts pricing by considering theservice requirements (deadline and budget) of users.

In addition, for sequential applications, we canobserve that Libra+$Auto accepts the least num-ber of requests for both LU and HU requests (Fig-ure 5(c) and 6(c)). But, for parallel applications,Libra+$Auto is able to accept a higher number ofrequests similar to most other pricing mechanisms(Figure 7(c) and 8(c)). This is because parallel ap-plications need multiple nodes which require higherbudget, compared to sequential applications whichonly require a single node. Hence, the low budgetleads to a huge inconsistency in performance be-tween sequential and parallel applications for otherpricing mechanisms due to the inflexibility of staticpricing parameters. However, Libra+$Auto is ableto progressively increase the accumulated revenue

16

over the 7-days period for parallel applications(Figure 7(a) and 8(a)), as compared to sequentialapplications (Figure 5(a) and 6(a)). For example,Libra+$Auto is still able to achieve almost the samerevenue as Libra+$Max even though Libra+$Maxaccumulates more revenue much earlier from Day 2to 5 (Figure 8(a)). This is because Libra+$Auto ad-justs to a lower β at various times to accommodatemore requests with lower prices than Libra+$Maxto eventually fix the initial shortfall (Figure 8(b)).Hence, unlike Libra+$Max and Libra+$Min, Li-bra+$Auto can also automatically adjust pricingbased on application requirements, in addition toservice requirements.

As listed in Table 2, Libra+$Auto has a signif-icantly lower standard deviation (SD = 39.65) ofimprovement in revenue compared to FixedMin,which is about 1.8 and 1.1 times less than that ofLibra+$Max (SD = 70.59) and Libra+$Min (SD= 45.43) respectively. In fact, the standard devia-tion of Libra+$Auto is also much lower than thatof FixedMax (SD = 58.01) which is a fixed pricingmechanism. Even though Libra+$Auto has a higherstandard deviation than that of FixedTimeMax(SD = 22.76) and FixedTimeMin (SD = 8.19), Li-bra+$Auto is able to generate considerably higherrevenue for HU requests of both sequential and par-allel applications by differentiating both applicationand service requirements of users, which is criticalfrom the perspective of a utility computing service.

Table 3 shows that Libra+$Auto is the most op-timal out of all seven pricing mechanisms across allvarious scenarios. Libra+$Auto has the lowest stan-dard deviation (SD = 2.89) of gap in revenue com-pared to the upper bound, which is about 7.0 and 8.4times less than that of Libra+$Max (SD = 20.27)and Libra+$Min (SD = 24.46) respectively. Unlikethe other six mechanisms which have a wide rangeof percentage gap between LU and HU requests, Li-bra+$Auto consistently maintains a narrow rangeof percentage gap for both LU and HU requests(45%–52%). This demonstrates that Libra+$Autois able to adjust pricing effectively to maximize rev-enue across all various scenarios.

However, Libra+$Auto is not the most optimalfor each specific scenario. Libra+$Auto is only themost optimal for HU sequential application requestswith the lowest percentage gap of 49%. Instead, Li-bra+$Max is the most optimal for the other threescenarios with the lowest percentage gap of 21%,14%, and 34% for LU sequential, LU parallel and HUparallel application requests respectively. Hence, the

current simple heuristic of Libra+$Auto can be fur-ther enhanced to not only maximize revenue acrossall various scenarios, but also for each specific sce-nario.

7. Conclusion

This paper studies the performance of chargingfixed and variable prices for a utility computingservice. Charging fixed prices is simple to under-stand and straightforward for users, but do notdifferentiate pricing to exploit different user require-ments in order to maximize revenue. Hence, thispaper emphasizes the importance of implementingautonomic metered pricing for a utility computingservice to self-adjust prices to increase revenue. Inparticular, autonomic metered pricing can also bestraightforward for users through the use of ad-vanced reservations. With advanced reservations,users can not only know the prices of their requiredresources in the future ahead, but are also able toguarantee access to future resources to better planand manage their operations.

Through the actual implementation of an en-terprise Cloud, we show that a simple autonomicpricing mechanism called Libra+$Auto is able toachieve higher revenue than other common fixedpricing mechanisms by considering two essentialuser requirements: (i) application (sequential andparallel) and (ii) service (deadline and budget). Theuse of advanced reservations enables Libra+$Autoto self-adjust prices in a more fine-grained mannerbased on the expected workload demand and avail-ability of nodes so that more precise incentives canbe offered to individual users to promote demandand thus improve revenue. Experimental resultsshow that Libra+$Auto is able to exploit budgetlimits to achieve higher revenue than other variableand fixed pricing mechanisms by automatically ad-justing to a higher β to increase prices when theavailability of nodes is low and a lower β to reduceprices when there are more unused nodes which willotherwise be wasted.

Our future work will involve conducting exper-imental studies using real applications and servicerequirements of users which can be collected byproviders such as Amazon, Sun Microsystems, orTsunamic Technologies. We also need to under-stand how users will react to price changes andwhen they will switch providers. This knowledgecan be used to derive more sophisticated models to

17

construct a more complex autonomic pricing mech-anism that considers more dynamic factors such asuser response from price changes and competitionfrom other providers. A stochastic model can thenbe built based on historical observation data to pre-dict future demand and adjust prices accordingly.In addition, allowing cancellation of reservations isessential to provide more flexibility and conveniencefor users since user requirements can change overtime. Therefore, future work needs to investigatethe implication of cancellations for a utility comput-ing service and possible overbooking of reservationsto address cancellations. It may be possible to applyrevenue management [8] to monitor current can-cellations, amend cancellation and refund policies,and adjust prices for new reservations accordingly.The providers may also require users to pay penal-ties or not be entitled to any refunds for cancellingreservations depending on specific booking termsand agreements during the time of reservation.

Acknowledgments

We thank Chao Jin and Krishna Nadiminti fortheir help with the use of Aneka. We also want tothank anonymous reviewers for their constructivecomments which helped to improve this paper. Thiswork is partially supported by research grants fromthe Australian Research Council (ARC) and Aus-tralian Department of Innovation, Industry, Scienceand Research (DIISR).

References

[1] C. S. Yeo, R. Buyya, M. D. de Assuncao, J. Yu,A. Sulistio, S. Venugopal, M. Placek, Utility Computingon Global Grids, in: H. Bidgoli (Ed.), Handbook ofComputer Networks, John Wiley and Sons, Hoboken,NJ, USA, 2007.

[2] M. A. Rappa, The Utility Business Model and the Futureof Computing Services, IBM Systems Journal 43 (1)(2004) 32–42.

[3] R. Buyya,C. S. Yeo, S. Venugopal, J. Broberg, I. Brandic, CloudComputing and Emerging IT Platforms: Vision, Hype,and Reality for Delivering Computing as the 5th Utility,Future Generation Computer Systems 25 (2009) doi:10.1016/j.future.2008.12.001.

[4] Amazon, Elastic Compute Cloud (EC2),http://www.amazon.com/ec2/ (Oct. 2008).

[5] Sun Microsystems, Sun Grid,http://www.sun.com/service/sungrid/ (Oct. 2008).

[6] Tsunamic Technologies, Cluster On Demand,http://www.tsunamictechnologies.com/services.htm#COD(Oct. 2008).

[7] I. Foster, C. Kesselman, C. Lee, B. Lindell,K. Nahrstedt, A. Roy, A Distributed ResourceManagement Architecture that Supports AdvanceReservations and Co-Allocation, in: Proceedings ofthe 7th International Workshop on Quality ofService (IWQoS 1999), IEEE Communications Society:Piscataway, NJ, USA, London, UK, 1999, pp. 27–36.

[8] R. L. Phillips, Pricing and Revenue Optimization,Stanford University Press, Stanford, CA, USA, 2005.

[9] X. Chu, K. Nadiminti, C. Jin, S. Venugopal, R. Buyya,Aneka: Next-Generation Enterprise Grid Platform for e-Science and e-Business Applications, in: Proceedings ofthe 3th International Conference on e-Science and GridComputing (e-Science 2007), IEEE Computer Society:Los Alamitos, CA, USA, Bangalore, India, 2007, pp.151–159.

[10] C. S. Yeo, R. Buyya, A Taxonomy of Market-based Resource Management Systems for Utility-drivenCluster Computing, Software: Practice and Experience36 (13) (2006) 1381–1419.

[11] R. Buyya, D. Abramson, J. Giddy, H. Stockinger,Economic Models for Resource Management andScheduling in Grid Computing, Concurrency andComputation: Practice and Experience 14 (13–15)(2002) 1507–1542.

[12] G. A. Paleologo, Price-at-Risk: A Methodology forPricing Utility Computing Services, IBM SystemsJournal 43 (1) (2004) 20–31.

[13] K.-W. Huang, A. Sundararajan, Pricing Models forOn-Demand Computing, Working Paper CeDER-05-26,New York University (Nov. 2005).

[14] J. P. Degabriele, D. Pym, Economic Aspects of a UtilityComputing Service, Technical Report HPL-2007-101,HP Labs, Bristol (Jul. 2007).

[15] B. P. Pashigian, Price Theory and Applications, 2ndEdition, Irwin/McGraw-Hill, Boston, MA, USA, 1998.

[16] A. Sulistio, K. H. Kim, R. Buyya, Using RevenueManagement to Determine Pricing of Reservations, in:Proceedings of the 3th International Conference on e-Science and Grid Computing (e-Science 2007), IEEEComputer Society: Los Alamitos, CA, USA, Bangalore,India, 2007, pp. 396–404.

[17] Y. Chen, A. Das, N. Gautama, Q. Wang,A. Sivasubramaniam, Pricing-based strategies forautonomic control of web servers for time-varyingrequest arrivals, Engineering Applications of ArtificialIntelligence 17 (7) (2004) 841–854.

[18] J. Sherwani, N. Ali, N. Lotia, Z. Hayat, R. Buyya,Libra: A Computational Economy-based Job SchedulingSystem for Clusters, Software: Practice and Experience34 (6) (2004) 573–590.

[19] C. S. Yeo, R. Buyya, Pricing for Utility-driven ResourceManagement and Allocation in Clusters, InternationalJournal of High Performance Computing Applications21 (4) (2007) 405–418.

[20] S. Venugopal, R. Buyya, L. Winton, A Grid ServiceBroker for Scheduling e-Science Applications on GlobalData Grids, Concurrency and Computation: Practiceand Experience 18 (6) (2006) 685–699.

18

[21] J. F. Kurose, R. Simha, A Microeconomic Approach toOptimal Resource Allocation in Distributed ComputerSystems, IEEE Trans. Comput. 38 (5) (1989) 705–717.

[22] T. T. Nagle, J. E. Hogan, The Strategy and Tacticsof Pricing: A Guide to Growing More Profitably, 4thEdition, Prentice Hall, Upper Saddle River, NJ, USA,2006.

[23] W. Smith, I. Foster, V. Taylor, Predicting ApplicationRun Times Using HistoricalInformation, in: Proceedings of the 4th Workshop on JobScheduling Strategies for Parallel Processing (JSSPP1998), Vol. 1459/1998 of Lecture Notes in ComputerScience (LNCS), Springer-Verlag: Heidelberg, Germany,Orlando, FL, USA, 1998, pp. 122–142.

[24] J. Yang, I. Ahmad, A. Ghafoor, Estimation of ExecutionTimes on Heterogeneous Supercomputer Architectures,in: Proceedings of the 22th International Conference onParallel Processing (ICPP 1993), Vol. 1, IEEE ComputerSociety: Los Alamitos, CA, USA, Syracuse, NY, USA,1993, pp. 219–226.

[25] C. Jin, R. Buyya, MapReduce Programming Model for.NET-based Distributed Computing, Technical ReportGRIDS-TR-2008-15, Grid Computing and DistributedSystems Laboratory, The University of Melbourne (Oct.2008).

[26] S. Venugopal, X. Chu, R. Buyya, A NegotiationMechanism for Advance Resource Reservations using theAlternate Offers Protocol, in: Proceedings of the 16thInternational Workshop on Quality of Service (IWQoS2008), IEEE: Piscataway, NJ, USA, Enschede, TheNetherlands, 2008, pp. 40–49.

[27] Parallel Workloads Archive,http://www.cs.huji.ac.il/labs/parallel/workload/ (Oct.2008).

[28] D. E. Irwin, L. E. Grit, J. S. Chase, BalancingRisk and Reward in a Market-based Task Service, in:Proceedings of the 13th International Symposium onHigh Performance Distributed Computing (HPDC13),IEEE Computer Society: Los Alamitos, CA, USA,Honolulu, HI, USA, 2004, pp. 160–169.

19