Adaptive and similarity-based tradeoff algorithms

Inf Syst Front DOI 10.1007/s10796-013-9432-y

Adaptive and similarity-based tradeoff algorithms in a price-timeslot-QoS negotiation system to establish cloud SLAs Seokho Son & Kwang Mong Sim

# Springer Science+Business Media New York 2013

Abstract Since participants in a Cloud may be independent bodies, some mechanisms are necessary for resolving the different preferences to establish a service-level agreement (SLA) for Cloud service reservations. Whereas there are some mechanisms for supporting SLA negotiation, there is little or no negotiation support involving price, time slot, and QoS issues concurrently for a Cloud service reservation. For the concurrent price, timeslot, and QoS negotiation, a tradeoff algorithm to generate and evaluate a proposal which consists of price, timeslot, and QoS proposals is necessary. The contribution of this work is designing a multi-issue negotiation mechanism to facilitate 1) concurrent price, time slot, and QoS negotiations including the design of QoS utility functions and 2) adaptive and similarity-based tradeoff proposals for price, time slots, and level of QoS issues. The tradeoff algorithm referred to as “adaptive burst mode” is especially designed to increase negotiation speed, total utility, and to reduce computational load for evaluating proposals by adaptively generating concurrent set of proposals. The empirical results obtained from simulations carried out using an agent-based testbed suggest that using the negotiation mechanism, (i) a consumer and a provider agent have a mutually satisfying agreement on price, time slot, and QoS issues in terms of the aggregated utility and (ii) the fastest negotiation speed with (iii) comparatively lower number of evaluated proposals in a negotiation.

S. Son Department of Information and Communications, Gwangju Institute of Science and Technology, 261 Cheomdan-gwagiro, Buk-gu, Gwangju 500-712, Republic of Korea K. M. Sim (*) School of Computing, The University of Kent, Chatham Maritime, Kent ME4 4AG, UK e-mail: [email protected]

Keywords Cost-models and economics of grid/cloud computing . Agent-based cloud computing . Service level agreement . Multi-issue negotiation . Cloud service reservation . QoS negotiation

1 Introduction A Cloud is a type of parallel and distributed system consisting of a collection of interconnected and virtualized computers that are dynamically provisioned and presented as one or more unified computing resources based on service-level agreements (SLA) established through negotiation between the service provider and consumers (Buyya et al. 2009). In reserving Cloud services, Cloud participants have to consider the price of the service and when to use a service (i.e., position of timeslot). Also QoS requirements of the service are important issues for Cloud participants. Both a consumer and a provider have to reach agreements on these issues for establishing an SLA before the consumer leases a Cloud service. However, since Cloud participants that consist of consumers and providers are individual bodies, some mechanisms are necessary to resolve different preferences on leasing or lending services. A negotiation mechanism is one of key methods to resolve different preferences between participants. Whereas previous works have reported on advance reservations considering bandwidth or time constraints (Foster et al. 1999; Netto et al. 2007; Foster et al. 2000) and adopting a negotiation mechanism for SLA (Venugopal et al. 2008), to date there is no service reservation system that concurrently considers both the price and timeslot negotiation except (Son and Sim 2012). However, the design of (Son and Sim 2012) does not include QoS as a negotiation issue. Since negotiation issues (i.e., price, timeslot, and QoS) are in a tradeoff relationship—a consumer who pays a great

Inf Syst Front

deal of money for a service can demand to use the service at a more desirable timeslot or QoS—price, timeslot, and QoS have to be negotiated not individually but concurrently. Accordingly, a multi-issue (i.e., multi-attribute) negotiation mechanism also has to be considered in this work. Even though there are several negotiation mechanisms for Grid resource negotiation (see (Sim 2010a) for a survey), these negotiation mechanisms generally do not consider time slot and QoS negotiation. Whereas (Yan et al. 2007) designed multi-issue SLA negotiations for Web service, these mechanisms are not specifically designed for negotiation issues in Cloud service reservation. There has been little work to date on Cloud service negotiation except for (Sim 2010b, 2012, 2013) that propose a complex Cloud negotiation mechanism for supporting concurrent negotiation activities in interrelated markets in which the negotiation outcomes between Cloud brokers and Cloud resource providers in one market can potentially affect and influence the negotiation outcomes of Cloud brokers and Cloud consumers in another market. However, whereas (Sim 2010b, 2012, 2013) focuses on a complex concurrent negotiations in multiple interrelated Cloud markets, in which the outcomes in one market can potentially influence another, this work is the earliest work to consider a Cloud service reservation system supporting a concurrent negotiation mechanism for price, timeslot, and QoS level including a tradeoff algorithm. Since resources of a Cloud provider are utilized by various users, the amount of service requests of consumers (i.e., resource loads) varies over time. To support all consumers’ requests, the Cloud provider is required to prepare a very high resource capacity which leads a huge investment for the provider. Even though the Cloud provider have a high resource capacity, the resources will often (maybe a long period) be overprovisioned (i.e., a situation where the resource is underutilized), then the rate of return on investment will be low. To overcome overprovisioning and under provisioning problems, some researches are focused on Cloud federation to allow providers to dynamically outsource resources to other providers (Goiri et al. 2012; Hassan et al. 2012). (Goiri et al. 2012) presented a characterization of providers operating in a federated Cloud to make a decision (when to outsource, insource, or turn off unused nodes to save power) depending on the environment conditions. However, in a federated Cloud, the Cloud providers are individual enterprises and may have some conflicts operating a shard resource pool. For instance, there can be problem with SLAs established with consumers. An SLA may not be guaranteed if the contractor and actual service provider are different enterprises. On the other hand, the economic impact on the PriceTimeslot-QoS Negotiation mechanism and the design of Price-Timeslot-QoS utility functions is that the advanced multi-issue negotiation mechanism is applicable to Cloud

computing environments where the amount of service requests of consumers (i.e., resource loads) varies over time since a provider can guide consumers to use services at a time when the resource load is low with a variable pricing. Also, a negotiation system (agent) is to represent personal preferences and the resource can be owned by a provider individually. Without sharing federated resources, a provider can increase the resource utilization level by a negotiation with consumers so that the provider supports a high resource load that varies over time. Negotiating price, timeslot, and QoS concurrently can provide a load distribution in temporal manner (from timeslot utility function) with varying amount of resources (from QoS utility function) so that the Cloud provider can be facilitated to increase resource utilization level. In addition, consumers are beneficial because consumers can use Cloud service according to their budget. For instance, a consumer who has insufficient budget can use a low quality Cloud service or can use the service at a time when the Cloud provider faces a low resource demand. Accordingly, it is important to devise such utility functions that well represent individual’s preferences and to design a negotiation mechanism that can increase negotiation performance in term of negotiation utility, negotiation speed, and computational load to evaluate proposals. In (Son and Sim 2012), the concurrent price and timeslot negotiation mechanism (CPTN) was designed. The design of CPTN includes a novel tradeoff algorithm, referred to as the “general burst mode” proposal, designed to enhance both the negotiation speed and aggregated utility of the price and timeslot in a multi-issue negotiation. With burst mode, agents are allowed to make a concurrent set of proposals, in which each proposal consists of a different pair of price and timeslot that generate the same aggregated utility. Increasing the number of proposals in concurrent set lets agents generally enhances negotiation speed and aggregated utility. However, in (Son and Sim 2012), agents can specify only a definite number of proposals in the concurrent set, and the burst mode does not consider adaptively selecting the number of proposals in concurrent set. This paper proposes a new tradeoff algorithm referred to as “adaptive burst mode” especially designed to increase negotiation speed, total utility, and to reduce computational load by adaptively selecting the number of proposals in the concurrent set. Also, in (Son and Sim 2012), the negotiation agent is not sufficient for a Cloud service reservation since there is no consideration for Cloud QoS issues in the multi-issue negotiation mechanism. This work considers many unconsidered and unspecified Cloud QoS attributes in multi-issue negotiations. The objectives of this work are to: 1) design the Cloud service reservation system for supporting concurrent PriceTimeslot-QoS negotiation (Section 3); 2) design and implement the concurrent price, timeslot, and Cloud QoS negotiation agent including the design of Cloud QoS utility

Inf Syst Front

functions and the adaptive tradeoff algorithm (Section 4); 3) evaluate performances of the proposed negotiation mechanism using the agent-based Cloud testbed described in Section 5 in terms of the outcomes (i.e., the negotiation speed, the aggregated utility, and the number of proposals evaluated in each negotiation) for negotiating for price, timeslot and QoS for Cloud service reservation (Section 6). Finally, Section 7 concludes this paper with a list of future works.

