A Policy-Definition Language and Prototype Implementation Library for Policy-based Autonomic Systems Richard John Anthony University of Greenwich [email protected]

A Policy-Definition Language and Prototype Implementation Library for

Policy-based Autonomic Systems

Richard John AnthonyUniversity of [email protected]

Introduction

This work is towards a generic policy toolkit to support the implementation of autonomic computing systems in which the policies themselves can be adapted dynamically and automatically.

Clearly identifiable need for powerful, easy to deploy tools to facilitate policy-based self-managing behaviours in a very-wide range of application domains.

A generic solution must: • Be flexible to enable a diverse set of behaviours to be defined; • Be sufficiently expressive to capture both simple and complex business logic; • Support re-use of behaviour to reduce policy development time; • Be accessible to non autonomics-expert software developers working in a diverse range of application fields; • Facilitate integration with legacy applications.

Richard Anthony University of Greenwich ICAC 2006 1

Background

Policies identified as a key concept for implementation of AS(At least 50% of papers at ICAC 2006 use or advocate policies)(Current state of policy technology a Key identified shortcoming)

Developed self-config, self-opt Parallel Processing application early 2005(eventually supported by 5 separate policies, addressing various aspects ofbusiness logic – dynamic adjustment of granularity, resource management etc).

• An exploration exercise• Policies directly embedded into application• Policies ranged in complexity and functionality• Each policy required some common, and some unique features• Simple self-adaptation achieved in some policies• Developer time split evenly between:

Business logic and mechanisms, and Self management / policy aspects

There must be a better way … Richard Anthony University of Greenwich ICAC 2006 2

Direction

Current policy-based systems can exhibit self-adaptive behaviour by embedding a policy which itself is static at run-time. → Policy changes typically require open-loop adaptation.

This work is concerned with future policy-based systems:• Able to ‘evolve’ because the policy can adapt itself. • Embed a suite of policies and use a meta-policy to dynamically select based on environment / context.

It will be possible for several dimensions of adaptation to occur concurrently:• Fine-grained policy-static control,• Medium-grained optimisation achieved through policy self-adaptation,• Coarse grained behavioural shifts achieved through meta-policy high-level governance.


Interpretation of the term ‘policy’

• A set of configuration values that parameterise a rule-based decision engine - in this work referred to as a Template. • A set of rules that are applied to determine the behaviour of the system given certain inputs.

Polices thus contain the configuration parameters and the actual decision rules externally to the embedded mechanism.

Templates and policies are ideal entry-level techniques for embedding adaptive behaviours into applications. → Current schemes usually provide only initiation-time configuration, i.e. - configuration remains static at run-time, or

- run-time behaviour scoped within pre-set bounds.

Complex systems with wide potential behaviour space do not lend themselves well to governance by a single policy. → Better to have a collection of policies and use a Meta-policy to select.


Current State-of-Practice in Policy-based Autonomics

Three distinct levels of sophistication are found in current approaches:

1. Policy rules are statically embedded. The template configuration is exposed and can be modified between executions.

2. Policy updates are open-loop. An external entity (usually a human) identifies, or is alerted to, potential configuration optimisations, which can be applied between executions.

3. Closed-loop adaptation, where the policy dynamically and automatically adapts its own rule-base or template settings during execution. (Few schemes target or achieve this level at present).


(a) P (b) T P

T P(c)

TTT P(d)

M

PPP P(e)

M

T P(f)

P

MT

TTT

PPP

Manual configuration Policy (rule based) Library of templates

Template configuration Meta policy Library of policies

Direct configuration / control Controlled system Persisted state

Feedback / monitoring / update State propagation

Pictographic representation of policy life-cycles found in current practice


Extending the state of the art

The new policy language and library support self-adaptive policy behaviour:

The policy is able to adapt its own behaviour as well as adapting thecontrolled system.

This gives rise to a number of envisioned policy-system configurationsbeyond current practice.


T P(g)

T P(h)

PPP P(i)

M

TTTPPP P(j)

MT

P

MT

TTT

PPP

Manual configuration Policy (rule based) Library of templates

Template configuration Meta policy Library of policies

