verifiable resource accounting for cloud computing services

1

Verifiable Resource Accountingfor Cloud Computing Services

Vyas Sekar, Petros ManiatisISTC for Secure

Computing

2

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!

Divided opinions on “better accounting”

4

Non-problemTechnically “easy”Market forces will solve this!

“Obviously” critical problemBut, we don’t know how!!

vs.

Little systematic research on this topic!

Goal of this work

• Stimulate active discussion

• Our own position: “obviously critical”

• Sketch a technical framework for how

5

Outline

• Motivation

• Problem definition

• Did-I verifiability

• Should-I verifiability

• Discussion

• Ongoing work

6

Problem Setup

7

Customer

ProviderTask (T)

AttributionModel (A) e.g., SLA-like contract

Report (R)

Witness (W)

Verifier

T,R,W,A

Trusted Layer

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?

Outline

• Motivation

• Problem definition

• Did-I verifiability

• Should-I verifiability

• Discussion

• Ongoing work

9

Did-I Verifiability

10

Provider PT1C1

C2

R1

T2

R2

T1, T2 did physically consume X1, X2 cyclesi.e., P is not “double counting” or overcharging

A Clean-slate Solution

11

Task1 Task2

Resource 1

Resource 2

Epoch Resource1 Resource2

1 T1=5, T2=0

T1=1,T2=2

2 T1=1, T2=10

T1=0,T2=10

….

Hardware-root-of-trust

Visibility into low-level

No spurious reports

“Witness”

“Trusted”

Challenges with Clean Slate

12

Task1 Task2

Resource 1

Resource 2

Epoch Resource1 Resource2

1 T1=5, T2=0

T1=1,T2=2

2 T1=1, T2=10

T1=0,T2=10

….

Doesn’t exist yet!

Bandwidth overhead

Performance slowdown

Practical Approximations• Bandwidth overhead Aggregation

• Performance slowdown– Sampling or snapshots

• Relaxing hardware dependence – Small instruction stream recorder (not online)– Shim layer for monitoring

13

Outline

• Motivation

• Problem definition

• Did-I verifiability

• Should-I verifiability

• Discussion

• Ongoing work

14

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’

Clean-slate Should-I

16

Allocator

Provider

Requests

Interrupts

Decisions

Customer

Log of Requests, interrupts

Log of Decisions

Verifier

Allocator

Decisions

“Witness”e.g., this is the VMM or cluster scheduler implementing “weighted fair queuing”

Challenges with Clean-Slate

17

Allocator

Provider

Requests

Interrupts

Decisions

Customer

Log of Requests, interrupts

Log of Decisions

Verifier

Allocator

Decisions

Leak proprietary logic

Log overhead

e.g., locate verifier or agent close to P

Balancing privacy vs accountability

18

AllocatorTemplate

Provider

Requests

Interrupts

Decisions

Customer

Log of Requests, interrupts

Log of Decisions

PrivatePolicy

Hidden

Verifier

AllocatorTemplate

Decisions

e.g., Is the provider running a “fair queueing” scheduler?But “weights” are private policy

Alternative “Quantitative” Should-I

19

Allocator

Provider

Requests

Interrupts

Decisions

Customer

Log of Requests, interrupts

Log of Decisions

Verifier

Allocator

Decisions1 2 3 4 5 6 7

0

40

Expected

CPUMemory

Allocator

Leak proprietary logic

Very different from SLA verificationNot promising lower bound on “resources” Rather computing upper bound on “consumption”

Task

Report

Outline

• Motivation

• Problem definition

• Did-I verifiability

• Should-I verifiability

• Discussion

• Ongoing work

20

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

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 realization22