On the Fly Negotiation for Urgent Service Level Agreement on Intercloud Environment

: Problem statement: Impatient jobs are the jobs that have strict constraints in starting and completion time and need a fast response and attention in mapping to resources. The negotiation process in cloud computing needs a customer-provider agreement that leads to loss of a significant amount of time for impatient jobs. The huge increasing in cloud service providers makes selecting the best provider an exhaustive task. Approach: We considered the problem of Service Level Agreement (SLA) negotiation and commitment process for immediate mode scheduling under intercloud paradigm. This study explored an alternative model dedicated for impatient jobs under intercloud paradigm. We developed a model of negotiation where the cloud-broker had the ability to nominate the best cloud provider, commit the agreement and submit the jobs for execution. Cloudsim simulators with synthetic datasets had been used to evaluate the proposed system. Results: The results showed an improvement in SLA waiting time and the number of jobs failure. Conclusion: This study proved the importance of rapid mapping for impatient jobs in increasing system throughput.


INTRODUCTION
Cloud computing (Michael et al., 2009) is the new paradigm of computing where easily offers computing resources as services.These computing services are generally charged using a pay-as-you-go pricing method and hence, it becomes attractive to most customers.Cloud computing can be defined as Internet-based "cloud" services and use of computer technology (computing) that offers flexible and dynamic IT infrastructure, a Quality of Service (QoS) (Yin et al., 2010) guaranteed environment and reconfigurable services (Wang et al., 2008).This new paradigm is being driven by many well known cloud providers like Roebuck (2011); Miller (2011) Microsoft (Jennings, 2010;Lohr, 2007) HP Cloud Services and IBM Cloud Services Multiple clouds can interoperate with each other to form what is called Intercloud (Bernstein et al., 2009).It can be defined as "cloud of cloud" (Metz, 2009;Briscoe and Marinos, 2009;Johnston, 2009) and it is a metaphor for Internet, which is Network of Networks.
Intercloud was first coined by Kelly (2007) in his article."Eventually we'll have the intercloud, the cloud of clouds", Kelly writes.
SLA (Pichot et al., 2009;Hovestadt, 2006) is a contract signed between a service provider and a customer that describes the service, responsibilities, terms, guarantees and service-level to be provided.SLA is an important element of the service oriented computing paradigm and defines a mutually agreed upon set of consumer expectations and provider obligations.Typically, SLAs encode QoS parameters such as resource availability, response time and completion deadlines.The role of the consumer is usually limited to specify their QoS parameters and perhaps revising those parameters if an SLA cannot be agreed (Netto et al., 2010).
According to Jennings et al. (2001), a negotiation can be defined as: "the process by which a group of agents come to a mutually acceptable agreement on some matter".SLA Automatic negotiation can be a complex and time-consuming process when two parties need to create an agreement on multiple criteria (Jennings et al., 2001;Shen et al., 2002).
Cloud computing providers offer their services after confirming SLA agreement between them and the customers.The negotiation process needs both parties to agree on the SLA and then sign the contract.This process involves many steps, which is sometimes time consuming for some customers with urgent needs.The normal SLA negotiation process requires sending an offer from the customer (i.e., buyer) to the provider (i.e., seller) and the response by a bid from the provider to the customer.This process can be repeated several times until an agreement is reached between both sides.In the last step, the provider creates the agreement template and sends it back to the customer for confirming.The customer then confirms the template.The last step is time-consuming and is only needed to confirm the offer again (i.e., sign the contract).
In addition to above, the huge growing in cloud providers and their services increase the difficulty for urgent customers to surf all their services and provide a decision to which the request should be sent.Most of the previous negotiation strategies include the steps of sending an offer from the customer (i.e., client or buyer) to the provider (i.e., seller) asking for a specific Service (s), the provider returns with their bid or acceptance of the customer's offer and the last step is the confirmation from the provider side.
On-the-Fly-Negotiation Algorithm (OFNA) is the proposed algorithm that maps the jobs to the cloud services with less negotiation steps to provide fast response for urgent jobs.The proposed model takes into consideration the urgent and normal jobs.

