SLA Management in an Auction-Based Market Infrastructure

Simon Caton, Nikolay Borissov & Omer Rana

Contents Overview of SORMA

Market-based SLA Generation and Representation

Challenges of this process, and related research issues

Currently, unanswered research questions

Motivation for this work

Emergence of work on Cloud Computing Commercial providers offering resources (disk storage,

processors) + hosting environments Examples: CycleComputing, EC2/S3, Hadoop, IBM Blue

Cloud, Sun Cloud, Nimbus, Eucalyptus, etc

Pricing Price pre-advertised – then payment based “on demand”

usage Significant potential for brokering approaches in this

domain – especially when interoperability between these providers arises E.g. Eucalyptus using EC2/S3 interfaces

SORMA Overview… 1

SORMA Overview… 2

Intelligent Tools – Agent-based auction participation Market- and agenda-driven

Bid/Offer submission Trading Management – the

Auctioneer Introduces consumers and

providers using technical and economic matchmaking

EERM – an Economically Enhanced Resource Manager

Contract Management – SLA Life Cycle Modelling: Generation, Runtime Logic and

Final price calculation SLA Enforcement – impartial SLA

adherence monitoring; violation detection

Payment – Transaction management for SLA-related billing (Paypal)

The SORMA Model Use Cases:

Job Submission

Service Provision

Market “rules”

All bids and offers are binding – like eBay

i.e. if there is a match participants are (currently) obliged to enter an SLA

Term Languages

JSDL – job/service definition – requirements modelling

WS-Agreement – SLA representation

EJSDL* – Economically Enhanced JSDL for Market-specific data

Currently, no intrinsic or extrinsic support in WS-Agreement for this data

Actors: Consumers Providers SORMA Market

Ecomonic Data

Common Market Data

Bid/Offer

Penalty type

Payment type

Service type

Private Economic Data

Bidding Strategy

Consumer’s Maximum willingness to pay and provider’s reserve price

Optional Market Data

Reservation Period

EJSDL* Envelops JSDL to provide an

economic foundation for Market participation

Three Versions: EJSDLBid – defines the

bid/offer of a Market participant

EJSDLPrivate – defines the private Market-specific data of each participant

EJSDLMarket – encapsulates an established Market Match

Ultimately, the use of EJSDL* means that we reduce the number of matchable and definable terms inherent in WS-Agreement E.g. preference elicitation/term

weighting But, core Market data is more

important!

SLA Generation & RepresentationWS-Agreement WS-Agreement envelops one or more disseminated EJSDLMarket

documents Generation is automated using an EJSDL-orientated Java API +

Apache’s XmlBeans Each SLA is between the consumer and the provider – SORMA

