1 Introduction

A Cloud market is the culmination point of stakeholders providing and requiring services. Recently, Gartner predicted a growth of 38.6% for the Infrastructure as a Service (IaaS) market in 2017 [12]. Infrastructure services such as virtual machines (VMs) are mainly traded on provider platforms whereby Amazon Web Services (AWS) with the EC2 platform is market leader [9]. Amazon EC2 supports four different marketspaces for trading virtual machines: (i) On the reservation marketspace consumers and providers have a long-term relationship with a fixed, predefined price. (ii) A marketspace exists where consumers can resell virtual machines with a long-term contract - which were purchased on the reservation market - to other consumers. (iii) Consumers on the on-demand marketspace pay per hour for a virtual machine whereby the prices are higher than the prices on the reservation marketspace. (iv) The spot marketspace is more dynamic: here consumers can bid for virtual machines. The higher the bid, the higher is the chance of getting the virtual machine. The recent development of Amazons spot marketspace - with spot blocks and spot fleet management - shows that dynamic Cloud markets are gaining popularity. The notion of such a dynamic Cloud market is not a simple buyer-seller relationship, there are numerous other intermediaries involved in it. Papers of e.g. Weinmann [31, 32] consider intermediaries as important players on future Cloud markets - see also [3, 8, 20]. Strategies as well as a detailed analysis of the impact of such intermediaries are missing. We envision a whole network of market participants which negotiate autonomously with each other against end-user requirements resulting into binding SLAs and consequently to a temporary value network. During negotiation the participants exchange offers and counteroffers - such negotiations are called Bazaar-based negotiations - see e.g. [17, 24] for our previous work on this topic. Specifications such as the Web Service Agreement Negotiation specification (WS-Agreement) [30] support the development of such Bazaar-based Cloud markets. Due to the high number of different market participants as well as the infinite number of possible negotiation strategies, simulation environments are an eligible approach to assess the success of negotiation strategies under changing market conditions. For simulating such markets no appropriate frameworks exist: (i) The framework wsag4j [33] allows to create WS-Agreement documents in Java but has no simulation capabilities. (ii) The simulation environment greenCloud [14] was developed by the University of Luxembourg. It focuses on the simulation of energy consumption of Cloud infrastructures only. (iii) iCanCloud [21] is a Cloud simulation framework for analyzing trade-offs between costs and performance of a given set of applications executed on a certain hardware. (iv) Genius is a generic simulation environment focusing on negotiations without any Cloud specific simulation capabilities. (v) The CloudSim framework [5] was developed at the University of Melbourne and is widely used in the scientific community. It is able to simulate Cloud datacenters but no Cloud markets.

The previous ICCS conferences underpin a trend towards domain-specific simulation environments in the scientific community - see [1] for a detailed analaysis. So e.g. in [7] the authors present a simulation approach for search engine services with the special aim on measuring the impact of different configurations on the performance. In [11] the authors focused on simulating financial portfolios for stress testing scenarios with Suppes-Bayes Causal Networks while in [19] the authors developed a simulation environment for evacuation scenarios at the Gdansk University of Technology. Unlike generic simulation environments such as e.g. GeniusFootnote 1 domain-specific simulation environments are designed for simulating a narrow domain comprehensivelyFootnote 2.

Due to the lack of a simulation environment which is able to simulate the envisioned Bazaar-based Cloud market we developed our own simulation environment based on CloudSim. This framework (i) is well known by the community and, (ii) offers Cloud specific simulation capabilities. The subject of negotiation of our simulation environment is a virtual machine as an example of a Cloud service.

The remainder of the paper is structured as follows: In the following section we present foundations of Cloud markets. The architecture of the simulation environment is summarized in Sect. 3 while an overview of the implemented simulation environment is given in Sect. 4. Section 5 contains a summary of a use case which we executed with the simulation environment. The paper closes with the conclusion in Sect. 6.

2 Background