Related work:
Since the 1980s, SLAs were established as tools for stating the QoS.They were mainly used in the telecommunication domain and used as study printouts there was a tendency in the research community to try to adapt the SLA concepts on other domains (Green et al., 2007;Munoz et al., 2010).
Work presented Al-Ali et al. (2002), extended the service abstraction in the Open Grid Services Architecture for QoS properties.They focused on the application layer, whereby a given service may indicate the QoS properties it can offer, or where a service may search for other services based on particular QoS properties.Ouelhadj et al. (2005) proposed a new infrastructure for efficient job scheduling on the Grid using multi-agent systems and a SLA negotiation protocol based on the Contract Net Protocol.In their protocol, the agents exchange SLA-announcements, SLA-bids and SLA-awards to negotiate the schedule of jobs on Grid compute resources.Their model needs multi-level negotiation between the agents.
Furthermore, the client in their model has to select a bid from set of offers and commits it.Munoz et al. (2010) and Parkin et al. (2008) described an abstract, domain-independent protocol for the renegotiation of an agreement, including SLA formed using the WS-Agreement standard.Their proposed protocol is based on the principles of contract law to make any new agreements using them, legally compliant.It allows for multi-round renegotiation in a network environment where messages may be lost, delayed, duplicated and re-ordered.In their mode, the user needs pre-knowledge about the current services and commits the last agreement.
Work presented Green et al. (2007) proposed novel augmentations to existing service negotiation protocols in the areas of scalability, flexibility, support for distinct services and negotiation with several service providers simultaneously.Their proposed autonomous negotiation protocol is based on a distributed multiagent framework creating an open market for Grid services.Their model includes at each negotiation process a binding stage whereby a valid SLA instance is formally agreed to by the consumer and all the involved service providers.After binding, the consumer and provider(s) have to commit the agreed SLA.Pichot et al. (2008) in their study, discussed basic functionality for resource orchestration in grids, namely mechanisms to dynamically negotiate and create service level agreements using WS-Agreement.They proposed multi-level negotiation process where the metascheduler should negotiate with the provider to find the best template.The SLA should be committed using two-phase commit protocol.
The proposed framework Hudert et al. (2009) augments this WS-Agreement to enable negotiations according to a variety of bilateral and multilateral negotiation protocols.The framework design is based on a thorough analysis of taxonomies for negotiations from the literature in order to allow for capturing a variety of different negotiation models within a single WS-Agreement compatible framework.In order to provide for the intended flexibility, the proposed protocol takes a two-stage approach: a meta-protocol is conducted among interested parties to initially agree on a common negotiation protocol before the real negotiation is carried out in the second step using the protocol established in the first step.
Work presented An et al. (2010) considered the problem of allocating networked resources in cloud computing platforms, where providers strategically price resources to maximize their utility.They explore an alternative approach where providers and consumers automatically negotiate resource leasing contracts.In their model, both the provider and consumer are selfish.The consumer needs to know the ability of each cloud provider (i.e., pre-knowledge) and to commit the agreement before approval.

MATERIALS AND METHODS
In the proposed model, there are three tiers namely: the customer, the cloud broker and the cloud providers.Each cloud provider has set of datacenters which in turn consists of set of Physical Machines (PM) used to host Virtual Machines (VMs).The cloud broker acts as an advisor for the customers.The customer c sends his request R c , which has the list of jobs J c , to broker B. The customer does not know which cloud provider is suitable to execute his request or he does not have the time to look for the appropriate provider.
The main idea of this study is to let the cloud broker commit and submit the impatient jobs to the cloud provider.The customer should permit the broker agent to sign the agreement on behalf of the customer if the broker agent finds a suitable cloud provider that fits with the requirements of the customer's QoS.
We assume that customer c and the broker B are working on a utility function as described in (1).The time needed by customer c to create the request R c and send it to the broker B is equal to δ c .The time needed by broker B to map all the jobs in R c to the available resources and return back the offer is equal to ρ.The estimated time for customer c to confirm the offer is c ω and A c is the decision variable such that: As can be seen from ( 3), if the customer c sets the auto-confirm option, the broker does not consider the confirmation time and vice versa.The completion time for each job j c is proposed to be computed using (5) as shown: Now, from ( 6) and ( 7) we can find the utility variable J c as shown below: Customer c can ask for full respect of his request R c , which means J c = 0 or he can specify a maximum value for it.
While most of the current cloud providers charge the customers per hour, we can compute the amount of total charge for customer c and his request R c by: c vp j p c v j J TET * cos t 3600 where, β c is the total amount of money that should be paid by costumer c to the cloud provider(s).It is calculated by multiplying the VM cost by the total execution time in hours as can be seen in ( 9).

Negotiation protocol:
The architecture of our proposed negotiation framework is shown in Fig. 1.It is composed of three kinds of agents that are responsible for managing the negotiation process and creating the SLA agreements.These agents are: Customer agent: This agent is located at the customer's side.Its responsibilities are: (a) collects the list of jobs and their requirements, (b) creates the request template and (c) sends the request template to the broker agent and waits for acknowledgment.
Broker agent: This agent is the mediator between the cloud customers and cloud providers.It can also be considered as the meta-scheduler of the cloud customers' requests.Its main responsibilities are: (a) receives the request template from the customers agent and decodes it, (b) sends the requests to the scheduler that can find the best mapping for this request, (c) creates the agreement template and signs it on behalf of the customer in case of auto-confirmation or sends it back to the customer's agent, d) submits the customer's request to the cloud providers and (e) receives the cloud updates from the provider agent, which is the current status of each cloud provider to be used by the scheduler.