2 Related work This work explores the topic of designing a multi-issue negotiation mechanism for establishing Cloud SLAs, areas related to this research include: 1) Grid Resource Negotiation; 2) SLA and Multi-issue SLA Negotiation Considering a Tradeoff Relationship; and 3) Advance Reservation and Resource Co-allocation. 1) Grid Resource Negotiation: In a recently published survey paper (Sim 2010a), Sim reviewed and discussed state-of-the-art approaches to Grid resource negotiation mechanisms. The following are some of the works surveyed in (Sim 2010a). Gimpel et al. (2003) adopted a rule-based framework for negotiation in service contracts. In policy-driven automated negotiation decisionmaking approach (PANDA), rule sets express policies that consider customer satisfaction and business reputation rather than just maximizing utilities. Lang (2005) adopted a two-phase bargaining protocol for Grid resource negotiation. In (Lang 2005), the negotiation protocol consists of a distributive negotiation phase, in which self-interested agents adopt heuristic strategies to iteratively exchange bids; and an integrative negotiation phase, in which agents attempt to find joint gains while attempting to maintain the utility distribution outcomes from the distributive negotiation phase. Even though (Gimpel et al. 2003; Lang 2005) support multi-issue negotiation, the utility functions defined in them are only for monotonic linear attributes (such as the number of packets, job deadline, or price). The utility functions defined in (Gimpel et al. 2003; Lang 2005) are not appropriate for time slot negotiations or negotiations involving a tradeoff relationship between the price and time slot preference. Lawley et al. (Lawley et al. 2003) investigated the use of negotiation agents for identifying mutually acceptable terms among information providers and consumers of message notification services in a Grid computing environment. In (Sim 2006), Sim adopted a market-driven strategy and a relaxed-criteria protocol for Grid resource negotiation. Following a relaxed-criteria protocol, negotiation agents representing resource providers and consumers are programmed to

slightly relax their bargaining criteria to enhance their chance of successfully acquiring resources. The difference between this work and previous works that consider single (Lawley et al. 2003; Sim 2006) and multiple issue negotiations without a specific tradeoff algorithm (Lang 2005; Gimpel et al. 2003) for Grid resource negotiation is that this work considers a concurrent price, time slot, and Cloud QoS issue negotiation mechanism that includes the design of the utility functions and the tradeoff algorithms. 2) SLA and Multi-issue SLA Negotiation Considering a Tradeoff Relationship: A generalized resource management model is proposed by (Czajkowski et al. 2002) in which resource interactions are mapped onto a welldefined set of platform independent SLAs regarding deliver capability, perform activities, and bind activities to capabilities. The model is based on a service negotiation and acquisition protocol (SNAP), which governs the lifetime management of SLAs. Brandic et al. (2009) proposed a meta-negotiation for SLA specifications to allow two parties to reach an agreement on what specific negotiation protocols, security standards, and documents to use before starting the actual negotiation. Also, to manage SLAs, Paschke et al. (2005) proposed a declarative rule-based SLA (RBSLA) language for describing SLAs in a generic way. RBSLA is machine-readable and has executable contract specifications. Whereas (Czajkowski et al. 2002; Brandic et al. 2009; Paschke et al. 2005) do not focus on specifying negotiation strategies or designing utility functions for each negotiation term, (Yan et al. 2007) adopted a tradeoff algorithm for multi-issue SLA negotiations. (Yan et al. 2007) proposed a framework for a Web service composition that provides SLA negotiation for QoS constraints. Based on this framework, a utilityfunction-based decision-making model that supports coordinated negotiations was presented. To ensure coordinated SLA negotiations, the framework in (Yan et al. 2007) consists of a coordinator agent (CA) and a set of negotiation agents (NA). The CA is responsible for the SLA negotiation governing the composition as a whole, while each NA is in charge of the SLA negotiation for one service in the composition. The NA is related to the proposed mechanism in this paper. Similar to this paper, the design of the decision-making model of NA for the multi-attribute negotiation in (Yan et al. 2007) includes the design of utility functions and a negotiation strategy. The difference between (Yan et al. 2007) and this work is that while agents in (Yan et al. 2007) generate a single proposal in each round using heuristics, agents using the proposed mechanism in this work (Section 4) generate a set of concurrent proposals

Inf Syst Front

in each round. In the NA of (Yan et al. 2007), a single attribute utility function for linear and monotone QoS attributes was designed. This linear and monotone utility function is appropriate for generic attributes (e.g., price, reliability, and network bandwidth). However, since the time slot attribute cannot be represented as a linear and monotone utility function, the utility function in (Yan et al. 2007) is not an appropriate model for time slot negotiations. In addition, unlike (Yan et al. 2007), the proposed time slot utility function in this work enables Cloud participants (i.e., the consumers and providers) to express temporal preferences during negotiations. Also, (Yan et al. 2007) designed two negotiation strategies for generating counter-proposals, which include making concessions and tradeoffs. The concession algorithm seeks, within an acceptance range, a point with a fixed deduction of the total utility value of the current-offer to generate a new counter-proposal. Whereas the concession algorithm in this work adopted the time-dependent strategies in (Sim 2005), a fixed deduction is preconfigured by the NA in (Yan et al. 2007). Additionally, (Yan et al. 2007) proposed a heuristic tradeoff algorithm described in Section 6.3. It is reasonable to argue that the heuristic approach is efficient for selecting a proposal when the utilities are defined using linear functions. However, empirical results reported in Section 6 show that the negotiation speed of the heuristic tradeoff algorithm proposed in (Yan et al. 2007) is slower than the proposed burst mode when negotiations involve a non-linear function such as the time slot utility function. The empirical results presented in Section 6 also show that the tradeoff algorithm in this work achieves a faster negotiation speed and higher total utility. 3) Advance Reservation and Resource Co-allocation: For an advance reservation of Grid resources, (Venugopal et al. 2008) adopted a protocol for negotiating SLAs based on Rubinstein’s alternating offers protocol (Rubinstein 1982). (Venugopal et al. 2008) considered negotiation for time slots and the number of resources (i.e., Grid nodes) between a consumer and provider in a Grid environment. The mechanism proposed in (Venugopal et al. 2008) provides time slot negotiation and resource co-allocation for given QoS requirements. In (Venugopal et al. 2008), the consumer side of the protocol was implemented in a Gridbus broker and the provider side of the protocol was implemented within a .NET-based enterprise Grid system called Aneka. Aneka includes a reservation manager that takes care of allocating and enforcing reservations on allocation managers of each Grid node. Using the Rubinstein’s alternating offers protocol, the Gridbus broker and the Aneka reservation manager identify the number of Grid

nodes that can provide a co-available time slot and satisfy QoS requirements. In (Venugopal et al. 2008), however, a time slot utility was not adopted, and a consumer only checks whether or not the proposed time slot is within its job deadline, which is a very simple evaluation criteria. Unlike (Venugopal et al. 2008), using the consumer’s time slot utility in Section 4.1.3, a consumer in this work can express multiple temporal preferences in time slot negotiation. Moreover, the provider’s time slot utility enables a provider agent or scheduler to express temporal preferences to optimize resource utilization. Also, consumer QoS constraints (including price) are not negotiable in (Venugopal et al. 2008), as providers in (Venugopal et al. 2008) simply reject negotiation requests that violate their QoS requirements. Additionally, (Sim and Shi 2010) considered a concurrent negotiation mechanism for Grid resource coallocation. Their concurrent negotiation mechanism was designed for managing the (de)commitment of contracts through one-to-many negotiations and the coordination of multiple concurrent one-to-many negotiations between a consumer and multiple groups of resource providers. (Sim and Shi 2010) devised a utility-oriented coordination (UOC) strategy, three classes of commitment management strategies (CMSs) for concurrent negotiations, and negotiation protocols for consumers and providers. The difference between this work and (Sim and Shi 2010) is that whereas (Sim and Shi 2010) focuses on very complex concurrent negotiations for resource pricing in multiple interrelated Grid/Cloud markets, in which the outcomes in one market can potentially influence the other, this work considers a multiissue negotiation mechanism especially designed for concurrent price, time slot, and Cloud QoS issue negotiations. Finally, it should be noted that some of the preliminary ideas of this work were presented in (Son and Sim 2010, 2011, 2012). This work has significantly and considerably augmented and generalized the preliminary initiatives in (Son and Sim 2010, 2011, 2012) as follows. (Son and Sim 2012) presented the ideas of a concurrent price and time slot negotiation (CPTN) mechanism that includes the design of price and time slot utility functions and a tradeoff algorithm, referred to as the “general burst mode” proposal. However, CPTN agents can specify only a specific number of proposals in the set of concurrent proposals, and the burst mode does not consider adaptively selecting the number of proposals in the set of concurrent proposals. This paper proposes a new tradeoff algorithm referred to

Inf Syst Front

