Advanced Resource Reservation and QoS Based Refunding in Cloud Federation

Advanced Resource Reservation and QoS Based Refunding in Cloud Federation Mohammad Aazam Computer Engineering Department Kyung Hee University, Suwon South Korea aazam@ieee.org Abstract With rapidly increasing digital media, importance of cloud computing is also scaling up. Cloud computing not only provides ubiquitous access, but also, ease of management for hugely increasing data. The next era is going to be of cloud federation, in which services would be brought up to the user through multiple clouds, creating an inter-cloud computing environment. One of the key entities in inter-cloud computing is cloud broker. Cloud broker plays an important role in cloud federation environment. Broker has to reserve resources and perform pricing and billing. At times, promised quality cannot be delivered. When a customer gives up the service without completely consuming it, service provider has to consider quality degradation factor, while refunding the remaining amount. We have proposed a model which addresses the issue of advanced resource allocation and quality of service (QoS) based refund. We have implemented and tested our model on CloudSim 3.0.3 toolkit. The results presented here justify and endorse our model. Index Terms Cloud broker; media cloud; inter-cloud computing; cloud federation; resource management. I. INTRODUCTION With the rapid increase in digital media content, it has influentially surpassed traditional media, as a result of which long-term and vast changes are required for the contents shared over the Internet. In 2010, Internet video traffic had surpassed global peer-to-peer (P2P) traffic [1]. Excluding the amount of video exchanged through P2P file sharing, since 2012, Internet video has become over 50 percent and will reach 62 percent by the end of 2015. Counting all forms of videos, the number will be approximately 90 percent by 2015 [2]. This media revolution not only brings great opportunities, but also bears some challenges. To meet those challenges, much better infrastructure, sophisticated technologies, and powerful capabilities are required to be incorporated. Recently, cloud computing has swiftly advanced as a favorable and inevitable technology. Cloud computing platform provides vastly manageable and scalable virtual servers, storage resources, computing power, virtual networks, and network bandwidth, according to the requirement and affordability of user. Therefore, it can provide solution package for the media Eui-Nam Huh Computer Engineering Department Kyung Hee University, Suwon South Korea johnhuh@khu.ac.kr revolution, if wisely designed for media cloud. In cloud datacenters, virtual machines consume a lot of memory. Efficient resource management becomes more important in that case. In- Memory Virtual Desktop Infrastructure (IM-VDI) can be one example in this regard. Cloud computing is needed to be deployed and integrated with the advanced technologies on media processing, transmission, and storage, keeping in view the industrial and commercial trends and models. An average user generates content very quickly, until runs out of storage space [2]. Users tend to use and communicate content very frequently, which requires to be accessed easily. One of the key aspects of cloud computing is media management, since cloud makes it possible to store, manage, and share large amounts of digital media. Cloud computing is a handy solution for processing content in distributed environments. Additionally, data can be accessed ubiquitously without the hassle of keeping large storage and computing devices. Sharing large amount of media content is another feature that cloud computing provides. Other than social media, traditional cloud computing provides added features of collaboration and editing of content. Moreover, if content is to be shared, downloading individual files one by one is not easy. With cloud computing, this issue is catered by allowing contents to be accessed at once by other parties, with whom the content is being shared. Managing the increasing content and meeting users requirements requires now to have federative clouds environment. A single cloud cannot handle content or users requests, consequently, two or more clouds have to interoperate and federate their resources. Interoperability is performed through an intermediary, known as cloud broker or simply broker. Such scenario is known as inter-cloud computing or cloud federation. Inter-cloud computing involves transcoding and interoperability related issues, which also affect the overall process of multimedia content delivery. Cloud brokerage plays an important role in this regard. It performs the negotiation between the interested parties and allocates resources for the customer. Based on the services consumed by the customer, broker performs billing and pricing as well. In this paper, we present a framework for advanced resource allocation by cloud broker in cloud federation environment. We also discuss 978-1-4799-7470-2/14/$31.00 2014 IEEE 226

