A Resource Allocation Controller for Cloud-based Adaptive Video - - PowerPoint PPT Presentation

1/16

A Resource Allocation Controller for Cloud-based Adaptive Video Streaming

Luca De Cicco, Saverio Mascolo, Dario Calamita

Politecnico di Bari, Dipartimento di Ingegneria Elettrica e dell’Informazione

MCN 2013 - Budapest, Hungary

13 June 2013

2/16

Motivation

Two ongoing trends (Cisco VNI) Video is booming: video applications today account for more than half of the global traffic Mobile is growing: mobile data traffic will be half of global traffic in 2017

2010 2011 2012 2013 2014 2015 10 20 30 40 EB Video P2P Data Web Video conf

Introduction 3/16

The challenge

Main Goal Design a cloud-based platform for massive distribution of adaptive videos

Introduction 3/16

The challenge

Main Goal Design a cloud-based platform for massive distribution of adaptive videos Issues

1 Bandwidth is unpredictable in best-effort Internet 2 Mobile devices have limited CPU and display resolution 3 User demand is highly time-varying

Introduction 3/16

The challenge

Main Goal Design a cloud-based platform for massive distribution of adaptive videos Issues

1 Bandwidth is unpredictable in best-effort Internet 2 Mobile devices have limited CPU and display resolution 3 User demand is highly time-varying

Design Goals

1 Issues 1 and 2 ⇒ Implement video adaptivity 2 Issue 3 ⇒Resource Allocation to dynamically turn on/off servers

The control plane 4/16

The proposed Control Plane

• ther

flows i−th server j−th server Clients

1

Client Load Balancer Resource Alloc. Controller Cloud API Central Unit Mon. Mon.

3 2

SSAC SSAC SSAC SSAC

4

N(t)

B(i)

A

˜ l(i)

n(i)

M(t)

˜ l(i)

1

B(j)

A

˜ l(j)

1

Architecture One Central Unit M(t) servers Controllers Stream Switching Adaptation Controller (per-flow) Load balancer (centralized) Resource Allocation Controller (centralized)

The control plane 5/16

Stream Switching Adaptation Controller

Stream-switching approach The video is available at different resolutions and bitrates, a controller selects the video to be streamed Quality Adaptation Controller (QAC) - ACM MMSYS 2011

Switching Controller

Video buffer

l(t)

sender Levels

r(t), l(t) HTTP traffic

buffer

Player

q(t)

τf

Decoder

Server Internet

selects video level

Adaptation logic is executed at the server (in the Cloud) The video flow behaves as any TCP greedy flow Fairness is inherited by TCP congestion control

Resource Allocation Controller 6/16

Inelastic videos

Total Uplink Capacity Interruptions

• ccur

Video bitrate n CT/l CT l Fact If video is not adaptive, the delivery network must be always

• verprovisioned to prevent playback interruptions

Resource Allocation Controller 7/16

Elastic videos

Total Uplink Capacity Interruptions

• ccur

n CT CT/lM l ∈ {l0, . . . , lM} CT/l0 We can work at 100% uplink channel utilization But: users will not receive the maximum video level anymore Action: increase the number of servers to increase uplink capacity

Resource Allocation Controller 8/16

Why flows do not get the maximum video level?

Where’s the bottleneck?

1 At the Server. Can act on these flows by turning ON machines. 2 At the Client. Cannot act on these flows (threated as a disturbance)

Resource Allocation Controller 8/16

Why flows do not get the maximum video level?

Where’s the bottleneck?

1 At the Server. Can act on these flows by turning ON machines. 2 At the Client. Cannot act on these flows (threated as a disturbance)

The goal of the RAC is to steer to zero the number of uplink-limited flows nUL(t) We need to estimate nUL(t) # limited flows = # uplink-limited flows + # client limited flows nL(t) = nUL(t) + nCL(t) The CU measures nL(t) easily A variable threshold mechanism estimates nCL(t) (details in the paper)

Resource Allocation Controller 9/16

The Resource Allocation Controller

