© 2006 Open Grid Forum Service Level Terms Andrew Grimshaw

© 2006 Open Grid Forum

Service Level TermsAndrew Grimshaw

2© 2006 Open Grid Forum

OGF IPR Policies Apply

• “I acknowledge that participation in this meeting is subject to the OGF Intellectual Property Policy.”• Intellectual Property Notices Note Well: All statements related to the activities of the OGF and addressed to

the OGF are subject to all provisions of Appendix B of GFD-C.1, which grants to the OGF and its participants certain licenses and rights in such statements. Such statements include verbal statements in OGF meetings, as well as written and electronic communications made at any time or place, which are addressed to:

• the OGF plenary session, • any OGF working group or portion thereof, • the OGF Board of Directors, the GFSG, or any member thereof on behalf of the OGF, • the ADCOM, or any member thereof on behalf of the ADCOM, • any OGF mailing list, including any group list, or any other list functioning under OGF auspices, • the OGF Editor or the document authoring and review process

• Statements made outside of a OGF meeting, mailing list or other function, that are clearly not intended to be input to an OGF activity, group or function, are not subject to these provisions.

• Excerpt from Appendix B of GFD-C.1: ”Where the OGF knows of rights, or claimed rights, the OGF secretariat shall attempt to obtain from the claimant of such rights, a written assurance that upon approval by the GFSG of the relevant OGF document(s), any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specification(s) under openly specified, reasonable, non-discriminatory terms. The working group or research group proposing the use of the technology with respect to which the proprietary rights are claimed may assist the OGF secretariat in this effort. The results of this procedure shall not affect advancement of document, except that the GFSG may defer approval where a delay may facilitate the obtaining of such assurances. The results will, however, be recorded by the OGF Secretariat, and made available. The GFSG may also direct that a summary of the results be included in any GFD published containing the specification.”

• OGF Intellectual Property Policies are adapted from the IETF Intellectual Property Policies that support the Internet Standards Process.


Agenda

• At the last OGSA F2F we discussed the need to address QoS/SLA’s in OGSA. The first step is to define what is meant, to determine use cases, and therefore requirements. It was noted that just defining terms is difficult and very domain specific and that solving the general problem, for all classes of service, is an open question. We therefore decided to begin with a short session focused on two specific OGSA services: ByteIO and BES. In this session we will introduce the problem, discuss the roles of WS-Agreement and JSDL, and define prototype (strawman) definitions of SLT’s for both services.

• Proposed Agenda:• Agenda bashing • Present problem• Present examples for ByteIO and BES• Discuss role of WS-Agreement and JSDL• Next steps and action items


What is the problem?

• Specification of QoS/SLA terms to “factory-like” operations. E.G.• Createactivity (JSDL,deadline, cost, reliablity, ..)• Createfile(cost, size, availability, reliability, read

performance, write performance, time intervals …)

• Specify trade-offs• Agree to terms• Implement service


Walk through

• ByteIO• BES container


Dependability

• A few “ilities” of interest for ByteIO• Reliability• Availability• Confidentiality• Integrity• Performability


Availability

• Probability that system will be operational at time t

• Probability that the system will operate correctly up until time t

Reliability

MTTF

MTTF + MTTR

In both cases, in a real world storage example, individuals could select or request a certain set of “ilities” for a certain time span such as:

•“For the next ten minutes”•Every week from 9am Monday until 5pm Friday•For Janurary 2006•Etc.


One per operation (in the limit). Describes for an operation what the individual dependability characteristics of that operation are/should be.

Optional. Gives default values to cover operations/time-slots that are not covered specifically.

Describes a number of named time slots over which dependability sections will be described.

Dependability Documents<file-dependability>

<time-slots>

…

</time-slots>

<default-section>

…

</default-section>

<operation name=“foo”>

…

</operation>

</file-dependability>


What’s in an operation?

…

<operation name=“foo”>

<reliability time=“time-slot1”>0.75</reliability>

<reliability time=“time-slot2”>0.88</reliability>

<availability time=time-slot1>0.99</availability>

<confidentiality>encrypted</confidentiality>

…

</operation>

…


<file-dependability> <time-slots> <work-day>* 9-17 * * 1-5</work-day> <weekend>* * * * 0,6</weekend> <late-night>* 0-9,17-23 * * 0-6</late-night> <school-year>* * * 1-5,8-12 *</school-year> </time-slots> <default> <reliability time=“work-day”>0.99</reliability> <availability time=“work-day”>0.99</availability> <availability time=“late-night”>0.9</availability> <confidentiality>clear</confidentiality> <integrity>protected</integrity> </default> <operation name=“write”> <reliability time=“work-day”>0.9</reliability> <availability time=“work-day”>0.9</availability> <availability time=“late-night”>0.9</availability> <confidentiality>clear</confidentiality> <integrity>protected</integrity> </operation> <operation name=“append”> <reliability time=“work-day”>0.75</reliability> <confidentiality>clear</confidentiality> <integrity>protected</integrity> </operation></file-dependability>


ByteIO Example


<time-slots><work-day>* 9-17 * * 1-5</work-day><weekend>* * * * 0,6</weekend><late-night>* 0-9,17-23 * * 0-6</late-night><school-year>* * * 1-5,8-12 *</school-year>

</time-slots>

I use crontab time syntax here merely as an example, not as a recommendation for an actual syntax!


ByteIO Example


<default> <reliability time=“work-day”>0.99</reliability> <availability time=“work-day”>0.99</availability> <availability time=“late-night”>0.9</availability> <confidentiality>clear</confidentiality> <integrity>protected</integrity></default>


ByteIO Example


<operation name=“write”> <reliability time=“work-day”>0.9</reliability> <availability time=“work-day”>0.9</availability> <availability time=“late-night”>0.9</availability> <confidentiality>clear</confidentiality> <integrity>protected</integrity></operation>


ByteIO Example


<operation name=“append”> <reliability time=“work-day”>0.75</reliability> <confidentiality>clear</confidentiality> <integrity>protected</integrity></operation>


NOTE: Missing Tradeoffs

• Am I willing to trade availability for reliability for each other or cost?

• At what rate?• We’ve found going down this path leads

to complex specification documents that users cannot understand – let alone fill in



We’re moving to a MacDonalds Model

• Give the user a set of choice – like the “special meals deals”


UGH! That’s Ugly


BES


OGSA EMS

Service Container

BES

Program Manager

Abstract JSDL

Info. ServiceExecution Planning

Service

Task Assignment

In concrete JSDL


What might you want to specify

• Deadline• Value function as function of time

• i.e., a tradeoff in time/cost

• Probability it will complete within the deadline

• How much you are willing to pay• Confidentiality requirements on the

execution


Aside

• We’re using the notions in an experimental HA-JES – High Availability Job Execution Service that is extends OGSA BES and uses low quality resources to provide high quality service via replication in space and time