refunding of unutilized resources, on the basis of achieved quality of service (QoS). Rest of the paper is arranged in this way that section II discusses already done studies on this topic. Section III is about inter-cloud broker and our proposed model for resource reservation and refund. Section IV presents performance evaluation of our model. We conclude our paper in section V. II. RELATED WORK Cloud federation is still a newly evolved paradigm in cloud computing arena; consequently, it lacks standard architecture for data communication, media storage, compression, and media delivery. Prior works mainly focus on presenting architectural blueprints for this purpose. Intel-HP viewpoint paper [3] presents industrial overview of the media cloud. It is stated that media cloud is the solution to suffice dramatically increasing trends of media content and media consumption. For media content delivery, QoS is going to be the main concern. In our work presented in [4], we discuss it in detail by presenting end to end QoS provisioning mechanism using Flow Label of IPv6 and Multi-Protocol Label Switching (MPLS). To reduce delay and jitter of media streaming, better QoS is required, for which Z. Wenwu et al. [5] propose media-edge cloud (MEC) architecture. The authors present the MEC as a cloudlet which locates at the edge of the cloud. MEC is composed of storage space, central processing unit (CPU), and graphics processing unit (GPU) clusters. The MEC stores, processes, and transmits media content at the edge, thus incurring a shorter delay. In turn, the media cloud is composed of MECs, which can be managed in a centralized or peer-to-peer (P2P). Rogers Owen et al. present a resource allocation mechanism, but resource prediction and detailed billing, along with refunding issue is not considered [6]. Park Ki-Woong et al. [7] present a billing system with some security features. To resolve different types of disputes in future, a mutually verifiable billing system is presented. Their work only focuses on the reliability of transactions made in purchasing and consuming resources. They do not focus on the overall resource management, pricing, refunding, or similar important features of cloud broker. Wang Wei et al. [8] propose a brokerage service for reservation of instances. The authors propose a brokerage service for ondemand reservation of resources, for IaaS clouds. Their work is limited to only on-demand jobs and they do not present anything beyond that. Jrad Foued et al. present a generic architecture of broker [9], which lacks resource management feature of brokerage. They present how broker handles service level agreement (SLA) management and interoperability of resources. Deelman Ewa et al. present performance tradeoffs of different resource provisioning plans [10]. They also present tradeoffs in terms of storage fee of Amazon S3. Shadi Ibrahim et al. present [11] the concept of fairness in pricing in respect of microeconomics, not discussing how pricing should be done for different types of services. Nikolay Grozev et al. present basic taxonomies for inter-cloud architecture [12]. Buyya et al. present architectural fundamentals of inter-cloud computing in [13]. III. CLOUD FEDERATION BROKER When clouds are to be federated, to increase resources pool and create extended portfolio of resources, cloud broker comes into play. Broker performs the interoperability and negotiation related tasks to federate the resources. It then advertises and makes those resources available to the customers. Without broker, interoperability becomes an issue and both the parties, the service provider and the consumer, have to handle such things on their own. Furthermore, handling heterogeneous customers with different types and scales of requests is not easy for service provider. Managing resources in prior and managing customers according to their requests, attributes, and characteristic becomes very necessary, for which broker is a vital entity. Cloud broker offers a single interface through which multiple clouds can be managed and share resources [14]. Cloud broker operates outside of the clouds and controls and monitors those clouds. Broker s core purpose is assisting the customer find the best provider and the service according to their needs with respect to specified SLA. It provides its customers with a uniform interface to manage and observe the deployed services. Cloud broker earns its profit by fulfilling requirements of both the parties. Cloud broker uses a variety of methods, such as a repository for data sharing and integration across data sharing services to develop a commendable service environment and achieve the best possible deal and SLA between two parties, i.e., Cloud Service Provider (CSP) and Cloud Service Customer (CSC) [13]. Broker typically makes profit either by taking remuneration from the completed deal or by varying the broker s spread, or some combination of both. The spread is the difference between the price at which a broker buys from seller (provider) and the price at which it sells to the buyer (customer). A. Resource reservation and refunding model Pay-as-you-go billing model is one of cloud computing s core attributes. It allows the customers to scale their capacity according to their changing requirements and pay for the resources they have consumed. CSCs contact cloud broker to acquire the required service(s) at best price. Broker performs the negotiation and SLA tasks with CSP [15]. Once the contract is agreed upon, the service is provided to the customer. In this regard, broker not only provides services on ad hoc basis, but also, it has to predict consumption of resources, so that they can be allocated in advance. Resource prediction allows more efficiency and fairness at the time of consumption. Prediction and pre-allocation of resources also 227

