Applied Science, Faculty of
Electrical and Computer Engineering, Department of
DSpace
UBCV
Chi, Yuanfang
Master of Applied Science - MASc
University of British Columbia
Resources are limited in capacity. In the meanwhile, over-provisioning of resources resulted in server low utilization could be costly to cloud providers. The underlying reasons of the low utilization are multiple-folds, such as uneven application fit where the application cannot fully utilize the resources allocated or the uncertainty in demand forecasts that is introduced by the dramatically varied demand of the cloud resource between peak and non-peak periods. While many research works are devoted to optimize the resource allocation techniques in the effort of achieving higher server utilization, how to control resource demand so the correct level of resource provisioning can be determined has become the next research question. In this thesis, we introduce a pricing methodology with dynamic pricing that intended to induce desired demand pattern and enhances the revenue of a cloud provider. The proposed pricing methodology encourages cloud tenants, whose requested Virtual Machines (VMs) can be allocated easily, to use more cloud service by offering them lower prices and discouraging cloud tenants, whose requested VMs are difficult to allocate, from using cloud service by charging them higher prices. We study our pricing methodology with a combinatorial optimization algorithm, the Knapsack Algorithm and show that the overall revenue is enhanced through evaluations. Then, to achieve fairness among users, we further perform a case study of our pricing methodology with a multi-resource allocation fairness algorithm, the Heterogeneous Dominant Resource Fairness (DRFH) algorithm. Trace-driven simulation results show that the proposed pricing methodology with DRFH can increase the overall revenue by up to 11.60%. Furthermore, we propose a novel cloud federation system that is cognitive to the dynamic prices as a decision making assistant tool for our pricing methodology. The cloud federation system automatically selects and migrates user tasks to a cloud system that is charging at a more affordable rate. We discuss the architectural framework and platform design, provide a mathematical formulation and investigate a total service cost minimization approach with privacy constraints. Simulation results demonstrate the proposed system can lower the cost of cloud services by exploiting the advantages of dynamic prices of multiple clouds.
A Cloud Eco-System: Reactive DemandControl and Dynamic Pricing MethodologybyYuanfang ChiB.A.Sc., The University of British Columbia, 2012A THESIS SUBMITTED IN PARTIAL FULFILLMENT OFTHE REQUIREMENTS FOR THE DEGREE OFMASTER OF APPLIED SCIENCEinThe Faculty of Graduate and Postdoctoral Studies(Electrical and Computer Engineering)THE UNIVERSITY OF BRITISH COLUMBIA(Vancouver)October 2015c© Yuanfang Chi 2015AbstractResources are limited in capacity. In the meanwhile, over-provisioning of resources resulted in serverlow utilization could be costly to cloud providers. The underlying reasons of the low utilization aremultiple-folds, such as uneven application fit where the application cannot fully utilize the resourcesallocated or the uncertainty in demand forecasts that is introduced by the dramatically varied demand ofthe cloud resource between peak and non-peak periods. While many research works are devoted to opti-mize the resource allocation techniques in the effort of achieving higher server utilization, how to controlresource demand so the correct level of resource provisioning can be determined has become the nextresearch question. In this thesis, we introduce a pricing methodology with dynamic pricing that intendedto induce desired demand pattern and enhances the revenue of a cloud provider. The proposed pricingmethodology encourages cloud tenants, whose requested Virtual Machines (VMs) can be allocated eas-ily, to use more cloud service by offering them lower prices and discouraging cloud tenants, whoserequested VMs are difficult to allocate, from using cloud service by charging them higher prices. Westudy our pricing methodology with a combinatorial optimization algorithm, the Knapsack Algorithmand show that the overall revenue is enhanced through evaluations. Then, to achieve fairness amongusers, we further perform a case study of our pricing methodology with a multi-resource allocationfairness algorithm, the Heterogeneous Dominant Resource Fairness (DRFH) algorithm. Trace-drivensimulation results show that the proposed pricing methodology with DRFH can increase the overall rev-enue by up to 11.60%. Furthermore, we propose a novel cloud federation system that is cognitive tothe dynamic prices as a decision making assistant tool for our pricing methodology. The cloud federa-tion system automatically selects and migrates user tasks to a cloud system that is charging at a moreaffordable rate. We discuss the architectural framework and platform design, provide a mathematicalformulation and investigate a total service cost minimization approach with privacy constraints. Sim-iiulation results demonstrate the proposed system can lower the cost of cloud services by exploiting theadvantages of dynamic prices of multiple clouds.iiiPrefaceThe pricing methodology proposed in this thesis is based on work conducted in UBC Wireless Networksand Mobile Systems Laboratory with Xiuhua Li, Dr. Xiaofei Wang, Professor Victor C.M. Leungand Professor Abdalalh Shami. As the first author of this paper, I initiated and conducted most ofthe research. I conducted all the simulations and wrote most of the manuscript. Xiuhua Li and Dr.Xiaofei Wang contribued in research ideas and mathematical models. Professor Victor C.M. Leung andProfessor Abdalalh Shami helped in research directions and manuscript proof-reading. The following isthe details of the published paper in the thesis.The cognitive price-aware cloud federation system is based on work conducted in UBC WirelessNetworks and Mobile Systems Laboratory with Wei Cai, Zhen Hong, Professor Henry C.B. Chan andProfessor Victor C.M. Leung. As the first author of this paper, I contribued in research ideas, math-ematical models and manuscript preparing. Wei Cai and Zhen Hong contribued in simulations andmathematical model refining. Professor Victor C.M. Leung and Professor Henry C.B. Chan helped inresearch directions and manuscript proof-reading. The following is the details of the published paper inthe thesis.• Yuanfang Chi, Xiuhua Li, Xiaofei Wang, Victor C.M. Leung and Abdalalh Shami, “A Fairness-Aware Pricing Methodology for Revenue Enhancement in Service Cloud Infrastructure”, acceptedfor publication in IEEE Systems Journal, 2015.• Yuanfang Chi, Wei Cai, Zhen Hong, Henry C.B. Chan and Victor C.M.Leung, “A Privacy andPrice-Aware Inter-cloud System”, to appear in 7th IEEE International Conference on Cloud Com-puting Technology and Science (CloudCom2015), Vancouver, Canada, Nov 30-Dec 3, 2015.ivTable of ContentsAbstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiPreface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ivTable of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vList of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiiList of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixList of Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiNotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiAcknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xivDedication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Summary of Results and Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1 Resource Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Fairness in Resource Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Price-based Demand Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10v2.4 Pricing Models of The Cloud Service . . . . . . . . . . . . . . . . . . . . . . . . . . 112.5 Service Recommendation Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.6 Cloud Federation Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 A Pricing Methodology for Revenue Enhancement . . . . . . . . . . . . . . . . . . . . . 163.1 The Pricing Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.1.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2 Problem Formulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2.1 Price Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2.2 Cloud Task Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.3 Revenue Enhancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3 Case Study on Knapsack Combinatorial Optimization . . . . . . . . . . . . . . . . . 243.3.1 Knapsack Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3.2 Knapsack-based Revenue Enhancement . . . . . . . . . . . . . . . . . . . . . 253.3.3 Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.3.4 Discussion of Knapsack-based Revenue Enhancement . . . . . . . . . . . . . 333.4 Case Study on DRFH Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.4.1 DRFH Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.4.2 DRFH-based Revenue Enhancement . . . . . . . . . . . . . . . . . . . . . . 353.4.3 DRFH-based Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.4.4 Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464 A Price-Aware Cloud Federation System . . . . . . . . . . . . . . . . . . . . . . . . . . 484.1 The Price-Aware Cloud Federation System . . . . . . . . . . . . . . . . . . . . . . . 484.1.1 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2 Problem Formulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.2.1 Program Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.2.2 Dynamic Pricing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52vi4.2.3 Assignment of Codes and Data Sets . . . . . . . . . . . . . . . . . . . . . . . 534.2.4 Assignment Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.2.5 Price Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.2.6 State-Transition Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.2.7 Optimization Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.3 Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.3.1 Simulation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.3.2 Pricing Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.3.3 Cognitive Price-Aware Transition . . . . . . . . . . . . . . . . . . . . . . . . 634.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.1 Summary of Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.2 Future Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68viiList of Tables3.1 Definition of Input Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 System Resource Vector for Knapsack-based Revenue Enhancement . . . . . . . . . . 263.3 User Demand Vector and Prices of Google Compute Engine for Knapsack-based Rev-enue Enhancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.4 New Unit Prices Compared to Google Compute Engine Unit Prices for Knapsack-basedRevenue Enhancement With Total Unit Price Redistribution . . . . . . . . . . . . . . . 283.5 New Unit Prices Compared to Google Compute Engine Unit Prices for Knapsack-basedRevenue Enhancement With Total Revenue Redistribution . . . . . . . . . . . . . . . 313.6 System Resource Vector for DRFH-based Revenue Enhancement. . . . . . . . . . . . . 383.7 User Demand Vector and Prices of Google Compute Engine for DRFH-based RevenueEnhancement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.8 New Unit Prices Compared to Google Compute Engine Unit Prices for DRFH-basedRevenue Enhancement with Total Unit Price Redistribution . . . . . . . . . . . . . . . 393.9 New Unit Prices Compared to Google Compute Engine Unit Prices for DRFH-basedRevenue Enhancement with Total Revenue Redistribution . . . . . . . . . . . . . . . . 424.1 Default Simulation Parameters for Cognitive Cloud Federation System . . . . . . . . . 60viiiList of Figures3.1 Sequence Diagram for Fairness-aware Pricing . . . . . . . . . . . . . . . . . . . . . . 183.2 Commodity Demand Curve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3 Comparison of Revenues with Different Alpha Values for Knapsack-based Revenue En-hancement With Total Unit Price Redistribution . . . . . . . . . . . . . . . . . . . . . 273.4 Comparison of Requests Generated by Each User for Knapsack-based Revenue En-hancement With Total Unit Price Redistribution . . . . . . . . . . . . . . . . . . . . . 283.5 Comparison of Allocated Virtual Machines for Each User for Knapsack-based RevenueEnhancement With Total Unit Price Redistribution . . . . . . . . . . . . . . . . . . . 293.6 Comparison of Revenues Generated by Each User for Knapsack-based Revenue En-hancement With Total Unit Price Redistribution . . . . . . . . . . . . . . . . . . . . . 303.7 Comparison of Revenues with Different Alpha Values for Knapsack-based Revenue En-hancement With Total Revenue Redistribution . . . . . . . . . . . . . . . . . . . . . . 303.8 Comparison of Requests Generated by Each User for Knapsack-based Revenue En-hancement With Total Revenue Redistribution . . . . . . . . . . . . . . . . . . . . . . 313.9 Comparison of Allocated Virtual Machines for Each User for Knapsack-based RevenueEnhancement With Total Revenue Redistribution . . . . . . . . . . . . . . . . . . . . 323.10 Comparison of Revenues Generated by Each User for Knapsack-based Revenue En-hancement With Total Revenue Redistribution . . . . . . . . . . . . . . . . . . . . . . 323.11 Comparison of Revenues Generated by Existing and Proposed Pricing Model for DRFH-based Revenue Enhancement with Total Unit Price Redistribution . . . . . . . . . . . 38ix3.12 Comparison of Requests Generated by Each User for DRFH-based Revenue Enhance-ment with Total Unit Price Redistribution . . . . . . . . . . . . . . . . . . . . . . . . 403.13 Comparison of Allocated Virtual Machines for Each User for DRFH-based RevenueEnhancement with Total Unit Price Redistribution . . . . . . . . . . . . . . . . . . . . 403.14 Comparison of Revenues Generated by Each User for DRFH-based Revenue Enhance-ment with Total Unit Price Redistribution . . . . . . . . . . . . . . . . . . . . . . . . 413.15 Comparison of Revenues Generated by Existing and Proposed Pricing Model for DRFH-based Revenue Enhancement with Total Revenue Redistribution . . . . . . . . . . . . 423.16 Comparison of Requests Generated by Each User for DRFH-based Revenue Enhance-ment with Total Revenue Redistribution . . . . . . . . . . . . . . . . . . . . . . . . . 433.17 Comparison of Allocated VMs for Each User for DRFH-based Revenue Enhancementwith Total Revenue Redistribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.18 Comparison of Revenues Generated by Each User for DRFH-based Revenue Enhance-ment with Total Revenue Redistribution . . . . . . . . . . . . . . . . . . . . . . . . . 443.19 Comparison Between Existing and Proposed Pricing Model with Data Extracted fromGoogle Trace for DRFH-based Revenue Enhancement . . . . . . . . . . . . . . . . . 453.20 Comparison Between Existing and Proposed Pricing Model with Data Extracted fromGoogle Trace for DRFH-based Revenue Enhancement . . . . . . . . . . . . . . . . . 464.1 Architectural Framework for Cognitive Cloud Federation System . . . . . . . . . . . . 504.2 Design of Decomposed Cloud Federation Platform . . . . . . . . . . . . . . . . . . . 514.3 Tradeoff between Security Level and Cloud Service Fee . . . . . . . . . . . . . . . . . 614.4 Effect of Data-Code Relationship on the Cloud Service Fee . . . . . . . . . . . . . . . 624.5 Effect of Data Access Proportion on the Cloud Service Fee . . . . . . . . . . . . . . . 624.6 Efficiency of Proposed Platform with Pricing Variety Time Interval . . . . . . . . . . . 634.7 Efficiency of Proposed Platform with Time Elapsed . . . . . . . . . . . . . . . . . . . 64xList of AbbreviationsAmazon EC2 Amazon Elastic Compute CloudCPU central processing unitCSP Constraint Satisfaction ProblemDRF Dominant Resource FairnessDRFH Heterogeneous Dominant Resource FairnessFIFO first-in-first-outGB gigabyteIaaS Infrastructure as a ServiceNP-hard non-deterministic polynomial-time hardPM physical machinePSM Price Sensitivity MeasurementQoS Quality of ServiceRAID redundant array of independent disksSLA Service Level AgreementTRR Total Revenue RedistributionTUPR Total Unit Price RedistributionVBSE Value-Based Software EngineeringVM virtual machinexiNotations.T transpose||.||1 l1 normα price elasticity coefficientωd data access proportionΘ maximum quantity of program codes allowed to be hosted in the same cloudΦ maximum quantity of data sets allowed to be stored in the same cloudcs number of available cloud service providerscl normalized resource capacity vector for each server ldc number of data chunksdir normalized resource vector of user i’s Virtual MachinefR(p) demand functionpc the number of program codesw set of pricing weightsA matrix of resource allocationBd matrix of assignment of data chunks over cloud servicesBp matrix of assignment of program codes over cloud servicesDi resource vector of user i’s demanded Virtual MachineFd set of data chunksFp set of program codesGi(Ai) global dominant share allocated to user iI matrix of network input volumeL matrix of code-data relationshipxiiM matrix of message exchangesNi(Ai) total number of VMs that can be scheduled for user iO matrix of network output volumePα set of unit computational resource pricesPβ set of unit data storage pricesPθ set of unit output bandwidth pricesPρ set of unit input bandwidth pricesPc total computing pricePd set of new prices generated by our pricing methodologyPe set of prices the cloud provider chargesPi total inbound bandwidth pricePn over all network pricePo total outbound bandwidth pricePs total storage priceQi total message inbound bandwidth priceQo total message outbound bandwidth priceRd set of revenue with the prices generated by our pricing methodologyRe set of revenue a cloud provider receives with existing unit pricesRi total inbound bandwidth priceRo total outbound bandwidth priceS set of servers the cloud system containsSr vector of resource types each server containsTs vector of number of Virtual Machines submitted to the system by all tenantsTn vector of number of Virtual Machines allocated to a userU set of cloud tenants active in the cloud systemVr matrix of network volume data reading from one cloud serviceVm matrix of network volume with inter-cloud message exchangeVs matrix of network volume of state-transitionxiiiAcknowledgmentsI would like to take this chance to thank all of those who have helped me and supported me during thecourse of my research work.I want to appreciate Professor Victor C.M. Leung for providing me the life changing chance ofpursuing a Graduate Degree and conducting research in Cloud Computing. Without your mentorship,guidance and support, this work would not be possible. Also, I am thankful to Professor Abdalalh Shamifor the help of the manuscript of the published paper contained in this thesis.I would like to thank my colleagues Xiuhua Li, Xiaofei Wang and Wei Cai for the help during myresearch journey. Thank you all for the effort of discussing research topics and tips with me.This work was supported by the Natural Sciences and Engineering Research Council (NSERC) ofCanada.xivDedicationxvChapter 1IntroductionThis thesis presents how resource management of the cloud system can be accomplished through de-mand control using dynamic prices. As more and more companies or individuals have moved theirapplications or computing tasks to the cloud, cloud providers are facing a new challenge: the server uti-lization is only at 10% [1]. Low server utilization has numerous causes, such as uneven application fitwhere the application cannot fully utilize the resources allocated or the uncertainty in demand forecaststhat is introduced by the dramatically varied demand of the cloud resource between peak and non-peakperiods. While many research works are devoted to optimize the resource allocation techniques in theeffort of achieving higher server utilization, how to control resource demand so the correct level of re-source provisioning can be determined has become the next research question. This thesis introducesa new approach of using dynamic pricing to control aggregate demand to avoid resource over/under-provisioning and achieve a higher profitability. Further, to avoid requiring users to pay close attentionsto the frequent changing prices and make real-time request decisions themselves, this thesis demon-strates a price-aware cloud federation system that could cognitively reacts to the dynamic prices andautomatically makes demand decisions.1.1 MotivationFor any for-profit organization, the ultimate goal is to maximize its profitability. Ever since the CloudComputing has emerged, we have observed a rising number of cloud service providers providing differ-ent service types, such as infrastructure, computing and storage, have been introduced to the market [2].To achieve its ultimate goal, a cloud provider is devoted to seek the way to lower costs through resourcemanagement and develop an efficient pricing strategy that focuses not only on how much it increases1price, but also on how much it increases profitability[3].The virtualization technique is the key in cloudcomputing. Computational and storage resources are provided by Infrastructure as a Service (IaaS)cloud through different types of Instances. Upon the request of an Instance by a tenant, if the cloud hasenough resources to host the instance, a virtual machine (VM) is allocated onto a server so that the cloudtenant could run her applications or other computational tasks on the Instance, or the VM to be specific.Therefore, resource management in cloud computing is well studied in the perspectives of virtualizationand allocation optimization [4][5][6]. However, optimization from any aspect alone is limiting. Theamount of resources a cloud tenant needs varies from time to time. Traditional resource allocation andprovisioning techniques still require data centers to be prepared for the intense resource demand dur-ing peak period [7]. Incorrect estimations of user demand levels may lead to costly over-provisioningof resources. Moreover, regardless of how the cloud is considered to be an unlimited resource pool,any resource has fixed capacity. In case of resource competition, the cloud resource should be sharedamong all users fairly. It is important to incentivize cloud tenants to request for cloud resources rea-sonably. Also, given the cloud system is becoming more compatible and easier to access, changing to acheaper service provider has becoming a common practice for users who are price sensitive. Thus, thedemand of cloud resources is more reactive nowadays. A competing cloud provider is urged to developa more “dynamic” pricing strategy that could control the reactive demand to maintain system utiliza-tion level and revenue. Therefore, user demand patterns should also be considered as inputs to the VMplacement problem. In this thesis, we propose a pricing methodology that, by shaping the demand pat-tern, contributes in the resource management perspective that achieves system resource high utilizationwith Knapsack Algorithm and resource fair-sharing with Heterogeneous Dominate Resource Fairness(DRFH) Algorithm. The profitability of the proposed pricing methodology is evaluated through numer-ical and trace-driven simulations. Results have shown that it enhances the cloud provider’s revenue.The ability of the proposed pricing methodology to induce user demand pattern is also proven to be asuccess.On the other hand, the key for a service to be acceptable for general users is powerful functions yetsimplified usages. The pricing methodology we proposed may need users constantly paying attentionsto the current prices a cloud provider charges for their VMs. Users also need to constantly make de-2cisions about whether or not to continue using the service at the given prices since the price may bechanging. These may become new obstacles for users to adopt the cloud services. Moreover, the goalof service consumers, especially consumers with huge service demand, are to receive qualified serviceswith minimum costs possible. To this end, we introduce a new way to improve user experiences onsuch cloud services. We propose a price-aware cloud federation system that provides the capabilityof automatically choosing and migrating user tasks to the cloud system that is charging at the lowestrate on real-time basis. The cloud federation [8] system inter-connects global “cloud of clouds” withthe ability to communicate and cooperate between clouds provided by different vendors. Our pricingmethodology is more user-friendly with the cloud federation system. When one cloud resource is tooexpensive for a user, the cloud federation system would automatically migrates her program or data setrunning on a VM of a cloud service to a cloud service with an affordable rate. Simulation results haveshown that the total cost for users is dropped significantly with the cloud federation system, comparingto a single-cloud service.The rest of the thesis is organized as follows: in Chapter 2, we provide an overview of differenttechniques of resource management, pricing-based demand control and cloud federations in cloud com-puting. In Chapter 3, we propose a pricing methodology that enhances the cloud providers’ revenuesand keeps system resource utilization high. We study the ability of the proposed pricing methodology toaffect the user request submission pattern and the profitability of the proposed pricing methodology fora cloud provider through numerical and trace-driven simulations. In Chapter 4, we introduce a price-aware cognitive cloud federation system as a supporting tool of our proposed pricing methodology. InChapter 5, we discuss the conclusion and suggestions of possible extension of the work included in thisthesis.1.2 Summary of Results and ContributionIn this thesis, we• Propose a pricing methodology that leverages cloud task scheduling algorithms to determine theoptimal demand pattern of the cloud service, generates dynamic prices according to current work-3load of the cloud system and uses pricing as a tool to control the aggregate demand and achieve ahigher profitability.• Propose a framework of a price-aware cloud federation system as a supporting tool for the pro-posed pricing methodology that would help user automatically choosing, and migrate computationtasks to, a cloud service that is charging at a affordable rate.• Provide a model of price-aware cognitive decision making and mathematically formulation of theoptimization problem.4Chapter 2Background2.1 Resource ManagementA cost efficient cloud need to use fixed costs optimally and to discourage behavior that drives excessiveservice costs. Unlike traditional enterprises where leading cost is operational staff, the leading costof a cloud data center is servers and infrastructures, facilities dedicated to consistent power deliveryand evacuate heat [1]. Study shows that 45% of the amortized cost goes to servers and 25% of theamortized cost goes to infrastructure. So one of the goals of the cloud provider is to seek a high rateof return of its investment. Unfortunately, statistics show that server utilization is only at 10% [1].Low server utilization has many causes. Processing capacity is over-provisioned for many businessapplications to meet the Service Level Agreement (SLA) specifications in terms of appropriate levelof quality, availability, reliability and performance during peak demand periods. Also, to guaranteeapplication isolation, the traditional ad-hoc deployment of one application requires one application perunit of physical hardware [4]. Lots of server resources such as central processing unit (CPU), Memoryand storage unit are wasted during low demand periods. Furthermore, the networking costs concentratemainly in the networking gear (i.e. switches, routers and load balancers), network power consumptionand network traffics between geographically distributed data centers and the Internet Service Providers.Therefore, it is obvious that both achieving high server utilization and finding the optimal placementof data centers to deploy service applications have a role to play in achieving cost efficient cloud. Ourdynamic pricing methodology utilizes a resource allocation algorithm to determine how many VMseach user should receive according to their requests. In this section, we discuss resource allocationoptimizations which have been tackled from various perspectives.5Static and Dynamic Virtual Machine PlacementIn data centers that use static VM placement algorithms, a physical machine (PM) is chosen at thetime of VM creation with the knowledge of PM capacity and the resource requirements of the VM.The placement might not be rearranged until the PM is restarted [9]. On the other hand, dynamicplacement algorithms leverages the VM live migration capability to rearrange the VM placement inresponse of variations in traffic load, resource demand and unplanned downtime of a PM. The fact thatVM placement decisions are made with the knowledge of system status such as PM capacity and trafficload enabled our pricing methodology to calculate new unit prices according to real-time system load.SLA Violation Reduction Virtual Machine PlacementSLA violation reduction VM placement algorithm reduce SLA violations. SLA specifies not only levelof qualities of the cloud services that the cloud provider provisions, but also has additional constraintsregarding security, data availability or the physical location of the data storage. SLA is negotiatedbetween cloud providers and consumers [10]. A consumer may require that the VM cannot run on aPM that is located over-seas. A cloud provider may require that the resource demand does not overloadthe resource capacity by a probability of p. [4] proposed a dynamic VM placement algorithm thatminimizes the number of PMs required to provision the VMs subject to constraint of the probability ofserver overloading, which reduces the rate of SLA violations. It measures the time series and probabilitydistribution of VM’s CPU demand during the interval t. The CPU demand for the next interval of lengtht is predicted based on the historical demand during the prior interval of length t. VM placement or VMmigration decisions are then made based on the prediction. This algorithm fulfills the resource demandwith a probability.Another VM placement algorithm minimizes the number of resource utilized, SLA violations dueto the failure of allocating all VMs and the allocation time [11]. All PMs are organized in a binarysearch tree. Searching for a PM involves a binary search that would reduce the VM placement com-putation time. A VM scheduler calculates the ratio of requested VM specification to the available PMspecification for each PM in the binary tree until it finds the best fit (PM that has the maximum VM6specification to PM specification ratio smaller than 1). VM migration also requires the destination PMto have enough computation resources that could host the migrating VM. Therefore, migration domainis carefully defined and the placement service can associate different policies with different migrationdomains.A Constraint Programming optimization approach with a global utility function integrates both thedegree of SLA fulfillment and the operating costs [12]. The VM placement stage is separated from theVM provisioning stage within the global decision layer autonomic loop. Both problems are formulatedas Constraint Satisfaction Problems (CSP), as well as are instances of an non-deterministic polynomial-time hard (NP-hard) knapsack problem. Such an approach avoids the problems encountered by rule-and policy- based systems where conflicting objectives must be handled in an ad-hoc manner by theadministrator.Network-aware Virtual Machine PlacementOptimization of the network costs is another resource management optimization goal. In [5], a place-ment algorithm focused on minimizing communication cost among VMs is proposed. With one CPU/Memoryunit on a host is referred to as a slot, VM can be placed in any slots available. The algorithm first par-titions VMs into clusters using min-cut graph algorithm to ensure communicating VM pairs are parti-tioned into the same VM cluster. Available slots are partitioned with slot pairs with low-cost connectionsin the same slot cluster based on the cost matrix. Then, the algorithm uses Ci j to denote the communi-cation cost between slots i, j. Di j denotes the traffic rate from VM i to j. ei and gi denotes the externaltraffic for VM i and communication cost between VM i to the gateway. With the assumption that thereare n VMs and n slots, the goal of the algorithm is to find the permutation function that maps VMclusters with heavy communication traffic to slot clusters with low-cost connections.Network-aware VM placement can also focuses on network power reduction with consideration ofaccount network topology and network traffic [13]. The VM placement problem is formulated as a net-work flow problem using a weighted directed graph G = (V,E). Switches, PMs and client applicationsare modeled as a vertex v, an edge e represents communication links between PMs and switches. Thesource or destination of the flow network is one of VMs or client applications. An edge has a non-zero7flow only if the switches or PMs at both ends of the edge are powered on. The flow assignment on eachedge specifies the amount of traffic flow for every source-destination demand. Then the optimal VMplacement is found to be the shortest path in the flow network. The algorithm keeps iterate to select aVM placement requires minimum increase in network power as a locally optimal placement.With considerations of both constraints on local physical resources, such as CPU and Memory,and constraints on network resources evolving from complex network topologies and dynamic routingschemas, network-aware VM placement optimality problem is much more complex due to its quadraticnature and since it involves many factors beyond the physical host [14]. This problem strives to minimizethe maximum ratio of the demand and the capacity across all cuts in the network, in order to findplacement solutions that, by having spare capacity on each network cut, can absorb unpredicted trafficbursts. Since this problem is an NP-hard problem, the solving algorithm uses two novel heuristics,with diverse tradeoffs between solution quality and execution time. The first heuristic exploits integerprogramming techniques to solve the problem. It exploits the tree network structure to define and solvesmall problem instances on one-level trees recursively. Thus, each placement step, solved by a mixedinteger programming solver, has to deal with a reduced number of VMs, hosts, and network topologycuts. The second heuristic, which completely leaves out mathematical programming, consists of twomain phases: the first one ranks all the traffic demands, while the second one exploits the ranking toplace VMs on available hosts.2.2 Fairness in Resource ManagementAbove mentioned algorithms optimize resource allocation solely from the cloud providers’ perspective.Since the cloud is a resource pool with fixed capacity, competition of resources among users will arisein a demand burst. In this section, we discuss resource allocation techniques taking fairness among allusers as an optimization goal and the fairness-efficiency trade-offs.Hadoop Fair Scheduler and Quincy are slot-based fair scheduling falls in the category of AssetFairness, where each user receives equal share of resources 1. Unlike original Hadoop scheduler that put1http://hadoop.apache.org/docs/r2.7.0/hadoop-yarn/hadoop-yarn-site/FairScheduler.html8applications in a queue when the resource is fully occupied, the fair scheduler frees up resources for thenewly joined applications, so that each application in the system eventually occupies the same amountof resource.Considering the multi-resource nature of cloud platform, [15] introduced the idea of Dominant Re-source Fairness (DRF) to this area. DRF is a multi-resource allocation problem with the goal to equalizethe dominant share, which is the maximum ratio of any resource allocated to a user in the system, amongall cloud tenants. It is modeled as a max-min optimization problem and is shown to possess a numberof fairness properties such as sharing incentive, strategy-proofness, envy-freeness and Pareto efficiency.A higher system utilization is also promised compared to a slot-based fair scheduling and a max-minfair sharing algorithm that focuses on a single resource type [15]. Yet one limitation of DRF is that itsimplifies resources in a cloud computing system as resources in a super computer. It does not considerthe capacity limitation of each server and the fact that, after several VMs are placed in a server, theremaining resources of this server might not be sufficient to host other VMs. DRFH is proposed in [16],which generalizes DRF [15] by applying it to real cloud computing systems with heterogeneous servers.For resource competitions during a congested situation, [17] has indicated that it is unfair for aspecific user to be given a small amount of resources, or experiences a long service completion time.In the method proposed in this work, when submitting a task request, users are required to submita reduction ratio specifying how much the requested size of resource can be reduced in the case ofcongestion. Then, the system dynamically adjusts the resource allocation according to reduction ratiosfor each user when the resource utilization level is greater or equal to a predefined threshold. Simulationresults show that the proposed method achieves the fair allocation.Fairness-efficiency trade-offs were studied in [18] with multiple resource types. The authors definedpercentage efficiency as the percentage difference between the total number of jobs processed in a givenallocation and the maximum number of jobs that can be processed with the same capacity constraint,and the leftover capacity as the amount of unused resources. They proposed and evaluated two fair-ness functions for multi-resource allocations. Their evaluation results show that fairness functions beardifferent fairness-efficiency trade-offs.92.3 Price-based Demand ControlDespite all these effort spent on resource allocation of the cloud system, the resource over/under provi-sioning problem still cannot be solved since the demand is still unpredictable. The right pricing heavilyaffects customer behavior, customer commitment, and thus the organizations’ success [19]. Use pric-ing to guide user behavior toward a more efficient operating point has been shown to be a success inradio resource management, wireless networks [20] and the Internet [21]. In this section, we discussprice-based demand control.Demand Control with Dynamic-Rate PricingThe smart metering model proposed in [22] provides dynamic pricing of the cloud service based onthe load condition. The resource usage is metered and recorded. The customer’s historical utilizationstatistics are used to predict the load condition for the next time interval of operation and thus determinethe price. The price is then published on the cloud provider’s website so the customer could decidewhether to continue her usage.Pricing plan can be used to incentivize users to shift their usage from peak to off-peak periods byproviding lower prices in less-congested periods [21]. Authors have implemented a mobile applicationand invited 50 trial participants to evaluate their proposed model and user sensitivity to prices. Theyconclude that users did shift their traffic from high- to low- price periods.Auction game-based pricing model has also been studied for the cloud market. A double auctionbayesian game-based pricing model proposed in [23] provides the capacity for users to trade their left-over cloud resources. Both cloud resource providers and consumers form a double auction. Resourceallocation takes place when two sides make a deal at a certain price.Demand Control with Fairness-Aware PricingWhile the resources of an instance are dedicated to one cloud tenant, the cloud bandwidth is sharedamong all cloud tenants. Haiying et al. [24] introduced a pricing policy that focuses on preventing usersfrom competing for bandwidth at the cost of the data center or other users with current flat-rate pricing10models. Their pricing policy achieves network proportionality, which means that network resourcesallocated to tenants are proportional to their payments and thus achieves fairness between tenants. An-other work [25] considered the price competitions among different providers in the open market. Theytackled the cloud competition problem and proposed a non-cooperative game to investigate the pricecompetition among cloud providers and its impact on profit of all cloud providers, tenant satisfactionand final instance prices.2.4 Pricing Models of The Cloud ServiceIn this section, we discuss existing pricing models of the cloud service. For IaaS cloud, computinginfrastructures such as CPUs, storage and network are virtualized and provisioned to cloud tenants asInstances. Each cloud tenant simply requests Instances to run her applications or other services. Someexamples of IaaS are Amazon Elastic Compute Cloud (Amazon EC2) and Google Compute Engine [19].The flat rate pricing model is used by most of the cloud providers, such that cloud tenants are chargedaccording to the time of usage regardless of network congestions or system workload. Many researchershave proposed pricing models that provide dynamic rates to encourage cloud tenants to lease Instancesin a desired manner.Computational PricingSince our pricing methodology optimizes computational resources, in this section we discuss existingcomputational pricing of the cloud services. Reserved Instances: Amazon EC2 provides the option forcustomers to subscribe to its cloud service for one- or three-year periods with a non-refundable one-timepayment at a lower rate. Cloud tenants can use their reserved resources at anytime during the reservedperiod while Amazon ensures that the reserved resources are always available [26]. However, resourcesmay be wasted if the cloud tenant has reserved an instance, but for most of the time left it idle. Freemiumand Usage-based: To encourage potential cloud tenants to try their cloud services, both Amazon EC2and Google Compute Engine provide free but limited amount of resources for a limited time period.Once the actual usage exceeds the limits, usage-based pricing is generally applied. Usage-based pricing11is the most common pricing model for cloud services as it is elastic and charges a tenant based on theactual usage. A typical Google Compute Engine standard instance may contain 1 virtual core, 3.75GBmemory and charges in minute-level increments for the time that the cloud tenant runs her instance1.Amazon EC2 bills to the nearest server-hour or gigabyte-month [26]. Usage-based pricing allows usersto use the cloud service anytime without a long-term commitment, but the access to cloud service isnot always guaranteed. Financial Option: Sharma et al. [27] proposed a pricing model that employsthe financial option theory and Moore’s law. They treated the cloud computing commodities as assetsand mapped cloud parameters to the Black-Scholes-Merton Model. Moore’s law is used to describethe value of the resources in cloud. The price determined by their model is the optimal price the cloudprovider should charge the clients to recover its initial cost.Although flat-rate pricing is widely adopted by mobile, Internet and television service providers,[28] has shown that flat-rate pricing is optimal when the capacity or quantity of the expected sales isinfinite. On the other hand, the dynamic pricing method has shown its benefit when the capacity isfixed and unsold volume is worthless such as in the airline, hotel and electric utility industries [29].Spot Instances: Amazon provides its unsold cloud capacity as spot instances for customers to bid on.Amazon sets its spot prices through a market-driven auction and publishes its spot price for the nexttime period online so that customers can run those instances as long as their bids exceed the current spotprice. Spot Instance pricing allows Amazon to sell more of its unused resources at the highest possiblerate while preserving control over the spot price [30]. Unfortunately, for cloud tenants, spot instancesintroduce uncertainty to their access to the cloud service because they may be terminated at any time.Networking PricingDespite various types of pricing policies, almost all networking pricing models follow a principle thatcharge users’ Internet usage bidirectional with different standards2. In general, ingress is cheaper thanegress. Despite various types of pricing models, almost no pricing model comes with a performanceguarantee. Google advertises that its Google Compute Engine instances can achieve maximum perfor-2https://cloud.google.com/products/compute-engine/12mance, throughput and availability at low cost through its native load-balancing technology 3. However,what kind of maximum performance and how low the cost are not specified anywhere. The AmazonEC2 SLA specifies its service commitment of 99.95% availability 4. Yet no performance guarantee isincluded in the SLA.Storage PricingStorage pricing provided by various cloud services are relatively lower compared to computing andnetworking. Microsoft Azure 5 provides four types of storage, including block blobs, page blobs anddisks, tables and queues and files (in preview stage). It also has four redundancy levels, includinglocally redundant, zone redundant, geographically redundant and read-access geographically redundant.In addition to basic storage price, some cloud companies also charge users for data operations (request,delete, etc.) and data transfer, e.g., Amazon Simple Storage Service and Google Cloud Storage. In thiswork, we simply use network transmission to represent these additional cost applied to the storages.2.5 Service Recommendation SystemsBecause each cloud service provides different VM types and SLAs, selecting an appropriate cloud ser-vice for user applications may require some technical background. To ease up this process, some re-search works have been devoted to service recommendation systems [31][32][33]. Authors in [31]proposed a business-centric revenue-driven recommendation system that considers the appropriate rec-ommendation time, price and the number of repetitions when finding the optimal recommendation strat-egy to maximize the seller’s expected total revenue. In [32], authors proposed a recommendation systemfor IaaS Cloud applications based on analytic hierarchy process method. The proposed system automat-ically selects a cloud service that satisfies the required network Quality of Service (QoS) constraintson real-time basis. In [33] authors proposed a cloud service discovery system that automatically find acloud service according to user provided service query specified in pre-defined query structures.3https://cloud.google.com/products/compute-engine/4http://aws.amazon.com/ec2/sla/5https://azure.microsoft.com132.6 Cloud Federation SystemsThe term of cloud federation, or inter-cloud, the cloud of clouds, was first introduced by Kevin Kellyin 2007. The inter-cloud is analogous in the way the Internet works. An Internet service providerthat has an endpoint attached to it will access or deliver traffic from/to source/destination addressesoutside of its service area by using Internet routing protocols with other Internet service providers withpre-arranged exchange or peering relationships. The work [34] first proposed the inter-cloud blueprintto describe the high level architecture of the inter-operating of multiple clouds. With the concept ofinter-cloud, distributed software systems [35] explored a new application scenario. Federated cloudsystem helps to achieve better QoS, reliability and flexibility [36]. Authors in [37] proposed a cloudfederation system that provides profit-aware solutions in order to receive benefits from pricing policiesprovided by multiple clouds. Some of the other cloud federation systems are proposed for load balancingand distribution of elastic applications among different cloud data centers to achieve reasonable QoSlevels [38].Program DecompositionDecomposition of software program is breaking the system into small parts that are easy to maintain.The decomposition can be in terms of system functions as classes or objects and data entities. Programdecomposition, distributed storage and computation are the fundamental techniques for parallel com-puting, which is widely adopted as a solution in big data processing and complex computing [39]. Forexample, Hadoop decomposes data into chunks and distributes them among computer clusters. Then,based on the data each node contains, the Hadoop MapReduce sends appropriate program module toeach node to process data in parallel 6. [40] proposed a decomposition algorithm that decompose asequential program into speculatively parallel threads that can run on multi-processor chip, with consid-erations of data dependency and load imbalance. In [41], authors proposed a program decompositionframework that provides near-optimal mappings of program segments to machines with minimum-cost.Data elements needed for the program segments can be transferred among machines. The cost of exe-6https://en.wikipedia.org/wiki/Apache Hadoop14cuting a program segment depends on machine selections and associated data transfer costs.With decomposed and distributed programs, cognitive optimization of resource allocation is also anopen issue. Intrinsically as a group of dynamic partitioning problem, research on the dynamic parti-tioning between cloud and users’ mobile terminal has been conducted from the perspectives of offlineK-step approach [42] and flexible partitioning [43]. A similar idea has been used in [44], which hasdesigned and developed a cognitive platform that enables task migration and dynamic task allocationbetween the cloud server and the devices.Privacy Regulation Through Across-Clouds DistributionKeeping computing tasks that involve sensitive data in a private cloud and outsourcing the rest of com-puting tasks that involve insensitive data to public clouds is a preliminary solution for data privacyregulation. However, as more data-intensive computing tasks are required, this kind of hybrid cloudcomputing has became inappropriate. [45] proposed a Privacy-Aware Data Intensive Computing on Hy-brid Clouds that automatically splits data-intensive tasks according to security levels of the data. Theymodified MapReduce’s distributed file system to replicate data and send sanitized data to the publiccloud. Using multiple public clouds to ensure data security is also a popular solution. Faults in softwareor hardware in cloud computing are known as Byzantine faults. Many research work has been doneon Byzantine fault tolerance [46]. DepSky virtual storage cloud system [47] leverages the Byzantinequorum system protocols to ensure data security. The DepSky system is consisted of n clouds, while theDepSky system reads and write to each cloud separately. With intensive tests, experiences of working ona specific cloud and extraordinary positive user reviews, a cloud provider might be trustworthy. Besides,a series of redundant array of independent disks (RAID) of the cloud work [48] tackle the problem byencrypting and encoding the original data and later by distributing the fragments transparently acrossmultiple providers. This way, none of the storage vendors can see the full picture of the client’s data.15Chapter 3A Pricing Methodology for RevenueEnhancement3.1 The Pricing MethodologyAs discussed in Chapter 1, in this chapter, we propose a pricing methodology with dynamic pricing[49], which has been shown to be beneficial in many industries [29]. Under this methodology, an IaaScloud provider may charge different tenants different prices. Inspired by the principle of the Law ofSupply and Demand, we aim to use pricing to incentivize cloud tenants to use data center resourcesin a way that high utilization level is ensured. Given that the types of VMs and the number of VMsrequested by all active cloud tenants are known at any point in time, our pricing methodology leveragesa task scheduling algorithm to evaluate how many VMs each tenant should receive so that the systemutilization is maximized. Since the fewer resources allocated to a user by the task scheduling algorithmindicates that the system has more difficulty to place the user requested VM, we are motivated to raisethe prices of these users who overload the system. Thus, a pricing weight for each tenant is derivedaccording to the number of VMs allocated to the tenant. Finally, new prices are determined based onthe prices the cloud provider was charging originally and the weight derived in two methods: we studyour pricing methodology with Total Unit Price Redistribution (TUPR), where we sum up the unit pricescharged by a cloud provider originally and redistribute the charges among users according to the pricingweight, and Total Revenue Redistribution (TRR), where we sum up the revenue received by a cloudprovider originally and redistribute the charges among users according to the pricing weight.Moreover, we study our pricing methodology with two resource allocation algorithms. First, we16study our pricing methodology with Knapsack Algorithm, a combinatorial optimization algorithm thataims to maximize the total revenue and the server utilization level of a cloud data center. From thesimulation results we notice that some of the users may not be getting any resources and this is notfair. Therefore, we further study our pricing methodology with the DRF algorithm [15] where totalresources allocated to each cloud tenant is fair and resource utilization is higher compared to other fairsharing resource allocation algorithms [50]. As a result of price changes, requests for a specific type ofVM by existing or potential users are encouraged or discouraged according to the Law of Supply andDemand, so system optimal resource utilization and optimal usage behaviors are eventually achieved.From simulation results, we show that the total revenue a cloud provider receives is enhanced and overallfairness is archived among users through simulations. The proposed pricing methodology follows apay-as-you-go pricing model. It suits the fundamental characteristics of the cloud as an on-demand andusage-based service. The proposed pricing methodology is transparent and truthful because it takes thetotal allocable resources into consideration so that any manipulation from the backend such as resourcethrottling or capacity right-sizing is reflected in the new prices. Unlike the Spot Instance [30], ourproposed pricing methodology does not produce service termination. Also, instead of setting the priceto the highest possible rate, the prices generated by our pricing methodology are determined by lookingat the utilization of system resources.3.1.1 MethodologyAs mentioned above, the main motivation of this work is leveraging pricing policy to manipulate userbehavior, for the purpose of increasing system resource utilization. Figure 3.1 is a sequence diagramthat demonstrates the working mechanism of the proposed Fairness-aware Pricing Methodology. Usersrequest VMs with known current prices of VM types. Then, upon the arrival of a new user’s VM request,task scheduling algorithms are executed to dynamically allocate cloud resources, subject to the cloudserver’s existing tasks and available resources. The algorithm not only determines how easily the VMcould be hosted, but also decides on which server the VM is to be placed. While the user’s requestis being fulfilled, the real-time cloud information, including incoming VM settings and current cloudworkload, are updated to the decision making module that implements our proposed pricing model. The17new price is generated accordingly after the allocation decision. With the new prices, existing usersreact by increasing or decreasing their usage percentage of the cloud service. Once the user reactionsare submitted to our system, the algorithm starts again from the beginning as a new loop. Also, potentialusers may decide to start to use the cloud service. This procedure continues as the users’ demandsfluctuate. It is apparent that a decision making module that predicts users’ reaction to future pricesand subsequently adjusts prices to achieve predefined optimization goals is the key of our methodology.Details are described in following sections.Figure 3.1: Sequence Diagram for Fairness-aware Pricing3.2 Problem FormulationWith the pricing methodology proposed in the last section, a number of open issues remain to be ad-dressed before the methodology can be put in practice. For instance, on which server or servers shouldthe cloud system place the requested VMs? How would pricing affect users’ demands? How to deter-mine the price, in order to enhance the revenue? In this section, we discuss these issues.We define the input variables as shown in Table 3.1. Suppose the set of servers S, resource types Srand resource capacity vector cl are known for each server l. Also suppose the set of cloud tenants U ,resource vector of their desired types of VM Di and the number of VMs users initially requested Ts are18known.S = {1, . . . ,k} Set of servers the cloud system contains.Sr = {1, . . . ,m} Resource types each server contains.cl = {cl1, . . . ,clm} Normalized resource capacity vector for each serverl, where clr denotes the total amount of resource ravailable in server l.U = {1, . . . ,n} Set of cloud tenants active in the cloud system.Di = {Di1, . . . ,Dim} Resource vector of the VM requested by user i,where Dir denotes the fraction of resource r requiredby user i’s VM.Ts = {Ts1 , . . . ,Tsn} The number of VMs submitted to the system by alltenants, where Tsi denotes the number of VMs sub-mitted by user i.Table 3.1: Definition of Input Variables3.2.1 Price SensitivityOur pricing methodology leverages the concept of price sensitivity to model user reaction to the newprice generated by our pricing model. In a competitive market, price sensitivity defines the highest pricea customer would pay for the desired product and the lowest price a customer would pay without secondthought of the product quality [51][52]. As the most powerful tool to marketers, price sensitivity iswell studied when setting the price of a new product to maximize the demand of the product and thebusiness outcome [53]. For a majority of the buyers, the price is not only a key factor that will influencetheir purchase decisions, but also an indicator for them to perceive product or service quality. The pricethreshold that captures consumer insensitivity to small price changes was examined in [53]. Harmonet al. [51] studied the Price Sensitivity Measurement (PSM) model and incorporated it into the Value-Based Software Engineering (VBSE) process. PSM check is used twice during the VBSE process to firstrefine customer value assessment of the potential product and then help in finalizing the development ofa marketing plan prior to commercialization. Moreover, the Law of Supply and Demand suggests thatthe availability and desirability of a product has a great effect on the product price [54]. If the supply19is sufficient but the demand is low, the price will be low. In contrast, if the supply is inadequate butthe demand is high, the price will be high. Then, given that all other factors are equal, the demand ofthe good or service decreases as the price increases7. The demand curve of a commodity is downwardsloped as shown in Figure 3.2. However, to the best of our knowledge, the specific demand curves ofcloud services have not been well studied.Figure 3.2: Commodity Demand CurveSince the supply and demand functions of the cloud service as the price changes has not been wellstudied, in this work, we utilize an iso-elastic demand function to model how the level of user demandchanges as price changes [55]fR(p) = (1/p)(1/α),α ∈ (0,1)α =1log1/p fR(p)(3.1)where α is the elasticity coefficient and fR(p) represents the demand.In this work, a higher demand level indicates an increasing need of cloud VMs.7http://www.investopedia.com/terms/l/lawofdemand.asp203.2.2 Cloud Task SchedulingOne of the most important steps of our proposed pricing methodology is to determine how easily a VMcan be handled by the cloud. The computing resources provided by the cloud consist of heterogeneousservers where each server may contain a different amount of resources. Hence, the allocation of variousforthcoming VM requests onto the distributed servers in the cloud is of great importance for the overallsystem efficiency. In this work, we utilize resource allocation algorithms that maximizes the cloudserver utilization level to help us determine how should the user requests of VM should be addressed.Namely, given the number of VMs each user has initially requested, Tsi , we determine Tni , the numberof VMs each user is allocated in the cloud system by a cloud task scheduling algorithm.3.2.3 Revenue EnhancementOne of the goals of our proposed pricing methodology is to enhance the revenue for cloud serviceproviders. According to the Law of Supply and Demand, given that other factors such as advertisement,brand preferences, product differentiation and segment membership are kept the same, the quantitydemanded and the price of a commodity are inversely related [51]. For simplicity, letwi =1Tni∑i∈U 1Tni,∀i ∈U (3.2)where w = {w1, . . . ,wn} denote the weights assigned to n tenants.Revenue Enhancement with Total Unit Price RedistributionTo calculate our new prices of a VM, we first study the case in which we keep the total unit price ofall users the same and redistribute the sum among users according to the weights. To be specific, thenew price for each user i is calculated according to the weight of user i and the price the cloud providercharges each tenant. For example, a typical Google Compute Engine standard instance may contain1 virtual core, 3.75GB memory and charges in minute-level increments for the time the cloud tenantruns her instance at $0.07/hour1. Let Pe = {Pe1 , . . . ,Pen} denote the prices the cloud provider charges ntenants and Pd = {Pd1 , . . . ,Pdn} denote the new prices generated by our pricing model for the n tenants,21then,Pdi = wi×∑i∈UPei ,∀i ∈U. (3.3)Algorithm 1 Pricing Calculator for user i with Total Unit Price Redistribution1: Set Pesum ← 02: Get Tni ← TaskSchedulingAlgorithm3: for n = 1 to N do4: wi←1Tni∑i∈U 1Tni5: Pesum ← Pesum +Pei6: end for7: Pdi ← wi×PesumThe algorithm for calculating unit prices for user i is shown in Algorithm 1.Revenue Enhancement with Total Revenue RedistributionNext, we study the case in which we keep the total revenue of all users the same and redistribute the sumamong users according to the weights, given the number of VMs that can be scheduled for each user byDRFH. To be specific, the revenue generated by user i, Rei , is calculated asRei = Tni×Pei ,∀i ∈U. (3.4)New unit price Pd = {Pd1 , . . . ,Pdn} is calculated asPdi =wi×∑i∈U ReiTni,∀i ∈U. (3.5)Algorithm 2 Pricing Calculator for user i with Total Revenue Redistribution1: Set Pesum ← 02: Get Tni ← TaskSchedulingAlgorithm3: for n = 1 to N do4: wi←1Ni(Ai)∑i∈U 1Ni(Ai)5: Resum ← Resum +Pei ×Ni(Ai)6: end for7: Pdi ← wi×PesumNi(Ai)The algorithm for calculating unit prices for user i is shown in Algorithm 2.22Reactive Revenue CalculationThen, given Pei known, the total revenue Re a cloud provider receives is calculated asRe = ∑i∈UTsi×Pei ,∀i ∈U. (3.6)User elasticity is determined through the demand functionTsi = fR(Pei),∀i ∈U. (3.7)We input the same user demand vectors and system resource vectors into our pricing model to obtainthe new prices Pdi . Then, we use the demand function again to derive the number of VMs users wouldrequest after they receive the new prices, denotes as T ′siT ′si = fR(Pdi),∀i ∈U. (3.8)All users’ VM requests T ′si are scheduled using first-in-first-out (FIFO) scheduling again. Let T′ni bethe number of VMs each user is allocated. The total revenue Rd a cloud provider receives with the newprices is calculated asRd = ∑i∈UT ′ni×Pdi ,∀i ∈U. (3.9)From (3.1) and (3.9) we deduce thatRd = ∑i∈U(1/Pdi)(1/α−1),α ∈ (0,1). (3.10)When Pdi is smaller than 1, the revenue generated by our pricing methodology decreases as α in-creases. In contrast, when Pdi is larger than 1, the revenue generated by our pricing methodology in-creases as α increases.233.3 Case Study on Knapsack Combinatorial OptimizationCombinatorial optimization optimizes the total value of the items that could fit in a container with fixedvolume. Knapsack problem is a popular combinatorial optimization problem widely applied in resourceallocation and cost-benefits analysis where there are financial constraints exist [56][57]. Thus, in thissection, we study our proposed pricing methodology with knapsack allocation algorithm.3.3.1 Knapsack ProblemIn general knapsack problem, given a set of n items, each item with a weight ki and value vi, and alsogiven the maximum weight K of the container, the knapsack problem determines the number of itemsthat can be put into the container with the optimization goal of maximizing the total value of the items.When applying knapsack problem into resource allocation of cloud data center with resource capacityvector c, given Tsi VMs requested by cloud tenant i, each VM with a resource vector Di and price Pei ,the optimization goal is to maximize the total revenue of a cloud provider given the amount of resourcesuser requested VMs contain, the prices of each VM and the total resource available in the cloud datacenter.0-1 Knapsack Problem0-1 knapsack constraints that each type of the VM requested by user i is allocated on cloud servers withno repetition. The mathematical expression of the 0-1 knapsack problem is,maximizen∑i=1PeiTnisubject ton∑i=1DiTni ≤ c,Tni ∈ (0,1).(3.11)24Bounded Knapsack ProblemBounded knapsack problem allows multiple but limited VMs requested by user i to be allocated on cloudservers. Let Tsi denotes the maximum number of VM each VM type i that user requests, then,maximizen∑i=1PeiTnisubject ton∑i=1DiTni ≤ c,Tni ∈ (0, . . . ,Tsi).(3.12)Unbounded Knapsack ProblemUnbounded knapsack problem allows unlimited VMs requested by user i to be allocated on cloudservers. Thus, the problem is formulated as,maximizen∑i=1PiTnisubject ton∑i=1DiTni ≤ c,Tni ≥ 0.(3.13)3.3.2 Knapsack-based Revenue EnhancementSince there are possibilities that different users would require the same VM, or the same user wouldrequire multiple VMs of the same type, we study our pricing methodology with bounded knapsackproblem. The mathematical formulation of pricing weight is,wi =1Tni∑i∈U 1Tni,∀i ∈U (3.14)Knapsack-based Revenue Enhancement with Total Unit Price RedistributionThe calculation of Pdi is straight forward,Pdi = wi×∑i∈UPei ,∀i ∈U. (3.15)25Knapsack-based Revenue Enhancement with Total Revenue RedistributionWith the number of VM that is allocated for each user i, the calculation of Pdi is as follows,Rei = Tni×Pei ,∀i ∈U. (3.16)New unit price Pd = {Pd1 , . . . ,Pdn} is calculated asPdi =wi×∑i∈U Reixi,∀i ∈U. (3.17)3.3.3 SimulationsIn order to evaluate the proposed pricing methodology, we conduct experiments to compare the totalrevenue our pricing model produces with the total revenue a pricing model with flat-rate unit price wouldproduce. We use actual Google Compute Engine VM types to model our cloud system. To be specific,we assume a cloud provider with unified resource formulated as <CPU,Memory >, where Memory isrepresented in terms of gigabyte (GB) and four users each requesting a VM with resource formulatedin terms of <CPU,Memory >. We compare the revenue of our pricing model with the revenue a cloudprovider would receive with Google Compute Engine unit prices. New prices are generated once arequest of VM has arrived at the system. Then, user responses to the new prices are modeled accordingto the demand function described in Section 3.2.1. Finally, the revenue of our pricing model is calculatedas the product of the new unit prices and users’ final decision of the amount of the VMs they request.Furthermore, we compare the change of user requests with our new unit prices to evaluate the abilityof demand control of our proposed pricing methodology. The numeric data used in the simulations islisted in Table 3.2 and Table 3.3 .Table 3.2: System Resource Vector for Knapsack-based Revenue EnhancementTotal Resource < 40CPU,180GB >From Table 3.3 we observe that User A requested VM is small so while it is easy to be allocated26Table 3.3: User Demand Vector and Prices of Google Compute EngineUser A < 1CPU,3.75GB > $ 0.045/hourUser B < 4CPU,3.6GB > $ 0.112/hourUser C < 2CPU,7.5GB > $ 0.089/hourUser D < 4CPU,15GB > $ 0.177/hourusing resource fragments, it also would fragmentize server resources. User B requested VM is CPUintensive. It would quickly use up server CPUs but left too much Memory. User C requested VM ismedium sized which is easier to be allocated than User D requested VM but also easier to fragmentizeserver resources.Simulation for Knapsack-based Revenue Enhancement with Total Unit Price RedistributionIn Figure 3.3, we compare the revenue our pricing methodology generates with alpha set to 0.5 to 0.9.The revenue decreases as the alpha value increases. The overall revenue is higher comparing to therevenue generated with Google Compute Engine unit prices.0 5 10 15 20 25 30 35 400.40.60.811.21.41.61.82 Sum of VM requested by all usersRevenue ($/hour) Existing RevenueNew Revenue with Alpha = 0.5New Revenue with Alpha = 0.6New Revenue with Alpha = 0.7New Revenue with Alpha = 0.8New Revenue with Alpha = 0.9Figure 3.3: Comparison of Revenues with Different Alpha ValuesIn Table 3.4 we show the new unit prices our pricing methodology produces. The unit price of theVM User A requested is raised by 17.8% and the unit price of User B requested VM is raised by 135.7%27Table 3.4: New Unit Prices Compared To Google Compute Engine Unit PricesVM Type Number ofVMsRequestedGooglePricesNew Prices< 1CPU,3.75GB > 5 $ 0.045/hour $ 0.053/hour< 4CPU,3.6GB > 5 $ 0.112/hour $ 0.264/hour< 2CPU,7.5GB > 5 $ 0.089/hour $ 0.053/hour< 4CPU,15GB > 5 $ 0.177/hour $ 0.053/hourto discourage User A and, especially, User B from requesting resources. The unit price of the VM UserC requests is lowered by 40.4% while the unit price of the VM User D requested is lowered by 70% toencourage User C and D to request more resources.0 5 10 15 20 25 30 35 400510152025 Sum of requested VM by all usersNumber of VMs Requested User A Request With Existing Unit PriceUser A Request With New Unit PriceUser B Request With New Unit PriceUser C Request With New Unit PriceUser D Request With New Unit PriceFigure 3.4: Comparison of Requests Generated by Each UserIn Figure 3.4, we compare the change of user requests with our new unit prices of the types of VMsused in example with α set to 0.9. To maximize the total revenue and the server utilization level, acloud provider needs to sell as much VMs as possible. The VM User B requests is the least encouragedaccording to the knapsack algorithm because the CPU would quickly be used up if User B requeststoo much. Therefore, from the simulation result, the number of VMs User B requests as a response to28our new unit prices is changed to 0 eventually. Also, since the VM User D requested is large, User D isstarting to be discouraged to request resources as the server is fully utilized and the sum of requested VMby all users goes to 40. On the other hand, the VM User C requests is the most encouraged accordingto knapsack algorithm. So the number of VMs User C requests as a response to our new unit prices isincreased the most.0 5 10 15 20 25 30 35 4001234567 Sum of requested VM by all usersNumber of VMs Consolidated User A Allocated VMs With Existing Unit PriceUser A Allocated VMs With New Unit PriceUser B Allocated VMs With Existing Unit PriceUser B Allocated VMs With New Unit PriceUser C Allocated VMs With Existing Unit PriceUser C Allocated VMs With New Unit PriceUser D Allocated VMs With Existing Unit PriceUser D Allocated VMs With New Unit PriceFigure 3.5: Comparison of Allocated Virtual Machines for Each UserIn Figure 3.5 and Figure 3.6, we further show the change of allocated VMs for each user and comparethe revenue each user generates with our new unit prices. The result show to correctness of our pricingmethodology since it indeed controlled user demand in a way that Knapsack Algorithm suggests.290 5 10 15 20 25 30 35 4000.20.40.60.811.21.4 Sum of VM requested by all usersRevenue ($/hour) User A Existing RevenueUser A New RevenueUser B Existing RevenueUser B New RevenueUser C Existing RevenueUser C New RevenueUser D Existing RevenueUser D New RevenueFigure 3.6: Comparison of Revenues Generated by Each UserSimulation for Knapsack-based Revenue Enhancement with Total Revenue RedistributionIn Figure 3.7, we compare the revenue our pricing methodology generates with alpha set to 0.5 to 0.9.The revenue decreases as the alpha value increases. The overall revenue is higher comparing to therevenue generated with Google Compute Engine unit prices.0 5 10 15 20 25 30 35 4000.511.522.53 Sum of VM requested by all usersRevenue ($/hour) Existing RevenueNew Revenue with Alpha = 0.5New Revenue with Alpha = 0.6New Revenue with Alpha = 0.7New Revenue with Alpha = 0.8New Revenue with Alpha =0.9Figure 3.7: Comparison of Revenues with Different Alpha ValuesIn Table 3.5 we compare the new unit price our pricing methodology produces with the existing unitprices the Google Compute Engine charges. User A, C, and D are encouraged to request more resources30Table 3.5: New Unit Prices Compared To Google Compute Engine Unit PricesVM Type Number ofVMsRequestedGooglePricesNew Prices< 1CPU,3.75GB > 5 $ 0.045/hour $ 0.042/hour< 4CPU,3.6GB > 5 $ 0.112/hour $ 1.042/hour< 2CPU,7.5GB > 5 $ 0.089/hour $ 0.042/hour< 4CPU,15GB > 5 $ 0.177/hour $ 0.042/hoursince the unit price User A requested is lowered by 6.7%, the unit price User C requested is loweredby 52.8% and the unit price User D requested is lowered by 76.3%. The unit price User B requested israised by 803.3% to discourage User B from requesting resources.0 5 10 15 20 25 30 35 40051015202530354045 Sum of requested VM by all usersNumber of VMs Requested Request With Existing Unit PriceUser A Request With New Unit PriceUser B Request With New Unit PriceUser C Request With New Unit PriceUser D Request With New Unit PriceFigure 3.8: Comparison of Requests Generated by Each UserIn Figure 3.8, we compare the change of user requests. Same as the simulation results of TUPR,User B is the least encouraged to request VM, so the number of VMs User B requests is graduallychanged to 0. User D is discouraged to request VM as the sum requested VM by all users goes to 40.User C is most encouraged to request VM, so the number of VMs user C requests increased the most.310 5 10 15 20 25 30 35 40012345678910 Sum of requested VM by all usersNumber of VMs Consolidated User A Allocated VMs With Existing Unit PriceUser A Allocated VMs With New Unit PriceUser B Allocated VMs With Existing Unit PriceUser B Allocated VMs With New Unit PriceUser C Allocated VMs With Existing Unit PriceUser C Allocated VMs With New Unit PriceUser D Allocated VMs With Existing Unit PriceUser D Allocated VMs With New Unit PriceFigure 3.9: Comparison of Allocated Virtual Machines for Each UserIn Figure 3.9 and Figure 3.10, we compare the change of allocated Virtual Machines of each userwith our new unit prices and the revenue each user generates with our new unit prices. The resultsshows that our pricing methodology is able to control demand according to the suggestion of Knapsackalgorithm.0 5 10 15 20 25 30 35 4000.20.40.60.811.21.4 Sum of VM requested by all usersRevenue ($/hour) User A Existing RevenueUser A New RevenueUser B Existing RevenueUser B New RevenueUser C Existing RevenueUser C New RevenueUser D Existing RevenueUser D New RevenueFigure 3.10: Comparison of Revenues Generated by Each User323.3.4 Discussion of Knapsack-based Revenue EnhancementThe knapsack problem maximizes the total revenue for the cloud provider. However, it does not considerfairness among users. Some of the desirable fairness properties are sharing incentive that guaranteesthat no user is better off in a system where resources are equally partitioned among all users; strategy-proofness, where no user can be better off by providing untruthful resource demands; Pareto-efficiency,where user requests are allocated without preempting existing allocations; envy-freeness, where no userprefers the allocation of another user [15]. From the simulation results, we can see that eventuallyUser B will not be able to use any of the cloud resources. We claim that it is not fair for User B.However, as discussed in previous chapter, the fairness-efficiency trade-off is also an important factorfor any algorithms or methodologies that tries to achieve fairness. How to find an acceptable thresholdhas become an interesting question. To this end, we study our pricing methodology with the DRFHalgorithm, which is proved to be able to achieve fairness and a higher system utilization than several fairschedulers in next section.3.4 Case Study on DRFH FairnessIn [16], authors have proved that the DRFH allocation algorithm achieves significant improvements inresource utilization, compared to the traditional slot scheduler (e.g., Hadoop Fair Scheduler). Thus, inthis section, we study our proposed pricing methodology with DRFH allocation algorithm.3.4.1 DRFH SchedulingDRFH takes the set of heterogeneous servers S, server resource types (e.g., CPU, Memory, storage) Srand normalized resource capacity vector for each server l, cl , as one input and takes the set of cloudtenants U and resource vector of demanded VM Di as another input. Let r∗i be the largest resourcerequired by user i’s VM, then the normalized demand of user i’s VM is calculated asdir = Dir/Dir∗i ,∀i ∈U,r ∈ R. (3.18)33For example, consider a system with 2 servers, Server 1 with 2 CPUs, 12GB Memory and Server 2 with12 CPUs, 2GB Memory. The system has 14 CPUs, 14GB Memory in total. Thus, Server 1 and Server 2have normalized resource capacity vectors < 1/7,6/7 > and < 6/7,1/7 >, respectively. Suppose thereare two users. User1 requests VMs with 0.1 CPUs and 0.5GB Memory. User2 requests VMs with 1CPU and 0.2GB Memory. User1 and User2 have normalized demand vectors < 1/5,1 >, < 1,1/5 >,respectively.Let Ail = {Ail1, . . . ,Ailm} be the resource allocation vector for user i on server l, Ai = {Ai1, . . . ,Aik} bethe allocation matrix of user i and A = {A1, . . . ,An} be the overall allocation for all users. An allocationis feasible only if no server has used more resources than its total resources∑Ailr ≤ clr,∀l ∈ S,r ∈ R. (3.19)Let Nil(Ail) be the maximum number of VMs that can be scheduled for user i in server l and Dir bethe fraction of the total resource r required by user i, then,Nil(Ail) = minr∈R{Ailr/Dir},∀l ∈ S,r ∈ R. (3.20)Let Ni(Ai) be the total number of VMs that can be scheduled for user i under allocation Ai, then,Ni(Ai) =∑l∈SNil(Ail). (3.21)The dominant resource allocated to user i in server l isGil(Ail) = Nil(Ail)Dir∗i = minr∈R{Ailr/dir}. (3.22)Therefore, the global dominant share allocated to user i isGi(Ai) =∑l∈SGil(Ail) =∑l∈Sminr∈R{Ailr/dir}. (3.23)The goal of DRFH is to maximize the minimum global dominant share among all users, subject to34the capacity constraints of each server,maxAmini∈UGi(Ai),s.t.∑Ailr ≤ clr,∀l ∈ S,r ∈ R. (3.24)DRFH allocates resource to the user with the minimum global dominant share among all activeusers. When a user has all its VMs placed in a server, it is removed from the user set U and DRFHrepeats the allocation process with the updated user set.3.4.2 DRFH-based Revenue EnhancementAs introduced in Section 3.2.3, the pricing weight calculation for DRFH-based revenue enhancementmethodology iswi =1Ni(Ai)∑i∈U 1Ni(Ai),∀i ∈U (3.25)DRFH-based Revenue Enhancement with Total Unit Price RedistributionThe calculation of Pdi isPdi = wi×∑i∈UPei ,∀i ∈U. (3.26)DRFH-based Revenue Enhancement with Total Revenue RedistributionNext, the calculation of Pdi for TRR isRei = Ni(Ai)×Pei ,∀i ∈U. (3.27)New unit price Pd = {Pd1 , . . . ,Pdn} is calculated asPdi =wi×∑i∈U ReiNi(Ai),∀i ∈U. (3.28)353.4.3 DRFH-based FairnessIn [15], authors showed that unlike the fair division mechanism Competitive Equilibrium from EqualIncomes [58], which does not satisfy strategy-proofness and population monotonicity, and Asset Fair-ness, which does not satisfy sharing incentive and bottleneck fairness, DRF satisfies sharing incentive,strategy-proofness, envy-freeness, Pareto-efficiency, single resource fairness, bottleneck fairness andpopulation monotonicity at the mean time. In [16], authors proved by deduction that DRFH, as an ex-tension of DRF, satisfies strategy-proofness, envy-freeness, Pareto-efficiency, single resource fairness,bottleneck fairness and population monotonicity as the DRF does. Furthermore, authors in [16] showedthrough the trace-driven evaluation that although DRFH does not guarantee 100% sharing incentive forall users, it provides 98% of users the same task completion ratio as traditional Slots schedulers do.Since the calculation of our new prices is inversely proportional to the number of tasks DRFH algorithmcan schedule for a user, our proposed pricing methodology satisfies the same fairness properties asDRFH. That is, our proposed pricing methodology provides sharing incentive for most of the users; it isstrategy-proof, envy-free and Pareto-efficient, and satisfies single resource fairness, bottleneck fairnessand population monotonicity.For the same example described previously, suppose a cloud provider charges for one VM with 0.1CPU and 0.5GB RAM at $0.6/hour and one VM with 1 CPU and 0.2 GB RAM at $1.2/hour. Alsoassume each user requests an infinite number of VMs. DRFH allocates 12 VMs to user1 and 6 VMs touser2. The new prices are calculated as $0.4/hour and $1.6/hour for user1 and user2, respectively.Personal Fairness Since by Personal Fairness [59], most users would expect that a VM consistingof smaller resources is cheaper than a VM that consists of larger resources, the new prices of $0.4/hourfor a 0.1 CPU and 0.5GB RAM VM and $1.6/hour for a 1 CPU and 0.2 GB RAM VM indicate personalfairness of our pricing model.Social Fairness Social fairness means that the provider does not profit unreasonably and the priceonly increases based on the increase of costs. Since server capacity is limited, one VM with a largeramount of resources allocated in a server could use up a large portion of the server’s resources and theremaining resources might not be sufficient for allocation to other users’ VMs. Therefore, a VM with36larger amount of resources is more costly to allocate. Our new prices are inversely proportional to thenumber of VMs a user receives. With the goal of DRFH allocation algorithm to equalize the share ofresources among all active users, fewer VMs allocated indicates the type of VM requested consists oflarger amount of resources. VM with larger amount of resources is more costly to allocate, so it shouldbe charged more. Comparing to the original prices, the decrease in user1’s price and increase in user2’sprice indicate social fairness of our pricing model.3.4.4 SimulationsIn order to evaluate the proposed fairness-aware pricing methodology, we conduct experiments to com-pare the total revenue our pricing model produces with the total revenue a pricing model with flat-rateunit price would produce. To be specific, in numerical evaluations, we use actual Google ComputeEngine VM types to model our cloud system. We compare the revenue of our pricing model with therevenue a cloud provider would receive with Google Compute Engine unit prices. In the trace-drivenevaluation, we use the sum of CPU and memory of each requesting VM as the unit price of this VM.Then, we compare the revenue of our pricing model with the revenue a cloud provider would receivewith the calculated unit prices. New prices are generated once a request of VM has arrived at the sys-tem. Then, user responds to the new prices are modeled according to the demand function describedin Section 3.2.1. Finally, the revenue of our pricing model is calculated as the product of the new unitprices and users’ final decision of the amount of the VMs they request.Numerical SimulationsIn this section, we demonstrate the efficiency of our algorithm with numerical simulations with 2types of computing resources, including CPU units and Memory. A cloud service provider with 2servers is hosting 4 users’ applications simultaneously. We formulate the servers’ resource as a vector< CPU,Memory >, represented in GB, and all users’ request as a resource vector < CPU,Memory >and corresponding unit prices from Google Compute Engine. These numeric data are listed in Table 3.6and Table 3.7, respectively. We use FIFO scheduling to simulate the process of VM allocation and atthe end of scheduling process, get the actual number of VMs each user could receive.37Table 3.6: System Resource VectorServer 1 < 27CPU,50GB >Server 2 < 13CPU,50GB >Total Resource < 40CPU,100GB >Table 3.7: User Demand Vector and Prices of Google Compute EngineUser A < 1CPU,3.75GB > $ 0.07/hourUser B < 4CPU,3.6GB > $ 0.176/hourUser C < 2CPU,7.5GB > $ 0.14/hourUser D < 4CPU,15GB > $ 0.28/hourDRFH-based Revenue Enhancement with Total Unit Price Redistribution0 5 10 15 20 25 30 35 400.811.21.41.61.822.2 Sum of VM requested by all usersRevenue ($/hour) Existing RevenueNew Revenue with Alpha = 0.5New Revenue with Alpha = 0.6New Revenue with Alpha = 0.7New Revenue with Alpha = 0.8New Revenue with Alpha = 0.9Figure 3.11: Comparison of Revenues Generated by Existing and Proposed Pricing ModelFigure 3.11 illustrates the comparison of revenues achieved with unit prices of Google Compute En-gine and proposed policies with α set to 0.5, 0,6, 0.7, 0.8 and 0.9. Revenues converge as the systemresource is fully occupied at which the sum of VM requested by all users is approximately 15. Sincethe unit prices are smaller than 1, the revenue with a smaller α value is greater than the revenue with38a larger α value, as depicted in Section 3.2.1. Overall, new revenue generated by our proposed pricingmethodology is higher than the existing revenue calculated with unit prices of Google Compute Engine.Table 3.8: New Unit Prices Compared to Google Compute Engine Unit PricesVM Type Number ofVMsRequestedGooglePricesNew Prices< 1CPU,3.75GB > 5 $ 0.07/hour $ 0.097/hour< 4CPU,3.6GB > 5 $ 0.176/hour $ 0.162/hour< 2CPU,7.5GB > 5 $ 0.14/hour $ 0.162/hour< 4CPU,15GB > 5 $ 0.28/hour $ 0.244/hourIn Table 3.8 , we compare our new unit prices of each user with Google Compute Engine unit pricesfor the types of VMs used in the example with each user requesting 5 VMs of their desired type. Theunit price of the VM User A requested is raise by 38.6% and the unit price of VM User C requested israised by 15.7%, where as the unit price of VM User B requested is lowered by 8.0% and the unit priceof VM User D requested is lowered by 12.9%. The VM with < 1CPU,3.75GB > that User A requestedrequires the smallest portion of resources so that it is easy to be placed on a server. Therefore, the unitprice of VM < 1CPU,3.75GB > is the lowest. On the other hand, the VM with < 4CPU,15GB > thatUser D requires the largest portions of resources so that it is hard to be placed on a server. Hence, thenew price of this type of VM is the highest.390 5 10 15 20 25 30 35 400246810121416 Sum of requested VM by all usersNumber of VMs Requested Request With Existing Unit PriceUser A Request With New Unit PriceUser B Request With New Unit PriceUser C Request With New Unit PriceUser D Request With New Unit PriceFigure 3.12: Comparison of Requests Generated by Each UserIn Figure 3.12, we compare the change of user requests of our new unit prices of the types of VMsused in the example with α set to 0.9. The VM with < 1CPU,3.75GB > is charged at the lowest price;therefore, the number of VMs User A requests is increased the most. On the other hand, the VM with< 4CPU,15GB > is charged at the highest price; therefore, as a respond to the price increases, User Drequests less and less VMs.0 5 10 15 20 25 30 35 4011.522.533.54 Sum of requested VM by all usersNumber of VMs Consolidated User A Allocated VMs With Existing Unit PriceUser A Allocated VMs With New Unit PriceUser B Allocated VMs With Existing Unit PriceUser B Allocated VMs With New Unit PriceUser C Allocated VMs With Existing Unit PriceUser C Allocated VMs With New Unit PriceUser D Allocated VMs With Existing Unit PriceUser D Allocated VMs With New Unit PriceFigure 3.13: Comparison of Allocated Virtual Machines for Each User400 5 10 15 20 25 30 35 4000.10.20.30.40.50.60.70.80.9 Sum of VM requested by all usersRevenue ($/hour) User A Existing RevenueUser A New RevenueUser B Existing RevenueUser B New RevenueUser C Existing RevenueUser C New RevenueUser D Existing RevenueUser D New RevenueFigure 3.14: Comparison of Revenues Generated by Each UserIn Figure 3.13, we show the number of VMs allocated on a server for each user with our new unitprices with α set to 0.9. In Figure 3.14, we compare the revenue generated by each user with ournew unit prices of the types of VMs used in the example with α set to 0.9. Compared to the revenueachieved with Google Compute Engine unit prices, the results show that revenues generated with ourpricing methodology by users B and D are decreased, whereas the revenues generated by users A andC are increased. Still, with our pricing methodology, the greatest revenue is generated by user D as itrequires the type of VM that is most difficult to handle; the next greatest revenue is generated by user C,and then user B and user A, which indicates personal and social fairness.41DRFH-based Revenue Enhancement with Total Revenue Redistribution0 5 10 15 20 25 30 35 400.511.522.533.5 Sum of VM requested by all usersRevenue ($/hour) Existing RevenueNew Revenue With Alpha = 0.5New Revenue with Alpha = 0.6New Revenue with Alpha = 0.7New Revenue with Alpha = 0.8New Revenue with Alpha = 0.9Figure 3.15: Comparison of Revenues Generated by Existing and Proposed Pricing ModelFigure 3.15 illustrates the comparison of revenues achieved with unit prices of Google Compute Engineand proposed policies with α set from 0.5 to 0.9. Revenues converge as the system resource is fullyoccupied. Again, the revenue with α = 0.5 is greater than the revenue with α = 0.9. Overall, newrevenue generated by our pricing methodology is higher than the revenue calculated with the existingunit prices of Google Compute Engine.Table 3.9: New Unit Prices Compared To Google Compute Engine Unit PricesVM Type Number ofVMsGooglePricesNew Prices< 1CPU,3.75GB > 5 $ 0.07/hour $ 0.054/hour< 4CPU,3.6GB > 5 $ 0.176/hour $ 0.151/hour< 2CPU,7.5GB > 5 $ 0.14/hour $ 0.151/hour< 4CPU,15GB > 5 $ 0.28/hour $ 0.34/hourIn Table 3.9, we compare the unit prices generated for each user’s requested VM type with the unitprices provided by Google Compute Engine. The unit price of VM User A requested is lowered by4222.9% and the unit price of VM User B requested is lowered by 14.2%, where as the unit price of VMUser C requested is raised by 7.9% and the unit price of VM User D requested is raised by 21.4%.0 5 10 15 20 25 30 35 400510152025303540 Sum of requested VM by all usersNumber of VMs Requested User A Request With Existing Unit PriceUser A Request With New Unit PriceUser B Request With New Unit PriceUser C Request With New Unit PriceUser D Request With New Unit PriceFigure 3.16: Comparison of Requests Generated by Each User0 5 10 15 20 25 30 35 4011.522.533.54 Sum of requested VM by all usersNumber of VMs Consolidated User A Allocated VMs With Existing Unit PriceUser A Allocated VMs With New Unit PriceUser B Allocated VMs With Existing Unit PriceUser B Allocated VMs With New Unit PriceUser C Allocated VMs With Existing Unit PriceUser C Allocated VMs With New Unit PriceUser D Allocated VMs With Existing Unit PriceUser D Allocated VMs With New Unit PriceFigure 3.17: Comparison of Allocated Virtual Machines for Each UserIn Figure 3.16, we compare the requests submitted to the cloud system by each user with the existingand new unit prices. All users are able to request for resource. As the sum of requested VM by all usersgoes to 40, the number of VMs User A requests is increased the most and the number of VMs User Drequests is decreased the most.43In Figure 3.17 we show the differences of the number of requested VMs allocated for each user withthe existing and new unit prices. In Figure 3.18, we compare the revenue generated by each user withα set to 0.9. The results show that, compared to the revenue achieved with Google Compute Engineunit prices, the revenues generated by users A and B are decreased with our new unit prices, whereasrevenues generated by users C and D are increased with our new unit prices. Furthermore, the greatestrevenue is generated by user D as it requires the type of VM that is most difficult to handle; the nextgreatest revenue is generated by user C, and then user B and user A, which indicates personal and socialfairness.0 5 10 15 20 25 30 35 4000.20.40.60.811.21.4 Sum of VM requested by all usersRevenue ($/hour) User A Existing RevenueUser A New RevenueUser B Existing RevenueUser B New RevenueUser C Existing RevenueUser C New RevenueUser D Existing RevenueUser D New RevenueFigure 3.18: Comparison of Revenues Generated by Each UserTrace-driven SimulationsIn this section, we evaluate our proposed pricing methodology with empirical data from Google cluster-usage traces8. The traces contain user resource requests and system resource information for about amonth-long period in May 2011. We extract the system resource vector (S and Sr), set of active cloudtenants (U), resource vector of the VM requested by the ith user (di), and the number of VM requestssubmitted (Tsi) from the traces. Since server resources provided in Google cluster-usage traces arenormalized to the largest server resource, the actual Google Compute Engine price of the requested type8https://code.google.com/p/googleclusterdata/44of VM is hard to determine. Thus, we assume that originally the cloud provider charges $1 per CPU perhour and $1 per GB Memory per hour, where both CPU and Memory are normalized numbers extractedfrom Google cluster-usage traces. For example, a server with normalized 0.5 CPU and 1 GB Memoryis originally charged at $1.5 per hour.As described in Section 3.2.1, elasticity coefficient α is the decisive parameter for market reaction.However, the values of α are different from user to user, subject to distinct application domain andvarious motivations. To simulate a reasonable scenario, the elasticity coefficient α is derived by dynamiccalculations with price and demand settings in our experiments. Specifically, the value of α is calculatedby the following equation for our trace-driven simulations:α =1log1/p fR(p). (3.29)DRFH-based Revenue Enhancement with Total Unit Price Redistribution0 0.5 1 1.5 2 2.5 3x 101000.20.40.60.811.21.41.61.82x 104Time(microsecond)Revenue ($) Existing RevenueNew Revenue with Total Unit Price RedistributionFigure 3.19: Comparison Between Existing and Proposed Pricing ModelThe trace-driven simulation results for total unit price redistribution are depicted in Figure 3.19. Therevenue of the cloud provider is calculated according the user demands extracted from the traces and theassumed original unit prices from Google Compute Engine and unit prices generated by our proposedpricing methodology. The user demands vary throughout the monitoring period, so does the cloud45provider’s revenue, which ranges from around $0 to around $15000. From the results we observe thatour proposal outperforms existing pricing policy in most of the time slots. Cumulatively, the cloudservice providers’ overall revenue can be increased from $2173700 to $2426000, which is by up to11.60%.0 0.5 1 1.5 2 2.5 3x 101000.511.522.5x 104Time(microsecond)Revenue ($/hour) Existing RevenueNew Revenue with Total Revenue RedistributionFigure 3.20: Comparison Between Existing and Proposed Pricing ModelDRFH-based Revenue Enhancement with Total Revenue RedistributionIn contrast, we also conducted evaluations for the pricing of total revenue redistribution. From the resultsshown in Figure 3.20, we observe that the cloud service provider derives more revenue with the novelpricing solution, comparing to existing flat pricing approach. The overall revenue increased significantlyfrom $2172800 to $2415600, which is around 11.18%.3.5 SummaryIn this chapter, we have proposed a pricing methodology that induces the optimal resource demandpattern and enhances the revenue of cloud providers. New prices are determined according to the numberof tasks a user could get scheduled by the cloud task scheduling algorithm. A user whose task is difficultfor the system to process is discouraged from being submitted to the system as frequently as other users’46tasks that can be handled easily. Our new prices are calculated with TUPR and TRR. Then, we havestudied our methodology with the Knapsack Algorithm and DRFH allocation algorithm. Numericalsimulations have been conducted to compare the total revenue a cloud provider would receive withthe new unit prices generated by our pricing methodology in both of the cases to the total revenuea cloud provider would receive with its original prices. Simulation results have also shown that ourpricing methodology is able to control demand according to the allocation algorithms’ suggestions.An empirical study with trace-driven simulation results has shown that the proposed pricing policy withDRFH algorithm can increase the cloud service providers’ overall revenue by up to 11.60% and 11.18%,respectively.47Chapter 4A Price-Aware Cloud Federation System4.1 The Price-Aware Cloud Federation SystemOur pricing methodology proposed in Chapter 3 requires users to constantly pay attentions to the currentprices the cloud providers charge. This may be a shortcoming for our pricing methodology to be accept-able or useful. Furthermore, since the cloud is the best effort service, many organizations are afraid torely on a third-party cloud service to ensure the organizations’ service availability and business continu-ity. Another concern relates to data security, confidentiality and auditability [60]. Crackers and hackershave never stopped their efforts on attacking information systems to steal users’ virtual properties. Sincethe access is public, cloud exposes their systems to more public attacks than conventional data centers.On the other hand, users cannot easily extract their data and programs from one cloud service to an-other. When a cloud data center crushes, users can hardly move their data to another data center ontime. Plenty of research works are devoted to investigate secured and robust cloud service infrastruc-tures. All of these obstacles can be removed by using services from a cloud federation or inter-cloud[8] system that supports distributed cloud services where one cloud could use the computational, stor-age or network resources of other clouds [61] to complete a task together [62]. Similar to cloud-RAID[48], better privacy protection can be achieved if users were able to control on which clouds the highlysensitive software classes or objects are hosted and distribute the rest of system function codes on otherclouds. This way, no public cloud provider could acquire all the program pieces. With programs anddata scattered among and backed-up by different data centers maintained by different cloud providers,also with the automated service choosing and program/data sets migration ability, the cloud service andour proposed pricing methodology are more reliable and convincible for users to adopt.As discussed in Chapter 1, in this chapter, we propose a price-aware cloud federation system in-48tended to provide a tool for users to automatically choose and migrate their applications to a cloudprovider that is charging at a more acceptable rate. Further, we take the advantage of program decom-position techniques, where a large program system can be broken down into system functions as smallerclasses or objects and data entities9. In this chapter, we assume user applications can be decomposedinto program and data sets, each set can run on a VM as a task. Our cloud federation system allows usersto configure the privacy constraints of their program by defining the number of program or data sets thatcould be hold in one cloud service concurrently. The system looks up current prices a cloud providercharges for their VM at a pre-defined time interval. Then, each of the program and data sets can beassigned to a cloud service charging at the lowest rate according to the privacy constraints. The cost ofrunning the program or data set at the destination service, along with the cost of migrating the programor data sets to the destination service are considered before the migration decision is made. As a price-aware cognitive system, the proposed platform collects pricing information from multiple clouds anddynamically adapts its execution modality on purpose of minimizing total cost. This dynamic adaptionseeks optimal assignment of codes and data sets of user decomposed application, which is a procedurethat uses the update-to-date prices to predict future trend of cost and eventually lead to a lower pricedsolution. Hence, it is also a user-oriented system that benefits its customers financially.4.1.1 System OverviewArchitectureThe architectural framework of the cloud federation system is shown in Figure 4.1. The platform con-catenates multiple cloud services to provide a unified inter-cloud environment. Essentially, it is a three-layer software system: application layer (consists of the code layer and the data set layer), platform layerand cloud infrastructure layer, from top to bottom. As the middle-ware between the cloud infrastruc-ture and application layer, the cloud federation platform monitors the real-time pricing from differentproviders and cognitively adjust the decomposed program and data sets of user applications to minimizethe overall price.9https://en.wikipedia.org/wiki/Decomposition49Figure 4.1: Architectural Framework for Cognitive Cloud Federation SystemCode DefinitionWe define c program codes in set C and d data chunks in set D as illustrated as ovals and rectangles inFigure 4.1. We also define s cloud service providers S. Note that some cloud server hosts both codeand data set, while some of the others only supports either code or data set. Considering the code-datarelationship between program codes and data chunks, we define that a program code can be associatedwith 0 to d data chunks, while a data chunk can be accessed by 0 to c program codes. Furthermore,we consider the code-data relationship as a directed graph G, where the directed edges are the data flowfrom data chunks to the program codes, the weights of the edges are the data size to be transmitted. Ingeneral, a program code only require a small proportion of data in the data chunk. In this chapter, wedenote ω as the data access proportion. Note that if a program code and its associated data chunk arelocated in different cloud server, an inter-cloud data transmission is required.Code MigrationOne of the key features of our inter-cloud system is the capability of program and data set migrationsamong multiple cloud services on demand. A mobile agent is a composition of computer software anddata that is able to migrate from one cloud to another autonomously and continue its execution at thedestination [63][64]. In our cloud federation system, once a better task and cloud assignment solution is50found, designated program codes or data chunks can be encapsulated into mobile agents and dispatchedto the destination cloud.Inter-Cloud Message ExchangeIn order to facilitate the work flow of user task, the program codes need to communicate with eachother through messages, including native context states, processed data and control signals. Since theprogram codes are executed in a distributed manner among multiple clouds and a single code can behosted in different clouds under different circumstances, a message exchanges between two code setscan be either local invocations (e.g., when the two code sets are hosted in the same cloud) or remote calls(e.g., when the two code sets are executed in different clouds). Hence, a dynamic message forwardingmechanism that determines the source and destination of a message is needed in the cognitive cloudfederation system.Platform DesignFigure 4.2: Design of Decomposed Cloud Federation PlatformThe cloud federation system introduces challenges including decomposition granularity, responselatency, synchronization frequency and application programming interface design. In order to facili-tate the proposed architectural framework, we design the cognitive cloud federation platform with bothprivacy and pricing awareness as shown in Figure 4.2.51Similar to the concept of Master Node and Slave Node implemented in the Hadoop10 system, theproposed platform incorporates Cognitive Node and Element Node to facilitate the cognitive feature. ACognitive Node is the core of the whole network, which is hosted in a secured cloud infrastructure, e.g.,a private cloud. The Price-Aware Cognitive Engine collects the pricing data from Element Nodes inpre-defined time interval and makes cognitive decisions to optimize the program/data set and the cloudassignment. Note that both Cognitive Node and Element Node contain a Message Coordinator, whichserves as the router for inter-code message exchange. The Price-Aware Cognitive Engine’s decisionprovides message routing information, which is broadcasted by the Cognitive Node to all Element Nodesspreading in multiple clouds.4.2 Problem FormulationIn this section, we mathematically formulate the cloud federation system. For a particular user applica-tion, we denote the number of available cloud service providers as cs, the number of program codes aspc, and the number of data chunks as dc.4.2.1 Program FeatureWe model the code-data relationship as a 1−n,{n = 0,1,2,3..,dc} pair, which means a program codecan access 0 to dc data chunks distributed in various cloud servers. We formulate the code-data relation-ship as pc×dc logical matrix L, in which the numeric value of elements are defined to be either 0 or 1.Hence, Li j = 1 indicates that the ith program code requires data chunk j for its procedure. In addition,we denote the message exchange between code as a pc× pc matrix M, where Mi j indicates the messagedata size between the ith and the jth program codes.4.2.2 Dynamic PricingWith the assumption that each cloud service is charging with dynamic prices, we denote instance pricesfor the cs cloud providers in vectors Pα and Pβ with length of cs, where Pα represents the unit com-10http://hadoop.apache.org/52putational resource prices and Pβ represents the unit data storage prices, respectively. In addition, wedenote the network prices for the cs cloud providers as Pρ and Pθ , representing the unit input and outputbandwidth prices.4.2.3 Assignment of Codes and Data SetsA key of the system design is to determine the assignment of program codes and data chunks. Weformulate the assignment of program codes over cloud services as a pc× cs matrix Bp. It is defined asa logical matrix, where Bpi j = 1 represents that the ith code is executed at the jth cloud service. Similarto code assignment, we define a dc× cs logical matrix Bd to formulate the assignment of data chunksover cloud services. Bdi j = 1 indicates that the ith data chunk is stored at the jth cloud service.4.2.4 Assignment ConstraintsSoftware IntegrityIn order to guarantee the completeness of the software system, every program code and data set chunkis required to be assigned to either one or more cloud services. In order to simplify our model, we onlyconsider the case that no duplicate exists in this work. Therefore, the constraints on software integritycan be described by the following equations:n∑j=1Bpi j = 1,∀i ∈ Bpi j (4.1)where Bpi j represents whether the ith code is executed at the jth cloud service.n∑j=1Bdi j = 1,∀i ∈ Bdi j (4.2)where Bdi j represents whether the ith data chunk is stored at the jth cloud service.53Privacy AssurancePrivacy assurance involves a series of techniques and SLAs, which constrain the access of sensitivedata. With strict privacy requirements, some sensitive data even need to be stored in cloud serverswithin certain geographical areas. For instance, some health care data cannot be transferred outside theUS territory, according to specific laws and legislations. In this chapter, we demonstrate the privacy of asoftware system by a set of privacy levels T heta and Phi, which represent the privacy restriction on theassignment of program codes and data chunks, respectively. The value of privacy level T heta,Θ∈ [1,c],is defined as the maximum quantity of program codes allowed to be hosted in the same cloud. Similarly,Phi, Φ ∈ [1,d], constrains the coexistence of multiple data sets for a specific cloud service. In either ofΘ or Φ, a value 1 represents that all program codes or data chunks shall be distributed among differentclouds, while the values of pc and dc provide complete freedom for assigning the program codes anddata chunks. Thus, the smaller Θ and Φ are, the higher privacy level is assured. With these definitions,we derive the constraints of privacy assurance as follows:n∑i=1Bpi j ≤Θ,∀ j ∈ Bpi j (4.3)where Bpi j represents whether the ith code is executed at the jth cloud service.n∑i=1Bdi j ≤Φ,∀ j ∈ Bdi j (4.4)where Bdi j represents whether the ith data chunk is stored at the jth cloud service.Apparently, privacy and pricing represent a pair of trade-off that the software users shall be awareof.544.2.5 Price CalculationComputing PriceAccording to above formulations, the total computing price Pc is derived as follows:Pc = FTp BpPα (4.5)where FTp is the transpose of the pc×1 program code set Fp, Bp is the pc× cs matrix representingthe assignments program codes and cloud services and Pα is the cs× 1 vector of unit computationalresource prices.Storage PriceAccording to above formulations, the total storage price Ps is derived as follows:Ps = FTd BdPβ (4.6)where FTd is the transpose of the dc×1 data chunk set Fd , Bd is the dc× cs matrix representing theassignments data chunks and cloud services and Pβ is the cs×1 vector of unit data storage prices.Networking PriceWith the data access proportion ωd , we first derive the cs× cs data networking volume matrix Vr infollowing algorithm:Algorithm 3 Data Networking Matrix Algorithm1: Initiate a cs× cs all 0 matrix Vr2: for each (i, j) in Li j == 1 do3: for each (x,y) satisfies Bpix == 1 and Bd jy == 1 do4: if x!=y then5: Vryx ← ωdFdy6: end if7: end for8: end for55According to the above formulations, the total inbound bandwidth price Pi is derived as follows:Pi = ||VrPρ ||1 (4.7)where Vr is a cs× cs matrix representing the networking volume between cs cloud services when apiece of data is read from one cloud service and Pρ is the cs×1 vector of unit input bandwidth prices.||.||1 is the l1 norm.while the total outbound bandwidth price Po is derived as follows:Po = ||V Tr Pθ ||1 (4.8)where V Tr is the transpose of the cs× cs matrix representing the networking volume between cscloud services when a piece of data is read from one cloud service and Pθ is the cs× 1 vector of unitoutput bandwidth prices. ||.||1 is the l1 norm.Also, we derive the cs× cs message networking volume matrix Vm as follows:Algorithm 4 Message Networking Matrix Algorithm1: Initiate a cs× cs all 0 matrix Vm2: for each (i, j) in Mi j! = 0 do3: for each (x,y) satisfies Bpix == 1 and Bp jy == 1 do4: if x!=y then5: Vmxy ←Mi j6: end if7: end for8: end forAccording to the above formulations, the total message inbound bandwidth price Qi is derived asfollows:Qi = ||VmPρ ||1 (4.9)where Vm is a cs× cs matrix representing the networking volume between cs cloud services in caseof inter-cloud message exchange and Pρ is the cs×1 vector of unit input bandwidth prices. ||.||1 is thel1 norm.56while the total message outbound bandwidth price Qo is derived as follows:Qo = ||V Tm Pθ ||1 (4.10)where V Tm is the transpose of the cs×cs matrix representing the networking volume between cs cloudservices in case of inter-cloud message exchange and Pθ is the cs× 1 vector of unit output bandwidthprices. ||.||1 is the l1 norm.Therefore, the overall network price Pn is derived asPn = Pi+Po+Qi+Qo (4.11)Total PriceHence, we derive the total price P of the cloud federation system:P = Pc+Ps+Pn (4.12)4.2.6 State-Transition CostWhen the price changes, the cognitive system needs to adapt to the new optimal solution. However,the transition between two assignment states involves network transmissions. Since the package size ofa program code is relatively insignificant comparing to the size of a data chunk, we only consider thenetworking volume produced by the migration of data chunks. Given the current dc× cs data chunkassignment matrix Bd at the total price of P, we assume that with an up-to-date pricing status, theproposed system optimizes and derives a set of new dc× cs data chunk assignment matrix B′d with newtotal price P′. The network volume of state-transition dc× cs matrix Vs can be derived by the followingequations:Vs = B′d−Bd (4.13)57Here we derive the inbound matrix I, a d× s logical matrix, byIi j =Vsi j , Vsi j > 00, otherwise(4.14)where Vsi j represents the ith data chunk state transition cost.According to the calculation procedure, a non-zero element Ii j indicates a network input of the ithdata chunk to the jth cloud in the state-transition from Bd to B′d .Similarly, we derive the outbound matrix O, a d× s logical matrix, byOi j =−Vsi j , −Vsi j > 00, otherwise(4.15)where Oi j indicates a network output of the ith data chunk to the jth cloud in the state-transitionfrom Bd to B′dHence, the total inbound bandwidth price Ri is derived as follows:Ri = FTd IPρ (4.16)where Fd is the transpose of the dc× 1 data chunk set Fd , I is the dc× cs matrix representing theinbound network volume and Pρ is the cs×1 vector of input bandwidth prices.while the total outbound bandwidth price Ro is derived as follows:Ro = FTd OPθ (4.17)where FTd is the transpose of the dc×1 data chunk set Fd , O is the dc× cs matrix representing theoutbound network volume and Pθ is the cs×1 vector of output bandwidth prices.58Therefore, the state-transition pricing R can be derived by:R = Ri+Ro (4.18)4.2.7 Optimization TargetIn the starting stage of the system, the price-aware feature requires the system to seek an optimal com-bination of program code assignments Fp and data chunk assignments Fd that minimizes the overall costaccording to a given prices. Hence, the optimization target is formulated as follows:Minimize: P(Fp,Fd)Subject to: (4.1)(4.2)(4.3)(4.4)(4.19)Once the system is launched, to maintain the price-aware performance, the cognitive engine needsto make decisions to adjust the assignments of program codes and data chunks, according to the real-time pricing fluctuation. It is a continuous process that keeps the assignment up-to-date with dynamicprices. Note that, this procedure does not only simply seeking for the lowest prices, but also need totake the state-transition cost into consideration. With the assumption that pricing policy for all cloudswill last for a time interval t, the system is able to make decisions by calculating the overall cost withcurrent price P and new minimal price P′ with the state-transition price R. Hence, the objective functionis constructed as:Minimize: R+P′(Fp,Fd)tSubject to: R+P′(Fp,Fd)t < P(Fp,Fd)t(4.1)(4.2)(4.3)(4.4)(4.20)4.3 SimulationsTo validate the performance of our proposed system and the efficiency of optimization approach, weconduct simulations from the perspectives of pricing optimization and cognitive price-aware transition.594.3.1 Simulation SetupTable 4.1: Default Simulation Parameters for Cognitive Cloud Federation Systemcloud service provider cs 10code quantity pc 8data set quantity dc 8code-data relationship probability p 0.1computational requirement C (GB) 1 ∼ 30size of data sets Fd (GB) 1024 ∼ 10240size of message exchange M (GB) 0 ∼ 0.1data access proportion ωd 1×10−5minimum computing pricing Pα 0.0073∼ 0.0089maximum computing pricing Pα 0.036∼ 0.044minimum storage pricing Pβ 0.000032∼ 0.000040maximum storage pricing Pβ 0.000050∼ 0.000062minimum inbound network pricing Pρ 0.0011∼ 0.0013maximum inbound network pricing Pρ 0.0019∼ 0.0023minimum outbound network pricing Pθ 0.11∼ 0.13maximum outbound network pricing Pθ 0.19∼ 0.23code and data set privacy level (Θ,Φ) (4,4)This section describes the initial settings for our simulations. For user applications to be deployedover our cognitive cloud federation system, we specify the quantities of codes and data sets, while initiatetheir code-data relationship by randomly generating non-zero values for all elements in the matrix Lwith a probability of p. For the prices from different cloud service providers, we set up random valuesfor minimum and maximum prices for a specific service and simulate the dynamic prices within theintervals. Note that the prices of computational resource is given by dollars per unit per hour, the pricesof storage space is given by dollars per GB per hour and the prices of network is given by dollars perGB. From existing commercial cloud service pricing policies, the initial values for parameters of thesimulations are set in Table 4.1. Note that, all random parameters follow uniform distributions.604.3.2 Pricing OptimizationWe first simulate the starting stage of the system to demonstrate the efficiency of seeking an optimalassignment with the lowest cloud service fee. In addition to our proposed optimization approach, wealso compare the cloud service cost with our cloud federation system with the conventional Single-Cloudsolution, which selects the cloud with lowest total service fee to host all codes and data sets.Data Set Privacy Level1 2 3 4 5 6 7 8Cloud Service Fee ($)3.23.43.63.844.24.44.64.85Single-CloudΘ = 1Θ = 2Θ = 4Θ = 6Θ = 8Figure 4.3: Tradeoff between Security Level and Cloud Service FeeFigure 4.3 reveals the trade-off between privacy regulation and pricing optimization. We derive thecloud service fee for various combinations of privacy levels in codes and data sets. It is obvious that asthe privacy level increases, either in codes Θ or in data sets Φ, the total cloud service fee grows. Thisrequires the user to choose from different privacy levels based on various requirements. According toour experimental settings, the proposed cognitive optimization can only outperform the Single-Cloudsystem with Θ= 6 and Φ> 6.One of the most important features of our cloud federation system is the data-code relationships.Figure 4.4 shows its impact on the cloud service fee. We increase the probability of code-data rela-tionship, p, to illustrates its impact on cloud service fee. Note that, along with the growth of p from0 to 1, the cloud service fees for distinct combinations of Θ and Φ all linearly raised to a higher level.Apparently, these increases are caused by additional inter-cloud data transmissions from data chunks610 0.2 0.4 0.6 0.8 12.533.544.55Component−Data Relationship Probability pCloud Service Fee ($) Single−CloudΘ = 1, Φ = 1Θ = 4, Φ = 4Θ = 8, Φ = 8Figure 4.4: Effect of Data-Code Relationship on the Cloud Service Feeto program codes. Similar comparison on Θ and Φ combinations are also conducted. As depicted, ifwe select the highest privacy level with Θ = 1 and Φ = 1, the cloud service fee is higher than that ofSingle-Cloud within the range of 30%∼ 46%. In contrast, the setting of lowest privacy level with Θ= 8and Φ= 8 will save the users’ cost by 3%∼ 20%.10−6 10−5 10−4 10−32.533.544.555.56Data Access Proportion ωCloud Service Fee ($) Single−CloudΘ = 1, Φ = 1Θ = 4, Φ = 4Θ = 8, Φ = 8Figure 4.5: Effect of Data Access Proportion on the Cloud Service FeeAnother critical feature that impacts the cloud service cost is the data access proportion ωd . As62shown in Figure 4.5, we evaluate the system performance with various values of ωd . Apparently, alarger ωd yields a higher volume of data transmissions between multiple clouds, which results in ahigher cloud service fee. Note that the cost for highest privacy level with Θ= 1 and Φ= 1 dramaticallyclimbs to 6 dollars. The growth rate is relatively higher than other schemes. This is because the highestprivacy level restricts the program codes and data chunks to be completely distributed, and thus thesolution space for price-aware optimization is much smaller than others.4.3.3 Cognitive Price-Aware TransitionAfter the establishment of the optimal assignment solution, we perform simulations over time to evaluatethe platform’s cognitive capability to the dynamic prices. With the initial privacy level setting at Θ= 4and Φ= 4, we compare the cost of three deployment methodologies: Single-Cloud: to host all programcodes and data chunks in the lowest-cost cloud and never change deployment over time, Optimal-Static:to find the optimal program codes and data chunks assignments initially and never change deploymentover time, and Optimal-Cognitive: to be cognitive to the dynamic prices of multiple clouds and keepoptimizing deployment assignment over time.100 101 1021.61.71.81.922.12.22.32.42.52.6 x 104Pricing Period (hours)Total Price ($) Single−CloudOptimal−StaticOptimal−DynamicFigure 4.6: Efficiency of Proposed Platform with Pricing Variety Time IntervalAccording to our discussion before, the length of price change time interval will impact the state63transition decisions. In our formulation, the optimization target in state transition involves the pricechange time interval t, which implies that longer time interval will make the cost in state transitionworthy. Therefore, we expect to see a decrease in total cost with a longer interval in our simulations.Figure 4.6 illustrates the results of our experimental settings with value of t ranging from 1 hour to 100hours. In contrary to the total cost of Single-Cloud and Optimal-Static methodologies, we observe adecline in the service cost of the Optimal-Cognitive scheme. In a nutshell, the performance of proposeddynamic optimization is not severely impacted by the frequency of price fluctuation. This phenomenonindicates that the occurrence of state-transition in our simulations rarely involves inter-cloud transfer ofdata chunks, which will instead significantly increase the cost of state-transition.0 10 20 30 40 500123456Time Elapsed (hours)Instant Cloud Service Fee ($) Single−CloudOptimal−StaticOptimal−CognitiveFigure 4.7: Efficiency of Proposed Platform with Time ElapsedGiven price change time interval t = 1, Figure 4.7 illustrates the average cloud service cost over50 hours for 100 random iterations. In the first hour, Optimal-Static and Optimal-Cognitive share thesame assignment for program codes and data chunks. So they share identical costs. Afterwards, sincethe Single-Cloud and Optimal-Static schemes are not cognitive to the price fluctuations of clouds, theirperformances become worse as time progresses. In contrast, the Optimal-Cognitive scheme dynamicallyadapts new strategies for different pricing combination, thus yields an around 30% reduction on totalcloud service cost.644.4 SummaryIn this chapter, to make our dynamic pricing methodology more user friendly, we have investigated aprice-aware cloud federation system that automatically chooses and cognitively migrates user tasks to acloud provider charging at a more affordable rate as a reaction to dynamic prices. With the ability of mi-grating to a lower-rated cloud service, our cloud federation system provides a lower priced solution thatbenefits its customers financially. We have mathematically formulated and derived optimal solutions inboth first-stage pricing minimization and cognitive strategy. Preliminary numeric results have revealedthe trade-off between privacy and cost. Simulation results have also demonstrated the efficiency of theproposed system in reducing total cloud service cost while considering privacy constraints.65Chapter 5Conclusion5.1 Summary of ContributionsThis thesis has tackled resource management of the cloud system through demand control using dy-namic prices. Low server utilization problem cloud providers encountered today has numerous causes,including uneven application fit where the application cannot fully utilize allocated resources and theuncertainty in demand forecasts that requires the cloud system always need to be prepared for the de-mand burst during peak period. Many research works have been devoted to optimize resource allocationfrom different perspectives. In this thesis, we have introduced a new approach of using dynamic pricingto control aggregate demand to avoid resource over/under provisioning and achieve a higher profitabil-ity. Then, to free users from paying close attentions to the frequent changing prices and make real-timerequest decisions themselves, we have introduced a framework of a price-aware cloud federation systemthat automatically chooses and cognitively reacts to the dynamic prices and migrate user tasks that ischarging at an affordable rate.In Chapter 3 we have studied our pricing methodology with resource allocation techniques Knapsackalgorithm and DRFH fair sharing algorithm. We have verified the correctness of our pricing methodol-ogy and simulation results have shown that the proposed pricing methodology is able to control demandas the resource allocation algorithm suggests.In Chapter 4 we have formulated the price-aware cognitive decision making problem mathemati-cally for our cloud federation system. We have demonstrated the feasibility and efficiency of the cloudfederation system with in-depth simulations.665.2 Future DirectionsFor potential extensions of the current work, we suggest to let users define the maximum prices theywould accept for using a cloud service. Then, instead of responding to every price changes, the cloudfederation system only need to reassess the cost of new code/data set assignment when the price exceedsthe maximum prices. Also, we suggest to explore a more sophisticated system that allows redundantpresence of data chunks and parallel codes over multiple clouds. With the duplicated copies, the cloudfederation system will be more robust and reliable. Given the new setting, the pricing optimization pro-cedure will a become more complicated system since the system ought to select the appropriate pieceof program codes or data chunks from redundant identical copies. Note that, the information redun-dancy provides potential reduction in networking costs as it decreases the opportunity of intra-cloudtransmission between program codes and data chunks. On the other hand, this redundancy introducesstorage overheads to the system, which also raises the cost of storage spaces. Therefore, a well-designedmechanism that leverages this trade-off is needed.67Bibliography[1] A. Greenberg, J. Hamilton, D.A. Maltz, and P. Patel, “The cost of a cloud: Research problems indata center networks,” SIGCOMM Comput. Commun. Rev., vol. 39, no. 1, pp. 68–73, Dec. 2008.[2] C. Weinhardt, A. Anandasivam, B. Blau, N. Borissov, T. Meinl, W. Michalk, and J. Ster, “Cloudcomputing-a classification, business models, and research directions,” Business & InformationSystems Engineering, vol. 1, no. 5, pp. 391–399, 2009.[3] T. Nagle, J. Hogan, and J. Zale, The Strategy and Tactics of Pricing, vol. 1, Prentic Hall, UnitedStates, fifth edition, 2010.[4] N. Bobroff, A. Kochut, and K. Beaty, “Dynamic placement of virtual machines for managingsla violations,” in Integrated Network Management, 2007. IM ’07. 10th IFIP/IEEE InternationalSymposium on, May 2007, pp. 119–128.[5] X. Meng, V. Pappas, and L. Zhang, “Improving the scalability of data center networks with traffic-aware virtual machine placement,” in INFOCOM, 2010 Proceedings IEEE, March 2010, pp. 1–9.[6] M.A. Sharkh, M. Jammal, A. Shami, and A. Ouda, “Resource allocation in a network-based cloudcomputing environment: design challenges,” Communications Magazine, IEEE, vol. 51, no. 11,pp. 46–52, November 2013.[7] H. Zhang, C. Jiang, N.C. Beaulieu, X. Chu, X. Wang, and T.Q.S. Quek, “Resource allocationfor cognitive small cell networks: A cooperative bargaining game theoretic approach,” WirelessCommunications, IEEE Transactions on, vol. 14, no. 6, pp. 3481–3493, June 2015.[8] D. Bernstein, D. Vij, and S. Diamond, “An intercloud cloud computing economy - technology,68governance, and market blueprints,” in SRII Global Conference (SRII), 2011 Annual, March 2011,pp. 293–299.[9] C. Hyser, B. Mckee, R. Gardner, and B.J. Watson, “Autonomic virtual machine placement in thedata center,” Hewlett Packard Laboratories, Tech. Rep. HPL-2007-189, pp. 2007–189, 2007.[10] T. Dillon, Chen Wu, and E. Chang, “Cloud computing: Issues and challenges,” in AdvancedInformation Networking and Applications (AINA), 2010 24th IEEE International Conference on,April 2010, pp. 27–33.[11] S.K. Mandal, On-Demand VM Placement on Cloud Infrastructure, Ph.D. thesis, 2013.[12] H.N. Van, F.D. Tran, and J.M. Menaud, “Sla-aware virtual resource management for cloud in-frastructures,” in Computer and Information Technology, 2009. CIT ’09. Ninth IEEE InternationalConference on, Oct 2009, vol. 1, pp. 357–362.[13] V. Mann, A. Kumar, P. Dutta, and S. Kalyanaraman, “Vmflow: Leveraging vm mobility to reducenetwork power costs in data centers,” in NETWORKING 2011, J. Domingo-Pascual, P. Manzoni,S. Palazzo, A. Pont, and C. Scoglio, Eds., vol. 6640 of Lecture Notes in Computer Science, pp.198–211. Springer Berlin Heidelberg, 2011.[14] O. Biran, A. Corradi, M. Fanelli, L. Foschini, A. Nus, D. Raz, and E. Silvera, “A stable network-aware vm placement for cloud systems,” in Cluster, Cloud and Grid Computing (CCGrid), 201212th IEEE/ACM International Symposium on, May 2012, pp. 498–506.[15] A. Ghodsi, M. Zaharia, B. Hindman, A. Konwinski, S. Shenker, and I. Stoica, “Dominant resourcefairness: Fair allocation of multiple resource types.,” in NSDI, 2011, vol. 11, pp. 24–24.[16] W. Wang, B. Li, and B. Liang, “Dominant resource fairness in cloud computing systems withheterogeneous servers,” in INFOCOM, 2014.[17] T. Tomita and S. Kuribayashi, “Congestion control method with fair resource allocation for cloudcomputing environments,” in Communications, Computers and Signal Processing (PacRim), 2011IEEE Pacific Rim Conference on, Aug 2011, pp. 1–6.69[18] C. Joe-Wong, S. Sen, T. Lan, and M. Chiang, “Multi-resource allocation: Fairness-efficiencytradeoffs in a unifying framework,” in INFOCOM, 2012 Proceedings IEEE, March 2012, pp.1206–1214.[19] M. Al-Roomi, S. Al-Ebrahim, S. Buqrais, and I. Ahmad, “Cloud computing pricing models: Asurvey.,” International Journal of Grid & Distributed Computing, vol. 6, no. 5, 2013.[20] J. Wang, M. Chen, and V.C.M. Leung, “A price-based approach to optimize resource sharingbetween cellular data networks and wlans,” Telecommunication Systems, vol. 52, no. 2, pp. 485–496, 2013.[21] S. Ha, S. Sen, C. Joe-Wong, Y. Im, and M. Chiang, “Tube: Time-dependent pricing for mobiledata,” SIGCOMM Comput. Commun. Rev., vol. 42, no. 4, pp. 247–258, Aug. 2012.[22] A. Narayan, S. Rao, G. Ranjan, and K. Dheenadayalan, “Smart metering of cloud services,” inSystems Conference (SysCon), 2012 IEEE International, March 2012, pp. 1–7.[23] S. Shang, J. Jiang, Y. Wu, Z. Huang, G. Yang, and W. Zheng, “Dabgpm: A double auction bayesiangame-based pricing model in cloud market,” in Network and Parallel Computing, C. Ding, Z. Shao,and R. Zheng, Eds., vol. 6289 of Lecture Notes in Computer Science, pp. 155–164. Springer BerlinHeidelberg, 2010.[24] H. Shen and Z. Li, “New bandwidth sharing and pricing policies to achieve a win-win situationfor cloud provider and tenants,” in INFOCOM, 2014 Proceedings IEEE, April 2014, pp. 835–843.[25] X. Jin, Y.K. Kwok, and Y. Yan, “A study of competitive cloud resource pricing under a smart gridenvironment,” in Proceedings of the 2013 IEEE International Conference on Cloud ComputingTechnology and Science - Volume 01, Washington, DC, USA, 2013, CLOUDCOM ’13, pp. 655–662, IEEE Computer Society.[26] A. Gohad, N.C. Narendra, and P. Ramachandran, “Cloud pricing models: A survey and positionpaper.,” in Cloud Computing in Emerging Markets (CCEM), 2013 IEEE International Conferenceon, Oct 2013, pp. 1–8.70[27] B. Sharma, R.K. Thulasiram, P. Thulasiraman, S.K. Garg, and R. Buyya, “Pricing cloud computecommodities: A novel financial economic model,” in Proceedings of the 2012 12th IEEE/ACMInternational Symposium on Cluster, Cloud and Grid Computing (Ccgrid 2012), Washington, DC,USA, 2012, CCGRID ’12, pp. 451–457, IEEE Computer Society.[28] G. Gallego and G. Van Ryzin, “Optimal dynamic pricing of inventories with stochastic demandover finite horizons,” Management Science, vol. 40, no. 8, pp. 999–1020, 1994.[29] W. Elmaghraby and P. Keskinocak, “Dynamic pricing in the presence of inventory considerations:Research overview, current practices, and future directions,” Management Science, vol. 49, no. 10,pp. 1287–1309, 2003.[30] O.A. Ben-Yehuda, M. Ben-Yehuda, A. Schuster, and D. Tsafrir, “Deconstructing amazon ec2 spotinstance pricing,” ACM Transactions on Economics and Computation, vol. 1, no. 3, pp. 16:1–16:20, Sept. 2013.[31] W. Lu, S. Chen, K. Li, and L.V. S. Lakshmanan, “Show me the money: Dynamic recommendationsfor revenue maximization,” in the Very Large Data Bases Endowment, Sep 2014, vol. 7.[32] M. Zhang, R. Ranjan, M. Menzel, S. Nepal, P. Strazdins, W. Jie, and L. Wang, “An infrastructureservice recommendation system for cloud applications with real-timeqosrequirement constraints,”Systems Journal, IEEE, 2015.[33] A. Alfazi, T.H. Noor, Q.Z. Sheng, and Y. Xu, “Towards ontology-enhanced cloud services discov-ery,” in Advanced Data Mining and Applications, X. Luo, J.X. Yu, and Z. Li, Eds., vol. 8933 ofLecture Notes in Computer Science, pp. 616–629. Springer International Publishing, 2014.[34] D. Bernstein, E. Ludvigson, K. Sankar, S. Diamond, and M. Morrow, “Blueprint for the intercloud- protocols and formats for cloud computing interoperability,” in Internet and Web Applicationsand Services, 2009. ICIW ’09. Fourth International Conference on, May 2009, pp. 328–336.[35] R. Ranjan and R. Buyya, “Decentralized overlay for federation of enterprise clouds,” The Hand-book of Research on Scalable Computing Technologies, pp. 191 – 217, 2009.71[36] N. Grozev and R. Buyya, “Inter-cloud architectures and application brokering: taxonomy andsurvey,” Software: Practice and Experience, vol. 44, no. 3, pp. 369–390, 2014.[37] A. Toosi, R. Calheiros, R. Thulasiram, and R. Buyya, “Resource provisioning policies to increaseiaas provider’s profit in a federated cloud environment,” in High Performance Computing andCommunications (HPCC), 2011 IEEE 13th International Conference on, Sept 2011, pp. 279–287.[38] R. Buyya, R. Ranjan, and R.N. Calheiros, “Intercloud: Utility-oriented federation of cloud com-puting environments for scaling of application services,” in Proceedings of the 10th InternationalConference on Algorithms and Architectures for Parallel Processing (ICA3PP 2010). pp. 21–23,Springer.[39] J. Ekanayake and G. Fox, “High performance parallel computing with clouds and cloud tech-nologies,” vol. 34 of Lecture Notes of the Institute for Computer Sciences, Social-Informatics andTelecommunications Engineering, pp. 20–38. Springer Berlin Heidelberg, 2010.[40] T.A. Johnson, R. Eigenmann, and T. N. Vijaykumar, “Min-cut program decomposition for thread-level speculation,” in Proceedings of the ACM SIGPLAN 2004 Conference on Programming Lan-guage Design and Implementation, New York, NY, USA, 2004, PLDI ’04, pp. 59–70, ACM.[41] D.W. Watson, J.K. Antonio, H.J. Siegel, and M.J. Atallah, “Static program decomposition amongmachines in an simd/spmd heterogeneous environment with non-constant mode switching costs,”in Heterogeneous Computing Workshop, 1994., Proceedings, Apr 1994, pp. 58–65.[42] I. Giurgiu, O. Riva, D. Juric, I. Krivulev, and G. Alonso, “Calling the cloud: enabling mobilephones as interfaces to cloud applications,” in Proceedings of the ACM/IFIP/USENIX 10th inter-national conference on Middleware, Berlin, Heidelberg, 2009, Middleware’09, pp. 83–102.[43] B. Chun, S. Ihm, P. Maniatis, M. Naik, and A. Patti, “Clonecloud: elastic execution betweenmobile device and cloud,” in Proceedings of the sixth conference on Computer systems, NewYork, NY, USA, 2011, EuroSys ’11, pp. 301–314.72[44] W. Cai, C. Zhou, V. Leung, and M. Chen, “A cognitive platform for mobile cloud gaming,” in2013 IEEE 5th International Conference on Cloud Computing Technology and Science (CloudCom2013), 2013.[45] K. Zhang, X. Zhou, Y. Chen, X. Wang, and Y. Ruan, “Sedic: privacy-aware data intensive com-puting on hybrid clouds,” in Proceedings of the 18th ACM conference on Computer and commu-nications security. ACM, 2011, pp. 515–526.[46] L. Lamport, R. Shostak, and M. Pease, “The byzantine generals problem,” ACM Transactions onProgramming Languages and Systems (TOPLAS), vol. 4, no. 3, pp. 382–401, 1982.[47] A. Bessani, M. Correia, B. Quaresma, F. Andre´, and P. Sousa, “Depsky: dependable and securestorage in a cloud-of-clouds,” ACM Transactions on Storage (TOS), vol. 9, no. 4, pp. 12, 2013.[48] M. Schnjakin, D. Korsch, M. Schoenberg, and C. Meinel, “Implementation of a secure and re-liable storage above the untrusted clouds,” in Computer Science Education (ICCSE), 2013 8thInternational Conference on, April 2013, pp. 347–353.[49] W. Ma, H. Zhang, Zheng.W., and X. Wen, “Differentiated-pricing based power allocation indense femtocell networks,” in Wireless Personal Multimedia Communications (WPMC), 201215th International Symposium on, Sept 2012, pp. 599–603.[50] H. Zhang, C. Jiang, X. Mao, and H. Chen, “Interference-limited resource optimization in cognitivefemtocells with fairness and imperfect spectrum sensing,” Vehicular Technology, IEEE Transac-tions on, vol. PP, no. 99, pp. 1–1, 2015.[51] R. Harmon, D. Raffo, and S. Faulk, “Incorporating price sensitivity measurement into the softwareengineering process,” in Management of Engineering and Technology, 2003. PICMET ’03. Tech-nology Management for Reshaping the World. Portland International Conference on, July 2003,pp. 316–323.[52] R.E. Goldsmith and S.J. Newell, “Innovativeness and price sensitivity: managerial, theoretical and73methodological issues,” Journal of Product & Brand Management, vol. 6, no. 3, pp. 163–174,1997.[53] S. Han, S. Gupta, and D.R. Lehmann, “Consumer price sensitivity and price thresholds,” Journalof Retailing, vol. 77, no. 4, pp. 435 – 456, 2001.[54] D. Gale, “The law of supply and demand,” MATHEMATICA SCANDINAVICA, vol. 3, pp. 155–169, 1955.[55] H. Xu and B. Li, “A study of pricing for cloud resources,” SIGMETRICS Perform. Eval. Rev., vol.40, no. 4, pp. 3–12, Apr. 2013.[56] P. Jacko, “Resource capacity allocation to stochastic dynamic competitors: knapsack problem forperishable items and index-knapsack heuristic,” Annals of Operations Research, pp. 1–25, 2013.[57] K. Pan, W. Liu, and H. Li, “Work in progress: On the knapsack-based resource allocation for re-configurable network architecture,” in Communications and Networking in China (CHINACOM),2014 9th International Conference on, Aug 2014, pp. 621–624.[58] H.R. Varian, “Equity, envy, and efficiency,” Journal of Economic Theory, vol. 9, no. 1, pp. 63 –91, 1974.[59] H. Wang, Q. Jing, R. Chen, B. He, Z. Qian, and L. Zhou, “Distributed systems meet economics:pricing in the cloud,” in Proceedings of the 2nd USENIX conference on Hot topics in cloud com-puting. USENIX Association, 2010, pp. 6–6.[60] M. Armbrust, A. Fox, R. Griffith, A.D. Joseph, R. Katz, A. Konwinski, G. Lee, D. Patterson,A. Rabkin, I. Stoica, and M. Zaharia, “A view of cloud computing,” Commun. ACM, vol. 53, no.4, pp. 50–58, Apr. 2010.[61] M. Gall, A Schneider, and N. Fallenbeck, “An architecture for community clouds using conceptsof the intercloud,” in Advanced Information Networking and Applications (AINA), 2013 IEEE 27thInternational Conference on, March 2013, pp. 74–81.74[62] M. Schnjakin and C. Meinel, “Evaluation of cloud-raid: A secure and reliable storage above theclouds,” in Computer Communications and Networks (ICCCN), 2013 22nd International Confer-ence on, July 2013, pp. 1–9.[63] D. Lange and O. Mitsuru, Programming and Deploying Java Mobile Agents Aglets, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1st edition, 1998.[64] M. Mechtri, D. Zeghlache, E. Zekri, and I.J. Marshall, “Inter-cloud networking gateway archi-tecture,” in Cloud Computing Technology and Science (CloudCom), 2013 IEEE 5th InternationalConference on, Dec 2013, vol. 2, pp. 188–194.75
Thesis/Dissertation
eng
Electrical and Computer Engineering
Vancouver : University of British Columbia Library
Attribution-NonCommercial-NoDerivs 2.5 Canada
Graduate
A cloud eco-system : reactive demand control and dynamic pricing methodology
Text