as “adaptive burst mode” which is specially designed (Section 4.2.2) to increase negotiation speed, total utility, and to reduce computational load by adaptively selecting an appropriate number of proposals in the set of concurrent proposals. Whereas (Son and Sim 2010) presented a preliminary idea of “adaptive burst mode”, this paper enhances and augments the “adaptive burst mode” by considering the concept of fuzzy similarity (Yan et al. 2007). In (Son and Sim 2011), the preliminary ideas of a multi-issue negotiation mechanism to facilitate concurrent price, time slot, and Cloud QoS negotiations, which extends the CPTN mechanism by classifying Cloud QoS issues and designing Cloud QoS utility functions, was introduced. Whereas (Son and Sim 2011) only applied the “general burst mode” to negotiations involving price, time slot, and QoS issues, this paper 1) contributes an enhanced design of “adaptive burst mode” incorporating the concept of fuzzy similarity, and the design of Cloud QoS utility functions and 2) applies the idea of the trade-off algorithm to negotiations involving price, time slot, and QoS issues. In addition, whereas (Son and Sim 2010, 2011) only presented preliminary experimental results for a very small set of simulations, this paper reports a considerably larger set of experiments and empirical results. Also, very thorough and detailed analyses of the performance of the burst mode against other related schemes in terms of the negotiation speed, total utility, and computational load are presented in this work. Moreover, being short conference papers, (Son and Sim 2010, 2011) omitted comparisons with other related works. This paper provides a detailed comparison between this work and related works on Grid resource negotiation, SLA and multiissue SLA negotiation considering a tradeoff relationship, and advance reservation and resource coallocation.

3 Overview of cloud service reservation system This section introduces the framework of the Cloud service reservation system. The proposed Cloud service reservation system supports concurrent negotiation for price, time slot, and QoS level. The initiative of the system is that price, position of time slot, and QoS level are most important issues for a Cloud service reservation and both time slot and QoS level are closely related with price of the service. Therefore, a concurrent negotiation for these issues can be key issues in Cloud service reservation.

For consumers, the benefit of concurrent negotiation for price, time slot, and QoS level is that consumers can adjust level of satisfaction on timeliness using service and the quality of service on their budget because the concurrent negotiation mechanism can specify tradeoff relationships among price, time slot, and QoS level. A consumer who has not sufficient budget but has sufficient time to utilize a Cloud service is willing to reserve their services on negotiated time slots with a provider. Likewise, the concurrent negotiation can increase resource utilization of providers since providers can schedule their resource utilization by controlling the price of services for each period. For example, a provider can guide a consumer to reserve their job on available time slots by pricing the service at that time in a low cost. Therefore, the proposed reservation system is useful to manage their resources to providers and gives flexibility for selecting suitable services to service consumers. Even though one of the properties of Cloud is elasticity, managing resource utilization overall Clouds is important because there are limited resources in a Cloud eventually, and the reservation scheme is useful to efficiently share the Cloud resources for both consumers and providers. Figure 1 shows a framework of the Cloud service reservation system. The Cloud service reservation system consists of consumer’s site and provider’s site. For each side, the main component of the system is concurrent multi-issue negotiation agents. The negotiation protocol of the concurrent negotiation agents follows the Rubinstein’s Alternating Offers protocol (Rubinstein 1982) in which agents make counter offers to their opponents in alternate rounds. Both agents generate counter offers and evaluate their opponents’ offers until either an agreement is made or one of the agents’ deadlines is reached. Counter proposals are generated according to the negotiation strategy designed in Section 4.2, and proposals are evaluated by utility functions designed in Section 4.1. If a counter-proposal is accepted, both agents can eventually reach a mutually acceptable price, timeslot, and QoS level, and consumer can reserve the service in agreed price, timeslot, and QoS level. Conversely, if one of the agents’ deadlines expires before they reach an agreement, their reservation fails. With Cloud service reservation system, a consumer and a provider can specify preferences on price, time slot, QoS requirements, and QoS level through the reservation GUI. A provider also specifies preferences on price and time slot; determines preference on QoS level for negotiation according to QoS requirements from the consumer and a system situation. Also, negotiation parameters such as negotiation strategy and

Inf Syst Front Fig. 1 The framework of the Cloud service reservation system

Provider’ s or scheduler’ s inputs

Consumer’ s inputs

QoS requirements

Price

QoS requirements

QoS describer

Utility function generator

Proposal generator

Negotiation strategy manager

Proposal evaluator

Time slot

QoS Level

Proposal generator

Utility function generator

Proposal evaluator

Negotiation strategy manager

Concurrent multi- issue negotiation agent

Reservation GUI

Cloud service reservation system - consumer’ s site -

negotiation deadline can be specified through the reservation GUI. In case of QoS requirements, there can be many and diverse requirements according to Cloud services. Therefore, it is hard to specify all QoS utility functions for negotiation. To avoid complicated negotiation, this paper classifies QoS requirements into three kinds of QoS level: 1) service performance, 2) service availability, and 3) service reliability. In addition, the reservation manager in the provider’s site manages reservation queue. In the reservation queue, the services that satisfy consumers’ requirements are listed in the timeline. The number of services that can be concurrently executed can be estimated by each system of Cloud providers. If there is enough resource to execute the requested service, the time slots will be made available. Otherwise, the time slots are reserved time slots. The reservation manager records indices of available time slots and reserved time slots, and it is especially used for determining time slot utility function for providers.

4 Price-timeslot-QoS negotiation agent This section introduces the design of a concurrent negotiation mechanism for price, timeslot, and Cloud QoS. The proposed mechanism includes the design of utility functions and negotiation strategies.

Concurrent multi- issue negotiation agent

Reservation manager

QoS Level

Reservation queue

Negotiation parameters

Cloud service reservation system - provider’ s site -

Reservation GUI

4.1 Utility functions 4.1.1 Aggregated total utility function The utility function U(x) represents an agent’s level of satisfaction of a negotiation outcome x. Since each user has different preferences for the price, position of the timeslot, and QoS issues, a price utility function UP(P), timeslot utility function UT(T), Cloud QoS utility functions are defined in this section. In (Son and Sim 2012), a price utility function UP(P), timeslot utility function UT(T), and an aggregated utility function were defined. This section introduces the price and timeslot utility functions, and we extend the aggregated utility function by defining and classifying Cloud QoS issues into 3 categories: 1) service performance, 2) service availability, and 3) service reliability. Three QoS issues have been often considered as important QoS issues in systems provide services through networks and negotiable requirements for a Cloud service. Let wP, wT, wQp,wQa, and wQr be the weights for the price utility, the time slot utility, the service performance utility, service availability utility, and service reliability utility respectively, such that wP þ wT þ wQp þ wQa þ wQr ¼ 1. The aggregated price, timeslot, and QoS utility Utotal(P,T,Qperformance,Qavailability,Qreliability) at each price, time slot, and QoS issues is given as


 Utotal  P; T ; Qperformance ; Qavailability ; Qreliability 0 if either UP ¼ 0; UT ¼ 0; U Q p ¼ 0; U Q a ¼ 0; or U Q r ¼ 0 ¼ wP  UP þ wT  UT þ wQp  UQp þ wQa  UQa þ wQr  UQr ; otherwise:

By varying weights, users can place different combinations of emphases on the price, time slot, and Cloud QoS issues for negotiation. If either U P (P) = 0, U T (T) = 0, U Q p ( Q p ) = 0 , U Q a ( Q a ) = 0 , o r U Q r ( Q r ) = 0 , Utotal

Price

Time slot

Negotiation session

Negotiation parameters

QoS requirements

QoS describer




ð1Þ

 P; T ; Qperformance ; Qavailability ; Qreliability ¼ 0 because all utilities should be within the acceptable range of each utility. The guideline to determine the weights based on users’ preferences includes: Guideline 1) users specify the

Inf Syst Front

emphasis and importance of each attributes (i.e., price, time slot, service performance, and availability and reliability) by entering abstract preferences (e.g., budget is very important, time slot is of moderately low importance, etc.). The program automatically translates these abstract preferences into numbers that specify the weights following the guidelines in Table 1. Guideline 2) the sum of weights should be ‘1.0’ (system regulation). When users are entering abstract preferences, the system will guide users to ensure that the sum of all weights is ‘1.0’. For instance, if a user selected level 10 for the price utility, the system will guide the user to select level 0 for the other issues. By selecting level 10 (the level for the most important issue) means the sum of weights is already ‘1.0’ (just only for the price utility). Consequently, the other abstract preferences should be levels 0 (which means 0 weights). According to a situation, users can select abstract preferences for every five issues. For instance, the price utility can be the most important issue to a consumer who has a low budget. In that case, the consumer can select the highest user-level preference which is level 10 on the price utility to assign the highest value on the price weight. According to trade-off relationship (guideline 2), lower levels should be selected for the other issues. On the other hand, a consumer who can pay a great deal of money for a service can demand to use the service at a more desirable timeslot or QoS by assigning a lower level to the price utility. Since there are 5 issues to negotiate in the proposed reservation system, Utotal(P,T,Qperformance,Qavailability,Qreliability) can be expressed in 5 dimensions. For a simple expression, Utotal is expressed as a plane (3 dimensions for simplicity), as shown in Fig. 2. All combinations of price, timeslot, and QoS levels in this plane give the same aggregated total utility.

