VDC-Analyst: Design and Verification of VirtualDesktop Cloud Resource Allocations

Prasad Calyam, Sudharsan Rajagopalan, Sripriya Seetharam, Arunprasath Selvadhurai,Khaled Salah, Rajiv Ramnath

University of Missouri, The Ohio State University, USA; Khalifa University, UAEEmail: {calyamp,ssn68}@missouri.edu, {rajagopalan.32, selvadhurai.1, ramnath.6}@osu.edu, khaled.salah@kustar.ac.ae

Abstract—One of the significant challenges for Cloud Ser-vice Providers (CSPs) hosting “virtual desktop cloud” (VDC)infrastructures is to deliver a satisfactory quality of experience(QoE) to the user. In order to maximize the user QoE withoutexpensive resource overprovisioning, there is a need to designand verify resource allocation schemes for a comprehensiveset of VDC configurations. In this paper, we present “VDC-Analyst”, a novel tool that can capture critical quality metricssuch as Net Utility and Service Response Time, which can beused to quantify VDC platform readiness. This tool allows CSPs,researchers and educators to design and verify various resourceallocation schemes using both simulation and emulation in twomodes: “Run Simulation” and “Run Experiment”, respectively.The Run Simulation mode allows users to test and visualizeresource provisioning and placement schemes on a simulationframework. Run Experiment mode allows testing on a realsoftware-defined network testbed using emulated virtual desktopapplication traffic to create a realistic environment. Resultsfrom using our tool demonstrate that a significant increase inperceived user QoE can be achieved by using a combination ofthe following techniques incorporated in the tool: (i) optimizingNet Utility through a “Cost-aware Utility-Maximal ResourceAllocation Algorithm”, (ii) estimating values for Service ResponseTime using a “Multi-stage Queuing Model”, and (iii) appropriateload balancing through software-defined networking adaptationsin the VDC testbed.

Keywords-Virtual desktop cloud, Cloud simulator, Utility-directed resource allocation, Software-defined networking, Cloudtestbed experiment

I. INTRODUCTION

In recent years, desktop virtualization through Desktop-as-a-Service (DaaS) offerings has become an increasingly obviouschoice for enterprises because of: the seamlessly realized ben-efits of centralized desktop administration, standard securityconfigurations, data protection and simplified management ofthin-clients on “virtual desktop clouds” (VDCs) [1]. DaaSofferings can cater to the needs of user communities suchas virtual classroom labs in education, remote volume visu-alization in biomedical applications, and virtual modeling inmanufacturing. As more users switch from traditional desktopenvironments to VDCs, Cloud Service Providers (CSPs) arefaced with unique scalability challenges in elastically handlingrapid growth by resource sharing and load balancing of com-putation and network resources, so as to provide acceptableuser quality of experience (QoE) in order to maintain theirservice level agreements (SLAs), while also minimizing costs.

This material is based upon work supported by the National Science Foun-dation under award numbers CNS-1050225, CNS-1205658, and VMware.Any opinions, findings, and conclusions or recommendations expressed inthis publication are those of the author(s) and do not necessarily reflect theviews of the National Science Foundation or VMware.

In particular, perceived user QoE in virtual desktops (VDs)is sensitive to network degradation and cannot tolerate burstycross-traffic patterns [2] [3]. Most of the earlier researchavoided focusing on network optimization techniques forhandling user QoE deterioration because it is challengingto control routing dynamics in the Internet. The researchcommunity has been developing resource allocation schemessuch as [4] and [5] in order to increase the user experienceof VDCs based on thin-client protocol adaptations. However,given the complexity of a cloud system, infrastructure andtools to test or simulate such schemes are not easily accessible.There are many simulation tools [6] - [13] which eithermimic the cloud infrastructure or allow researchers to workon real cloud platforms. Nevertheless, these tools are focusedon testing application-oriented resource allocation policies atthe server side, and there is a dearth of tools for simulatingand emulating VDC systems to serve the salient needs of CSPslooking to offer DaaS, as well as educators and researchers ofVDC resource allocation schemes.

In this paper, to address the lack of tools for design andverification of human, network, and system aware resourceallocation schemes in VDCs, we have developed a novel toolcalled, “VDC-Analyst”. VDC-Analyst allows estimation oftwo novel user QoE metrics: Net Utility and Service ResponseTimes (SRTs). Net Utility of a VDC system not only measuresthe server side utility but also evaluates the VDC system underrealistic network settings that can impact the overall user QoE.End-to-end system and network latency also affects the SRTsof users’ VD requests by causing a considerable time lapsebetween the VD request and the provisioning of the VD from adesktop pool within a data center. The components of this SRTinclude network path determination, resource usage estimation,data center selection and finally, the VD instantiation.

To estimate the Net Utility of all the VD requests in a VDC,we have developed a new scheme called the “Cost-AwareUtility-Maximal Resource Allocation Algorithm” that com-putes the metric in a simulation framework. The scheme alsoenables software-defined networking capabilities to control therouting dynamics for improving user QoE on a real networkemulation testbed with OpenFlow protocol [14] compatibleswitches. To estimate the SRT metric of incoming VD requestsin a VDC system, we have developed a “Multi-stage QueuingModel” with an embedded Markov chain process.

The above metrics estimation development and their in-tegration into the VDC-Analyst tool architecture builds andsignificantly extends our prior works on VD resource provi-sioning and placement optimization schemes, as well as theslow-motion based thin-client performance benchmarking forVDC environments [3] [15] [16].