Switch-on Controller: steers ˆ nUL(t) to zero (control-loop set point) Switch-off Controller: turns off servers when the goal of the switch-on controller is reached

CU

Switch−on controller Switch−off controller Switch−on delay

G 0

c (z) 1 C

(1 − z−r)ˆ G(z)

z−r ˆ nUL N M

1 1−z−1

BA

1 B

Non

Noff

Switch-on controller PD controller: G 0

c (z) = Kp +Kd(1−z−1)

The Smith predictor compensates the effect of the switch-on delay The model used in the SP is an integrator (tf from N to M) Switch-off controller It turns off (if Non = 0) a number of machines equal to BA/B

Simulator 10/16

Simulations

Simulator based on CDNSim implements the control modules and a module monitoring CPU costs Metrics Fraction of flows obtaining the maximum level: α(t) = 1 − nL(t)/n(t) Total Servers costs Cc(t) Considered controllers The proposed PD controller with Kp = −0.7, Kd = −0.3 The proposed controller without the Smith predictor Feed forward controller: N(tk) = n(tk)/C − M(tk) (difference between the number of servers that should be ON to provide maximum quality and the number of active server)

Simulator 11/16

Scenarios

Scenarios Client downlink is not the bottleneck ⇒nCL(t) = 0 16% of users have a downlink channel not allowing maximum video level (nCL(t) = 0): Request arrival (Poisson with variable intensity r(t))

200 400 600 800 1000 1200 5 10 15 20 25 30 35 40 Time (s) Requests/s

Results 12/16

Results: client limited flows (ˆ nCL = 0)

200 400 600 800 1000 1200 50 100 150 Time (sec) M(t) r=20 r=30 r=5 r=30 r=0 SC FF RAC no SP RAC

Number of active servers over time is smooth with RAC Other controllers exhibit

• vershoots when r increases

Machines are turned on, but the effect on nUL is measured only after the switch-on delay

200 400 600 800 1000 1200 0.2 0.4 0.6 0.8 1 Time (sec) α(t) FF RAC no SP RAC

Undershoots

Overshoots waste resources, undershoots hurt QoE (less videos receiving max video level) RAC is worse than FF in terms

• f α only during transients when

r increases

Results 13/16

Results: client limited flows (ˆ nCL = 0)

16% of flows with 1Mbps connection ⇒ expected maximum α = 0.84

200 400 600 800 1000 20 40 60 80 100 Time (sec) M(t) r=20 r=30 r=5 r=30 r=0 SC FF RAC no SP RAC

Large overprovisioning in the case of feed forward controller RAC w/o SP performs better but shows overshoots when requests rate increases

200 400 600 800 1000 0.2 0.4 0.6 0.8 1 Time (sec) α(t) FF RAC no SP RAC

αRAC = 0.73 αFF = 0.78

RAC outperforms other controllers in terms of costs (saves 10%) and pays a slight performance degradation (4%)

Results 14/16

Cost savings (nCL = 0)

250 500 750 1000 10 20 30 40 50 Time (sec) Costs savings % FF RAC no SP

Results 15/16

Let’s see RAC in motion

Heat map Warmer color at (x,y) ⇒many flows are receiving level x by server y Ideal: dark blue (0) everywhere except for a bright evenly colored bar at level 9 Levels pdf Fraction of flows obtaining level x Ideal: zero for x < 9, one for x = 9

Conclusions 16/16

Conclusions

We have proposed a Resource Allocation Controller for cloud-based adaptive video streaming Feedback control theory is employed to compute the number of servers to turn on/off The RAC strives to minimize delivery network costs while delivering the maximum video quality The RAC controller saves up to 30% CPU costs while paying a small performance quality degradation during transients Future work: make the system distributed

Thanks!

Questions

? ? ? ? ? ? ? ? ?

BACKUP SLIDES

Conclusions 15/16

Estimating nUL(t)

Estimating the number of uplink-limited flows

L to estimate nL(t) (limited flows) L(t) to estimate ˆ nCL(t) ˆ nUL(t) = nL(t)−ˆ nCL(t)

