Mechanism Design for RealTime Scheduling

1
Mechanism Design for Real-Time Scheduling

• Carl Bussema III18 April 2005
• Based on "Mechanism Design for Real-Time
  Scheduling" by Ryan Porter

2
Teaser

• Definition of problem
• Previous results
• Designing a mechanism
• Restricted cases
• Conclusions and questions

3
Clueless Problem Definition I

• Online real-time scheduling (uniprocessor)
• Jobs released at various times, no knowledge of
  upcoming jobs
• Goal complete highest value of jobs before their
  deadlines
• Zero value if job not complete by deadline
• Compare results to optimal performance if all
  jobs known from start
• Formally define a job to have a release time r, a
  length l, a value v, and a deadline d

4
Clueless Problem Definition II

• Mechanism design
• Each jobs released to a different self-interested
  agent
• Agent gets value v if its job finishes before d
• Agent submits job with some type (r', l', v', d')
• Scale values as needed so no job has v lt l
• Server decides schedule from what it's told
• Server charges agents some price p
• Goal Design competitive mechanism with dominant
  strategy

5
A Different World Motivation

• Problem traditionally considered in non-strategic
  setting
• Jobs released directly to server no chance to
  lie no payments required
• Strategic setting makes more sense with modern
  environments like grid computing
• RT setting allows model to be used for
  mission-critical applications

6
The Others Previous results

• Most previous work focused on non-strategic
  settings
• Express competitive ratios based on k ?max /
  ?min , where ? is v/l for any job
• For k 1, a 4-competitive algorithm exists
• For k 1, a (1vk)2 - competitive algorithm
  exists
• Both bounds also shown tight for deterministic
  algorithms

7
Step by StepDesigning a Mechanism

• Agents being self-motivated want to profit
• Encourage participation
• Non-participants get 0 utility
• Participants get at least 0 utility
• System must be designed to handle this
• Competitive performance easier if truthfulness
  ensured
• Design system such that lying can't increase
  utility and may decrease it

8
CSI An example (I)CSI Conflicting Schedule
Illustrated

• Consider jobs in the table (l v ? k 1)
• Deciding to preempt
• Use some metric toassign priority
• This example findexpected loss based onwhat
  could be done by new jobs deadline
• Don't preempt if expected loss under desired
  ratio
• This example, 2 waits for 1 and is preempted by 3

9
CSI Example revisited (II)

• If instead, job 2 lies about its deadline, an
  algorithm might preempt job 1 for it, so 2 would
  finish before 3 arrives

10
The PracticePorter's Mechanism

• At every time t, run the job i with highest
  priority vi' vk (ei(t)) ?min
• ei(t) is elapsed processing time for job i by t
• Notice
• Priority based on reported value and elapsed
  processing time (k and ?min are independent of
  any single job)
• Priority of a job only increases when active
• Requires a priori knowledge of k and ?min

11
The Price is RightPayment Scheme

• Agents whose jobs are completed by deadlines must
  pay server the minimum value that would have
  completed their job, given everything else all
  agents reported
• This is similar to a second-price auction
• These agents then have utility v p
• Agents aware of this charging scheme and will
  abide by it (could demand v up front and use
  refund)
• Other agents pay nothing (therefore have zero
  utility)
• Thus we satisfy Individual Rationality agents
  will voluntarily participate because it can only
  help

12
To Tell the TruthPreventing LiesOverview

• Agents could lie about 4 things
• Release time
• Prohibit claiming r' lt r
• Length
• Prohibit claiming l lt l
• Value
• Deadline
• Necessary to show under- or over-stating any of
  these is not beneficial

13
To Tell the TruthPreventing Lies to Improve

• Because of 2nd-price auction, lying about value
  can't help
• Claiming an early release time or a shorter
  length are prohibited
• Claiming a later deadline could possibly help
• We avoid this by "holding" jobs on the server
  until reported deadline, only then return to
  agent
• Thus agents will not get their jobs by their real
  deadlines, and thus get no utility