Our ultimate aim in developing the VDC-Analyst tool isto realize maximization of the user QoE without expensiveresource over-provisioning by allowing design and verifica-tion of resource allocation schemes for a comprehensive setof VDC configurations. The tool provides ‘control knobs’for educators and researchers to fine tune their system andnetwork resource allocation policies and study trade-offs indesign decisions. By executing several test cases using thetool’s two modes: “Run Simulation” and “Run Experiment”,respectively - we show that an iterative synergy betweensimulation and realistic experiment environments is needed toassess the readiness of a VDC infrastructure. The Run Simu-lation mode allows researchers to test and visualize resourceprovisioning and placement schemes on a modular, extensible,and repeatable simulation framework; the Run Experimentmode leverages a real software-defined OpenFlow-based net-work testbed within the Global Environment for NetworkInnovations (GENI) infrastructure [18] [19] to emulate VDapplication traffic for testing, visualization and load-balancingof resource allocations in a realistic environment with networkcross-traffic.

The remainder of the paper is organized as follows: SectionII discusses related work on cloud simulators. Section IIIdiscusses VDC-Analyst’s architecture. Section IV describesthe implementation goals, workflow and User Interface (UI)features of the tool. The schemes for metric estimations inthe VDC-Analyst tool are described in Section V. Section VIpresents exemplar use cases of VDC-Analyst in Run Simula-tion and Run Experiment modes for research and educationpurposes. Section VII concludes the paper.

II. RELATED WORK

Currently, there are several tools such as [6] - [13], whichsimulate cloud infrastructures and provide testbeds for sim-ulation and verification of resource allocation schemes. TheCloudSim toolkit [6] offers a cloud computing framework formodeling and simulation of application provisioning policieson cloud platforms. It provides ways to model virtual machineallocations, cloud markets, dynamic workloads and other poli-cies with respect to application services. NetworkCloudSim[7] is an extension of CloudSim that features network modelsacross data centers to simulate complex application servicesand improve scalability by maximizing network bandwidth.

GreenCloud [8] tool, which is built on the network simulatorNS-2 [9] enables simulation of energy-aware data centerswithin cloud environments to model energy consumed byservers, data centers, switches and links. Similarly, a simu-lation framework for validating and evaluating inter-operablecloud service brokers on heterogeneous cloud environmentshas been developed in [10]. Another simulation platformiCanCloud [11] for modeling and simulating cloud infrastruc-tures leverages system performance in determining the costcomponents. Further, SimGrid [12] and GridSim [13] help insimulation of resource allocation policies for Grid Computingof peer-to-peer (P2P), parallel and distributed systems.

While all of the above work on tools is mainly targetedtowards transaction-oriented data clouds, VDC-Analyst is de-signed to test and validate resource allocation schemes relevantto virtual desktop applications (e.g., MS Word, Media Player,Matlab) within VDC infrastructures, where user QoE is highlysensitive to system and network performance fluctuations.The VDC-Analyst tool provides Run Simulation and Run

Fig. 1: Architecture of VDC-Analyst

Experiment modes to plugin and test resource allocationschemes in both environments on a single platform, whichmany existing tools do not support. Another novelty of ourwork is that we harness software-defined networking principlesusing the OpenFlow protocol to monitor the network healthand adapt the network allocation mechanism based on userQoE considerations, to maximize the Net Utility and SRT ofVDC infrastructures. Nevertheless, the tool also provides anintuitive UI to select input parameters such as VD requestsload, cross traffic and faults and visualize output graphs tocompare varied system and network states, similar to some ofthe above related works.

III. VDC-ANALYST ARCHITECTURE

The architecture of VDC-Analyst as depicted in Figure 1enables interactions between the data plane and control planeto estimate user QoE metrics of VD requests in a VDC.The main module of VDC-Analyst is the ‘Unified ResourceBroker’ (URB). The URB is the ‘brain of the VDC’ and isresponsible for handling all optimization and routing decisionsacross the VDC infrastructure. The ‘Logic Module’ withinURB enables large-scale simulations involving initial resourceallocations, and subsequent calculation of utility changes thatdetermine the Net Utility measurement across data centers. NetUtility calculation is performed based on the selected resourceallocation scheme (explained in Section V) to place VDs in acost-aware and utility-maximal manner. The ‘Logic Module’within URB also features a multi-stage finite queuing model(explained in Section V) that captures the various stages ofa VD request in a VDC system and estimates the SRT inserving individual VD requests. VD user profiles and realtime application usage is monitored using the Thin-clientPerformance Benchmarking module developed in our priorwork [17].

In the UI layer, workload generation module handles inputssuch as VD request load, and cross-traffic level settings rele-vant to Run Simulation and Run Experiment modes (detailed

2

workflows of the modes are explained in Section IV). Theoutput contains the VD Placement Allocations that indicateevery VD’s placement at different data centers based on theprovisioning and placement scheme selection in the input.The Result Graphing Module is responsible for displaying theSRT and Net Utility graphs for a given resource allocationscheme. The Net Utility and SRT obtained in Run Simu-lation mode are evaluated under a realistic environment inRun Experiment mode with network cross-traffic and fault-conditions to measure the VDC infrastructure’s performanceimpact on perceived user QoE for VD applications. A reduceduser QoE in Run Experiment mode in turn synergisticallyguides further enhancements in resource allocation schemesin Run Simulation mode.