depend upon customer s behavior and its probability of using those resources in future. We formulate the estimation of required service as: = { ( ( ) )) ) ) Where represents required resources, is the basic price of the requested service. In most of the cases, is decided at the time contract is being negotiated. ) ) is the average of service oriented relinquish probabilities of a particular customer of giving up (relinquish) the same resource which it has requested now. In case the customer is requesting this service for the first time, the default value set for ) ) is 0.3. Because, the average of low relinquish probability (0.1 to 0.5, from complete range of 0.1 to 0.9) is 0.3. For simplicity, we have categorized customers into two types, one having low ( ) giving up probability and the other having high ( ) giving up probability. Where, ) = {, (2) ) )) ) ) is the variance of service oriented relinquish probabilities. Customer can have a very fluctuating behavior in utilizing resources, which may lead to deception, while making decision about resource allocation. That is why, in our model, we have taken into account variance of relinquish probabilities, which helps determine the actual behavior of each customer. is a constant decision variable value, which is assigned by the broker to each user, according to its history of overall relinquish probabilities. Here, it should be noted that ) determines probability of the same service, which customer is requesting currently, while is overall probability, including all activities a particular customer has been doing. Last activity of the user in this regard tells about its most recent probability. That is why, it has been given more importance and the average is taken again, by adding last relinquish probability. In case of a new user, when there no historical data for that user, this value is set at low relinquish probability 0.3. ) is Signum function, which represents case. With this formulation, cloud broker can determine future resource requirements. It is important for cloud broker to rightly decide while reserving resources and prevent precious resources go waste. It will also help power consumption management, which is becoming a point of concern for cloud datacenters. An ongoing service can be discontinued at any stage by the customer. At that point, broker has to halt the service and refund ) (3) the remaining amount to the customer. In this case, broker has to take into account the utilized resources or consumed services and the remaining service value of the decided total initial service. This can be formulated through the following equations. (4) (5) In eq. 4, is the total amount to be refunded. is the refund amount of unutilized resources. is the refund amount to be paid on quality degradation. During service delivery, it is not always possible to deliver the service exactly according to the promise made during SLA. and are further calculated through equations 6 and 7 respectively. represents unutilized resources, while represents utilized resources. ) (6) ) ( ( )) ( ) ) (7) Where is the acquired quality of service and is the quality of service promised during SLA. is broker s ratio (e.g., 10% of the total cost), set by the broker, based on business policy. IV. VALIDITY AND PERFORMANCE EVALUATION In this section, we present evaluation of our proposed service model. We defined our service model through authentic algorithm to evaluate the effectiveness in cloud computing business. Our main objective is to observe the influence of performance factors on the systems and test the feasibility of our method. A. Simulation Setup Table 1 shows the simulation environment while Table 2 shows basic parameters setting. TABLE 1: SIMULATION SETUP System Intel(R) Core(TM) i5-m430, 2.27 GHz Memory 4 GB Implementation language Java using NetBeans 8.0 Simulator CloudSim 3.0.3 Operating System (OS) Window 7 Home Premium TABLE 2: KEY PARAMETERS SETTING FOR EVALUATION Parameters Range Service Level 0.9 Agreement (Q SLA ) Acquired service 0.9,0.8,0.7,0.6,0.5,0.4,0.3,0.2,0.1 quality (Q a ) Service Price ( ) 100,150, 200,250,,1000 Service utilization 30%,40%,50%,60%,70%,80%,90% Relinquish 0.1,0.2,0.3,,0.9 228