Direct configuration / control Controlled system Persisted state

Feedback / monitoring / update State propagation

Advanced policy configurations beyond the current state of practice


Differential between existing and proposed approaches (V. generalised)

Controlledcomponent

Manager

Policy

Controlledcomponent

Manager

Policy

Meta-Policy

State ofPractice ?

Proposed /Targeted

Some governance delegated to meta-policy

PolicyPolicy


The Policy Definition Language

Extends the state of the art in policy languages:

Explicit support for dynamic self-adaptation of policies over both shortand long term through persisted configuration changes.

Policy suites, in which a particular type of policy can have manydifferently-geared instances (e.g. cautious and aggressive versions).

Suites of templates for a given policy-type allow different initial configurations to be used, depending on circumstances.

Meta-policies can be used to select amongst many policy-instances and templates at initiation time.

Meta-policies can automatically ‘hot-swap’ between instances of the same type of policy at run-time.

Features to support bounded behaviour and enhance stability.

Facilitates policy-object reuse.


Overview of the policy definition language features (1)

Object oriented. Objects represent policies, rules, actions etc. OO approach facilitates re-use of behaviour, through reusing tested objects.

A polymorphic Variable-type (PolicyObject) facilitates referencing of policy objects within the policy rules and actions themselves.

Hierarchical support for three levels of ‘policy’: 1. Templates provide configuration parameters which are used to initialise the other types of policy. 2. Normal policies contain the low-level autonomics logic. 3. Meta-policies provide higher-level adaptation.

A single policy script may contain all three types forms of ‘policy’.

Meta-policies can be used to perform an initial configuration decision, and / or can operate continuously. In this latter mode, meta-policies support ‘hot-swapping’ between normal policy instances.


Overview of the policy definition language features (2)

Reinforces natural semantic differences between:• Variables that convey external information to the policy,• Variables used to maintain internal policy state.

External variables cannot be modified, configured in a template, or persisted. Must be passed into the policy via the library interface eachtime the policy is invoked.

Dynamic state represented by internal variables can be persisted to enable longer-term adaptation.

Separating variables into 2 classes reinforces type-safety and semanticchecking. E.g. an external variable may only occur on the RHS of an assignment operation.

Template configuration of internal variables supports specification of variousattributes, which include: upper and lower value limits,

increment and decrement amounts. (Attributes can be dynamically adjusted at run-time)

Policies are formatted in XML which enforces a standard general syntax and facilitates portability and deployment in heterogeneous systems.


Class Hierarchy

CPolicyObject

CPolicy

CTemplate CActionCRule

CInternalVariable

CVariable

CExternalVariable

strNameEvaluate()


Language structure and components (1)

ExternalVariable: Variables that are passed in to the policy at the point of policyevaluation. These variables represent environmental or contextual conditions.

InternalVariable: Variables used internally by a policy (e.g. counters and flags).

Variables can be of three basic types: Long, Boolean and PolicyObject.Strong validation is used to ensure correct usage.

Template: A collection of InternalVariable configuration statements that apply to a particular policy-type.

ReturnValue: Named Numerical return codes for use within the policy script.

Action: A grouped sequence of activities. A particular Action may occur when a Rule evaluates to either true or false, or when a ToleranceRangeCheck evaluates to either in-zone or not-in-zone.

Rule: A statement that evaluates to either true or false. Rules have separate Actions for the evaluate true and evaluate false cases.


Language structure and components (2)

ToleranceRangeCheck: A specialized rule that is used to implement fuzzy variable comparison, as well as dead-zones. Separate Actions can be specified for the In-Zone and Not-in-Zone evaluation cases.

Policy: A sequence of Rules and ToleranceRangeChecks that implement the self-management business logic. MetaPolicy (special case of Policy): A sequence of Rules and ToleranceRangeChecks that can be used to dynamically select the current policy and template configuration.

PolicySuite: A collection of Policies of the same ‘type’ (i.e. concerned with a certain aspect of business logic).


The Policy Library

Easy integration with legacy code:Provides internal support for many powerful language-support features. Clear demarcation between internally managed and externally maintained aspects of policy behaviour.