In Run Experiment mode, the ‘Service Applications’ withinURB interact with the physical infrastructure resources (i.e.,data centers, thin-clients, OpenFlow switches) to instantiatethe VDs within compute nodes and also determine the networkpaths from the thin client node to the corresponding VDC datacenter. The Hypervisor Interface is responsible for securelyprovisioning system resources at the data center with appropri-ate sizing of CPU, memory and network interface bandwidthsettings. The OpenFlow controller application comprises theflow identification and load balancer modules that are respon-sible for initializing the flow tables of VD network paths, andfor reconfiguring them dynamically on switches in cases suchas cross-traffic congestion or device failures.

IV. VDC-ANALYST IMPLEMENTATION

In this section, we first outline VDC-Analyst developmentgoals followed by workflow implementations for simulationand emulation modes. Next, we describe the implementationdetails of the individual modules in the UI.

A. GoalsVDC-Analyst has been developed based on a self-contained,

unified framework to toggle between simulation and emula-tion. Some of the goals we set for ourselves and addressedwere: the tool should provide modularity and extensibility inadding resource allocation schemes without configuration orworrying about details of the underlying components; the toolshould be robust in order to perform repeatable simulationsat-scale and emulations for diverse input parameters; the toolshould serve educational and research use cases that involveexperimentation with different resource allocation schemesin order to measure the two important user QoE metrics ofVDC infrastructures viz., Net Utility and SRTs; the tool shouldprovide a simple intuitive UI allowing users to configure inputvalues and visualize output values on a single view in both RunSimulation and Run Experiment modes.

B. WorkflowIn this section, we describe the VDC-Analyst workflow

shown in Figure 2, which illustrates the synergy between RunSimulation and Run Experiment modes. The synergy is createdby the exchange of Net Utility and SRT metrics obtainedin Run Simulation mode, which guides the resource config-uration and VD placements in the Run Experiment mode.Subsequently, the perceived user QoE measurements from thereal VDC environment can be used as feedback to adapt for

dynamic cases where user QoE is below acceptable thresholds.The adaptation can invoke new simulations that re-evaluate theprevious resource configurations and VD placements in orderto improve Net Utility and SRT, and so on.

1) Workflow for Run Simulation: The workflow for RunSimulation is as follows: Step-1 Input Selection: Input param-eters for VD requests, faults and cross traffic, and provisioningand placement schemes are selected through the tool’s UIpanel; Step-2 Resource Allocation: On triggering the RunSimulation, the selected provisioning scheme computes theamount of resource allocation required for the VD request. Theplacement scheme then determines the data center location tohost the VD request; Step-3 Net Utility Calculation: The URBallocates the required number of resources on the selected datacenter that gives rise to maximal utility. Once VD resourcesare allocated, the URB performs optimization decisions acrossdata centers to reduce operational costs and increase serverside utility. The Net Utility is calculated as a summation ofutility values at all data centers. The Net Utility of systemis then plotted against the current run along with Net Utilityvalues of previous runs; Step-4 SRT Calculation: The SRT forevery VD request is estimated using the tool’s analytical modeland plotted on the UI to observe the overall performance ofthe VDC system.

2) Workflow for Run Experiment: The work flow for RunExperiment is as follows: Step-1 Node Reservation: Thin-client Wide-Area ProtoGENI (WAPG) nodes on the GENIinfrastructure are reserved and configured for triggering VDrequests and cross traffic; VDC data centers are instantiatedwith VD pools. The OpenFlow controller application installsthe initial flow tables for OpenFlow switches that makeupthe VDC network; Step-2 Network Path Determination: OnceVD requests are initiated from the thin-client nodes, RunExperiment triggers the URB to allocate network paths on theGENI infrastructure and resources on VDC data centers usingthe selected provisioning and placement scheme; Step-3 FlowInstallation: The URB communicates the routing informationto the OpenFlow controller through marker packets that areused to identify flows for forwarding decisions [3]. Thecontroller programs the OpenFlow switches to route the VDdata packets between the data center and thin-client and viceversa; Step-4 End-to-End Monitoring: The URB then allocatesresources to provision the VD on the selected data centerand monitors user QoE through the Thin-client PerformanceBenchmarking module. In case, the interactive response timeof VD applications between the VD thin-client and data centergoes below a certain benchmarked threshold, the URB tries tore-evaluate the resource allocations on the data center whilemaintaining the Net Utility of the system. In the event ofnetwork cross traffic bursts or down links, the URB detects thenetwork degradation and switches the VD application path bycommunicating with the OpenFlow controller. Thus, the URBperforms load balancing on the network and maximizes theNet Utility of the VDC system.

C. User Interface

The VDC-Analyst tool’s UI shown in Figure 3 (built usingthe Matlab package) enables the performance as well asresource allocation analysis and visualization features. Weremark that the back-end scripts are independent of the UItechnology, and can be reused as plug-ins with other integrated

3

Fig. 2: Workflow of VDC-Analyst leveraging synergy between simulation and emulation modes

Fig. 3: VDC-Analyst User Interface: a) Cloud Broker, b) Workload Generator, c) Run Modes, d) Status Window, e) Resource AllocationLocation Graph, f) Net utility Graph, and g) Service Response Time graph

development environments such as Eclipse [20]. The provi-sioning and placement schemes to be simulated or emulatedare selected as part of the Cloud Broker panel [Frame a)of Figure 3]. The input parameters including VD requestsload, faults and cross traffic can be set through the WorkloadGenerator [Frame b) of Figure 3]. Users can either select RunSimulation or Run Experiment mode as shown in Run modespanel [Frame c) of Figure 3]. The Status Window [Frame d)of Figure 3] displays the current steps executed by the tool inRun Simulation or Run Experiment mode.

