Mechanism Design for Real-Time 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 ℓ, 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 vif its job finishes before d • Agent submits job with some type (r′, ℓ′, v′, d′) • Scale values as needed so no job has v < ℓ • 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/ℓ for any job • For k = 1, a 4-competitive algorithm exists • For k ≥ 1, a (1+√k)2 - competitive algorithm exists • Both bounds also shown tight for deterministic algorithms

7. Step by Step:Designing 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 (ℓ = v  k = 1) • Deciding to preempt: • Use some metric toassign priority • This example: findexpected loss based on“what could be done by new job’s 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 Practice:Porter's Mechanism • At every time t, run the job i with highest priority = vi′ + √k (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 Right:Payment 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 Truth:Preventing Lies—Overview • Agents could lie about 4 things: • Release time • Prohibit: claiming r′ < r • Length • Prohibit: claiming ℓ´ < ℓ • Value • Deadline • Necessary to show under- or over-stating any of these is not beneficial

13. To Tell the Truth:Preventing 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 & Order:Proof of Truthfulness – ri (I) • Ground rule: can't declare r′ < r • Assume for some reported (ri′, ℓi′, vi′, di′) job i finishes before d, but not under (ri, ℓi′, vi′, di′) • ℓ′ ≥ ℓ by ground rules, d′< d by rationality • We will show this is impossible

15. Law & Order:Proof of Truthfulness – ri (II) • Consider case with truthful r: • Let tpbe the first time i ispreempted; tabetime 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 & Order:Proof of Truthfulness – ri (III) • Now consider case where agent declares ri′> ri • S must change during (tp, ta] vs. when rideclared • i can't run longer outside this range when ri′ > ri • The change could be any job for another, not necessarily i • Call tcfirst time change occurs, ycjob 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)—won’t increase priority enough to outweigh a job that beats I at tp • During (tp,tc) the job ran longer under S′ (again has to replaceor 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 can’t help

17. Law & Order:Proof of Truthfulness – ℓi &di • Recall: ℓ′ < ℓ disallowed; di′ > di unhelpful • Only effect these have is on defining set of "available" jobs • Incomplete: those with elapsed time < ℓ′ • Abandoned: elapsed time + time to d′ ≤ ℓ′ • If job completes with ℓ′ 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/ℓ): • 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 ≥ (1+1/√k)vf (induction) • Prove max OPT can get per interval for jobs we abandoned is (1+√k)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+ √k)vf ≤ ((1+ √k)² +1)vf • vf is what we achieve each interval; so ratio is O((1+ √k)² +1)

19. The Outer Limits: Special case • If k=1 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