Supports use by non-autonomics-experts: Simplifies mapping of business logic into policy specifications, through features such as:

• Powerful library-internal validation and semantic checking,• Distinction between internal and external variables,• Automatic restriction of low-level adaptation within higher-level expressed bounds,• Silent conflict / violation handling.

Generic applicability to a wide range of problem domains: Flexible methods for defining application-to-policy interface objects such asExternalVariables and ReturnValues in programming-language-neutral ways.


Case Example 1: Self-optimisation in parallel processing

Conforms to configuration (f) in the policy taxonomy.

This example is one of several policies deployed in an exploratory self-managing parallel processing application.

This particular policy dynamically optimises Round-Trip Time (RTT) measurement activity (as part of the embedded discovery and dynamic optimisation capabilities).

The optimisation is in terms of achieving a balance between saving network bandwidth and processing by cutting out some calibration messages, and yet performing sufficient measurements to keep track of the variability of communication latency between components.


Policies operate at several logical levels

Business-level policy(expression of user intent)

“Optimise costs of calibration”,“I don’t care whether a specific calibration event is skipped or not”,“No more than 5 consecutive calibration measurements should be skipped”

System-Level policy(lower-level behaviour rules)

Attribute values govern manipulation of specific variables, e.g.

Variable: CalibrateIntervalAttributes: InitialValue="1" MaxValue="5" IncrementAmount="1“ …

One object (such as a variable) can directly impact the evaluation of anotherobject (such as a rule) – obvious case.

But also (for example) a rule can impact the manipulation of a variable by changing its attributes


Case Example 1: Self-optimisation in parallel processing (Outline operation)

A variable that governs the current number of calibration messages that canbe skipped (the soft limit) is initialised to 1, and has a MaxValue attribute set to 5 (the hard limit).

The policy keeps track of variability in RTT measurements, allowing calibrations to be skipped when the communication latency is stable.

During prolonged periods of stability the policy gradually ramps up the soft limit value – until eventually it reaches the hard limit.

Further increment requests can be made, but the library mechanisms ignore any requests that violate the variable’s attribute settings.

When the communication latency becomes more volatile the soft limit isdropped back to its initial value.

Summary: One set of rules maintain configuration parameters that governthe behaviour of other rules.


The RTT policy Script (abridged) Part 1

<PolicyConfiguration>  <EnvironmentVariables> <Variable Name="E_iCurrentSample" Type="long"/> </EnvironmentVariables> <InternalVariables> <Variable Name="I_iCalibrateInterval" Type="long"/> <Variable Name="I_iSimilarSampleCountThreshold" Type="long"/>

</InternalVariables> <Templates> <Template Name="DefaultTemplate"> <Assign Variable="I_iCalibrateInterval" InitialValue="1" MinValueValid="true" MinValue="1"

MaxValueValid="true" MaxValue="5" IncrementAmount="1"/> <Assign Variable="I_iSimilarSampleCountThreshold" InitialValue="3“ MinValueValid="true" MinValue="1" MaxValueValid="false" MaxValue="0“ IncrementAmount="1"/>

</Template> </Templates> <ReturnValues> <ReturnValue Name="YES_Forced" Value="1"/> </ReturnValues> <Actions> <Action Name="A_ContinueAfterInterval"> <Increment Variable="I_iCalibrateInterval"/> <Assign Variable="I_bCanSkipCalibrationUnlessIntervalReached" Value="true"/> <Assign Variable="I_iSkippedCount" Value="0"/> <Assign Variable="I_iPrevSample" Value="E_iCurrentSample"/> <Return ReturnValue="NO_Stable"/> </Action>

</Actions>

Externally configured

values


Soft Limit

Hard Limit

The RTT policy Script (abridged) Part 2

<Rules> <Rule Name="R_ContinueAfterInterval" LHS="I_bStable_CanSkipAfterCalibrateInterval“ Operator="EQ" RHS="true" ActionIfTrue="A_ContinueAfterInterval" ElseAction="Null"/> <Rule Name="R_SkipIntervalReached" LHS="I_iSkippedCount" Operator="LT" RHS="I_iCalibrateInterval" ActionIfTrue="A_CanSkipCalibration" ElseAction="A_MustPerformIntervalCalibration"/>