Amazon’s EC2 on-demand marketspaceFootnote 3 is an example of a platform which applies the supermarket approach. Here, consumers and providers trade services without negotiating price and service characteristics. More dynamic market mechanisms are currently emerging - see e.g. Amazon’s EC2 spot marketspaceFootnote 4. The scientific community suggests e.g. auction-based approaches  [4, 28] or bilateral negotiation-based approaches [10, 23] for future Cloud markets. Latter are based on the alternating exchange of offers which leads to negotiation trees - hence they are called Bazaar-based negotiations. The WS-Agreement Negotiation standard [30] is maintained by the Open Grid Forum and aims on specifying such negotiations. It is an extension to the WS-Agreement standard [2] and describes a XML based structure of offers as well as their possible states. In total the WS-Agreement Negotiation standard defines four states of offers. These four states and their transitions are illustrated in Fig. 1a.

Fig. 1.
figure 1

Offer states and architecture of the simulation environment

Full size image

An offer in the advisory state requires further negotiation as it is e.g. not completely specified. The solicited state is used for offers which are completely specified. The negotiation party which receives such an offer has to either accept the offer so that the state of the offer becomes acceptable or reject it which leads to the state rejected. Acceptable offers might result into agreements. Agreements are offers to which consumers and providers agree. Offers in the acceptable state of the WS-Agreement Negotiation standard are not binding: The ACCEPTABLE state indicates that a negotiation participant is willing to accept a negotiation offer as it is. But it is also described that there is no guarantee that a subsequent agreement is created. So in [16] we extended the specification by introducing a binding state. The rejected state is used for offers which are rejected. To improve the readability of the paper we call offers in the acceptable state acceptable messages, offers which are in the rejected state are termed reject messages and offers which are in the solicited state are called solicited messages. We use the term offers to either refer to all offers or to refer to offers in the advisory state - it should be clear from the context.

While the WS-Agreement Negotiation standard describes XML based offers and different states of offers, a concrete negotiation strategy is not specified. We surveyed existing bilateral service negotiation strategies in [25] but we have not found any WS-Agreement Negotiation compliant negotiation strategy. However, the need for WS-Agreement Negotiation compliant strategies was emphasized in [22, 27]. Descriptions of negotiation frameworks such as in [13, 18] elaborate on the importance of the WS-Agreement Negotiation standard without introducing compliant strategies. The negotiation strategy introduced in [34] mentions the WS-Agreement standard but does not use the WS-Agreement Negotiation standard. Instead, the strategy was developed to comply with the FIPA standard. In [29] a bilateral negotiation strategy was introduced. Thereby, the WS-Agreement Negotiation standard is mentioned but not considered for the introduced negotiation strategy. In [26] foundations of the simulation environment were introduced without a concrete negotiation strategy and use case.

Our analysis shows that the scientific community introduced bilateral SLA negotiation strategies. However, a systematic analysis of these strategies under changing market conditions is missing as well as a simulation environment which allows to asses and compare them.

3 Architecture Overview

Our simulation environment implements the concepts of the WS-Agreement standard described in Sect. 2. A high level architecture of the simulation environment is depicted in Fig. 1b. The simulation environment is based on CloudSim and uses fxyz for the creation of the 3D-View. There are three different types of participants: datacenter (representing providers), intermediary and broker (representing consumers). They inherit the structure and behavior of the CloudSim entity. Each entity has a negotiation manager which acts as a gateway: it forwards received messages to the corresponding negotiations. The negotiation component is a container which stores the negotiation history. Further, it has a reference to the used negotiation strategy. The components are detailed in the following paragraphs.

Negotiation Messages. Bazaar-based negotiations are characterized by the alternating exchange of offers between market participants. These offers are stored in messages - also termed events. In CloudSim, a event has three important fields which are summarized in Fig. 2a:

  • The content of a message is stored in the field MsgContent which is of type Object.

  • The type of a message is represented by the field MsgType. It is an integer and also termed tag. For example, the integer 2 represents the type of message \(Register\_Resource\). It is used by datacenters to register at the CISFootnote 5.

  • Each entity has an id which is used by CloudSim to deliver messages. This id is stored in the To field.

Fig. 2.
figure 2

Message structure and negotiation example

Full size image

For the simulation environment we created tags representing the offer states defined in the WS-Agreement Negotiation specification.