Cloud provider agent:
This agent is located at the side of each cloud provider and has many responsibilities, which are: (a) periodically sends the status of the cloud to the broker agent and (b) receives the list of jobs to be executed from the broker agent.

Fig. 1: The negotiation framework architecture
Agents actions: The main actions that are proposed to be taken by the agents are: • Request[r]: The work flow starts from the customer c side by sending its request R c , which has the list of job J c to the broker agent B • Submit[r]: If the scheduler finds a suitable mapping for the customer's request, the broker agent passes this request to the cloud providers to execute them and simultaneously send a confirmation message to the customer's agent • Reject[r]: When the scheduler cannot find a mapping that meets the customer's requirements from the deadline and budget point of view, the broker agent sends a reject message back to the customer agent for refining • Bid: When the broker agent B meets the deadline restrictions but with more budget requirement, a bid offer O is sent back to the customer agent c • Decommit: Decommit is defined as a withdraw from active service.This action is done by the customer c to cancel the current offer O or the current request R c Action flow sequence: The process of SLA negotiation can be defined as an activity to determine certain details of an interaction.Figure 2 depicts the finite state machine for the process of negotiation between the cloud customer agent, the broker agent and the cloud provider agent.
Initially, the cloud customer c, who has an impatient job(s), initiates the request r by creating a template that describes all the required jobs and their properties.It includes all the job constraints including the deadlines and budgets.The broker agent B receives the request r from the customer agent c.The broker sends r to the metascheduler to find the best mapping that can respect all the job requirements.If the mapping is done (i.e., respecting all the QoS requirements) then it has two directions.The first direction is to submit the mapping list directly to the nominated cloud provider without waiting for customer c conurbation in the case of autoconurbation, which is an option selected by the customer c.If the customer asks for the normal negotiation process (i.e., without auto-confirmation), the broker agent sends the agreement to the wait state, which is the state that awaits the commitment from customer c.In the waiting state, the customer has the ability to commit or reject the agreement.In case of commitment, the broker agent B sends the request to the cloud provider p to execute, otherwise the whole process returns to the initial state.
Events workflow of negotiation process: Figure 3 depicts the study flow sequence of the negotiation process.It shows the three agents (customer c, broker B and provider p).In the proposed model, the cloud provider agent p sends the cloud status periodically as initially occurs at time J 0 .These values (i.e., templates) describe the current state of the cloud by the number of available virtual machine images, the specifications of each VM from SW, HW and the cost point of view and the dynamic information such as the availability.At time J 1 the customer agent c sends the request r to the broker agent who has the list of jobs and their QoS requirements.The next time event J 2 is for broker agent B to submit the request r to the nominated cloud provider.This action is done in case of autoconurbation permission, which is taken form customer agent c.The broker agent at time J 3 sends an acknowledgement to the customer agent concerning the status of agreement.
This acknowledgment is sent after submitting the request to the cloud provider to save time.Time j 4 is the time to start execution of the customer's request r, thus, it is proposed for the cloud to acknowledge the customer about this action.
After the cloud provider finishes its execution, it should either send the result back to the customer or to the third party and acknowledge the customer at the same time.

Agents strategy:
As the aforementioned model shows the three components of intercloud paradigm, the three agents namely customer strategy, broker strategy and provider strategy are illustrated below.
Customer strategy: The customer's algorithm is depicted in Fig. 4. Steps (1-6) are used by the customer c to create the request R c to be sent to the broker.The if statement at step 2 is used to set the control variable A with or without value.We focus on this variable because it plays an important role in the proposed system.After creating the request R c the customer c sends the request to broker B. This is done at step (7).The statement at step ( 8) is used to check whether the broker accepts the requests or not.Two actions exist if the broker B accepts the request.If the broker accepts the request while the customer c sets the variable A to auto then it should wait for the acknowledgment from the provider, otherwise (i.e., A is not auto) the customer has to check the offer.In case the broker rejects the offer for its impossibility, then the customer should cancel the submitted request R c as can be seen in step (14).Step ( 15) and ( 16) check the case if the provider p sends an acknowledgment to the customer c and calls the wait function.If the result is received by the customer, then customer agent c finishes its work, as can be seen in steps ( 17) and ( 18).