</Rules> <ToleranceRangeChecks> <ToleranceRangeCheck Name="C_CurrentSampleStable“

CheckVariable="E_iCurrentSample" CompareAgainstVariable="I_iPrevSample" ToleranceRangePercentSpecifier="I_iSampleTolerancePercent" ActionIfInZone="A_CurrentSampleStable"

ActionIfOutsideZone="A_CurrentSampleNotStable"/> </ToleranceRangeChecks> <Policies> <Policy Name="DefaultPolicy" PolicyType="NormalPolicy"> <Initialise CurrentTemplate="DefaultTemplate"/> <Evaluate Rule="R_OptimisationAllowed"/> <Evaluate Rule="R_CanSkipCalibrationUnlessIntervalReached"/> <Evaluate ToleranceRangeCheck="C_CurrentSampleStable"/> <Evaluate Rule="R_ContinueAfterInterval"/> <Evaluate Rule="R_SameCountSufficient"/> </Policy> </Policies></PolicyConfiguration>


values


Sample results: the RTT policy in action

0

20

40

60

80

100

120

140

160

180

0 50 100 150 200 250 300 350Sample number

RT

T m

easu

rem

ents

(m

S)

0

1

2

3

4

5

'Cal

ibra

te I

nte

rval

' th

resh

old

val

ue

RTT Current SampleRTT variability (moving average)'Calibrate Interval' threshold


Case Example 2: A multi-policy stock trading scheme (1)

Conforms to configuration (i) in the policy taxonomy (beyond current state of practice).

This example illustrates the use of meta-policies and the advantage of dynamic switching between instances of business policies.

The stock system is representative of many real-world problems that have:Highly complex behaviour,Sensitivity to several sources of environmental volatility,Non-linear sensitivity to some environmental parameters, Many dimensions of freedom.

For a system with any of these characteristics, it is not realistic to closely track the system over its entire behaviour range with a single policy.



Trading decisions are subject to influences such as price behaviour trends, the rate of change in traded volumes and the rate of change in price, etc.

A single, generalised (and thus coarse) policy could lead to significant sub-optimality across a wide spectrum of behaviours.

One solution is to divide the application behaviour space into several zones.

Each zone requires a stock-price-based trading strategy, contextualised by a given range of rate of change in traded volumes and in price.

Zone # 2

Zone # 3Zone # 1

Zone # 4

Rate of Volume Traded change

Rate of Price

change

The policies have different configuration but are of the same ‘type’ since theyaddress the same business decision (but arrive at their decisions differently).


PolicymaintainedthresholdsPolicy

Time

Price PolicymaintainedthresholdsPolicy

Time

Price


Each policy is configured such that its operational envelope (that over which it guarantees safe and desirable behaviour) is tuned to map closely onto its ‘zone’.

A self-adaptive policy may adjust its own thresholds over time, or these might be supplied externally.



Individual policies need not be aware of the delimitation of their zones.

A MetaPolicy is employed to select between the different business policies.

The MetaPolicy monitors the behaviour of the target system and determines which policy should be employed at any given moment.

Policymaintainedthresholds

Policy

Time

Price

MetaPolicy

Policymaintainedthresholds

Policy

Time

Price

MetaPolicy



There is a risk of instability if simple cut-off points are used to determine the policy selection.

If the behaviour of the monitored system is close to one of the cut-offs there isa possibility that the policies will be switched to and fro, causing extra work forthe system.

The ToleranceRangeCheck language object facilitates easy configuration of dead-zones, enhancing stability (localised oscillatory behaviour in the target system is not mirrored in the behaviour of the MetaPolicy).

Policy # 2

Policy # 3Policy # 1

Policy # 4

Rate of ‘Volume Traded’ change

Rate of ‘Price’ change

Price rate-changedead-zone

Volume rate-change dead-zone

Policy # 2

Policy # 3Policy # 1

Policy # 4

Rate of ‘Volume Traded’ change

Rate of ‘Price’ change

Price rate-changedead-zone

Volume rate-change dead-zone