• More interesting is the problem of lying to worsen

14
Law OrderProof of Truthfulness ri (I)

• Ground rule can't declare r' lt r
• Assume for some reported (ri', li', vi', di') job
  i finishes before d, but not under (ri, li', vi',
  di')
• l' l by ground rules, d' lt d by rationality
• We will show this is impossible

15
Law OrderProof of Truthfulness ri (II)

• Consider case with truthful r
• Let tp be the first time i ispreempted ta be
  time Iabandoned (not enoughtime left)
• Claim all jobs that execute during (tp,ta
  either arrive during that same time and have
  higher priority at their release than i or are I
• If a job x was released before tp, clearly i has
  priority over x, because at some point before tp,
  i ran instead of x
• If a job z is released during the interval, then
  by definition it has lower priority at its
  release
• Inactive jobs do not increase in priority, so the
  claim holds

16
Law OrderProof of Truthfulness ri (III)

• Now consider case where agent declares ri' gt ri
• S must change during (tp, ta vs. when ri
  declared
• i can't run longer outside this range when ri' gt
  ri
• The change could be any job for another, not
  necessarily i
• Call tc first time change occurs, yc job running
  then under original S. How can any job have
  higher priority at tc than yc under S'?
• Before tp the job ran longer under S' (had to
  replace i)wont increase priority enough to
  outweigh a job that beats I at tp
• During (tp,tc) the job ran longer under S'
  (again has to replace or be i). Contradicts
  first time change occurs.
• Since no job can have higher priority than yc at
  tc under S' than under S, no change can occur,
  and a later release time cant help

17
Law OrderProof of Truthfulness li di

• Recall l' lt l disallowed di' gt di unhelpful
• Only effect these have is on defining set of
  "available" jobs
• Incomplete those with elapsed time lt l'
• Abandoned elapsed time time to d' l'
• If job completes with l' and d', the 1st
  condition must become false before 2nd becomes
  true
• Declaring earlier release and later deadline will
  only make "incomplete" false earlier and
  "abandoned" false later, so it will not help to
  lie about these.

18
NUMB3RS Competitive Ratio

• Proofsketch (recall k?max / ?min, ?v/l)
• List only jobs completed by schedule and divide
  time into intervals (tfopen,tfclose
• tfclose time when job f finished tfopen
  tf-1close (0 for t1)
• Prove no interval length (11/vk)vf (induction)
• Prove max OPT can get per interval for jobs we
  abandoned is (1vk)vf (we wouldn't have
  abandoned them)
• Give OPT per interval
• k times interval length (almost entire interval
  on max. dense job)
• bonus for doing some job we abandoned (short,
  dense)
• vf (it might finish this later)
• Add results (tfclose - tfopen)k vf (1
  vk)vf ((1 vk)² 1)vf
• vf is what we achieve each interval so ratio is
  O((1 vk)² 1)

19
The Outer Limits Special case

• If k1 and agents can't lie about length,
  payments will no longer be required to keep
  agents honest
• Proof mirrors above, only simpler
• Same as above, achieves 5-competitive ratio, but
  has advantage of not needing payments

20
Happy Days Conclusion

• Porter also proves his bound is a lower bound for
  any deterministic online mechanism with
  non-negative payments
• RT grid computing increasingly popular
• Need for competitive scheduling algorithms
• Insights here show strategic setting not
  significantly worse than non-strategic

21
Unsolved Mysteries

• Extend results to multiprocessor environment?
• Apply strategic concepts to bidding for CPU time
  in resource augmentation environment (online
  algorithm gets faster CPU(s) than OPT)?
• Find better bound with randomized mechanisms?
• Would knowing exact range of densities instead of
  just ?min and k lead to stronger bound?
• Your questions?

22
The A-Team Reference

• 1 Porter, Ryan. Mechanism Design for Real-Time
  Scheduling. In Proc. of the ACM Conference on
  Electronic Commerce (EC'04), 2004