1. Verifiable Resource Accounting for Cloud Computing Services Vyas Sekar, Petros Maniatis ISTC for Secure Computing 1

2. 2

3. State of cloud computing today.. 3 It's that dreaded time of the month again, the time of the month that we, the 400,000+ Amazon Web Service consumers await with great anticipation / horror. What I'm talking about is the Amazon Web Services Billing Statement sent at beginning of each month. As it turns out, Microsoft's doesn't disclose revenues related to its cloud services. And on that matter, it's not alone. Neither do Amazon, Google, or IBM. Need stronger, verifiable resource accounting!

4. Divided opinions on “better accounting” 4 Non-problem Technically “easy” Market forces will solve this! “Obviously” critical problem But, we don’t know how!! vs. Little systematic research on this topic!

5. Goal of this work Stimulate active discussion Our own position: “obviously critical” Sketch a technical framework for how 5

6. Outline Motivation Problem definition Did-I verifiability Should-I verifiability Discussion Ongoing work 6

7. Problem Setup 7 Customer Provider Task (T) Attribution Model (A) e.g., SLA-like contract Report (R) Witness (W) Verifier T,R,W,A Trusted Layer

8. What does verifiability mean? 8 Customer Verifier Task,Report,Witness,Attribution (T,R,W,A) 1.Did I use the resources billed?  T did physically consume X cycles, Y GB RAM, Z MB bandwidth  Is P double counting or overcharging? 2. Should I have used these resources?  e.g., Was it because of poor scheduling by P? Did T consume more due to “contention” with T’ on same CPU?

9. Outline Motivation Problem definition Did-I verifiability Should-I verifiability Discussion Ongoing work 9

10. Did-I Verifiability 10 Provider P T1 C1 C2 R1 T2 R2  T1, T2 did physically consume X1, X2 cycles i.e., P is not “double counting” or overcharging

11. A Clean-slate Solution 11 Task1 Task2 Resource 1 Resource 2 EpochResource1Resource2 1T1=5, T2=0 T1=1, T2=2 2T1=1, T2=10 T1=0, T2=10 …. Hardware-root-of-trust Visibility into low-level No spurious reports “Witness” “Trusted”

12. Challenges with Clean Slate 12 Task1 Task2 Resource 1 Resource 2 EpochResource1Resource2 1T1=5, T2=0 T1=1, T2=2 2T1=1, T2=10 T1=0, T2=10 …. Doesn’t exist yet! Bandwidth overhead Performance slowdown

13. Practical Approximations Bandwidth overhead  Aggregation Performance slowdown – Sampling or snapshots Relaxing hardware dependence – Small instruction stream recorder (not online) – Shim layer for monitoring 13

14. Outline Motivation Problem definition Did-I verifiability Should-I verifiability Discussion Ongoing work 14

15. Should-I Verifiability 15 T Consumer R T R’  Is R very different from R’ in ideal case? e.g., is P scheduling/allocating as it promised? e.g., is R high because of contention? Provider P Ideal Provider P’

16. Clean-slate Should-I 16 Allocator Provider Requests Interrupts Decisions Customer Log of Requests, interrupts Log of Requests, interrupts Log of Decisions Log of Decisions Verifier Allocator Decisions “Witness” e.g., this is the VMM or cluster scheduler implementing “weighted fair queuing”

17. Challenges with Clean-Slate 17 Allocator Provider Requests Interrupts Decisions Customer Log of Requests, interrupts Log of Requests, interrupts Log of Decisions Log of Decisions Verifier Allocator Decisions Leak proprietary logic Log overhead e.g., locate verifier or agent close to P

18. Balancing privacy vs accountability 18 Allocator Template Allocator Template Provider Requests Interrupts Decisions Customer Log of Requests, interrupts Log of Requests, interrupts Log of Decisions Log of Decisions Private Policy Private Policy Hidden Verifier Allocator Template Allocator Template Decisions e.g., Is the provider running a “fair queueing” scheduler? But “weights” are private policy

19. Alternative “Quantitative” Should-I 19 Allocator Provider Requests Interrupts Decisions Customer Log of Requests, interrupts Log of Requests, interrupts Log of Decisions Log of Decisions Verifier Allocator Decisions Allocator Leak proprietary logic Very different from SLA verification  Not promising lower bound on “resources”  Rather computing upper bound on “consumption” Task Report

20. Outline Motivation Problem definition Did-I verifiability Should-I verifiability Discussion Ongoing work 20

21. Discussion Provider incentives – More adoption to avoid underutilization – Less conservative in accounting – Prevent customers from gaming the system Why markets may not suffice? – Infrastructure  few players – Cost of migrating is non-trivial Relaxing provider assistance – Resource prediction or collaborative inference 21

22. Summary Honeymoon phase for cloud is over  Need stronger verifiable accounting Benefits to consumers & providers – Side benefit: may encourage better practices Sketch a framework, potential solutions – Did-I and Should-I verifiability Working toward a practical realization 22