probabilities Number of registered services Service duration( ) in months 10 1,2,3,4,5,6 B. Resource prediction for an absolutely new customer When different CSCs are requesting for a particular service, the CSP or broker has to analyze what number of resources have to be allocated for that service, based on the type of customer. For CSCs having low relinquish probability, priority in resource allocation is given. For those customers, who are absolutely new and broker has no past record for them, default probability is used. In other words, it is assumed that this new customer will be somewhat loyal. That is why, relinquish probability is set to 0.3. While perfectly loyal customer would be having a probability of 0.1. Since cloud resources are precious and it is not advisable to take risk, thence, instead of assigning 0.1 probability value, we have assigned 0.3. Figure 1 shows the unit of resources being predicted for new customers, for different types of registered services. This unit, for example, 49 in case of USD 100 service, is then mapped to actual resources (memory, CPU, storage space, etc.), according to the type of service being offered and policies of a particular CSP. increase as the service price increases. In case of customer 1, having SOP = 0.1 (bold font in the figure) and AOP = 0.4, 44 unit of resource are reserved for USD 100 service. In case of customer 2, SOP = 0.2 and AOP = 0.2, 63 resources are reserved. Even though customer 2 has relatively higher SOP, as compared to customer 1, but since its AOP is lower than customer 1, therefore, it gets more resources. Customer 5 having SOP = 0.5, has equal number of resources as that of customer 1, because it has a perfect loyalty record, with AOP = 0.1. This shows that both these types of probabilities have their impact and final decision is made accordingly, which makes it sure that a customer who has generally been loyal, but not so in case of some particular service, or vice versa, gets treated in view of that. Figure 2. Resource prediction for different types of CRCs, for USD 100 service. Figure 1. Resource prediction for new CRCs, for different requested services. C. Resource prediction for an existing customer For the returning customers, broker already has a historical record of its past activities and probabilities (overall probabilities and service oriented probabilities) with which it has been consuming resources. When characteristic of a particular customer is known, it is more justified and fair to determine and allocate resources accordingly. In this way, broker and CSP will be able to reserve right amount of resources and would be having least number of chances to lose profit. Figure 2 shows five different types of customers, having different Service Oriented Probability (SOP) and Average Overall Probability (AOP), requesting a particular service S. in this example, the result is presented for service price USD 100. The unit is greater for L customers, while it is smaller for H customers, because of their behavior. Since there are more chances of an H customer to relinquish the service(s), so more priority and quality is provided to the more loyal customer, having L probability. Resources D. Refunding for fixed service, according to service quality degradation Service quality plays a vital role in user satisfaction and its loyalty towards the service provider. Service quality is a core issue for which CSP always have to think about SLA fulfillment. However, it is not always possible and at times, an unsatisfied customer may change service provider. We have considered this issue in our proposed model, according to which, if SLA is not fulfilled, CSP would be penalized and CSC receives the increased refund amount, according to the degradation in service quality. In view of that, refund amount varies according to the achieved SLA or service quality. For more degraded service, higher refund rate would be provided. In this part, we vary SLA, ranging from 0.1 to 0.9. Where 0.9 is best quality (or SLA achieved) and rest of the values represent service degradation, with 0.1 being the worst quality. Figure 3 shows the refund amount for USD 100 service, based on different service quality, with fixed utilization of 70% in this instance. It shows that more the service is degraded more is the refund rate for each type of service. The first case when achieved quality is 0.1, having 70% of the USD 100 service utilized, the refund amount is not around USD 30. Instead, around USD 70 are being refunded. Because the quality provided had been worst. Similarly, with increasing quality, refund is adjusted accordingly. By this, fairness is made sure and customer satisfaction is achieved. 229

