Brokering SLAs for End-to-End QoS in Cloud Computing

Tommaso Cucinotta, Diego Lugones, Davide Cherubini and Karsten Oberle

Bell Laboratories, Alcatel-Lucent, Dublin, Ireland

Keywords:

Quality of Service, SLAs, Cloud Computing, Cloud Broker.

Abstract:

In this paper, we present a brokering logic for providing precise end-to-end QoS levels to cloud applications

distributed across a number of different business actors, such as network service providers (NSP) and cloud

providers (CSP). The broker composes a number of available offerings from each provider, in a way that

respects the QoS application constraints while minimizing costs incurred by cloud consumers.

1 INTRODUCTION

Cloud Computing introduces a novel model of com-

puting that brings several technological and business

advantages. Customers can rent cloud services on

a pay-per-use model, without the need for big in-

vestments for resources that have to be designed for

peak workloads, whilst being at risk of remaining

under-utilized for most of the time. Providers may

offer cloud services for rental, hosting them on big

multi/many-core machines, where the infrastructure

investments may be amortized over thousands of cus-

tomers.

However, the requirements of cloud customers

are evolving quickly, as cloud technology is being

massively used worldwide. Many enterprise applica-

tions that might take advantage from the cloud model

cannot be hosted on current infrastructures due to

their stringent performance aspects requiring more

and more from the best effort Internet. Think of vir-

tual desktop, Network Function Virtualization (NFV),

professional on-line multimedia editing and collabo-

rative tools, and on-line gaming, just to mention a few.

Even though recent standards and research efforts

deal with predictable QoS levels in Cloud Comput-

ing (Oberle et al., 2013), spanning across different

business and operations domains remains a great chal-

lenge. For example, a single user request may have

to traverse access, metro, core and data center net-

works, and the top-down provisioning chain across

the various cloud layers (SaaS, IaaS, etc.), and still re-

quire tight interactivity. Figure 1 depicts the situation.

Understanding how to combine all business actors in

agreements to deliver end-to-end QoS may become

overly difﬁcult.

Figure 1: Users crossing multiple network service providers

for accessing a cloud data center.

For these reasons, it is becoming increasingly

important to have available intermediation services

(a.k.a., brokerage) allowing cloud consumers to inter-

face themselves to the multitude of service providers,

including network carriers and cloud providers in-

volved in the end-to-end service delivery chain. Bro-

kering of cloud services (Plummer, 2012) allows for

dealing with the various aspects of SLAs possibly in-

volved in an end-to-end chain, including legal, eco-

nomical and technological aspects. However, in this

work we deal mainly with the latter aspects. That

is, we consider cloud consumers who care about the

price of a service and the expected and received end-

to-end quality.

In this paper, we propose a brokering approach for

610

Cucinotta T., Lugones D., Cherubini D. and Oberle K..

Brokering SLAs for End-to-End QoS in Cloud Computing.

DOI: 10.5220/0004959706100615

In Proceedings of the 4th International Conference on Cloud Computing and Services Science (CLOSER-2014), pages 610-615

ISBN: 978-989-758-019-2

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

deploying distributed cloud applications with guaran-

teed end-to-end QoS which is achieved as an end-to-

end composition of SLAs to be established along the

multiple players participating in the chain. We focus

on the mathematical formalization of the brokering

logic as a mixed-integer geometric programming pro-

gram. Note that, albeit a prerequisite to the brokerage

of cloud services is a certain level of interoperabil-

ity and compatibility among the offerings, we do not

address these speciﬁc issues in this paper. Namely,

we assume our brokering logic is managing only ser-

vices and offerings that can interchangeably be used

and composed with each other, for deploying end-to-

end applications. For an overview of the issues behind

cloud interoperability, we refer the reader to (Petcu,

2011).

2 RELATED WORK

The problem of brokerage of multiple CSP offer-

ings for hosting distributed cloud applications with

minimum cost has been addressed in (Houidi et al.,

2011). It has been modeled as a MILP, similarly to

what is done in this paper. However, Houidi’s model

is too simple as it does not consider QoS require-

ments nor capacity constraints. Pawluk et al. de-

ﬁned a cloud broker service (Pawluk et al., 2012)

(STRATOS) based on comparing different CSP of-

ferings. However, the presented broker logic is sim-

ply based on conﬁguration properties matching (e.g.,

minimum values to be satisﬁed on certain properties

for the offered services). InterCloud (Buyya et al.,

2010) and other architectures (Grivas et al., 2010)