Precondition for running negotiations on CloudSim is the exchange of offers. Therefore, the message content field cloud be used. A sender has to add its offer to the field MsgContent, set the type of message and set the destination using the to field. As CloudSim adds the entity id of the sender to CloudSim messages, the receiver is able to identify the sending entity - also termed source. Hence, entities could negotiate in parallel as Fig. 2b shows. Here, broker 2 negotiates with two datacenters in parallel. Entity 3 uses the added source field to distinguish between the two brokers. However, if an entity requires virtual machines e.g. for two different systems then it has two negotiations in parallel with another entity such as a datacenter. In such a case e.g. broker 3 is able to distinguish between the different entities using the source field. However, it is unable to distinguish between different negotiations with the same entity. This issue underpins the need of a negotiation id. Instead of adding offers directly to the message content field we suggest to use an intermediary object of type NegotiationMessage which is added to the field MsgContent. The most important fields are shown in Fig. 3a.

  • Each negotiation message has an unique id (UDDI).

  • Each negotiation message stores a reference to the preceding negotiation message (if existing).

  • The source field represent the id of the entity which created the negotiation message. It is part of the negotiation message to simplify it’s processing.

  • In the field VM the offered virtual machine is stored.

Fig. 3.
figure 3

Negotiation message and summary of the high level strategy

Full size image

Negotiation Manager. The negotiation manager is responsible for two tasks: forwarding negotiation messages and creating new negotiations. An example is depicted in Fig. 4. The CloudSim framework uses the entity id of the destination (field to) for forwarding messages. In the illustrated example, CloudSim forwards the message to the entity with the id 1. A negotiation entity - an entity which we introduced with our simulation environment - passes received messages to its negotiation manager. The negotiation manager checks, if the received message is a negotiation message (as described before). In such a case, the negotiation manager accesses the negotiation message stored in the received message and forwards it to the corresponding negotiation. If the negotiation does not exist, then the negotiation manager has to create one. In cases in which the received message is not a negotiation message the negotiation manager ignores it.

Fig. 4.
figure 4

Forwarding negotiation messages to the corresponding negotiation

Full size image

Negotiation. The negotiation component acts as a container which stores the negotiation id as well as the negotiation history. Further, it has a reference to the used negotiation strategy - see next paragraph. The negotiation strategy creates offers which it forwards to the negotiation component, which forwards the offers to the negotiation manager. The negotiation manager adds the source to the negotiation message and forwards the message to the CloudSim framework which delivers the offer.

Strategy. The simulation environment simulates Cloud markets. Each market participant uses a negotiation strategy. The strategy is responsible for deciding how to repose to received offers. The user of the introduced simulation environment is responsible for creating them and assigning the strategies to the market participants. For test purposes, we implemented initial negotiation strategies which follow the high-level strategy process illustrated in Fig. 3b. The figure contains dark boxes as well as dashed boxes. Former are components of the strategy which are shown in Fig. 1b. Latter will be discussed in the following use case section. The process starts with the collection of received offers. Then, these offers are ranked. Thereby, utility functions such as described in [23] are usedFootnote 6. The ranking of the offers is the precondition for making decisions - in Fig. 3b the decision maker decides if an offer is rejected or if a counteroffer (an advisory message) is created. In all the other cases offers in the states acceptable and solicited will be created.

4 Simulation Environment

CloudSim supports the simulation of technical algorithms such as allocation algorithms which map physical resources to virtual resources (time-shared, space-shared) and VM placement algorithms (which determine which host runs which virtual machine). The negotiation process is usually executed before VMs are placed on datacenters. Free capacities - which is determined by the used technical algorithms - might be considered by negotiations strategies during negotiations. For our simulation environment we created a result view. Figure 5a depicts the structure of it. The numbers in the figure represent three sections. The main section is Sect. 3 which composes the menu bar as well as the other two sections. Section 1 shows the participants of the simulated market. By selecting a negotiation of a market participant its negotiation details are loaded into Sect. 2 which consists of two visualizations:

  • The exchanged offers of a negotiation are visualized in a tree list. Each offer contains a description of a virtual machine - it’s characteristics are shown in in the rows of the tree list.

  • The utility-utility plot visualizes the tree list. As Fig. 7a shows, the ordinate shows the utility of the offers for the selected market participant (from Sect. 1) while the abscissa shows the utility of the offers of the negotiation partner. The points in the plot represent the exchanged messages which contain the offered VMs. The utility evaluator is responsible for assigning utility values to offers. The different colors indicate in which iteration an offer was exchanged. So e.g. the negotiation starts with an initial offer represented by a red point. The negotiation partner responds to this offer with counteroffers which are visualized by the green points. It is possible to calculate the Pareto-border which visualizes the efficiency of the exchanged offers.