provide stable and quality-maintained services, but it is not always possible. Therefore, when there is degradation in the QoS, the refunded amount should be paid keeping that in view. This is what our model achieves as well. Thorough testing of this model, based on simulations, shows the validity and efficient performance of our proposed model. We intend to extend this part now and work on more varied parameters under more heterogeneous environment where different types of devices are being used by customers and diverse services are requested. Figure 3. Refund amount according to service quality, for USD 100 service. E. Refunding for different services, according to service quality degradation Figure 4 shows different utilization levels, for different services, with different achieved quality levels. In case of first instance, USD 100 service was requested. Achieved quality remained 0.7, which is considered as good. Customer utilized that service 80%. Therefore, the refund amount is USD 22.47, (instead of USD 20). Similarly, more is the utilization, less would be the refund. On the contrary, more is the degradation in service quality, higher would be the refund factor and as a result, refund amount. Figure 4. Refund amount according to service quality, for different services. V. CONCLUSION AND FUTURE WORK Cloud federation and inter-cloud brokerage are still in their beginning. With rapidly increasing multimedia content in the cloud, QoS, efficiency, and customer s satisfaction is becoming a crucial task. In this study, we have highlighted a key issue of resource prediction, allocation, pricing, and refunding for cloud brokerage and present a complete model. In our presented model, up to 10 different types of services were considered, with different types of customers, having different characteristics. Based on customer characteristics, the prices are determined and QoS is maintained, making sure that more loyal and frequent customer is treated the way it deserves. Refunding is also based on different types of utilization levels as well as the acquired QoS. Even though the service providers always try their best to ACKNOWLEDGMENT This work was supported by the IT R&D program of MSIP/IITP [2014044078003, Development of Modularized In- Memory Virtual Desktop System Technology for High Speed Cloud Service]. The corresponding author is Prof. Eui-Nam Huh. REFERENCES [1] Mingfeng Tan, Xiao Su, "Media Cloud: When Media Revolution Meets Rise of Cloud Computing", Proceedings of The 6th IEEE International Symposium on Service Oriented System Engineering. [2] Cisco-White-Paper, "Cisco Visual Networking Index Forecast and Methodology, 2010 2015," June 1, 2011 [3] "Moving to the Media Cloud", Viewpoint paper, Intel-HP, Nov. 2010. [4] Mohammad Aazam, Adeel M. Syed, Eui-Nam Huh, "Redefining Flow Label in IPv6 and MPLS Headers for End to End QoS in Virtual Networking for Thin Client", in the proceedings of 19th IEEE APCC, Bali, Indonesia, 29-31 August, 2013. [5] Z. Wenwu, L. Chong, W. Jianfeng, and L. Shipeng, "Multimedia Cloud Computing," Signal Processing Magazine, IEEE, vol. 28, pp. 59-69, 2011. [6] Rogers, Owen, and Dave Cliff. "A financial brokerage model for cloud computing." Journal of Cloud Computing 1.1 (2012): 1-12. [7] Park, Ki-Woong, et al. "THEMIS: A Mutually verifiable billing system for the cloud computing environment." Services Computing, IEEE Transactions on 6.3 (2013): 300-313. [8] Wang, Wei, et al. "Dynamic cloud resource reservation via cloud brokerage, 33 rd IEEE ICDCS 2013. [9] Jrad, Foued,et al. "SLA based Service Brokering in Intercloud Environments." CLOSER. 2012. [10] Deelman, Ewa, et al. "The cost of doing science on the cloud: the montage example." Proceedings of the 2008 ACM/IEEE conference on Supercomputing. IEEE Press, 2008. [11] Shadi Ibrahim, Bingsheng He, Hai Jin, Towards Pay-As-You-Consume Cloud Computing, IEEE International Conference on Services Computing, Washington, USA, July 4-9, 2011 [12] Nikolay Grozev and Rajkumar Buyya, Inter-Cloud Architectures and Application Brokering: Taxonomy and Survey, Wiley Software: Practice and Experience (2012). [13] Buyya, Rajkumar et al., "Intercloud: Utility-oriented federation of cloud computing environments for scaling of application services." Algorithms and architectures for parallel processing. 13-31, 2010. [14] Mohammad Aazam, Eui-Nam Huh, Inter-Cloud Architecture and Media Cloud Storage Design Considerations in the proceedings of 7th IEEE CLOUD, Anchorage, Alaska, USA, 27 June 02 July, 2014. [15] Al-Amin Hossain, Eui-Nam Huh, Refundable Service through Cloud Brokerage, in the proceedings of 6th IEEE CLOUD, California, USA, 28 June 03 July, 2013. 230