The Resource Allocation Location graph of VD requestsand data centers on the UI gives a holistic understandingof placement of VDs across the data centers [Frame e) ofFigure 3]. This graph helps us gain insights on how differentplacement schemes allocate VD requests across data centersto maximize Net Utility. The color code associated with VDrequests represents the profile type of VD user. In our work, we

have assumed VD requests can arise from three kinds of userprofiles - a student in campus computer lab, a distance learninguser or a scientist in Engineering Site, each having specificresource requirements needed for satisfactory QoE of their VDapplication sets. For example, distance learning user will usevideoconferecning, and hence needs higher network bandwidththan the student in a campus computer lab. The tool alsoplots the Net Utility graph for the past five runs [Frame f) ofFigure 3]. The graph helps us compare different schemes undergiven set of VD requests load, cross traffic and faults. Thegraph also helps us analyze an individual scheme subjected todifferent VD requests load, cross traffic and faults which is acharacteristic test case in a real world VDC scenario. The lastpanel [Frame g) of Figure 3] consists of SRTs plotted againstincreasing VD requests load on the VDC system to measurethe system’s behavior in serving multiple VD requests.

4

V. MODELS AND ALGORITHMS USED IN VDC-ANALYST

A. Cost-Aware Utility-Maximal Resource Allocation Algo-rithm for Net Utility Estimation

Our cost-aware utility-maximal resource allocationalgorithm builds upon and significantly extends ourprovisioning schemes (i.e., Utility-directed ResourceAllocation Model (U-RAM), Fixed Resource AllocationModel (F-RAM), Economics-directed Resource AllocationModel (E-RAM)) and placement schemes (i.e., ‘Least Load’,‘Least Latency’, ‘Least Cost’ and ‘Least Joint’) from ourprior works [15] and [16]. The algorithm extensions toestimate Net Utility in a VDC infrastructure are more suitablefor OpenFlow controller application development in the RunExperiment mode. The detailed pseudocode of this algorithmis shown in Algorithm 1. The terminologies and assumptionsdescribed in the algorithm are summarized as follows:VDC consists of {L1, L2, .., Ll} number of data centers.Every data center contains corresponding d virtual desktops{v1, v2, ..., vd} and m resources {R1, R2, ..., Rm} for CPU,memory and network bandwidth allocations, respectively.Also, vdi is the ith VD request and n is the number of VDrequests. Further, Ul gives the utility at data center Ll andUnet represents Net Utility value of the VDC infrastructureand can be defined as:

Unet =

l∑i=1

Ul (1)

As we do not know the nature of arrival of random VDrequests, we provision the VDs sequentially in an onlinemanner by executing the algorithm to determine the data centerlocation Ll and the resource Rset required by the VD requestvdi. The algorithm chooses the network path providing max-imum end-to-end bandwidth between the thin-client node anddata center in an opportunistic manner. In a software-definednetwork, a single physical network can be broken down intoseveral logical networks {Pi,1, Pi,2 ... Pi,k} available fromthe thin-client’s OpenFlow switch i to every data center where,each path is a set {I1, I2 ... Ik} of interconnects that formsthe path. Each of these logical network paths can be visualizedas a ‘packet stream processor’. Proper path selection andload balancing amongst these packet stream processors canhelp provide better SRTs and optimized bandwidth usage forVD applications. We choose the path that provides maximumstandard deviation from the required bandwidth usage B asthe candidate path for a given data center.

The data center Ll selection is similar to the Hill ClimbingAlgorithm implemented in [21]. Unew

l and U curl represent the

new and current utility values at a data center Ll, and ∆Ul

represents the increase in utility at Ll. The Unewl at Ll is

calculated using the utility function Ugi(Ri,l) for vdi givenPi,k based on the U-RAM scheme. If the Unew

l is greaterthan the cost involved in reserving the resources on the datacenter (expressed as a factor of amount of resources needed)and the new ∆Ul is greater than its current local value, ∆Ul

is updated as the current maximum utility increase. Once theabove steps are performed iteratively for all the available datacenters, the data center Ll that gives rise to maximal ∆Ul isselected for placing the VD request.

Algorithm 1 Cost-Aware Utility-Maximal Resource Alloca-tion Algorithm for a given VD request

1: Input: VD request vdi, Utility function Ug(R) from U-RAM scheme, list of available data centers {L1, L2 ... Ll}each containing d virtual desktops {v1, v2, ..., vd} andm resources {R1, R2 ... Rm}, list of loop free paths{Pi,1, Pi,2 ... Pi,k}, predicted bandwidth usage B forvdi.

2: Output: Resource allocation Ri,l at data center Ll andpath Pi,k for new VD request vdi that maximizes raise inutility ∆Ul

3: begin procedure4: max∆U = 05: for each data center Ll do6: /*Step-1: Network path determination*/7: for each path Pi,k to data center Ll do8: if ∀IjεPi,k bandwidth at Ij >= B then9: Add Pi,k to the candidate paths set Cp

10: end if11: end for12: Select path Pi,k which provides the maximum Standard

Deviation from B among all Pi,kεCp

13: /*Step-2: Utility estimation*/14: Unew

l = Ugi(Ri,l) for vdi at Ll given path Pi,k

15: /*Step-3: Data center selection*/16: if Unew