(Ferrer et al., 2012) for federation of cloud providers

include a broker component that may be an excellent

candidate for realizing the brokering logic described

in this paper.

The IRMOS European Project has addressed how

to enhance execution of real-time multimedia applica-

tions in virtualized Cloud infrastructures (Cucinotta

et al., 2010; Kyriazis et al., 2011). IRMOS ensures

resource allocation for individual hosted applications.

However, one of its limitations is that it does not ad-

dress how to possibly guarantee service levels across

domain boundaries (i.e., whenever interacting with

other providers and infrastructures).

The SLA@SOI EU Project

developed a frame-

work (Wieder et al., 2011) for negotiation, provi-

sioning, monitoring and adaptation of SLAs through

the entire cloud service life-cycle. It includes both

functional and non-functional characteristics of ser-

More information is available at: http://sla-at-soi.eu/.

vices, such as QoS constraints, which can be formal-

ized through an XML-based syntax.

The ETICS (Economics and Technologies for

Inter-Carrier Services) European Project

investi-

gated on the critical issues for the creation of a

new ecosystem of innovative QoS-enabled intercon-

nection models between Network Service Providers

(NSPs) impacting all of the actors involved in the end-

to-end service delivery value-chain. ETICS produced

a novel architecture (Zwickl and Weisgrab, 2013) for

control and management of automated end-to-end de-

livery of QoS-enabled services across heterogeneous

carrier networks.

Furthermore, many studies exist trying to identify

critical factors affecting a market of cloud offerings,

including considerations related to QoS-aware provi-

sioning of resources and services. An overview of

such approaches can be found in (Breskovic et al.,

2013).

Concerning standarization, the European

Telecommunications Standards Institute (ETSI)

is currently involved in several activities related to the

issues mentioned above with the ETSI NFV Industry

and Speciﬁcation group. The Technical Committee

CLOUD is also addressing interoperability aspects

of end-to-end applications. NIST is also working in

this area, with a series of reports being of value to the

topic of end-to-end cloud service quality

, in addition

to the well-known reports on the deﬁnition of cloud

computing (Mell and Grance, 2011) and its reference

architecture (Liu et al., 2011), where the importance

of having cloud brokerage services is emphasized.

Additional details on research and standardization

efforts in this area can be found in (Oberle et al.,

2013).

3 BROKERING OPTIMIZATION

LOGIC

Notation and Assumptions. From an abstract

viewpoint, a distributed real-time cloud computing

application is modeled as a set of components A =

{

1, 2, . . .

}

, among which we include also client/user-

side components. These are interconnected in a logi-

cal application topology (limited to be a linear work-

ﬂow in this paper) expressed as the sequence S ≡

, . . . , s

) of n elements of A that activate one after

another, whenever triggered by users requests, com-

ing at a minimum inter-arrival time T. Each activa-

More information at: https://www.ict-etics.eu/.

More information can be found at:

http://www.nist.gov/itl/cloud/index.cfm.

BrokeringSLAsforEnd-to-EndQoSinCloudComputing

611

Figure 2: Simple application sequence graph.

tion i of component s

is associated with its com-

puting requirements C

, representing the amount of

time needed for (sequential) computations within the

component for each request received from the user.

After computations, the component sends a message

of size M

to the next component s

i+1

in the se-

quence S. For example, consider a cloud application

composed of 3 components A =

{

a, b, c

}

, where a

might represent the client part of the application run-

ning at the consumer premises (e.g., a web browser),

b might represent the front-end server (e.g., a web-

server), and c might represent the back-end compo-

nent (e.g., a database). Then, a sequence might look

like S = (a, b, c, b, a), where user requests traverse

the components forward and backwards.

A cloud application has to be deployed over a set

of cloud data centers P belonging to one or more

Cloud Service Providers (CSPs), interconnected by

means of network providers (NSPs). Each NSP is

characterized by a set of Edge Routers (ERs) R ,

through which it is connected either to other NSPs

or to CSPs or directly to users. From a mathematical

perspective, we consider in what follows data center

locations as edge routers as well, resulting in P ⊂ R .

The situation can be depicted as a graph where each

node represents an ER which has arcs towards all the

other ERs to which it is connected.

CSPs are assumed to be able to host one or more

components i by reserving a certain amount of com-

puting resources u

to it with a minimum VM comput-

ing latency of L