plays no part here! In the future (SORMA #2) we could consider a broker-like SLA

hierarchy, requiring much more sophistication in the Market logic Consumer SORMA SORMA 1 or more Providers

We will come back to this later

in the talk

SLA Lifecycle Overview WS-Agreement States (from SORMA’s perspective)

A bid is made No match

Market matchmaki

ng

Match found, SLA is created, enforced and

paid forSLA life cycle

complete

We do not use these

states

Note: this does not mean it

was not violated

Bids/offers are binding, they cannot

be terminated or withdrawn

Limitations with

bids that are “binding”

SLA Service and Guarantee Term States

For Pragmatic Enforcement and Billing

Service States Guarantee Term States

Service cannot yet be started

Service can be started or is

running

Service has finished

Not RunningRunning

Monitoring of SLA Guarantee term adherence

WS-Agreement only records a global state. Not useful for: Quantifying the impact or frequency of

violations Pragmatic penalty calculation

A finished service != successful service

SLA Enforcement must therefore also monitor at the service level

If a service fails, then it must determine why This is difficult to perform in practice!

Representing SLA Adherence…1WS-Agreement Specification Too General

SORMA provides an SLA Enforcement Mechanism, which collects SLA-related data for adherence classification.

Providers are actively encouraged to participant in this scheme Especially if they wish to be matched in the future Questions of trust are quickly raised, but will not be

discussed here. WS-Agreement’s State representation lacks a

practical representation of adherence in general

Remember that we need to be able to send this information between SORMA components and comply to the WS-Agreement specification.

Representing SLA Adherence…2A Motivating Example for change Example:

3 Non-static Terms T1, T2 and T3 e.g. % Range of CPU utilization available

Adherence is monitored 150 times, and all terms are determinable

T1 is violated 149 times, T2 is violated once and T3 is fully fulfilled

Questions: Terms T1 and T2 are both violated, but their violations

are not truly comparable. Should, and if so how can, we differentiate between these two violations?

How do we apply an appropriate penalty in this case? Is it fair to treat both violations in the same way? Should a penalty function consider that T2 was

predominantly fulfilled?

Augmenting the WS-Agreement Term States Representation The WS-Agreement State representation enables only the

basic status of a term i.e. [Fulfilled | Violated | Not Determined]

However, there is a spare <xsd:anyType> in the document specification

We add additional “house keeping” information here SORMA-specific term language identifying the frequency each

state observation Service scope

2 guarantee terms can have the same name, or 1 term can relate to multiple services.

This differentiation is performed using a service scope. Not in a state document. If the term is violated in one instance but not the other, the

whole term will be identified as violated, which is not the case. Our “House keeping” information encapsulates this too. Enables a fairer penalty application

Comparison of Documents

<GuaranteeTermState ws:termName="termName“>

<State>Violated</State></GuaranteeTermState>

<GuaranteeTermState ws:termName="termName">

<stat:GuaranteeTermStateHouseKeeping> <stat:ServiceScope

ws:ServiceName="serviceName"/> <stat:GuaranteeTermStateTransitions> <stat:NotDetermined> <stat:Frequency>1</stat:Frequency> </stat:NotDetermined> <stat:Violated> <stat:Frequency>1</stat:Frequency> </stat:Violated> <stat:Fulfilled> <stat:Frequency>1</stat:Frequency> </stat:Fulfilled> </stat:GuaranteeTermStateTransitions> </stat:GuaranteeTermStateHouseKeeping> <State>Violated</State></GuaranteeTermState>

Standard WS-Agreement Our Augmented Version

Namespaces (removed for ease of presentation): WS-Agreement: http://schemas.ggf.org/graap/2007/03/ws-agreement House keeping (stat:): http://www.sormaproject.eu/message/sla/state

Enables matchmak

ing

SLA PaymentFinal Price = Market Price – Applied Violation-Orientated Penalty Payment can only be made at

specific points in an SLA’s lifecycle: Before commencement and

After completion Not during

Penalties are specified in EJSDL:<Penalty>

<functionName>DefaultPenalty</functionName>

<normalizationConstant>1.0</normalizationConstant>

</Penalty>

Normalization constant Low is good for providers –

minimizes impact High is good for consumers –

maximizes assurance Negative values also would

introduce interesting scenarios

Best effort using standard representation

w(tn) – weight of term t p – price identified by the Market at the time

of match v(tn) – identifies whether term t was violated

returns [0,1] nc – normalization constant

v(tn), f(tn), nd(tn) – frequency violated, fulfilled and not determined respectively for term t

p

tw

twtvnc n

n

n

nn

*)(

)(*)(*

1

1

Simple Weighted Penalty Function

p

tw

twtndtvtf

tv

nc n

n

n

nnnn

n

*)(

)(*)()()(

)(

*

1

1

Penalty Function based on Violation Impact

Term violated [yes|no]

How the term was violated

Using the adherence data outside of penalty calculationsE.g. Market Information Services

When an SLA is complete all runtime information can be made available to a Market Information Service

For future use and Market Introspection Attribute level adherence monitoring:

Demonstrates provider reliability Enables reputation-based matchmaking Difficulty for a provider to adhere to specific attributes Mechanisms for providers to assess their own

violations, and reputation

Summary

WS-Agreement needs extension for intuitive use in market infrastructures

Term states do not currently enable a pragmatic representation of violation-related data, especially for violation-orientated billing

We are using WS-Agreement outside its "normal" use. There is no (bilateral) negotiation No agreement templates SLAs are based upon and stem from the market matching and

bidding mechanisms. In order to progress further we need a Market-Orientated

version of WS-Agreement. To include: Business values / weighting – in matchmaking Preference elicitation – for best case matchmaking Inclusion of Market data in WS-Agreement Offer Templates

We currently assume legal grounding for each SLA and in the future this needs resolution

Outlook

Identify valuation scenarios and incorporate it in penalty functions

Elaboration of general definitions for weighted Guarantee Terms SLO extraction from two matched JSDL documents

(Consumer and Provider) Mapping of weighted SLOs to Penalty Functions Inclusion of Legal Foundation

WS-Agreement – Specify economic extensions for: Auction-based infrastructures The associated scheduling strategies and decision making

models.

Some topics which are interesting for discussion…1

Can we build a tiered SLA model in a Market place? Consumer Market Broker, Market Broker 1 or more Providers The aim here is to increase transparency to the consumer But there are further challenges:

Handling malicious or untrustworthy providers Issues of Legal Liability for the Broker

Similar to work in AssessGrid? Whose fault is it when a service fails? And, how does this affect

the SLA? No scheduler or resource manager can guarantee a 100% success

rate on job/service submission What if no terms in the SLA were violated?

Is it the Consumer’s fault; perhaps poor programming? What about unfamiliarity of environment, or failed data staging?

Ultimately, who is responsible and therefore going to pay the fee/penalty?

Some topics which are interesting for discussion…2

Application of Legal Foundations in a SLA Example: A consumer pays in full and in advance for a service, but the provider does not

adhere to the SLA and a penalty is due. Therefore, the consumer has overpaid. How can we (en)force the provider to pay the penalty. Or, if they do not, instantiate a legal

process?

Aspect 1: How architecturally can legal issues be supported? Use of a trusted entity to provide a “legal foundation”? Digitally signing and counter signing a SLA. What constitutes a legal document in this context?

Aspect 2: Conceptual issues surrounding the legal enforcement of SLAs How long should an SLA be stored after it is complete

E.g. for dispute resolution Legal issues associated with payment types: (i) before use; (ii) after use; (iii)

either – each option has different legal stipulations E.g. Ensuring that a consumer pays in cases (ii) and (iii)

Which legal directives (e.g. European eCommerce directives) relate to an SLA when the participants are in different “Legal Zones” E.g. Consumer (US), Provider (Asia), Market (EU)

Issues of limited liability.

Questions…?