SLA Management in an Auction-Based Market Infrastructure

1. SLA Management in an Auction-Based Market Infrastructure Simon Caton, Nikolay Borissov & Omer Rana

2. Contents • Overview of SORMA • Market-based SLA Generation and Representation • Challenges of this process, and related research issues • Currently, unanswered research questions

3. 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

5. SORMA Overview… 1

6. 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)

7. 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 The SORMA Model

8. 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

9. 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!

10. 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

11. SLA Lifecycle Overview WS-Agreement States (from SORMA’s perspective) A bid is made No match Match found, SLA is created, enforced and paid for Market matchmaking SLA life cycle complete Note: this does not mean it was not violated Limitations with bids that are “binding” We do not use these states Bids/offers are binding, they cannot be terminated or withdrawn

12. SLA Service and Guarantee Term StatesFor Pragmatic Enforcement and Billing Service States Guarantee Term States Service can be started or is running Service has finished Service cannot yet be started Not Running Running • 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! • 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

13. 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.

14. 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?

15. 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

16. <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> Comparison of Documents 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

17. 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 SLA PaymentFinal Price =Market Price – Applied Violation-Orientated Penalty Simple Weighted Penalty Function Term violated [yes|no] Penalty Function based on Violation Impact Enables matchmaking How the term was violated

18. 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

19. 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

20. 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.

21. 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…1

22. 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.

23. Questions…?