4.1.2 Price utility function Whereas consumers prefer the cheapest price for leasing a service, providers want to sell their services at the highest prices. Let IPC and RPC (IPP and RPP, respectively) be the most preferred (initial) price and the least preferred (reserve) price for a consumer agent (provider agent, respectively)). Let P be the price to be evaluated. For a consumer, the price utility UPC ðPÞ that represents the level of satisfaction on P is given as (
  RPC P  P P u þ 1  u min min   RPC IPC ; IPC  P  RPC UPC ðPÞ ¼ 0; otherwise: ð2Þ For a provider, the price utility UPP ðPÞ is ( 
   P ; uPmin þ 1  uPmin   IPPRP  RPP  P  IPP P RP P P UP ðPÞ ¼ 0; otherwise: ð3Þ In (2) and (3), uPmin is the minimum utility that a consumer and a provider receive for reaching a deal at their respective reserve prices. For the purpose of experimentation, uPmin is defined as 0.01. If a consumer or a provider cannot reach an agreement before its deadline, each of them receives a utility of 0 since not reaching an agreement is the worst possible outcome. 4.1.3 Time slot utility function This section includes an explanation of the timeslot utility function designed in (Son and Sim 2012). The novel time slot utility function is designed to model consumers’ and providers’ preferences for different time slots.

Table 1 Guidelines for translating the abstract preferences to the numbers (weights) Level of importance for each issue (user-level preference selection)

Preference weight (machine-level assignment)

0 (not important)

0

1 (not very important) 2 3 (moderately low importance) 4 5 (moderate) 6 7 (moderately high importance) 8 9 (very important) 10 (most important)

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0

Fig. 2 Utility plane of the aggregated total utility function

Inf Syst Front

Provider’s time slot utility function Providers prefer to allocate jobs: 1) to their earliest available time slots, and 2) to the time slots at which the job sizes can be accommodated to optimize resource utilization. Figure 3 shows the reservation queue for a service provider. The reservation queue consists of numbered time slots. The shaded time slots are reserved time slots and the blank time slots are unreserved time slots. LJ is the job size requested by a consumer. FTP and LTP in Fig. 3 are the first and the last time slots selected by the provider, respectively. LiA is the length of continuously available time slots from index i. A job can be allocated to one of the available time slots from i toi þ LiA  1, if LiA  LJ . Let wFF and wEF be the weights for early job (i.e., allocating a job to earlier time slots) and fitting job size, respectively, and wFF þ wBF ¼ 1 . The provider can place different combinations of emphases on the preferences for early jobs and fitting job sizes by varying wFF and wEF. The provider evaluates the priorities of available time slots indexed by i according to LJ and LiA , such that     LTP  i LJ i V ¼ wFF  þ wBF  : ð4Þ LTP  FTP LiA All indices of each set of available time slots are then prioritized according to Vi so that the priority of i which gives the highest Vi becomes 1 and the priority of i which gives the lowest Vi becomes the last number of the index set. Let fTP ðT Þ be a mapping function from the time slot T to a priority. For the mapping, fTP ðT Þ searches for the ith set of available time slots including time slots from T to T+LJ-1 and returns the priority of i. To transform the priorities for the indices of available time slot sets into the time slot utility P defined between 0 and 1, fTP ðT Þ is divided by NAT which is the number of available time slot sets. Consequently, the time slot utility UTP ðT Þ that represents the level of satisfaction on T is given as ( UTP ðT Þ ¼

P i
 h f ðT Þ1 uTmin þ 1  uTmin  1  TN P 1 ; AT 0;

FTP  T  LTP otherwise:

ð5Þ In (5), uTmin is the minimum utility that the provider receives for reaching a deal at its worst time (or least preferred) slot within FTP and LTP. For the purpose of experimentation, uTmin is defined as 0.01. If a provider cannot agree with a consumer on a mutually acceptable time slot before its deadline, it receives a utility of 0. LJ

FTP

LTP

Job 1

2

3

4

5

6

7

i

8

9

L

10 11 12 13 14 15 16 17

i A

Fig. 3 Reservation queue of time slots

...

N

Reservation queue

Consumer’s time slot utility function When reserving a Cloud service, a consumer generally describes diverse forms of temporal preferences with multiple sets of time slots. For example, time slot preferences of a consumer can be presented using four sets of time slots and their priorities: (1st:201, 2nd:195, 3rd:190, and 4th:206), where “201”, “195”, “190”, and “206” are the first indices of the time slots. Each set of time slots is associated with a utility value, and the time slot utility values defined between uTmin and 1 are uniformly assigned according to the priority. uTmin is the minimum utility that the consumer receives for reaching a deal at its worst (or least preferred) time slot within FTC and LTC which are the first time slot and the last time slot respectively. For the purpose of experimentation, uTmin is defined as 0.01. If a consumer cannot agree with the provider on a mutually acceptable time slot before its deadline, it receives a utility of 0. In addition, the available range of time slots for a consumer FTC and LTC are selected by the consumer. If the consumer does not specify utility values, the system assigns a default utility of uTmin to FTC and LTC. In the example in Fig. 5(a), “201” is assigned a utility of 1.0; “195” is assigned a utility of 0.75; “190” is assigned a utility of 0.50; “206” is assigned a utility of 0.25, and FTC and LTC are both assigned a utility of uTmin. Also, the time slot utilities of intermediate time slots between two time slot preferences given by the consumer are defined by a linear function. For example, the pair of time slot preferences [190, 195] given by the consumer generates a partial function, represented as a dashed line labeled “original point” connecting [190, 195] in Fig. 5(a). Similarly, the other sequential pairs of time slot preferences [195, 201] and [201, 206] also generate partial functions, represented as a dashed line labeled “original point” in Fig. 5(a). Then, the time slot utility is an aggregated function of all partial linear functions, and each partial function is generated by any two time slot preference points given by the consumer. Each partial function allows the consumer agent to determine the utility of an intermediate time slot between two time slot preference points given by the consumer. For example, in Fig. 5(a), the point represented by a “dot” which is labeled “interpolation between given preferences” is a point which is derived using the partial function generated by [195, 201]. However, a simple aggregation is insufficient for expressing the utility space because providers and consumers may have different utility spaces. Equation (6) specifies that both the surface areas under the respective time slot utility functions for a consumer and a provider are equal. Let UTC ðT Þ be C the time slot utility function for a consumer, NAT (respecP tively, NAT ) be the number of available time slot sets
within  FTC and LT (respectively, FT and LT ). Let Max UTC ðT Þ C P P
C  and Min UT ðT Þ be the maximum
Cand minimum utility values of
the time slots, and Max UT ðT
Þ is defined as 1   and Min UTC ðT Þ is defined as uTmin . Max UTP ðT Þ and Min

Inf Syst Front




 UTP ðT Þ can be defined in a similar way.

8 LT


 PP > P > > UTP ðT Þ ¼ NAT  Max UTP ðT Þ  Min UTP ðT Þ =2 < T ¼FTP

LT

 PC > > C > UTC ðT Þ ¼ NAT  MaxðUTC ðT Þ  Min UTC ðT Þ =2: : T ¼FTC

ð6Þ Equation (6) is based on the design consideration for a time slot utility function that provides a fair criterion for both a consumer and a provider in evaluating their time slot preferences. Without considering the fairness in this design, consumer agents tend to accept providers' proposal more (respectively, LT PC less) easily since the surface area UTC ðT Þ of the time slot T ¼FTC

utility for a consumer may be larger (respectively, smaller)
 C than NAT  1  uTmin =2 but the time slot utility function for a provider satisfies (6). Figure 4 shows the surface areas under the respective time slot utility functions for a provider and a consumer. In Fig. 4(a), the time slot utility function for a provider satisfies (6) since all available time slots are prioritized and normalized to the range of values betweenuTmin and 1. However, given the same number of time slots for a provider P C ¼ NAT , the surface areas under the and a consumer, i.e., NAT time slot utility function for a consumer in Fig. 4(b) and (c) may not satisfy (6) since the shape of the surface area is determined by a consumer’s inputs. Fig. 4(b) shows an example of the time slot utility function for a consumer where it has LT
 PC C a larger surface area (i.e., UTC ðT Þ > NAT  1  uTmin =2 T¼FTC

), and Fig. 4(c) shows an example of the time slot utility function for a consumer where it has a smaller surface area LT
 PC C (i.e., UTC ðT ÞNAT  1  uTmin =2 ). To design the time T¼FTC

slot utility function that satisfies (6), we need a process to LT LT PC PC transform the value of UTC ðT Þ in Fig. 5(a) so that T ¼FTC T¼FTC
 C UTC ðT Þ ¼ NAT  1  uTmin =2 . Since we should not change the utility values of the time slot preferences given by the consumer, this process transforms the interpolated points into tuned points (see Fig. 5(a)). All interpolated points and all LT PC given points are used to calculate UTC ðT Þ , and all

utility at Ti (i.e., ΔUTi ¼ UTC;interpolated ðT i Þ  UTC;tuned ðT i Þ ). Figure 5(a) includes the graph of the time slot utility function consisting of reference points (consisting of both tuned points and given inputs from the consumer) and the time slot utility LT
 PC C function satisfies UTC ðT Þ ¼ NAT  1  uTmin =2 . T ¼FTC

Figure 5(b) shows the details for determining the tuned points given in Fig. 5(a). Whereas Fig. 5(a) shows the time slot utility function which is a combination of linear functions, details of the linear function are described in Fig. 5(b). Let Thx be the head time slot of a linear function and Ttx be the tail time slot of the xth segment of the time slot utility function, and let Uhx be the utility of Thx and Utx be the utility of Ttx . The partial formula UTC ðT Þx located in between two adjacent tuned points (Thx and Ttx ) can be given as follows 8 ðU x U x ÞðT T x Þ > < Uhx t hx x h ; Utx > Uhx ðTt Th Þ ð7Þ UTC ðT Þx ¼ x x x U ð > : Utx þ h Utx ÞðxTt T Þ ; Utx Uhx ðTh Tt Þ The time slot utility function for a consumer that satisfies (7) can be formulated as follows. If T is at a given point, the consumer’s time slot utility function UTC ðT Þ is the given utility value at the given point of a consumer. For instance, UTC ð201Þ ¼ 1:0, UTC ð195Þ ¼ 0:75, UTC ð190Þ ¼ 0:5, UTC ð206Þ ¼ 0:25 , and UTC ðFTC Þ ¼ UTC ðLTC Þ ¼ uTmin ¼ 0:01 in Fig. 5. If T is at a tuned point, UTC ðT Þ is the tuned utility value derived from the interpolated utility value. If T is located in between Thx and Ttx , UTC ðT Þ is determined by UTC ðT Þx. Let T i and ΔUTi be the ith reference point and the utility difference between the interpolated utility and the tuned utility at Ti, respectively. Let Ti be a reference point between two other reference points Ti-1 and Ti+1, and the utility values of Ti-1 and Ti+1 are UTi1 and UTiþ1 , respectively.
i1  i 1 The interpolated utility of T
is 2 UT þ UTiþ1 . Hence,  the tuned utility at Ti is 12 UTi1 þ UTiþ1  ΔUTi . Then, UTC ðT Þ is given as follows 8 Given utility T ¼ Given point >  value; > > < UTi1 þUTiþ1 i  ΔUT ; T ¼ T i ¼ Tuned point 2 UTC ðT Þ ¼ > UTC ðT Þx ; Thx < T < Ttx > > : 0; T < FTC or T > LTC : ð8Þ

T ¼FTC

interpolated points are tuned by relatively decreasing (respecLT PC tively, increasing) their utility values until UTC ðT Þ ¼ T ¼FTC
 C  1  uTmin =2 . In Fig. 5(a), ΔUTi is the amount of NAT decrement (respectively, increment) of utility from (respectively, to) the interpolated utility for computing the tuned

4.1.4 Cloud QoS utility function In this work, three Cloud QoS issues are discussed. There are many QoS issues such as performance metrics, security attributes, (transactional) integrity, reliability, scalability,

Inf Syst Front Fig. 4 Surface areas under the time slot utility functions

a

b

U TP (T )

c U TC (T ) Consumer’ s

U TC (T ) Consumer’ s

1

1

input

input

1

0.5

0.5

0.5 LTC

LTP

U TP (T )

T umin

T FTP

P T

f (T )

T umin

LTC

U TC (T ) T FTC

T

P N AT

Generated time slot Interpolation utility function that Given between given Given preference preferences preference satisfies equation (6)

Time slot utility

1 0.8

UTi Tuned points

0.4 0.2

original point reference point

T umin 0 FTC

195 LTC 190 201 206 188 190 192 194 196 198 200 202 204 206 208 First index of a time slot

b

(

Time slot utility

reference point

U tx

Given point

0.8

U hx

Given point

0.6 0.4

Tuned point

0.2 T umin 0 FTC

Thx T Tt x

¼


  C  uXmin þ 1  uXmin   IXXCRX RXC  ; 0;

:

RXC  X  IXC otherwise:

ð9Þ

function derived from (7)

1

T C N AT

performance, 2) service availability, and 3) service reliability since these issues are not only essential non-functional requirements but also negotiable requirements for a Cloud service. The proposal and negotiation outcome for Cloud QoS is a satisfaction level presented as a percentage. For the purpose of simplicity, the QoS utility functions are modeled as linear and monotone functions.

