Contract Management

Resources

Time

Resources

Time

Resources

Time

Figure 4.9: Optimising a resource schedule using scheduling techniques. Without intelligent scheduling the submitted task cannot be run even though there is available capacity, however using advanced scheduling techniques the other tasks can be scheduled in such a way as to opti-mise the overall schedule.

rithms have been extended to consider deadlines and QoS constraints placed on tasks. However in a DRIVE scenario deadline and QoS analysis is conducted during valuation and therefore al-gorithms can be used to organise the schedule at any time. The simplistic approach of allocating tasks by the order of arrival (FCFS) leads to issues of underutilisation and fragmentation as is seen in Figure 4.9 . Conservative and aggressive Backfilling [185, 186, 187, 188] approaches improve this situation by moving small jobs forward to fill holes in the schedule. Heuristic approaches [189, 190, 191] can be used to select the best task to move into the fragmented hole in the sched-ule.

In DRIVE Agents act on behalf of resource providers which in turn act on behalf of groups of resources, in this environment the scheduling problem is made even more complex when consid-ering multiple co-allocation requests that require synchronised execution over a pool of resources.

Scheduling techniques, such as those outlined in [184], are optimised to take into consideration distributed co-allocation and could be applied in DRIVE.

Scheduling algorithms are not within the scope of this thesis. However the Reservation Service has been designed to be extensible so that arbitrary scheduling algorithms can be implemented.

This scheduling can take place when tasks are added to the schedule or when tasks are considered for hosting. Polices regarding negotiations, tentative agreements, and hardened agreements can be used to determine the relevance of each to the scheduling process.

4.5 Contract Management

Having negotiated terms of service provision through an economic protocol the participating entities (providers and consumers) are inherently expected to honour their obligations. How-ever due to the self interested and competitive nature of participants there may be motivation to violate agreements for economic gain or malicious reasons. As in real world economies

con-tractual arrangements can be established to ensure each party honours their obligations, allowing consumers and providers to define and enforce specific terms of service usage and associated incentives (rewards/penalties) for honouring or violating agreements.

In DRIVE contracts describe SLAs between consumers and providers. A SLA contains a col-lection of specific requirements and QoS metrics to be delivered. Standardised representation is required as SLA descriptions may differ depending on the perspective of the entity, for example they may be task or service requirements in the case of a consumer or individual service levels for providers.

4.5.1 Service Level Agreements

A SLA represents an agreement between a service consumer and service provider for a particular provision, as such it is a favoured model of providing assurances in distributed systems. The agreement may be a 1-1 mapping between consumer and provider or possibly n-m between mul-tiple consumers and/or mulmul-tiple providers. A SLA is made up of a number of Service level Ob-jectives (SLO) that define particular QoS requirements that must be maintained by the provider.

These individual SLOs form the measurable parameters of the SLA and can be monitored during the provision to ensure service levels are met. SLAs contain information regarding the parties involved, time periods resources are used, and incentives for honouring obligations. There are a number of results at the conclusion of a SLA - there could be financial penalties/rewards enforced, reputation information formed for use in future transactions, or mutual resolution between par-ticipants such as re-execution of the agreement.

There is much literature regarding creation of SLAs in terms of advertising and posted price markets. However, there is much less research into dynamic market based mechanisms such as auctions. Typically in existing systems resource allocation and SLA negotiation are simultaneous - the negotiation is effectively the allocation. In DRIVE, SLA negotiation takes place after initial allocation. This initial allocation process considers loosely defined QoS parameters and results in a tentative agreement between parties. The parties then participate in a more concrete negotiation process to define the specific QoS constraints in the form of an SLA.

There have been many systems designed to define SLAs. The Contract Net Protocol [104, 192]

was one of the first protocols for negotiating electronic service contracts. Alternative languages for specifying SLAs include: WSLA [193], SLAng [194], WS-Agreement [78] and RBSLA [195].

However, none of these approaches explicitly consider an economic term language [72]. WS-Agreement provides a flexible framework in which a domain-specific term language can be de-fined and used. WS-Agreement has become the de facto standard due to its flexible nature and OGF support. This is demonstrated by many examples of its use in differing architectures, such as Cremona [196], SWAPS [197], and several projects; including SORMA, AssessGrid⁴, and SLA@SOI⁵. The main issue with WS-Agreement is that its protocol stack is not designed to

sup-4http://www.assessgrid.eu/

5http://www.sla-at-soi.eu/

4.5. CONTRACT MANAGEMENT 93 port auction-orientated SLAs, as it is designed for bipartite negotiation [198]. Despite this, it has been successfully used with auction mechanisms in projects such as SORMA using a proprietary economic term language.