The stock-trading multi-policy script (abridged) Part 1<PolicyConfiguration>  <EnvironmentVariables> <Variable Name="E_iCurrentPriceRateChange" Type="long"/> <Variable Name="E_iCurrentVolumeRateChange" Type="long"/> </EnvironmentVariables> <InternalVariables> <Variable Name="I_iPriceRateChangeDeadZone" Type="long"/> <Variable Name="I_iVolumeRateChangeDeadZone" Type="long"/> <Variable Name="I_iDeadZoneTolerancePercent" Type="long"/>

</InternalVariables> <Templates> <Template Name="MetaTemplate"> <Assign Variable="I_pCurrentPolicy" InitialValue="Policy1"/> <Assign Variable="I_iPriceRateChangeDeadZone" InitialValue="60"/> <Assign Variable="I_iVolumeRateChangeDeadZone" InitialValue="50"/> <Assign Variable="I_iDeadZoneTolerancePercent" InitialValue="10"/> </Template>

</Templates> <ReturnValues> </ReturnValues> <Actions> <Action Name="A_DeterminePolicyBasedOnPriceRateChange"> <Evaluate Rule="R_CurrentPriceRateChange"/> </Action> <Action Name="A_DeterminePolicyBasedOnVolumeRateChange"> <Evaluate Rule="R_CurrentVolumeRateChange"/> </Action>

</Actions>


values


The stock-trading multi-policy script (abridged) Part 2

<Rules> <Rule Name="R_CurrentPriceRateChange" LHS="E_iCurrentPriceRateChange" Operator="LT" RHS="I_iPriceRateChangeDeadZone" ActionIfTrue="A_SelectLowPriceRateChangePolicy" ElseAction="A_SelectHighPriceRateChangePolicy"/>

</Rules><ToleranceRangeChecks> <ToleranceRangeCheck Name="C_PriceRateChangeDeadZone" CheckVariable="E_iCurrentPriceRateChange" CompareAgainstVariable="I_iPriceRateChangeDeadZone" ToleranceRangePercentSpecifier="I_iDeadZoneTolerancePercent" ActionIfInZone="Null" ActionIfOutsideZone="A_DeterminePolicyBasedOnPriceRateChange"/>

</ToleranceRangeChecks><Policies> <Policy Name="Meta_Policy" PolicyType="MetaPolicy"> <Initialise CurrentTemplate="MetaTemplate"/> <Evaluate ToleranceRangeCheck="C_PriceRateChangeDeadZone"/> <Evaluate ToleranceRangeCheck="C_VolumeRateChangeDeadZone"/></Policy> <Policy Name="Policy1" PolicyType="NormalPolicy">  </Policy> <Policy Name="Policy2" PolicyType="NormalPolicy">  </Policy> <Policy Name="Policy3" PolicyType="NormalPolicy">  </Policy> <Policy Name="Policy4" PolicyType="NormalPolicy">  </Policy></Policies></PolicyConfiguration>


values


Conclusion

Meta-policies represent a meta-state transition in policy computing; bringing greater flexibility and a hierarchical aspect that helps control complexity.

The policy language supports several dimensions of adaptability: - Low-level changes enforced by a particular policy; - Dynamic adjustments to internal state variables (e.g. including the parameters that define the position and width of dead-zones). - Automatic switching of policies to ensure that the current policy always remains within its optimal operational envelope; - Longer-term adaptation by dynamically updating template configurations and persisting their state.

The direct support for dead-zones enables stability despite a potentially highextent of adaptability.

The library mechanisms automatically enforce adherence to constraints such as maximum value for a given variable (these attributes are themselves dynamically re-configurable).

The library facilitates integration into legacy code - many applications in current use need self-management, without complete re-development.


(Lots of) Further work

Further development of language specification• Support for utility functions (CUtility) and fuzzy comparisons are planned,• Richer attribute sets on objects.

Further development of library and interface• Flexible persistence support,• Internal logging / trace facility, • An instrumentation interface for external monitoring.

Development of a suite of demonstrator / validator applications

Documents

A Policy-Definition Language and Prototype Implementation Library for Policy-based Autonomic Systems Richard John Anthony University of Greenwich [email protected]