UXC ðX Þ

UTC ( T ) x which is the linear 1.2

U TC (T ) T FTC

1) A generalized utility function for cloud QoS: Intuitively, consumers prefer the highest guarantee for a service quality X, and providers want to sell their services with the lowest guarantee for the service quality with a given price. Let IXC and RXC (IXP and RXP) be the most preferred (initial) service quality and the least preferred (reserve) service quality for a consumer agent (a provider agent), and let X be the service quality to be evaluated. For the consumer, the service quality utility UXC ðX Þ that represents the level of satisfaction on X is given as

1.2

0.6

T umin

C N AT

and availability discussed in service oriented computing (Papazoglou et al. 2007). Also, availability, security properties, reliability, and throughput were introduced in (Menasce 2002, Jafarpour and Khayyambashi 2010; Maximilien and Singh 2004). Whereas there are many possible QoS issues, some issues are less essential and negotiable. The Cloud QoS issues that are considered in this work are: 1) service

a

Consumer’ s input

Consumer’ s input

LTC

188 190 192 194 196 198 200 202 204 206 208 First index of a time slot

Fig. 5 Process of generating the time slot utility function of a consumer. (a) Generation of the time slot utility based on the given time slot preferences. (b) Segments of the time slot utility function

For the provider, the performance utility UXP ðX Þ is (
  RXP X  uXmin þ 1  uXmin   RX ; IXP  X  RXP P P IXP UX ðX Þ ¼ 0; otherwise: ð10Þ In (9) and (10), uXmin is the minimum utility that the consumer and the provider receive for reaching a deal at its reserve performance. For the purpose of experimentation, uXmin is defined as 0.01. 2) Service performance utility function: The service performance is defined as resource constraints or, throughput (the rate at which a service can process requests) or the response time (the delay from the request to getting a response from the service) of a Cloud service in this

Inf Syst Front

work. The performance utility represents the level of satisfaction about the provisioned resource constraints, throughput, or response time. The actual parameters for service performance can be specified by the consumer who requests a service. For example, in case of a virtual machine (VM) instance service which is an Infrastructure as a Service (IaaS), resource constraints such as the number of virtual CPUs, RAM size, and disk I/O bandwidth of the VM instance can be described by a consumer. The consumer and the provider who provides the VM service can negotiate level of the guarantee for the performance resource constraints. Likewise, in case of Software as a Service (SaaS), the service performance can be described by the service throughput or the service response time. Since both response time and throughput emphasize different perspectives, Cloud users can select either throughput or response time according to the type of services. For example, if a job requires a fast response, the response time would be a better representation method. If a job (usually a huge job) requires lots of data processing, the throughput would be a better representation method. In general, consumers prefer the highest guarantee for the service performance, and providers want to sell their services with the lowest guarantee for the service performance with a given price. Let Qp be the performance quality at which a consensus is reached by both parties. Q p is substituted to X in (9) and (10) which are generalized utility functions for cloud QoS so that the performance utility is UQp ðQpÞ for reaching a consensus at Qp where IX=IQp, and RX=RQp. 3) Service availability utility function: Availability is expressed as a percentage of uptime (i.e., the duration for which the service has been operational continuously without failure) of the service in reserved timeslots. A Cloud provider may dynamically control their resources by the availability agreement. For example, when an IaaS provider is facing lack of resources because of high demand of service requests, the provider may lower resource demand by pausing some of VMs according to the availability agreement. A consumer may select availability according to their budget. Intuitively, consumers prefer the highest guarantee for availability, and providers want to sell their services with the lowest guarantee for service availability with a given price. Let Qa be the performance quality at which a consensus is reached by both parties. Qa is substituted to X in (9) and (10) which are generalized utility functions for cloud QoS so that the performance utility is UQa ðQaÞ for reaching a consensus at Qa where IX=IQa, and RX=RQa.

4) Service reliability utility function: Reliability is the likelihood of successfully using a service. As Maximilien and Singh 2004 introduced, some aspects of reliability such as fault rate (the rate of invocation failure for the service’s methods), MTBF (mean time between failures), consistency (the failure rate’s lack of variability), recoverability (how well the service recovers from failures), failover (whether the service employs failover resources, and how quickly), and disaster resilience (how well the service resists disasters) can be the actual parameters of the reliability utility. Intuitively, consumers prefer the highest guarantee for service reliability, and providers want to sell their services with the lowest guarantee for service reliability with a given price. For example, when a consumer selected the fault rate as the actual parameter of the service reliability utility, 0 % of fault rate will give the highest reliability utility and 100 % fault rate will give the lowest reliability utility to the consumer. Let Qr be the performance quality at which a consensus is reached by both parties. Qr is substituted to X in (9) and (10) which are generalized utility functions for cloud QoS so that the performance utility is UQa ðQaÞ for reaching a consensus at Qr where IX=IQr, and RX=RQr. 4.1.5 Evaluation of a proposal using the utility functions Table 2 shows an example of personalized utility functions for a consumer and sample offers from a provider and utility calculation of the offers. Using the consumer’s preferences such as IPC =100 and RPC =300, a consumer agent can generate personalized utility functions. There are two offers of a set of proposals from a provider (1:[210, 195, 98, 90, and 88] and 2:[120, 290, 82, 78, and 64]). The utilities from the first offer are 0.455, 0.750, 0.950, 0.89, and 0.762. Therefore, the aggregated total utility is 0.717. On the other hand, the aggregated total utility of the second offer is 0 because the time slot utility is 0 for the time slot proposal 290TS. Since T=290>LTC =210, the provider’s time slot proposal is not acceptable according to the time slot utility equation (8). If any of negotiation issues is out of acceptable range, the aggregated total utility is 0 and the negotiation agent should deny the offer without considering proposals for the other issues. 4.2 Negotiation strategy 4.2.1 Concession-making algorithm The concession-making algorithm determines the amount of concession ΔUtotal for each negotiation round, and