l >Cost involved in allocating vdi at Ll then17: ∆Ul = Unew

l - U curl

18: if ∆Ul >max∆U then19: max∆U = ∆Ul

20: end if21: end if22: end for23: Place vdi at Ll which gives max∆U24: /*Step-4: VD instantiation*/25: Allocate Ri,l to vdi on Ll with Pi,k

26: Update the selected data center utility U curl = Unew

l27: end procedure

B. Multi-stage Queuing Model for Service Response TimeEstimation

Our analytical model for estimating SRT in the VDCapplication is a finite FCFS (First Come First Served) queuingmodel. The behavior of the VDC infrastructure for a givenVD request can be represented as four stages of service in thequeue namely: Stage-1) Network path Determination, Stage-2) Resource Usage Estimation, Stage-3) Data center Selection,and Stage-4) VD Instantiation. As shown in Figure 4, incom-ing VD requests get first queued in a buffer of size K-1 whereK represents the maximum number of VD requests served bythe VDC infrastructure in n stages with each stage havinga different mean service rate, i.e., µ1, µ2, ...µ4. A new VDrequest enters the input queue and is processed only after theprevious request has departed the queuing system, i.e., leftStage-4. The incoming VD requests are sequentially executedin the queue and the execution of all stages are mutuallyexclusive (i.e., if one of the stages is executing, no other stagewill be executing concurrently). Also, in order to capture theincoming VD requests distribution over a period of time, wehave assumed a Poisson arrival λ of VD requests.

5

Fig. 4: Finite queuing model with 4 stages of service in VDC

Fig. 5: State transition rate diagram for the VDC finite queuingmodel with four-stage service

We calculate the mean service time of the fourth stage (i.e.,1/µ4 ) as the mean of the maximum of two service times: (i)the time taken for comparing a new VD request’s user profilewith existing VDs in the desktop pool, and (ii) the time takenfor creating a new VD image (when user profile does notmatch existing VDs) or the time taken for adding a new userto an already created VD pool (when user profile matchesexisting VDs). Both values are exponentially distributed withmeans of 1/ µu and 1/ µi, respectively. Hence, we have -

1/µ4 = 1/µu + 1/µi − 1/(µu + µi) (2)

The analytical finite queuing model for a VDC infrastructureis based on embedded Markov chain shown in Figure 5 witha state space S ={(k, n), 0 ≤ k ≤ K, 0 ≤ n ≤ 4}, where kdenotes the number of requests in the VD application. State(0,0) represents the special case when the VD application isidle, i.e., the state of system idleness. State (k,n) represents thestate where the application is busy executing service of stagen with k requests in the system.

Let Pk,n be the steady-state probabilities at State (k,n). Thesteady-state balance equations are shown for each state asfollows:

State(0, 0) : 0 = −λp0,0 + µ4p1,4 (3)

States(1, n) : 0 = −(λ+ µn)p1,n + µn−1p1,n−1,

(2 ≤ n ≤ 3) (4)

States(k, n) : 0 = −(λ+ µn)pk,n + λpk−1,n +

µn−1pk,n−1, (2 ≤ k ≤ K − 1; 2 ≤ n ≤ 3) (5)

States(K,n) : 0 = −µnpK,n + λpK−1,n +

µn−1pK,n−1, (2 ≤ n ≤ 3) (6)

State(K, 1) : 0 = −µ1pK,1 + λpK−1,1 (7)

Therefore, the state probabilities of pk,n can be expressedrecursively in terms of p0,0 as follows:From equation (3),

p1,4 =λ

µ4p0,0 (8)

From equation (4),

p1,n−1 =

(λ+ µn

µn−1

)p1,n, (2 ≤ n ≤ 3) (9)

From equation (5),

pk,n−1 =

(λ+ µn

µn−1

)pk,n −

(λ

µn−1

)pk−1,n,

(2 ≤ k ≤ K − 1; 2 ≤ n ≤ 3) (10)

From equation (6),

pK,n−1 =

(µn

µ3

)pK,n −

(λ

µ3

)pK−1,n,

(2 ≤ n ≤ 3) (11)

and from equation (7),

pK,1 =

(λ

µ1

)pK−1,1. (12)

Using the normalization condition, P0,0 can be obtained asfollows:

p0 = p0,0 =1

1 +K∑

k=1

4∑n=1

pk,n

p0,0

. (13)

Obtaining P0,0 can be used to find all other state probabil-ities {pk,n; 1 ≤ k ≤ K, 1 ≤ n ≤ 4}.

The mean system throughput γ is basically the departurerate i.e., the rate at which the VD request finishes successfullyafter being processed in Stage-4:

γ = µ

K∑k=1

pk,4. (14)

The departure rate γ can also be expressed as the effectivearrival rate λ′ which is λ(1− Ploss). Therefore,

γ = λ(1− Ploss) (15)

Where Ploss is the loss (or blocking) probability. Ploss canbe expressed as the probability of being in States (K, 1 - 4):

Ploss =

4∑n=1

pK,n. (16)

The mean number of VD requests in the system can beexpressed as:

E[K] =

K∑k=1

4∑n=1

kpk,n. (17)

Using Little’s law, the mean SRT of a VD request spent inthe system succeeding in entering the queue can be expressedas:

W =E[K]

γ=

1

γ

K∑k=1

4∑n=1

kpk,n. (18)

6

Fig. 6: Net utility Graph depicting system state under various schemes, VD requests load, faults and cross traffic

VI. VDC-ANALYST USE CASES AND RESULTS

