Mitigating Provider Uncertainty In Service Provision Contracts

1
Mitigating Provider Uncertainty In Service
Provision Contracts

• Chris Smith
• Aad van Moorsel
• School of Computing Science
• Newcastle University
• Workshop on Economic Models and Algorithms for
  Grid Systems (EMAGS2007)

2
contents
or more on IT and business metrics

• the main challenge (bottleneck?) in doing
  research on IT Business
• SLAs and what they enable
• pricing and trust no need for IT trust solutions
• better prediction makes more money (or, better
  modelling makes more money)
• our results in this line of work
• open issues

3
the bottleneck in ITbusiness (trust economics
example)
4
example trust economics

• with Merrill Lynch, HP, Bath, UCL how to decide
  about data protection technology

5
main challenge tractable metric

• all good and well, but we would need numbers for
• cost of software
• cost of IT admin time
• loss of employee productivity
• cost of upgrades
• value of data loss
• etc., etc.
• we cant quantify many of these, so we dont know
  what to measurelet alone know how IT impacts
  these un-measurable things

6
main challenge tractable metric

• research needed
• we need to measure something (stock price?
  profit?)
• and find some relation between IT or IT-driven
  events and these metrics
• there are some examples that we can take
  inspiration from eg., stock price and announced
  software security breaches
• however, let us for the moment avoid the metric
  challenge...

7
service level agreements

• several ways of avoiding/resolving the metric
  challenge
• service level agreements
• it gives us the metric relating IT QoS with
  prices and penalties
• regulations, like Basel 2
• it gives us the metrics relating QoS (2 days bank
  transfers) with penalties
• any other?
• any way, lets see how we can exploit SLAs to do
  better IT

8
pricing and trust
9
trust
Provider says response time lt 200msec. Why would
you trust this claim?
resp_time 200 ms
Contract
Resources
Stock Quote
Consumer
Payment
Provider
One-Time Exchanges in Service Provision
10
trust

• possible solution
• hire a trusted third party, build a monitoring
  infrastructure, when you want a service check
  with the third party what the typical QoS of the
  provider is
• that is, a lot of extra IT and process

11
Trust through Pricing

• Huberman Solving the QoS Problem
• negotiate about q, the probability the contract
  is met
• pricing and penalty depending on q
• if you do the pricing and penalty right, you
  achieve truth telling, i.e.,
• there is no benefit for a provider to lie about
  the QoS it can achieve
• this actually is a straightforward incentive
  compatibility result

12
trust through pricing conclusion

• instead of a complex solution with trusted third
  parties, simply design the pricing and
  negotiation so that truth telling is assured
• ? business-level design replaces IT
• notes
• provider must expose (advertise) prices for all
  q
• negotiation protocol unnatural who would
  negotiate about q?
• elements of uncertainty missing

13
a more natural SLA model

• negotiate about QoS level (response time value)
  instead of probability q of missing an SLA
• allow uncertainty of the attained QoS level
• EUm(v) gm (v) - ?vmax fm(v) dv hm
  (v)
• can be extended once more QoS level
  probability of meeting the QoS

payment for v
penalty if v
uncertainty for v
14
better prediction improves profits
15
knowing the achievable QoS
we have established there is no point in lying
about the QoS of the service problem how can
the provider know the QoS the service it is going
to deliver? Arent you forced to lie because
you cant know exactly? secondly if one invests
in finding out (through monitoring and modelling)
the future QoS, can you then make more money?
16
the cost of poor prediction
17
dealing with uncertainty in QoS

• instead of q we negotiate about QoS
• we already modelled uncertainty about QoS through
  a probability density f over QoS values v
• EUm(v) gm (v) - ?vmax fm(v) dv hm
  (v)
• extended with probability to meet QoS level
• truth-telling results are now harder to
  formulate, but can be established

18
better prediction makes more money

• almost a corollary of truth-telling result if
  you misestimate the delivered QoS, you lose money
• some experiments
• let us use historical data to predict the future
• let us assume that, indeed, the historical data
  are i.i.d. samples of f
• let us assign a cost c to collecting data,
  linear in amount of samples

19
Results
Monitoring Policy vs Expected Utility a 10, ß
? -10, ? 5, dg -10, eg 10, dh -15, eh
15
20
the benefit of better prediction
you think youll make this much
you knowQoS exactly
youll actually make this much
Chris Smith, AvM Mitigating Provider
Uncertainty in Service Provision Contracts,
EMAGS 2007
21
Implementation

• Representational State Transfer architectural
  style utilised.
• HTTP methods used to realise the architecture,
  providing all methods required for introspection
  and manipulation.
• Stateful entities represented by resources, and
  identified by URIs, e.g. jobs and contracts.
• Provider and consumer can invoke state
  transitions through the execution of the HTTP
  methods on these resources using their
  representations.
• Internal components manage the lifecycle of
  stateful entities.

22
conclusions

• SLAs are a convenient way to avoid the metric
  challenge and allow one to link up IT with
  business concerns
• examples of the use of SLAs
• in QoS negotiation, IT and process-heavy
  solutions can be replaced by straightforward
  business level solutions
• IT mechanisms can be evaluated with respect to
  the money they make
• in fact, a lot of earlier work can be (has been
  and is being) extended to optimize with respect
  to SLA prices and penalties
• we did
• generalized the formulation of the QoS
  negotiation problem, into a more intuitive format
• demonstrated that prediction through monitoring
  can be optimised with respect to money made from
  better monitoring
• implemented in REST architecture