, and we assume an ideal scalability

model: if the component is assigned computing ca-

pacity u

∈ (0, U

max

] ∈ R with VM wake-up latency of

, then the time needed to complete a user request is

reasonably approximated or bounded as:

. The

VM computing latency may depend on many factors,

such as hardware and software conﬁguration of hyper-

visors and guest OSes, including the CPU schedulers

type and their conﬁguration.

Similarly, NSPs are assumed to be able to place

the communication ﬂow between each component i

and the next one by dedicating a network bandwidth

and ensuring a maximum communication latency

, in such a way that the time needed to transmit

a message among these components (assuming no

queuing of messages from the same application/ﬂow

is needed) can be reasonably estimated/bounded as:

+ L

We assume that our brokering logic has available a

set of quotations (or equivalently a price list) from all

of these providers. More precisely, for each available

data center p ∈ P, we have available a few alternate

quotations R

. Each quotation r ∈ R

includes the

cost for deploying components at the CSP premises

that can be made available within conditions of quo-

tation r; this includes K

p, r

, the cost of a computing

capacity unit up to a maximum computing capacity

p, r

, and K

p, r

, the cost of a networking capacity unit

up to a maximum networking capacity of U

p, r

; the

quotation also includes a maximum VM access la-

tency of L

p, r

. For example, the same CSP might pro-

vide two different quotations with different latencies,

depending on the type of hardware where the VM(s)

would be deployed, and/or the hypervisor and guest

OS kernel conﬁguration(s) , and/or the level of con-

solidation of multiple VMs onto the same host pushed

by the provider in the context of that quotation; also,

the latency might depend on the network conﬁgu-

ration within the data center, so the CSP might be

willing to offer VMs at particularly chosen locations

within the DC, and/or using particular conﬁgurations

of, e.g., an SDN-enabled data center network, so as to

guarantee lower access latencies from the outside, at

a conveniently higher unit-cost; different quotations

may equally well represent different “sizes” of VMs

that can be seen in current CSPs IaaS offerings. Also,

for each NSP connecting two data centers or edge

routers p, q ∈ R , we have available a few alternate

quotations R

p, q

. Each quotation r ∈ R

p, q

is expressed

as a cost K

p, q, r

for deploying, with latency L

p, q, r

a unit of communication bandwidth between p and

q, up to a maximum available bandwidth of B

p, q, r

In cases where, among two data centers p, q ∈ P ,

there are multiple NSPs connecting them, or there are

multiple paths traversing different NSPs for connect-

ing them, we assume that all the corresponding quo-

tations are combined together into a single list R

p, q

combining together the available multiple quotations

to traverse. For example, quotations from two NSPs

to be traversed for connecting two locations p, q ∈ P

can be combined as follows: for each pair of quo-

tations r

from the ﬁrst NSP and r

from the sec-

ond NSP, we consider an equivalent quotation r

, r

in which the bandwidth-unit costs and the latencies of

and r

area added together, whilst the maximum

available bandwidth for the quotation is the minimum

among the two. After this operation of aggregating

quotations from different NSPs, we obtain equivalent

end-to-end quotations for all pairs of data center lo-

cations p, q ∈ P , thus in our formalization we can

forget about the existence of the intermediate edge

routers R \P among multiple NSPs carrying the traf-

ﬁc among all CSPs.

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

612

Problem Formalization. Now we proceed to for-

malize the cloud brokering problem as an optimiza-

tion program. To this purpose, we introduce Boolean

variables x

i, p, r

representing whether the broker will

deploy component i onto data center location p ∈ P

making use of quotation r ∈ R

, and the Booleans

i, p, q, r

representing whether or not trafﬁc between

components s

and s

i+1

in sequence S is to be de-

ployed between locations p, q ∈ P by using quotation

r ∈ R

p, q

. These variables are tied to each other by the

constraints:

∑

p∈P

∑

r∈R

i, p, r

= 1 ∀s

∈ S

(1)

∑

r∈R

p, q

i, p, q, r

∑

∈R

, p, r

∑

∈R

i+1

, q, r

∀p, q ∈ P , ∀s

∈ S\

{

}

(2)

where: the ﬁrst constraint forces each component

to be placed onto a single cloud provider, exploiting

one among the available quotations; the second one

says that, if component s

is deployed on p, and com-

ponent s

i+1

on q, then only one among the available

quotations for communications between p and q has

to be chosen; otherwise, y