In this section, we first analyze the simulation results for agiven provisioning and placement scheme in the Run Simula-tion mode. We then demonstrate and emulate our simulationresults with an experiment on the GENI testbed in RunExperiment mode. Lastly, we discuss the tool’s use case asan educational curriculum for a classroom lab exercise.

A. Run Simulation Use CaseTo simulate the VDC system under various real-world sce-

narios, we performed different combinations of provisioningand placement scheme tests with varying number of VDrequests load, faults and cross traffic levels. Figure 6 showsthe Net Utility graph for a sample set of 15 runs. The first fourruns are the outputs of different placement schemes under U-RAM provisioning when there is no fault in the system, theVD requests load is 500 and cross traffic level in the network isset to 10. As observed, Least Latency and Least Joint schemesgive rise to higher Net Utility compared to Least Cost andLeast Load schemes. While Least Latency places VDs on thenearest data centers from request locations, Least Joint schemeconsiders the overall utility of the system by optimizing VDrequests load on the data centers and gives rise to higher utility.Also, we observe that Least Cost placement scheme reducesthe Net Utility since it allocates VDs with minimum numberof resources and finally, Least Load scheme has the lowestutility since it allocates minimum VD requests load at everydata center, reducing the overall system utility.

When we introduce faults in the system, the behavior of thefour schemes are almost similar with only difference in themagnitude of Net Utility as observed from run numbers 5, 6,7 and 8. Though the fault rate is same across all schemes, themagnitude at with each scheme has scaled down is different. Ifwe closely look at the Least Latency and Least Joint placementscheme, there is a marginal difference in the utility values.The Least Joint placement scheme is more adaptable towardschanges in the environment. Thus, Least Joint scheme outperforms Least Latency scheme and could be preferable touse in a cloud environment when fault occurrence is more.

The run numbers 9, 10, 11 and 12 show the results of E-RAM and Fixed Resource Allocation Model algorithms. TheNet Utility of E-RAM scheme is slightly less as compared toU-RAM. This is because the E-RAM scheme while maintain-ing an relatively biased fairness between the VDs of differentuser profiles, decreases the number of VD requests served

(a) SRT results for provisioning already existing VDsthat match requests’ user group profiles

(b) SRT results for provisioning new VDs (requiresimage boot-up) that does not match requests’ user groupprofiles

Fig. 7: SRT estimations for different VD provisioning methods

per data center, which in turn marginally reduces the VDCutility. On the other hand, F-RAM utility is very low as veryfew VDs are placed at any given data center. Contrary tothe above observation, utility of E-RAM and U-RAM in thesubsequent runs 13 and 14 remains same for a VD requestsload of 200 while the F-RAM utility has further scaled down.Equal utility values for U-RAM and E-RAM can be attributedto the reason that the data centers have sufficient resourcesto allocate maximum amount of CPU and memory for everyVD request. The utility starts varying once some data centersexhaust their resources after a certain threshold of VD requestsload is reached.

The URB can provision VDs in two different ways. Ifa previously created VD matches a new VD request’s userprofile and is available for provisioning, then that VD will beprovisioned by adding the new user profile to it. The URBtakes about 1 minute (from our testbed experiences) on anaverage in performing the operation. If such a VD is not

7

(a) Without Load Balancing

(b) With Load Balancing

Fig. 8: VD application flows in GENI infrastructure

available, a new VD will be created by booting up a freshimage for the user and the user profile is added to the VD forthe request. In this case, the URB takes around 15 minutes(from our testbed experiences) approximately. Figure 7 showsSRTs for the two VD provisioning methods for a VD requestsload of 500. Figure 7a shows a snapshot of the SRT windowfor provisioning on already existing VDs when a new VDrequest’s user group matches existing user profiles. We observethat the difference between the lowest provisioning time andthe highest provisioning time is around 2 minutes. Similarly,Figure 7b shows a snapshot of SRT results for provisioningnew VDs that do not match user group profiles. The differenceis now less than 0.5 minutes. The reason can be attributedto the fact that, in the second case, the VD request spendsmore time in the request queue and hence the difference inprovisioning times is less when compared to the first case.

B. Run Experiment Use CaseTo emulate the Run Experiment mode in VDC-Analyst, we

reserved the OpenFlow Topology of GENI infrastructure withOpenFlow switches at different university campus locationsshown in Figure 8a. We had the VMLab data center at TheOhio State University (location: Columbus, Ohio) (runningVMware ESXi hypervisor for creating VD pools) hostingpopular applications (e.g., Excel, Internet Explorer, MediaPlayer) as well as advanced scientific computing applications(e.g., Matlab, Moldflow), connected to the GENI OpenFlownetwork. A mirror of VMLab setup was at the Emulab datacenter at The University of Utah. We also reserved PG46 andPG47 nodes in Clemson University to serve the purpose ofthin-client machines with smart thin-client software (i.e., it

(a) With both Load Balancing and Cross-Traffic disabled

(b) With Load Balancing disabled and Cross-Traffic enabled

(c) With both Load Balancing and Cross-Traffic enabled

Fig. 9: VDC-Analyst Experiments in GENI

generates VD application flows with marker packets) runningon these machines. Additionally, we reserved WAPG nodesPG48, PG49 in Stanford University; PG50 and PG51 inRutgers University to act as cross-traffic generators. We usedFloodlight [22] as the OpenFlow controller application. Fromthe topology in Figure 8a, we can observe that the pathbetween Stanford and Rutgers nodes overlap with the pathbetween the thin-client node at Clemson and the VMLab datacenter. This was done to generate cross traffic using highbandwidth for disrupting the VD traffic between the thin-clientnode and the data center.