The messages exchanged during negotiation can be further visualized using a 3D-Plot which is shown in Fig. 5b. Thereby, the white dots represent the offers while the axis represent the characteristics of the VMs contained in the offers. So the red axis represents the RAM, the blue axis represents the storage while the green axis represents the processing power.

Fig. 5.
figure 5

Screenshots of the simulation environment

Full size image

Evaluations such as scalability test are out of the scope of this paper. Scalability tests for CloudSim are published in [6].

5 Use Case

In this section we summarize a consumer-provider negotiation scenario. Following the high level strategy depicted in Fig. 3b three components are necessary for a negotiation strategy. The dashed boxes show how we implemented these components for the use case. For the use case we reverted to utility functions developed in [23]. They are depicited in Table 1. The min/max values are part of the utility functions introduced in [23]. Usually, neither consumers nor providers will publish these values and so in our simulation environment market participants can not see these values of other market participants. U is a typical example of a utility function used by a consumer where the utility value increases with additional VM resources. For the decision maker predefined utility values were used as threshold. A genetic algorithm is used for creating counteroffers and considers the valuation of negotiation partners in the fitness function as suggested in [15]. By assuming that the utility functions of the negotiation partners are unknown the creator of a counteroffer has to estimate the utility functions used by the negotiation partners. This assumption is typical for bilateral negotiations - see e.g. [10]. The utility function \(\hat{U}\) in Table 1 represents an estimation of a typical utility function which is used by a provider and which represents the profit contribution. For example 0.001 are the estimated costs for 1 MB RAM. The most important parameters are summarized in Table 1. With a focus on demonstrating the described genetic algorithm we assumed these parameters. In the paper at hand we focus on the genetic algorithm only.

In the following we use the vector \((x_{1},x_{2},x_{3},x_{4})\) for describing the characteristics of a virtual machine. The first element of the vector, \(x_{1}\) represents the storage (GB), \(x_{2}\) represents the processing power (MIPS), \(x_{3}\) represents the RAM (GB) and \(x_{4}\) represents the price ($). In the following, we describe the main components of the used genetic algorithm. The individuals generated using the genetic algorithm represent counteroffers.

Population. The population consists of the virtual machines which can be represented using the vectors introduced before. They are the individuals. We identified two options for generating the initial population.

  1. 1.

    The initial population is generated randomly without considering received offers.

  2. 2.

    The initial population is generated based on the received offer.

By using option 1 individuals will be created randomly so that they may not have a utility for the sender as well as for the receiver - more details are described in the following paragraph. Therefore, we used option 2. Here the initial population is created by modifying the received offer. For example, an individual is created by changing one of the before-mentioned characteristics of a virtual machine. So an individual could be created by modifying the RAM of the received virtual machine. Due to the following mutation and crossover operations the generated individuals will have less similarity with the received offers. However, they are more similar to the received offer than offers which are generated from a random initial population which is implied by option 1.

Fitness Function. The introduced fitness function aims on representing the utility of an offer for the sender as well as for the receiver. This results into a fitness function which has two components. The first component reflects the utility of an offer for the sender while the second component reflects the utility of an offer the receiver. As the sender does not know the utility function of the receiver it uses an estimated utility function \(\hat{U}\) for the second component while it uses its own utility function for the first component. For generating estimated utility functions techniques such as genetic programming could be used. They are part of our further research and so they are not described in this paper. A high fitness value of an individual is an indicator that it has utility for the sender as well as for the receiver of the offer. Consequently, the probability that the offer is accepted is high.

However, the used estimated utility function could be imprecise so that an individual with a high fitness value might not have value for the receiver of the offer. In other words, the high fitness value could be result of a wrong estimated utility function. To avoid such errors we decided to use option 2 for creating the initial population in order to keep the counteroffer similar to the received offer - the received offer is generated by the receiver and so it usually has utility for the receiver. By using option 2 the received offer is used as guideline for the creation of counteroffers. This reduces the risk of creating offers with high fitness values and low utility for the receiver. The structure of the used fitness functions are shown in Eq. 1. The fitness function \(F_{consumer}\) is used by consumers. It considers its utility function as well as an estimated utility function of the provider \(\hat{U}_{provider}\). Similarly, the fitness function used by the provider considers its utility function and an estimated utility function of the consumer \(\hat{U}_{consumer}\). The estimated utility functions have to be weighted with weight w for an adequate share. The higher the weight, the stronger is the consideration of the negotiation partner. Therefore, w is called consideration factor. For the scenarios we have pre-defined the size of w. In our simulation environment w could also be calculated dynamically.