WS-agreement has been chosen as the contract representation language for DRIVE due to its flexibility, extensibility and widespread adoption. WS-agreement has essentially become a de-facto standard for SLA representation in the wider Grid community. WS-Agreement also fits with the design of DRIVE in that it is standardised and task independent as any task description lan-guage can be used to form the description terms of the agreement. The economic representation limitations can be overcome by defining additional specialised term languages as is the case with SORMA. However, a slightly different approach has been taken in DRIVE, rather than extending an existing language a separate economic language has been defined to represent the economic aspects of negotiation. There are three major reasons for this approach, first an important goal in the design of DRIVE is independence from a specific class of task, a separate economic language separates the economic properties from the task description rather than binding the description to a specific term language (such as JSDL). Secondly there may be a requirement for an extended (or different) economic language depending on the protocol used, this is easier using a separate language which may be extended or replaced. Finally in a federated environment, providers may have existing economic representations (and possibly contract/agreement architectures), it there-fore makes sense to use a standardised representation like WS-agreement with the ability to map term representations rather than requiring providers implement proprietary non-standardised representations.

4.5.2 Contract Incentives

Enforcement of contracts is difficult in any environment, not least of which distributed archi-tectures as providers are under independent administration. Rather than enforcing appropriate behaviour DRIVE relies on incentives to encourage participants to act in a desired manner. In-centives are generally thought of in two categories: positive and negative, positive inIn-centives motivate entities to act a particular way by rewarding them for their actions, negative incentives take the opposite approach by punishing entities that do not act appropriately. Incentives can be further categorised as remunerative, moral or coercive depending on the way in which agents are motivated. Remunerative incentives are based on an expected reward (or penalty) in exchange for their actions, typically remunerative incentives are financial. Moral incentives exist when it is generally accepted that one course of action is the correct behaviour, entities acting against a moral incentive expect condemnation from the community while those that follow the moral incentive are looked at favourably. Moral incentives are similar to proportional share models.

Coercive incentives are based on a physical force being applied to entities that fail to act in an ap-propriate manner, for example actions such as imprisonment or confiscation. In DRIVE, financial rewards and penalties are considered remunerative incentives, reputation can be thought of as a moral incentive, and VO suspension or expulsion is a coercive penalty.

In economic systems financial penalties are the most commonly used means of providing both positive and negative incentives. Financial incentives are central to economics both in individual decision making and in co-operative or competitive reasoning and can therefore be considered in economic analysis of the system. Positive financial incentives are inherent in economic systems such as DRIVE, due to the fact providers are rewarded for services provided through payments by consumers. In this situation if a consumer is unhappy with the service received they may choose not to pay. However, if a service is half fulfilled it is difficult to establish the value of the violation. Penalties provide a way of categorising breaches and punishing poorly behaving users, in DRIVE a set of penalties can be outlined for differing levels of contract breaches.

The DRIVE architecture focuses on financial incentives to encourage agreement compliance, other approaches to enforcement are outside the scope of this thesis and are considered future work. DRIVE contracts define a set of rewards and penalties for each contract term. A binary measure of fulfilment is used - if a service level is delivered then a reward is paid, if the term is not fulfilled then a penalty is invoked. This approach provides a degree of flexibility allowing fine grained terms (and matching rewards or penalties) to be specified.

4.5.3 DRIVE Contracts

DRIVE contracts are expressed using WS-agreement with individual terms described in a domain-specific task description language. A unique two phase progressive contract creation process is used to mitigate the effects of allocation latency by hardening tentative agreements into con-tracts [199].

Progressive Contract Creation

There is potential for considerable latency in the DRIVE allocation process (auctions, tendering) between providers participating in economic negotiation and winner determination/confirma-tion. This latency may restrict providers participating in future negotiations due to lack of knowl-edge of the outcome of ongoing or previous negotiations. Providers have two approaches to this issue, they can reserve resources for the duration of the negotiation or they can wait until the result of the allocation before resource reservation. Neither situation is ideal; initial reservation leads to underutilisation as a negotiation typically has one winner and multiple losers, late reser-vation results in contract violations as resource state may have changed between negotiation and reservation. To mitigate the effect of latency DRIVE implements a progressive two phase contract mechanism to reflect the various stages of negotiation. Providers can therefore take into account the possibility of allocation when considering future negotiations.

The two phase contract structure is shown in Figure 4.10. As the result of an allocation a tenta-tive agreement is created between the user and winning provider(s) (phase 1), before redemption this agreement must be hardened into a binding agreement (or contract) that defines particular lev-els of service to be delivered along with a set of rewards and penalties for honouring or breaking the agreement (phase 2). Typically the tentative agreement is not strictly binding and penalties for

4.5. CONTRACT MANAGEMENT 95