Ideally nUL(t) = 0 with the minimum number of servers

number of Cumulative Flows concurrent flows l0 l1 l2 l3 l4 l5 L number of Cumulative Flows concurrent flows lM

Conclusions 15/16

Estimating nUL(t)

Estimating the number of uplink-limited flows

L to estimate nL(t) (limited flows) L(t) to estimate ˆ nCL(t) ˆ nUL(t) = nL(t)−ˆ nCL(t)

Ideally nUL(t) = 0 with the minimum number of servers

number of Cumulative Flows concurrent flows l0 l1 l2 l3 l4 l5 L number of Cumulative Flows concurrent flows lM number of Cumulative Flows concurrent flows l0 l1 l2 l3 l4 l5 L number of Cumulative Flows concurrent flows lM nL

Conclusions 15/16

Estimating nUL(t)

Estimating the number of uplink-limited flows

L to estimate nL(t) (limited flows) L(t) to estimate ˆ nCL(t) ˆ nUL(t) = nL(t)−ˆ nCL(t)

Ideally nUL(t) = 0 with the minimum number of servers

number of Cumulative Flows concurrent flows l0 l1 l2 l3 l4 l5 L number of Cumulative Flows concurrent flows lM number of Cumulative Flows concurrent flows l0 l1 l2 l3 l4 l5 L number of Cumulative Flows concurrent flows lM nL number of Cumulative Flows concurrent flows l0 l1 l2 l3 l4 l5 L number of Cumulative Flows concurrent flows lM nL Estimate of Client limited flows L(t) ˆ nCL

Conclusions 15/16

Estimating nUL(t)

Estimating the number of uplink-limited flows

L to estimate nL(t) (limited flows) L(t) to estimate ˆ nCL(t) ˆ nUL(t) = nL(t)−ˆ nCL(t)

Ideally nUL(t) = 0 with the minimum number of servers

number of Cumulative Flows concurrent flows l0 l1 l2 l3 l4 l5 L number of Cumulative Flows concurrent flows lM number of Cumulative Flows concurrent flows l0 l1 l2 l3 l4 l5 L number of Cumulative Flows concurrent flows lM nL number of Cumulative Flows concurrent flows l0 l1 l2 l3 l4 l5 L number of Cumulative Flows concurrent flows lM nL Estimate of Client limited flows L(t) ˆ nCL number of Cumulative Flows concurrent flows l0 l1 l2 l3 l4 l5 L number of Cumulative Flows concurrent flows lM nL Estimate of Client limited flows L(t) ˆ nCL Uplink limited flows

Conclusions 15/16

Estimating nUL(t)

Estimating the number of uplink-limited flows

L to estimate nL(t) (limited flows) L(t) to estimate ˆ nCL(t) ˆ nUL(t) = nL(t)−ˆ nCL(t)

Ideally nUL(t) = 0 with the minimum number of servers

number of Cumulative Flows concurrent flows l0 l1 l2 l3 l4 l5 L number of Cumulative Flows concurrent flows lM number of Cumulative Flows concurrent flows l0 l1 l2 l3 l4 l5 L number of Cumulative Flows concurrent flows lM nL number of Cumulative Flows concurrent flows l0 l1 l2 l3 l4 l5 L number of Cumulative Flows concurrent flows lM nL Estimate of Client limited flows L(t) ˆ nCL number of Cumulative Flows concurrent flows l0 l1 l2 l3 l4 l5 L number of Cumulative Flows concurrent flows lM nL Estimate of Client limited flows L(t) ˆ nCL Uplink limited flows

Ideal situation

nL = ˆ nCL

Conclusions 16/16

The Threshold L(t)

Definition Every flow getting an average video level less than L(t) is considered as client limited Fair Level lf (t) = min(B/n(t), lM) Fair level all n(t) flows should get in the case nCL(t) = 0. The threshold L(t) L(lf (t), α(t)) = lf (t) + α(t) · (lM − lf (t)) where α is the number of flows getting the maximum level. Bandwidth limited clients leave bandwidth to other clients with the effect

• f increasing their average levels