Inf Syst Front Table 2 Sample offers and utility calculation of the offers Negotiation issue

Consumer’s preference

Personalized utility functions

Price

IPC =100 RPC =300 FTC =188 LTC =210 IQpC =100 RQpC =60 IQaC =95 RQac =50 IQrC =100 RQrC =50 wP =0.3 wr =0.3 wQp =0.2 wQa =0.1 wQr =0.1

UPC ðPÞ ¼

Time slot Service performance Service availability Service reliability Total aggregated issues



 300P  ; 100  P  300 0:01 þ ð1  0:01Þ  300100 0; otherwise:

UTC ðT Þ ¼ Fig. 5 (b) (example in Fig. 5) 

 Qp60   ; 60  Qp  100 0:01 þ ð1  0:01Þ  10060 : 0; otherwise:  Qa50   0:01 þ ð1  0:01Þ  9550 : ; 50  Qa  95 C UQa ðQaÞ ¼ 0; otherwise:   Qr50    0:01 þ ð1  0:01Þ  10050 : ; 50  Qr  100 C UQr ðQrÞ ¼ 0; otherwise: C UQp ðQpÞ ¼


 Utotal  P; T ; Qperformance ; Qavailability ; Qreliability 0; if either UP ¼ 0; UT ¼ 0; UQp ¼ 0; UQa ¼ 0; or UQr ¼ 0 ¼ wP  UP þ wT  UT þ wQp  UQp þ wQa  UQa þ wQr  UQr ; otherwise:

 ΔUtotal ¼

 tþ1 ¼ Utotal

BPA!B;t ¼



tþ1 t

Calculated utility

1) 2) 1) 2) 1) 2) 1) 2) 1) 2)

1) 2) 1) 2) 1) 2) 1) 2) 1) 2) 1)

210 120 195 290 98 82 90 78 88 64

0.455 0.604 0.750 0 0.950 0.554 0.89 0.626 0.762 0.287 0.717

2) 0

corresponds to the reduction in an agent’s expectation based on its total utility. Agents in this work adopt the timedependent strategies in (Sim 2005) to determine the amount of concession required for the next proposal and the corresponding expectation. Let t, C , and 1 be the negotiation round, the negotiation deadline, and negotiation strategy respectively. t and C are natural numbers where 0≤t≤ C and C >0 respectively; 1 is a rational number where 1 >0. (Sim 2005) defined the time-dependent strategies [conciliatory (0< 1 1)]. Finally, the expected total utility Utotal is a rational number and 0≤Utotal ≤1. Based on (11), the negotiation agent determines the amount of concession ΔUtotal and then (12) determines its expectation of the total utility in the next 0 t round. According to (12), Utotal ¼ 1 and Utotal ¼ 0 so that a negotiator can represent the highest expectation at the first negotiation round and the lowest expectation at the negotiation deadline, and the middle is decisively determined by the time-dependent strategies.

t Utotal

Provider’s offer

1 :

1; tþ1¼0 t Utotal  ΔUtotal ; O:W:

ð11Þ

ð12Þ

4.2.2 Tradeoff algorithm This section introduces the general idea of “burst mode”, which is designed to enhance both the negotiation speed and the aggregated utility. The burst mode is originally designed for concurrent negotiation for price and time slot in (Son and Sim 2012). In this work, we extend the application of it for concurrent negotiation of 5 negotiation issues. In general, a multi-attribute proposal P from agent A to agent B during negotiation round t can be represented as PA→B,t =(xt,yt,…kt) where x,y,…,k are elements of a negotiation attribute respectively. Hence, a negotiation agent can make only one multi-attribute proposal in a negotiation round. With the burst mode, agents are allowed to make a concurrent set of proposals, in which each proposal consists of different pairs of price, timeslot, and QoS levels that generates the same aggregated utility, but differ in terms of individual price, timeslot, and QoS utility. A burst multi-attribute proposal x from agent A to B during negotiation round t can be represented as BPA!B;t ¼


t t 

 x1 ; y1 ; . . . ; k1t ; xt2 ; yt2 ; . . . ; k2t ; . . . ; xtn ; ytn ; . . . ; knt where x,y,…,k are a concurrent set of proposals; these concurrent proposals are uniformly selected from the utility line to generate a burst proposal. Since there are 5 negotiation issues in the proposed reservation system (i.e., price, timeslot, performance, availability, and reliability), a burst proposal can be represented as


t t 

 P1 ; T1 ; Qp t1 ; Qa t1 ; Qr t1 ; P2t ; T2t ; Qp t2 ; Qa t2 ; Qr t2 ; . . . ; Pnt ; Tnt ; Qp tn ; Qa tn ; Qr tn

ð13Þ

Inf Syst Front