i, p, q, r

must be 0 for each

r ∈ R

p, q

. Also, the deployment and quotations choice

has to satisfy the overall end-to-end deadline D con-

straint:

∑

∈S

∑

p∈P

∑

r∈R

p, r

i, p, r

∑

p, q∈P

∑

r∈R

p, q

p, q, r

i, p, q, r

≤ D (3)

and the allocation constraints

∑

∈S

i, p, r

≤ U

p, r

∀p ∈ P , ∀r ∈ R

(4)

∑

∈S

i, p,q,r

≤ B

p,q,r

∀p, q ∈ P ∀r ∈ R

p, q

(5)

where u

and b

are real problem variables. These

are further constrained due to the assumption that re-

quests submitted to the same application workﬂow at

the speciﬁed minimum inter-arrival time of T do not

queue after each other, namely:

≥

(6)

≥

. (7)

On the other hand, the broker will try to minimize

the cost for hosting the application:

min

∑

∈S

∑

p∈P

∑

r∈R

p, r

i, p, r

+ (8)

∑

∈S\

{

}

∑

p, q∈P

∑

r∈R

p, q

p, q, r

i, p, q, r

. (9)

The formalized problem falls in the class of mixed-

integer geometric programming optimization pro-

grams, for which there are solvers available, such

those found in the GAMS suite

4 IMPLEMENTATION

CONSIDERATIONS

Network Service Provider. In order to provide

end-to-end cloud services with precise QoS levels,

NSPs and CSPs must implement selected routing

paths and reserve appropriate resources. On the net-

working side, we distinguish between intra-domain

routing – if the end-to-end path is entirely within the

same Autonomous System (AS), and inter-domain

routing if the trafﬁc is sent across multiple NSPs.

In intra-domain routing, users and DCs where

their applications are deployed are all interconnected

via the same NSP. In order to compose different net-

working offers, the NSP can adopt different strategies

to build the end-to-end path. For example, a best ef-

fort latency offer can be realized by adopting tradi-

tional IGP protocols (e.g., OSPF or IS-IS) to route

trafﬁc between source and destination on the shortest

path. Of course, not always shortest path translates

into minimum latency. On the other hand, a premium

offer (or minimum latency offer) can be realized us-

ing Multi Protocol Label Switching (MPLS) with its

Trafﬁc Engineering extensions (MPLS-TE). In partic-

ular, a Label Switched Path (LSP) is a one-way tun-

nel that can transport the trafﬁc from origin to desti-

nation and that can satisfy multiple QoS parameters

(e.g., bandwidth, delay, jitter, availability, and loss).

The LSP routing path can either be conﬁgured auto-

matically (e.g., using Constrained Shortest Path First

– CSPF), or manually, e.g., as a result of more sophis-

ticated techniques (Cherubini et al., 2011).

In inter-domain routing, when users can reach

CSP’s DCs across different NSPs, optimal path calcu-

lation is inherently more complex. Each router should

have a global view of the network. Unfortunately,

NSPs “ﬁlter” important information needed for the

path establishment (e.g., for scalability or conﬁden-

tiality reasons). The Path Computation Element pre-

More information is available at:

http://www.gams.com/solvers/

BrokeringSLAsforEnd-to-EndQoSinCloudComputing

613

sented in (Farrel et al., 2006), represents a possible so-

lution to provide an optimal inter-domain routing path

(in the form of MPLS-TE LSP) that meets desired

QoS requirements and can scale the end-to-end net-

work up to 100,000 MPLS devices (Leymann et al.,

2013).

Cloud Service Provider. The centralized design of

today’s data centers offers advantages in terms of fab-

ric homogeneity and control, in comparison to the

best-effort networks describedabove, which usually

include various legacy equipment, specialized boxes,

multiple protocols and are potentially operated by in-

dependent NSPs.

However, meeting the latency guarantees required

by demanding Cloud applications in the data cen-

ter fabric is still a signiﬁcant challenge. The shared

nature of the network in multi-tenant data centers

leads to signiﬁcant variations in the perceived perfor-

mance. The lack of predictability increases the ten-

ant costs and causes provider revenue loss. Moreover,

the Internet-oriented protocols and ﬂow scheduling

mechanisms used in data centers are unaware of ﬂow

deadlines and application trafﬁc patterns. Instead,

they strive to optimize such low-level metrics as net-

work throughput and fairness, ignoring the actual per-