Broker strategy:
The broker algorithm is depicted in Fig. 5.The broker keeps listening to two things: (a) requests from the clients and (b) cloud status from the cloud providers.Steps (1) and ( 2) are responsible for listing the clients' requests and sending them to the scheduler.In this study we consider the Minimum Completion Time (MCT) algorithm as immediate mode scheduling algorithm.
It is adopted to be compatible with the cloud environment and renamed it to Cloud Minimum Completion Time (CMCT).In step (2), the scheduling algorithm returns the number of failed to meet deadlines, which is denoted by J c and the estimated execution price, which is denoted by β c .If all the jobs meet their deadlines (i.e., step (3)) then the request is either submitted directly to the nominated cloud provider if the customer sets A as auto (steps ( 5) and ( 6)) or waits for the customer to confirm the offer (see step (10).In case of failure in some deadlines then step (12) sends a reject message to the customer.Step (14) submits the request to the cloud provider if the customer confirms.Step ( 16) sends a reject message to the customer in case the latter decommit the offer.Cloud providers periodically send their cloud status.
Step (18) updates the cloud status.
Provider strategy: This study proposes that each cloud provider has an agent to deal with the broker agent.Figure 6 shows the main steps of this agent.Let µ be the time interval to send the cloud status to the broker as can be seen in steps 1 and 2. Steps 3 and 4 are responsible for request execution if the broker B sends as request.Sending the results back to the customer c is at step 5 and 6.

RESULTS
In the absence of real traces from real cloud providers, we generated the input workload randomly.Casazza et al. (2006) present a workload methodology to characterize the performance of servers exploiting virtualization technologies to consolidate multiple physical servers.They combine the workload of the web server, an email server and a database application to reflect the variation of application that can be run on cloud computing.
As aforementioned, we assume a certain number of users, jobs and cloud providers.The job workload is selected randomly (Ranganathan and Foster, 2002) with uniform distribution between 500-2000MB.Each job has a set of input and output files selected randomly between 1 and 6.Job length is a function to the total input size for 300D if we assume D is the total input size.For simplicity and without loss of generality we assume all jobs need a fixed time to offer or bid and each job needs 0..5 counteroffers.The job deadlines are functions that are based on their length and their data size.For the purpose of this work, the deadlines are very strict and hard, which means the jobs need quick attention.
Simulation is the process of imitation of the real system.Because of the difficulty in testing the proposed system in a real system, a simulation evaluation has been conducted on synthetic datasets.CloudSim (Calheiros et al., 2009) is a discrete event simulator that is used to simulate cloud environments.Cloudsim has the ability to create data centres, virtual machines and physical machines and configure system brokers, system storage.
Table 1 specifies the simulation parameters used for our study.Two performance metrics have been used to evaluate the proposed model namely: number of jobs failure and average waiting time.To evaluate the performance of the proposed model, twenty experiments were done using the cloudsim simulator.We created ten datasets with a different number of jobs and different loads to evaluate the performance.
As aforementioned, the deadlines are functions of the job's length and their data.The simulation process is done to evaluate the impact of on-the-fly algorithm on impatient job mapping under intercloud paradigm.
Figure 7 depicts the number of job failures in the proposed model and the CMCT.It indicates the number of jobs for which the scheduler cannot meet their deadlines.The value of this metric is the inverse to the value of throughput that indicates the number of finished jobs.The figure shows some failure even with the proposed system, which is because of the hard deadlines created within the synthetic datasets.The improvement in the system throughput using the proposed model is quite clear.Also, it is possible to notice that as the number of submitted jobs increase, the number of failed jobs is also increase.This is because of start deadline constraint that failed to meet the jobs requirements which is because of more waiting time through confirmation step.
Figure 8 depicts the average waiting time for all the submitted jobs.These metric measures the time needed to finish the negotiation process.It is the difference between the job arrival-time to the starting time of the scheduler to map this job as shown in Eq. 12.In this Fig. 8, we compute the waiting time for all the jobs even the failed jobs.Where: AWT Jc = The average waiting time for job list Jc st j = The time for the job j to reach the scheduler (i.e., finish the negotiation process) Figure 8 shows the improvement that happened in the waiting time or the negotiation time.The effect of confirmation on the total negotiation time is quite clear.The need for confirmation can improve the system based on the user's response time which implemented randomly in this study.5,10,15,20,30,50,100,200,300,400 Denotes the utility function of customer c J c = Denotes the number of deadlines (start and complete) that do not meet their requirements β c = Denotes the total budget for all the jobs in request R cThe time needed to execute each job j c in the request R c is computed using (2time needed to execute the job j c sent by customer c and nominated to execute on VM v p , which is offered by provider p. filein jc stagein is the time needed to fetch all the necessary input files while fileout jc stagein is the time for sending out all the output files to their destinations.up jc E gives the time needed to execute the job on the nominated virtual machine.The estimated job start time is calculated based on the current time and other factors as shown in (3): current time N = The number of counteroffers between the customer c and broker B such that N 1 ≥

Fig. 2 :
Fig. 2: Finite state machine for the proposed system

Fig. 3 :
Fig. 3: Work flow sequence in the proposed model

Fig. 7 :
Fig. 7: Job failure among different sets of jobs