$$\begin{aligned} F_{consumer}=U_{consumer} + \hat{U}_{provider} \cdot w, F_{provider}=U_{provider} + \hat{U}_{consumer} \cdot w \end{aligned}$$
(1)

Crossover and Mutation. New generations are created using elitism, mutation and crossover operations as described in the following. (i) In our genetic algorithm we used elitism for creating a new generation. This implies that the fittest individuals become part of the next generation. (ii) While the fittest individuals of the previous generation become part of the next generation, the remaining individuals are generated using mutation and crossover. For the selection of the parents of new individuals a Roulette Wheel Selection is used during the crossover operation. Thus, the parent selection probability is proportional to the fitness of an individual:

$$\begin{aligned} P_{i}=\frac{F_{i}}{\sum ^p_{n=0} F_{n}} \end{aligned}$$
(2)

\(P_{i}\) represents the selection probability of an individual i, \(F_{i}\) is the fitness of the individual i while p is the size of the population. After the two parents are determined a new individual is generated by taking two characteristics of the virtual machine of the first parent while the other characteristics are taken from the second parent. (iii) The so generated new individuals are mutated with a certain probability. This means that one of their characteristics is randomly modified.

The fittest offers which result from the algorithm become counteroffers. Figure 6 depicts negotiation examples where different consideration factors were used. In all graphs the ordinate represents the utility of the provider and the abscissa represents the utility of the consumer. The initial offer is represented by a white point with a black border and the message exchanged between consumer and provider are visualized by grey points. In all figures the black points forming a border represent an approximation of the Pareto-border. Messages on that border are Pareto-optimal. In Fig. 6c the consumer uses a high consideration factor while in Fig. 6b the provider uses a high consideration factor. In the negotiations 6a and 6d consumer as well as provider use a moderate consideration factor. Consumer and provider use real utility functions (\(\hat{U}=U\)) in the negotiation depicted in Fig. 6a. So almost all points are on the Pareto-border.

Fig. 6.
figure 6

Screenshot of the result view of the simulation environment

Full size image

The simulation environment supports two utility-utility plots. In the one depicted in Fig. 7a the ordinate represents the utility of the consumer while the abscissa represents the utility of the provider. The red dot represents the first offer with which the negotiation started. As already described, the colors of the other dots represent the negotiation round in which they were sent to the negotiation partner. The consumer created counteroffers in response to the first offer to which the provider responded with messages represented by green points. After the counteroffers were received, the provider responded to them with counteroffers visualized as blue triangles. A lot of offers have a great distance to the Pareto-border. The distance occurs because (i) the genetic algorithm calculates approximations and (ii) the estimated utility function \(\hat{U}\) is imprecise.

Fig. 7.
figure 7

Two utility-utility plots

Full size image

Figure 7b visualizes the perspective of the provider where the ordinate represents the estimated utility (\(\hat{U}_{consumer}\)) of the consumer. The offers created by the provider are approximately Pareto-optimal - from the perspective of the provider (with the estimated utility function).

Table 1. Genetic algorithm setup summary
Full size table

With a focus on the architecture as well as on the functional capabilities of the simulation environment we neglected non-functional characteristics such as performance which we see as part of our further research. An analysis of other possible negotiation strategies was done in [25]. This survey shows that Bayess theory is heavily used for negotiation strategies. We plan to implement and compare them with the introduced strategy.

6 Conclusion and Further Research

In this paper we presented a simulation environment based on CloudSim for the simulation of Bazaar-based Cloud markets. The simulation environment is compliant to the WS-Agreement negotiation specification. In the paper we describe its architecture as well as a negotiation strategy based on a genetic algorithm. Using the simulation environment brokers, intermediaries and datacenters are created, then negotiation strategies are assigned to them before the negotiation results can be analyzed.

In our future research we will develop further components based on the simulation environment: For example taxes on Cloud Markets have not been considered yet by the scientific community as well as smart contract technology which can be used for the created SLAs. Further, novel negotiation strategies based on deep learning techniques are part of our future research.