formance requirements associated to trafﬁc ﬂows.

Another reason that makes it difﬁcult to deliver

precise QoS levels in data centers is that typical de-

signs focus on bisection bandwidth by overprovision-

ing the fabric. However, these are clearly not op-

timized for ultra-low latency applications with pre-

dictable delivery of packets. Moreover, overprovi-

sioning today’s data centers is prohibitively expen-

sive.

The most common strategy is to implement

QoS mechanisms by segregating trafﬁc into differ-

ent classes to provide isolation and enable trafﬁc en-

gineering. Typically, these mechanisms are imple-

mented in switches and network cards where trafﬁc

is prioritized explicitly by marking packets or implic-

itly by using port ranges. In addition, the cloud ser-

vices are typically run at low utilization to meet strict

SLA demands, which decreases efﬁciency. However,

advanced research in the ﬁeld proposes different alter-

natives such as removing the kernel and network stack

from the critical path of communication and load bal-

ancing requests across application instances (Kapoor

et al., 2012). In (Ballani et al., 2011) authors pro-

pose to create virtual network abstractions to allow

tenants to expose their network requirements. Pro-

posal in (Alizadeh et al., 2012) run the network with

near zero queueing and adaptively respond to conges-

tion marks using DCTCP (Alizadeh et al., 2010).

Also, deadline-based scheduling of packets has

been proposed as an alternative to TCP. In (Wilson

et al., 2011), a control protocol is proposed that uses

deadlines to achieve informed allocation of network

bandwidth. In (Andrews, 2000), EDF scheduling is

leveraged for providing probabilistic end-to-end guar-

antees to individual streams.

5 CONCLUSIONS AND FUTURE

WORK

In this paper, we addressed optimum brokering of

cloud and carrier services accounting for end-to-

end QoS requirements of cloud applications, and the

availability of multiple offerings by CSPs and NSPs

with different and heterogeneous quality levels corre-

sponding to different price conditions. The problem

has been mathematically modeled as a mixed-integer

geometric programming optimization program that

can be solved by available standard solvers. This

work constitutes a ﬁrst step towards the realization

of evolved end-to-end cloud services offering to con-

sumers precise, stable and reliable QoS levels across

the heterogeneous, multi-provider “supply” chain that

is involved in the process.

Our planned and ongoing future work in the area

includes development of simpliﬁed versions of the

introduced problem, as well as fast heuristic solvers

for trading off accuracy of the solution versus solv-

ing time. Also, an implementation of the described

technique is under way and its effectiveness will soon

be evaluated by simulation, within our CloudNetSim

framework (Cucinotta and Santogidis, 2013), and by

real prototyping.

REFERENCES

Alizadeh, M., Greenberg, A., Maltz, D. A., Padhye, J., Pa-

tel, P., Prabhakar, B., Sengupta, S., and Sridharan, M.

(2010). Data center tcp (dctcp). SIGCOMM Comput.

Commun. Rev., 41(4):–.

Alizadeh, M., Kabbani, A., Edsall, T., Prabhakar, B., Vah-

dat, A., and Yasuda, M. (2012). Less is more: trad-

ing a little bandwidth for ultra-low latency in the data

center. In Proceedings of the 9th USENIX conference

on Networked Systems Design and Implementation,

NSDI’12, pages 19–19, Berkeley, CA, USA. USENIX

Association.

Andrews, M. (2000). Probabilistic end-to-end delay bounds

for earliest deadline ﬁrst scheduling. In INFOCOM,

pages 603–612.

Ballani, H., Costa, P., Karagiannis, T., and Rowstron, A.

(2011). Towards predictable datacenter networks.

SIGCOMM Comput. Commun. Rev., 41(4):242–253.

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

614

Breskovic, I., Brandic, I., and Altmann, J. (2013). Max-

imizing liquidity in cloud markets through standard-

ization of computational resources. In Proceedings

of the 2013 IEEE Seventh International Symposium

on Service-Oriented System Engineering, SOSE ’13,

pages 72–83, Washington, DC, USA. IEEE Computer

Society.

Buyya, R., Ranjan, R., and Calheiros, R. (2010). Inter-

cloud: Utility-oriented federation of cloud computing

environments for scaling of application services. In

Hsu, C.-H., Yang, L., Park, J., and Yeo, S.-S., editors,

Algorithms and Architectures for Parallel Processing,

volume 6081 of Lecture Notes in Computer Science,