On triggering the Run Experiment with U-RAM and LeastCost as the provisioning and placement schemes in the CloudBroker UI panel, Figure 8a shows the flow rules that wereinstalled in the OpenFlow switch for the thin-client traffic.We initiated a VD request from the Clemson thin-clientnode. Once the VD resource based on the selected resourceallocation schemes was reserved on the VMLab data center,we ran a high-definition (HD) wildlife video clip on Windowsplatform to show the Media Player capability. We observedthat the video ran smoothly, without any lag or jitter andthe Windows Graphical User Interface (GUI) was responsive.When we opened other applications in parallel, GUI inter-actions responded in a smooth manner. The graph in Figure9a shows the average bandwidth consumed by the thin-clienttraffic in the network.

Next, we introduced cross traffic using the Iperf tool [23]in the network by setting the cross traffic level to 100 in theVDC-Analyst window and ran the experiment again with the

8

same provisioning and placement schemes. The shortest pathchosen by the URB between the thin-client node and datacenter overlaps with the path between Stanford and RutgersWAPG nodes used for cross traffic generation. The OpenFlowcontroller application installed the flow rules for the crosstraffic in the OpenFlow network devices. Once the cross trafficflows were installed, the Iperf client and server at Stanford andRutgers started to communicate with a traffic of 100 Mbpsbandwidth, respectively. The cross traffic disrupted the thin-client traffic on the same path and made the thin-client nodePG47 at Clemson to freeze, and its GUI became unresponsive.The path used by both these flows is shown in Figure 8a withthe congestion path highlighted. Figure 9b shows the systemcharacteristics - the flow tables in the OpenFlow switches withnew entries for the cross traffic flows, the diminishing videoquality at the thin-client site and the average bandwidth usagestatistics as collected at WAPG nodes i.e., PG47 at Clemson(thin-client node) and PG50 at Rutgers (cross-traffic node).

We finally selected our cost-aware utility-maximal resourceallocation scheme, kept the cross-traffic as 100 and ran theexperiment again. With the selected scheme in place, loadbalancing was activated by the URB on the network and analternate path in the multi-path GENI OpenFlow core wasdetermined for cross-traffic generation. The new path did notoverlap with the path used by the thin-client flow and isrepresented in Figure 8b. The new path was communicatedto the OpenFlow network controller application by the URBand the controller installed the flow rules on the networkdevices for the path that was to be followed by the cross-traffic. Once the path was re-routed, the cross-traffic packetsthat had queued at the ports of network devices shared betweenthe two traffic flows were flushed out. The thin-client becameresponsive again, and the video resumed. The GUI interactionwas smooth and was similar to the working scenario whenthere was no cross-traffic in the network. Figure 9c shows theflow tables with new flow rules, and the average bandwidthusage statistics collected at the end-points of the two flows.

C. Educational Curriculum Use CaseMost of the current educational simulator tools allow stu-

dents to test resource allocation schemes on simulation frame-works, but do not integrate real-world testbeds to measurethe schemes’ actual performance and impact on user QoE.In this section, we describe how VDC-Analyst can be usedas an educational curriculum in classroom lab exercises ofcloud computing courses. The goal of the curriculum involvingVDC-Analyst is to allow students to design and verify efficientresource allocation schemes for VDCs.

As part of the lab exercises, students can build their ownresource allocation schemes and explore server, client andnetwork-side intelligent adaptations using the tool to maximizeuser QoE for VDs. The tool can be used to measure the NetUtility and SRTs of the schemes under varying loads, faultsand and cross-traffic in both modes of the tool. A low NetUtility or a high SRT indicates further refinement of resourceallocation schemes and helps students build optimized schemesfor VDCs. Students could also come up with their own qualitymetrics which can increase the VDC efficiency and integratethem easily into the tool.

In addition to developing resource allocation schemes, stu-dents could also explore various other optimizations of VDCswhich contribute to maximizing the utility of schemes. On

the server-side, students can design automated macro scriptsfor tasks having similar operations and reduce the end-to-endround trip time of thin-client control responses (i.e., implementlatency hiding) during network bottleneck events. On the thin-client side, the tool can be extended to measure individual thin-client protocols’ (RDP, PCoIP, etc.) performance in servingVD requests and choose appropriate thin-client encodingswhich give rise to higher utility. Furthermore, on the network-side, students could build their own OpenFlow network con-troller applications and automate traffic flow management inorder to reduce SRTs of VDCs. Some factors which canbe considered for building adaptations within the controllerapplication could involve: reduction of queuing delays, andavoidance of cyber-attacks. Students’ schemes could be gradedbased on relatively high or low Net Utility scores obtainedusing the VDC-Analyst tool. For example, a Net Utility scoreof 30+ could result in a Good grade, 20 − 30 range of NetUtility could result in a Fair grade, and < 20 Net Utility couldresult in a Poor grade.

VII. CONCLUSION

In this paper, we have presented a novel VDC-Analyst toolfor simulation and emulation of large-scale VDC infrastruc-tures measured through two important quality metrics NetUtility and Service Response Time. We demonstrated howload-balancing through “programmable” path switching basedon perceived user QoE, can increase the performance of theVDC infrastructure by leveraging software-defined networkingprinciples and the OpenFlow protocol. We described howVDC-Analyst can be used as an educational and researchtool to measure user QoE metrics for different placement andprovisioning schemes. Through our tool testing results, wedemonstrated the need for different utility-directed resourceallocation models as opposed to fixed resource allocation mod-els, to substantially improve user QoE and VDC infrastructurescalability.