The opponent who receives a concurrent set of proposals evaluates all sets, and then it can select the best proposal that gives the highest utility among concurrent proposals in a negotiation round. Therefore, with the burst mode, a negotiating agent can provide more options for its opponent agent without making a concession. The novelty of this work is in the adoption of a new tradeoff algorithm, referred to as “adaptive burst mode”, which is designed to enhance both the negotiation speed and the aggregated utility and to select the efficient number of proposals encoded in a concurrent set of proposals (i.e., selecting value NP for burst- NP). The idea of adaptive burst mode consists of (i) selecting NPt (the number of proposals encoded in a burst proposal for each negotiation round) adaptively and (ii) applying a similarity-based tradeoff algorithm to the burst mode. (i) Adaptive number of proposals for a burst proposal An agent using the adaptive burst mode adaptively selects NP according to the utility difference between the current utility expectation and the utility of the best-offer t;DIFF proposed by the opponent. Utotal is the utility difference between the current utility expectation and the utility of the best-offer proposed by the opponent at negotiation round t. t;DIFF As Utotal decreases, the chance that the opponent accepts t;DIFF the proposal increases. A high value of Utotal means that the current utility expectations between negotiating agents are too different to reach an agreement even though negotiation agents propose many NPt in negotiation round t. If the t;DIFF is low at negotiation round t, the general value of Utotal burst mode with a fixed number of NP can provide more acceptable options for its opponent agent. However, if the t;DIFF value of Utotal is high at negotiation round t, having an excessively large number of proposals in a concurrent set of the general burst mode may not increase the chance that the proposals will be accepted by an opponent. Therefore, when t;DIFF the value of Utotal is high at negotiation round t, a negotiation agent does not need to make excessively many proposals in a concurrent set. Instead of using the general burst mode with a fixed number of NP, negotiation agents can adopt the adaptive burst mode that adaptively selects t;DIFF NPt at each negotiation round t.according to Utotal to select the efficient number of proposals encoded in a concurrent set of proposals. Figure 6 shows an example adaptively assigning the number of proposals for each negotiation round according t;DIFF t;DIFF to Utotal . As negotiation round elapses, Utotal decreases by the concession making algorithm, and the negotiation agent relatively increases the number of proposals in a burst proposal (NPt is determined by decreasing NPt ` relatively to t;DIFF ). The basis to calculate NPt is the preferred range of Utotal

timeslots (LT−FT, where FT is the first timeslot and LT is the last timeslot) since the timeslot utility function is the most complex utility function (i.e., a non-monotonic and a discrete function) in this work. Finally, the number of proposals encoded in a burst proposal NPt at negotiation round t is then given as  NPt ¼

1; t;DIFF ðLT  FT Þ  ð1  Utotal Þ;

t;DIFF t t ðUtotal ¼ 0; Utotal ¼ 1; Utotal ¼ 1Þ O:W:

ð14Þ

(ii) Similarity-based tradeoff algorithm In this research, the trade off algorithm is enhanced by using the concept of fuzzy similarity (Yan et al. 2007). The fuzzy similarity models the concept that the more similarity between the proposal and the “current-offer” from the negotiating opponent, the higher the chance to achieve the agreement of the negotiation. In choosing to make a trade-off negotiation action, an agent is seeking to find a contract that has the same score as its previous proposal for itself, but that may be more acceptable to (have higher score for) its negotiation opponent. However, the key problem here is how to select a contract that is likely to increase the score of the opponent, given that the agent does not know its preferences. To select the contract that is most “similar” or “close” to the opponent’s last proposal (since this may be more acceptable to the opponent) in the concurrent price, timeslot, and QoS negotiation, we need to consider the properties of the timeslot utility function. Whereas the proposed utility functions for price and QoS issues are defined using linear and monotonic functions, the proposed timeslot utility function is a non-linear, discrete, and non-monotonic function in the Section 4.1.3. Figure 7 shows the procedure for evaluation

Fig. 6 Adaptive selection of the number of proposals (Son and Sim 2010)

:

Inf Syst Front

of last proposal and generation of a burst proposal. To select the contract that is most “similar” or “close” to the opponent’s last proposal, the algorithm utilizes time slot proposals TkA!B from the opponent’s last proposals. If a proposed timeslot is not available as shown in Fig. 8, the proposal is not acceptable even though all proposals for each attribute except timeslot give high utilities because the aggregated total utility will be ‘0’. Therefore, this algorithm selects a time slot proposal advised by the similarity-rule. If the proposed timeslot by an opponent can be allocated in the reservation queue, select the exactly same position of timeslot for the timeslot proposal in the next proposal to the opponent. This is to increase the similarity between the received proposal and the next proposal that will be proposed to the opponent. Otherwise, if the proposed timeslot by an opponent cannot be allocated in the reservation queue (i.e., some of timeslots were already reserved by other jobs), then modify the position of timeslot to the next closest sections of the reservation queue and select the modified timeslot proposal for the timeslot proposal in the next proposal to the opponent. Figure 8 shows the adjusted time slot proposal of a provider. Since the change of the total utility of the proposal from the opponent is less, the opponent who receives the next proposal can receive a similar proposal with the proposal that was proposed by itself in the last negotiation round. After the timeslot proposal is selected, the other proposals for each attribute have to be selected to generate the aggregated proposal that can express the current expected utility. First, the scheme subtracts the weighted timeslot Fig. 7 A similarity rule to generate an adaptive proposal

utility of the selected timeslot proposal from a given total utility in the current negotiation round according to the concession algorithm (i.e., current total utility). The other proposals for each attribute are randomly generated to fulfill the total utility that remains. Finally, the adaptive burst proposal consists of proposals generated by using similarity rule and proposals randomly generated as shown in Fig. 9. Even though the similarity rule gives a higher utility, we should not adopt the similarity rule for all proposals in a burst proposal. If the agent adopts a similarity rule for all proposals, time slot proposals quickly (within few negotiation rounds) converged into some values, and time slot proposals lose diversity. For example, when NPt is 5, let us assume that agent B proposed a burst proposal with the time slot proposals [32, 42, 50, 20, and 5] to agent A. Agent A modified the time slot proposals to [32, 40, 55, 18, and 5]. If the timeslot proposals [32, 40, 55, 18, and 5] are available for agent B, agent A and B will not propose different time slot proposals in the future negotiation rounds.

5 Agent-based cloud testbed The agent-based Cloud testbed is designed and implemented using JAVA and JADE (Java Agent Development Framework) to demonstrate the proposed ideas. Figure 10 shows the agent-based Cloud Testbed. There are many consumers and service providers in this Cloud market, and the Cloud testbed has consumer agents and provider agents acting on

Attributes Parser

Timeslot utility function Price utility function

Proposal Queue

Performance utility function

Aggregated Total Utility Function

Availability utility function

A burst proposal from an opponent

Reliability utility function

Attributes Concatenator

Proposal Queue

A burst proposal to the opponent

Timeslot Proposal generator Price Proposal generator Performance Proposal generator Availability Proposal generator Reliability Proposal generator

Proposal Evaluator

Current Expecting Utility

Proposal generator

Inf Syst Front TS- Proposal from a consumer

6

8

1) When a negotiation session starts, the negotiation round t of a consumer agent is 1

9

i

FTP 1

7

2

3

4

5

LTP 6

7

8

9

10 11 12 13 14 15 16 17

Adjust TS proposal

...

N

Reservation queue of a provider TS- Proposal to the consumer

7

8

9

10

Fig. 8 A similarity rule for proposing timeslot

behalf of consumers and providers. The roles of each component in the testbed are summarized in Table 3. All agents in this testbed such as Cloud service providers and consumers participate in the Cloud market through the Cloud market registry. All agents are registered in the Cloud market registry implemented using the JADE Directory Facilitator (DF). All consumer agents connected to the Cloud market registry can recognize and communicate with each provider agent. A provider agent and a consumer agent generate service descriptions and specify their preferences on service name, price, time slot, QoS requirements, and a negotiation strategy using a Cloud service reservation GUI. For Cloud service reservation, the testbed provides a simple service discovery functionality which assists consumers in finding a cloud provider that has the Cloud service a consumer needs. In the testbed, provider agents represent and block agreed time slots by marking the memory array, and notify reservation results to a contracted consumer. Therefore, provider agents in the testbed emulate a Cloud environment using a memory array for a Cloud service reservation queue. The main role of the provider and consumer agents is a bilateral negotiation. In the provider and consumer agents, the proposed Price-Timeslot-QoS negotiation mechanism is implemented. For each negotiation round, a negotiation agent generates a proposal to offer its opponent the proposal. The utility functions and the negotiation strategy which consists of concession and tradeoff algorithms are incorporated to generate a proposal. The detail procedures with examples for a consumer agent are as follows. The main stages in a negotiation session are 1) the initial stage, 2) an intermediate stage, and 3) the final stage (there are two conditions to end the session: proposal is accepted or negotiation deadline is reached). Using similarity

BPA

B,t

Random generation

SP SP SP SP SP SP

P P P P P P

N Pt Fig. 9 A burst proposal using similarity rule

A. The total utility that the consumer expects Utotal is 1.0 (initially, the consumer expects the highest utility). B. To generate an initial proposal to the opponent, the consumer agent refers current utility expectation which is Utotal =1 and generates an individual proposal for each negotiation issue (i.e., price, time slot, performance, availability, and reliability). To generate an individual proposal of a negotiation issue, a value for individual utility is selected on the condition that aggregation of all individual utilities for the five negotiation issues should be same with Utotal =1. Since wP þ wT þ wQp þ wQa þ wQr ¼ 1, all individual utility values should be 1 (i.e., UP ðPÞ ¼ 1; UT ðT Þ ¼ 1; UQp ðQpÞ ¼ 1; UQa ðQaÞ ¼ 1; UQr ðQrÞ ¼ 1 ). From the individual utility value, the agent can find an individual proposal ( P; T ; Qp; Qa; Qr ) using the utility function designed in Section 4.1. For instance, the agent refers the time slot utility function UT(T) (Fig. 11 shows an example of UT(T)) to find T where UT(T) =1 so that the agent can generate the time slot proposal T at the initial round. C. Since the number of proposals encoded in a concurrent set of proposals (i.e., selecting value NP for burst- NP) in the initial round is 1 according to (14), the agent encodes only one proposal in a burst proposal. 2) In an intermediate negotiation stage (e.g., t=10) A. The consumer’s expectation Utotal is determined by (11) in an intermediate stage. Let Utotal =0.7 as an example. B . T h e a g e n t r e c e i v e s o p p o ne n t ’s p r o p o s a l BPProvider→Consumer,10 and evaluates the proposal using the utility functions (choose the best proposal among proposals encoded in a burst proposal). Let Opponent Utotal ¼ 0:4 as an example. C. In this example, since opponent’s offer is not acceptable and the negotiation deadline is not reached Opponent yet (Utotal > Utotal , negotiation deadline is 50), the agent denies the offer and generates a counter proposal. D. To generate a proposal to the opponent, the consumer agent refers current utility expectation which is Utotal =0.7. Figure 11 shows an example of the procedure for burst proposal generation. First, the agent randomly generates a set of individual utilities (UP,UT,UQp,UQa,UQr) that satisfy wP  UP þ wT  UT þ wQp  UQp þ wQa  UQa

Inf Syst Front

Cloud Simulation Controller

Consumer GUI

Consumer Agent 1

Provider Agent 1

Consumer GUI

Consumer Agent 2

Provider Agent 2

Consumer GUI

Consumer Agent k

1 2 3 4 5

...

N

Reservation queue

1 2 3 4 5

...

N

Reservation queue

Provider GUI

Provider GUI

Invoking consumers

Negotiation session

Provider Agent i

1 2 3 4 5

...

N

Reservation queue

Provider GUI

Reservation queue

Consumers

Cloud status recorder

Service providers register

Agent registration

Cloud market registry

Agent registration

Recording outcomes

Fig. 10 The agent-based Cloud Testbed

þwQr  UQr ¼ 0:7. Let the individual utilities be UP,1,UT,1,UQp,1,UQa,1,UQr,1, then the matched individual proposals are P110, T110, Q p110, Q a110, Qr110 according to the utility function designed in Section 4.1. These individual proposals are an aggregated single proposal. E. In an intermediate session, the number of proposals encoded in a burst proposal NP is adaptively determined according to the utility 10;DIFF difference Utotal between the current utility expectation and the utility of the best-offer proposed by the opponent at negotiation round 10. In this example, NP at the round 10 is 30. Therefore, the agent repeats the previous step ‘D’ to generate a single proposal thirty times and encodes the single proposals in a burst proposal. So, there are 30 proposals encoded in a bust proposal at t=10 as follows.


BPConsumer!Provider;t¼10 ¼ P110 ; T110 ; Qp 10 ; Q 10 1 ;

1 10 a 10 10 10 10 10 10 10 Qr 1 Þ; P2 ; T2 ; Qp 2 ; Qa 2 ; Qr 2 Þ; . . . ; P30 ; T30 ; 10 10 Qp 10 30 ; Qa 30 ; Qr 30 Þ. Among the 30 proposals, 15 proposals are generated according to the similarity-based tradeoff algorithm in Section 4.2.2 (i.e., generate a similar time slot proposal to a recent time slot proposal of the opponent). 3) The final stage, condition 1: when opponent’s offer is accepted (e.g., t=23) A. The consumer’s expectation Utotal is determined by (11) in an intermediate session, and let Utotal =0.55. B . T h e a g e n t r e c e i v e s o p p o ne n t ’s p r o p o s a l BPProvider→Consumer,23 and evaluates the proposal using the utility functions (choose the best proposal among proposals encoded in a burst proposal). Let Opponent Utotal ¼ 0:56 as an example.

Table 3 Components of the agent-based Cloud testbed Component

Roles

Provider agent Consumer agent

Service provider, Service advertisement, price-timeslot-QoS negotiation Service consumer, Service discovery, price-timeslot-QoS negotiation

Cloud market registry Cloud simulation controller Cloud status recorder

Agents information repository Simulation controller for a periodic simulation Status recorder for information of Cloud market and negotiation outcomes from all negotiation sessions in the market

Inf Syst Front Fig. 11 The procedure for a burst proposal generation

C. In this example, since opponent’s offer is now Opponent ), the agent accepts acceptable ( Utotal < Utotal the offer and finalizes the negotiation session. 4) The final stage, condition 2: when the negotiation deadline is reached (e.g., t=50)

of the negotiation mechanism in terms of the outcomes for negotiating for price, timeslot and QoS for Cloud service reservation.

A. The consumer’s expectation Utotal is determined by (11) in an intermediate session, and let Utotal =0. B . T h e a g e n t r e c e i v e s o p p o ne n t ’s p r o p o s a l BPProvider→Consumer,10 and evaluates the proposal using the utility functions (choose the best proposal among proposals encoded in a burst proposal). Let Opponent Utotal ¼ 0:1. C. In this example, since opponent’s offer is not acceptable and the negotiation deadline is reached yet Opponent (Utotal > Utotal , t=50, and negotiation deadline is 50), the agent denies the offer and finalizes the negotiation session (i.e., negotiation failure).

To evaluate the performance of the adaptive burst mode, we used 1) negotiation speed, 2) average total utility of the negotiation pair, and 3) the number of proposal evaluations as the performance measures which are important measures to evaluate a negotiation mechanism in general. The negotiation speed S is a function of the negotiation rounds R spent in the negotiation. S→0 means the negotiation has a lower speed and S→1 means the negotiation has a higher speed. The average total utility of the negotiation pair shows the level of satisfaction in terms of price, timeslot, and QoS with the agreed upon service. The average total utility of the negotiation pair is the main system performance indicator since it reflects whether the proposed negotiation mechanism can help the users find a common interest which will increase utilities of both the consumer and provider while they have opposite preferences. Finally, the number of proposal evaluations is a measure to quantify the computational load of the negotiation mechanism. A more detailed expression of the performance measures is given in Table 4.

In addition, the testbed includes the simulation functionalities with the Cloud simulation controller and the status recorder. The Cloud simulation controller can periodically invoke a consumer agent to start a service reservation with a provider. When the controller invokes a consumer agent or a new provider agent, the controller automatically generates random values for a resource reservation and transmits the values to the GUI of the consumer agent. Also, the Cloud status recorder records all results of negotiation and reservation.

6 Simulations and empirical results A series of experiments was carried out using the agentbased Cloud testbed (Section 5) to evaluate the performance

6.1 Performance measure

6.2 Experimental setting Tables 5 and 6 show the input data sources for the experiments, and include the experimental settings for a Cloud market (Table 5) and user preference (Table 6) for a Cloud service. The input data sources of the Cloud market are parameters for the Cloud simulation controller. In the experiments, a Cloud market consists of 200 provider agents and 200 consumer agents to examine the performance of the

Inf Syst Front Table 4 Performance measure

Total number of proposals evaluated

S ¼ 1  R=Minðt C ; t P Þ
P

 aver: C Utotal ¼ Utotal P; T ; Qp ; Qa ; Qr þ Utotal P; T ; Qp ; Qa ; Qr =2 tC tP P P NPtotal ¼ NPt;P!C þ NPt;C!P

Min(τC,τP) R NPt;P!C NPt;C!P

The shorter deadline between a consumer and a provider Number of rounds spent until the end of negotiation The number of proposals evaluated by the consumer at round t The number of proposals evaluated by the provider at round t

Negotiation speed (0–1) Average total utility of negotiating pair (0–1)

t¼1

reservation system in a balanced Cloud market. They are automatically generated by the controller, and the controller randomly invokes a consumer 300 times for each simulation case to start a service reservation. We note that market dynamics are not considered in this experiment. The Cloud load (0 ≤CL ≤1) in Table 5 represents and simulates different levels of utilization of the Cloud service in the Cloud environment. CL is defined here as the ratio of: 1) Ntot —the total number of timeslots in the reservation queues of all service providers, and 2) Nres —the number of reserved timeslots. To simulate the uniformly distributed loads to all service providers, each provider agent automatically fills their reservation queue with uniformly distributed virtual reservations from the simulation settings, up to a given CL. For user preference values, the settings are given in Table 6 for each consumer agent and provider agent to emulate human behaviors in a market. In the experiments, some variables (e.g., IP, RP, FT, LT, IPL, RPL and job size) were controlled as extraneous variables for studying the effects of independent variables such as CL, negotiation strategy, and negotiation deadline because it is hard to simulate all possible combinations of input negotiation parameters due to space limitations. Every agent randomly selects the weights that satisfy wP þ wT þwQp þ wQa þ wQr ¼ 1 in the simulations to emulate diverse preferences on non-functional requirements of Cloud consumers and providers. Also, since it is hard to simulate real human behaviors, we made three assumptions in this simulation as follows. 1) A consumer and provider have a similar interest area in the negotiation issue. For instance, the interest area of both a consumer and provider in the service price is 10$–250$. 2) A consumer and provider have an opposite preference in the negotiation issue. For example, consumer’s IP (RP) and provider’s IP (RP) are opposite. 3) For the Table 5 Input data source: cloud market

t¼1

negotiation parameters (the negotiation strategy and deadline), a negotiator can select one of strategies (conciliatory, linear, or conservative) and one of deadline types (a short deadline: 50 rounds or a long deadline: 200 rounds). The settings shown in Table 6 follow the assumptions. 6.3 Simulations Empirical results were obtained for some representative combinations of the input data (i.e., {C C: C P} = {50:50, 50:200, 200:50, 200:200}, CL={0.1, 0.3, 0.5, 0.7, 0.9}, and negotiation agents adopting 1 C ={1/3} and 1 P ={1/3}, 1 C ={1.0} and 1 P ={1.0}, or 1 C ={3.0} and 1 P ={3.0}). The performance measures (i.e., negotiation speed, average total utility of the negotiating pair, and computational load) were then simulated for all burst modes while changing the number of proposals in each burst proposal (i.e., B10, B50, and B100), adaptive burst mode (i.e., AB), and related schemes (i.e., M1, R1, and H1). M1 refers to a tradeoff scheme that selects a middle point of total utility line to generate a tradeoff proposal. R1 refers to a random selection of total utility line to generate a tradeoff proposal. H1 refers to a heuristic selection that uses the similarity on utilities between negotiation agents that suggests if the utility of an agent’s proposal and that of the opponent’s proposal are similar, there is a high chance that the opponent will accept the agent’s proposal (Yan et al. 2007). In Fig. 12 from (Yan et al. 2007), a negotiation agent identifies a point which has the shortest distance from an opponent’s “best-offer” and t lies on the line labeled Utotal . This point is the perpendicular projection point (PPP) of an opponent’s “best-offer” on the t . If PPP lies on the acceptance range of line labeled Utotal utilities (the utility plane – shown as a shaded square region

Input data

Settings

Cloud Load(CL ¼ Nres =Ntot ) No. of provider agents No. of consumer agents Cloud services a provider provides No. of negotiation sessions per each simulation case

0≤CL≤1 200 service provider agents 200 consumer agents 200 services/provider (randomly selected) 300 negotiation sessions

Inf Syst Front Table 6 Input data source: user inputs for service reservation

Input Data

Annotation

10–60 200–250 10–60 300–350 50–100 0–49 50–100 0–49 50–100 0–49

200–250 10–60 10–60 300–350 0–49 50–100 0–49 50–100 0–49 50–100

Job size Negotiation Strategy(λ)

Integer (Cloud time unit) Conciliatory( 1) Integer (Round unit)

2–8 1/3( 1) 50 rounds 200 rounds

2–8 1/3(