pages 13–31. Springer Berlin Heidelberg.

Cherubini, D., Fanni, A., Mereu, A., Frangioni, A., Mur-

gia, C., Scutell

a, M. G., and Zuddas, P. (2011). Linear

Programming Models for Trafﬁc Engineering in 100%

Survivable Networks under Combined IS–IS/OSPF

and MPLS-TE. Computers & Operations Research,

38(12):1805–1815.

Cucinotta, T., Checconi, F., Kousiouris, G., Kyriazis, D.,

Varvarigou, T., Mazzetti, A., Zlatev, Z., Papay, J.,

Boniface, M., Berger, S., Lamp, D., Voith, T., and

Stein, M. (2010). Virtualised e-learning with real-

time guarantees on the irmos platform. In Proceed-

ings of the IEEE International Conference on Service-

Oriented Computing and Applications (SOCA 2010),

pages 1–8, Perth, Australia.

Cucinotta, T. and Santogidis, A. (2013). Cloudnetsim -

simulation of real-time cloud computing applications.

In Proceedings of the 4th International Workshop on

Analysis Tools and Methodologies for Embedded and

Real-time Systems, Paris, France.

Farrel, A., Vasseur, J.-P., and Ash, J. (2006). RFC 4655 –

A Path Computation Element (PCE)-Based Architec-

ture.

Ferrer, A. J. et al. (2012). Optimis: A holistic approach to

cloud service provisioning. Future Generation Com-

puter Systems, 28(1):66 – 77.

Grivas, S., Kumar, T., and Wache, H. (2010). Cloud bro-

ker: Bringing intelligence into the cloud. In Cloud

Computing (CLOUD), 2010 IEEE 3rd International

Conference on, pages 544–545.

Houidi, I., Mechtri, M., Louati, W., and Zeghlache, D.

(2011). Cloud service delivery across multiple cloud

platforms. In Services Computing (SCC), 2011 IEEE

International Conference on, pages 741–742.

Kapoor, R., Porter, G., Tewari, M., Voelker, G. M., and

Vahdat, A. (2012). Chronos: predictable low latency

for data center applications. In Proceedings of the

Third ACM Symposium on Cloud Computing, SoCC

’12, pages 9:1–9:14, New York, NY, USA. ACM.

Kyriazis, D., Menychtas, A., Kousiouris, G., Oberle, K.,

Voith, T., Boniface, M., Oliveros, E., Cucinotta, T.,

and Berger, S. (2011). A real-time service oriented

infrastructure. GSTF International Journal on Com-

puting, 1(2).

Leymann, N. et al. (2013). draft-ietf-mpls-seamless-mpls-

04 – Seamless MPLS Architecture.

Liu, F., Tong, J., Mao, J., Bohn, R., Messina, J., Badger, L.,

and Leaf, D. (2011). Nist special publication 500-292

– nist cloud computing reference architecture.

Mell, P. and Grance, T. (2011). NIST SP800-145: The NIST

Deﬁnition of Cloud Computing.

Oberle, K., Cherubini, D., and Cucinotta, T. (2013). End-

to-end service quality for cloud applications. In

Proceedings of the 10th International Conference on

Economics of Grids, Clouds, Systems and Services,

Zaragoza, Spain.

Pawluk, P., Simmons, B., Smit, M., Litoiu, M., and

Mankovski, S. (2012). Introducing stratos: A cloud

broker service. In Cloud Computing (CLOUD), 2012

IEEE 5th International Conference on, pages 891–

898.

Petcu, D. (2011). Towards a Service-Based Internet,

volume 6994 of Lecture Notes in Computer Sci-

ence, chapter Portability and Interoperability between

Clouds: Challenges and Case Study, pages 62–74.

Springer Berlin Heidelberg.

Plummer, D. (2012). Gartner, inc. – cloud services broker-

age: A must-have for most organizations.

Wieder, P., Butler, J., Theilmann, W., and Yahyapour, R.

(2011). Service Level Agreements for Cloud Comput-

ing, springer edition.

Wilson, C., Ballani, H., Karagiannis, T., and Rowtron, A.

(2011). Better never than late: meeting deadlines in

datacenter networks. SIGCOMM Comput. Commun.

Rev., 41(4):50–61.

Zwickl, P. and Weisgrab, H. (2013). Final ETICS architec-

ture and functional entities high level design.

BrokeringSLAsforEnd-to-EndQoSinCloudComputing

615