Our future work with VDC-Analyst is aimed at integratingthe tool with emerging Virtual LAN (VLAN) technologiessuch as Virtual Private LAN service [24], Overlay TransportVirtualization [25], and Virtual Tenant Networks [26]. Sincethere are no open-solutions available that provide services suchas predictable bandwidth performance for a virtual networkalong with traffic isolation, our planned work with VDC-Analyst aims to extend our method of leveraging OpenFlowfor VDCs to accommodate virtual tenant network virtualiza-tion use cases for data-intensive and latency-sensitive VDapplications.

REFERENCES

[1] L. Yan, “Development and application of desktop virtualization tech-nology”, Proc. of IEEE International Conference on CommunicationSoftware and Networks, 2011.

[2] M. Fiedler, T. Hossfeld, P. Tran-Gia,“A generic quantitative relationshipbetween quality of experience and quality of service”, Proc. of IEEENetwork, 2010.

[3] P. Calyam, S. Rajagopalan, A. Selvadhurai, A. Venkataraman, A. Berry-man, S. Mohan, R. Ramnath, “Leveraging OpenFlow for ResourcePlacement of Virtual Desktop Cloud Applications”, IEEE/IFIP IM, 2013.

[4] L. Deboosere, B. Vankeirsbilck, P. Simoens, F. De Turck, B. Dhoedt, P.Demeester, “Cloud-Based Desktop Services for Thin Clients”, Proc. ofIEEE Internet Computing, 2012.

[5] K. Beaty, A. Kochut, H. Shaikh, “Desktop to cloud transformationplanning”, Proc. of IEEE International Symposium on Parallel DistributedProcessing, 2009.

9

[6] CLOUDS Lab, University of Melbourne, “CloudSim Toolkit 2.1.1”,http://www.cloudbus.org/cloudsim

[7] S. Garg, R. Buyya, “NetworkCloudSim: Modelling Parallel Applicationsin Cloud Simulations”, Proc. of IEEE International Conference on Utilityand Cloud Computing, 2011.

[8] D. Kliazovich, P. Bouvry, Y. Audzevich, S. Khan, “GreenCloud: A Packet-level Simulator of Energy-aware Cloud Computing Data Centers”, Proc.of IEEE Globecom, 2010.

[9] Network Simulator 2, http://www.isi.edu/nsnam/ns[10] F. Jrad, J. Tao, A. Streit, “Simulation-based Evaluation of an Intercloud

Service Broker”, Proc. of Conference on Cloud Computing, GRIDs, andVirtualization, 2012.

[11] G. Castane, A. Nunez, J. Carretero, “iCanCloud: A Brief ArchitectureOverview”, Proc. of IEEE International Symposium on Parallel andDistributed Processing with Applications, 2012.

[12] H. Casanova, A. Legrand, M. Quinson, “SimGrid: A Generic Frameworkfor Large-Scale Distributed Experiments”, Proc. of IEEE InternationalConference on Computer Modeling and Simulation, 2008.

[13] R. Buyya, M. Manzur, “GridSim: A Toolkit for the Modeling andSimulation of Distributed Resource Management and Scheduling for GridComputing”, Concurrency and Computation: Practice and Experience,Vol. 14, No. 13, pp.1175-1220, 2002.

[14] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson,J. Rexford, S. Shenker, J. Turner, “OpenFlow: Enabling Innovation inCampus Networks”, ACM SIGCOMM Computer Communication Review,Vol. 38, No. 2, pp. 69-74, 2008.

[15] P. Calyam, R. Patali, A. Berryman, A. Lai, R. Ramnath, “Utility-directedResource Allocation in Virtual Desktop Clouds”, Elsevier ComputerNetworks, 2011.

[16] M. Sridharan, P. Calyam, A. Venkataraman, A. Berryman, “Defragmen-tation of Resources in Virtual Desktop Clouds for Cost-Aware Utility-Optimal Allocation”, Proc. of Utility and Cloud Computing (UCC), 2011.

[17] A. Berryman, P. Calyam, M. Honigford, A. Lai, “VDBench: A Bench-marking Toolkit for Thin-client based Virtual Desktop Environments”,Proc. of IEEE International Conference on Cloud Computing Technologyand Science, 2010.

[18] Global Environment for Network Innovations - http://www.geni.net[19] TangoGENI Operations - http://groups.geni.net/geni/wiki/TangoGENI[20] Eclipse IDE for Application Developers - http://www.eclipse.org[21] A. Gulati, G. Shanmuganathan, et. al., “VMware Distributed Resource

Management: Design, Implementation and Lessons Learned”, VMwareTechnical Journal, 2012.

[22] Floodlight Controller - http://www.projectfloodlight.org/floodlight[23] A. Tirumala, L. Cottrell, T. Dunigan, “Measuring End-To-End Band-

width with Iperf Using Web100”, Proc. of Passive and Active Measure-ment Workshop, 2003.

[24] VPLS IETF Submission -http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-ldp-09

[25] OTV IETF Submission -https://datatracker.ietf.org/doc/draft-hasmit-otv[26] NEC Whitepaper, “NEC ProgrammableFlow: Redefining Cloud Net-

work Virtualization with OpenFlow”, 2012.

10