Dynamic Load Balancing for Efficient VideoStreaming Service

Junyeop Kim and Youjip WonDept. of Computer Software

Hanyang University Seoul, KoreaEmail: {exdream | yjwon}@hanyang.ac.kr

Abstract—As cloud and N-Screen services get active, thenetwork traffic of mobile devices is rapidly increasing. Thevideo streaming takes higher bandwidths in the mobile network.Servers with popular contents have to manage higher transmis-sion bandwidths in order to handle many user requests at atime. But servers with unpopular contents have relatively lowertransmission bandwidths although they can handle much moreuser requests. Such imbalance in loads among the servers willcause the lowering of QoS of the video service systems and wastethe resources. In this paper, we implemented an algorithm to solvethe imbalance between the loads by placing replicas of popularcontents in other servers. And in order to efficiently cope with thesevere variation of the popularity of the contents, we implementeddynamic video contents management system which handles theload balancing by checking of the states of the servers in realtime. We also verified the performance of the algorithm in manyaspects applying real mobile video service workload. As a result,we could reduce the deviation in the transmission bandwidthamong existing servers by 57%.

I. INTRODUCTION

Videos are basically data of large quantity, different fromtexts, and their constant transmission speed (bitrate) should beensured so that the videos may be replayed without interrup-tion. Therefore their bandwidth needed for a session of a user ismuch wider than that of other kinds of data. And Internet videostreaming services, such as Youtube and Netflix [1], [2], arevery popular these days, and their popularity is continuouslyincreasing. iShoot [3] is a representative video streamingservice in Korea as described in Fig. 1. Since the advent ofsmart phones, their popularity has even more increased, aswe can use video services not only in desktop computers butalso in mobile devices. Thus video streaming accounts for 25-40% of the total Internet traffic [4]. The requests by the usersfor the video contents are not constant among the contents,but they tend to concentrate on specific contents by theirpopularity [5], [6]. As the requests by the users for specificcontents get higher, traffic is concentrated on the servers withpopular contents. The difference in the popularity of the videocontents causes the unbalance in the loads between a few hotservers and other cold servers. Hot servers mean the serversfor which available transmission bandwidth is insufficient asthey handle much traffic, while cold servers are those withsufficient available transmission bandwidth. Hot servers willlatently reach to the limit of the transmission bandwidth,which will cause the lowering of Quality of Service(QoS) ofthe system so that the replays of videos are interrupted oradditional requests by the users for videos are refused. On the

This work was supported by a grant from IU Media Co., Ltd.

other hand, the sufficient available transmission bandwidth ofthe cold servers will lead to the waste of the system resources.If the traffic of the video streaming service is high for allthe servers, you can choose to enhance the performance ofeach server or add newly-installed servers. It is important todistribute the traffic and the added requests concentrated onhot servers to other servers so that the hot servers may be keptfrom reaching to the limits of their performances; and assigntraffic to the cold servers so that the available transmissionbandwidth of the servers may be utilized. This way, howyou can efficiently realize the traffic balancing between thevideo streaming servers is an important issue in the videostreaming services. As the popularity of the video contentsin the Video on Demand (VOD) services is closely relatedto the interest of the users, you cannot predict them, and itsvariation per time is severe. So a static method in which you tryto bring about the load balancing by distributing the contentsto each server in advance after predicting the popularity ofall the contents is difficult to implement, and inefficient, asprecise prediction is impossible. Therefore, it is necessary toimplement a dynamic contents management system in whichyou can efficiently distribute the loads among the servers bychecking the traffic states of the servers in real time andquickly responding to the changes of the traffic. In this paper,we implemented a dynamic contents management system and adynamic load balancing algorithm, for efficient VOD servers.And we implemented a simulator for the verification, whilewe analyzed the performance of the load balancing algorithmthrough diverse simulations.

httpd httpd httpd

Streaming Servers

http

http

index

Server

mobile DB

Encoding

Server

location content

search

update

new

Fig. 1: iShoot Video Streaming Cloud Service

II. TRAFFIC CHARACTERISTICS

Concrete traffic characteristics analysis was made for thevideo streaming servers of iShoot [6]. Each streaming serverprovides the contents to the users through HTTP of Apachehttpd, and we let it leave a log on the service results throughthe setup of Apache. A log records things like when a requestcame, from whom, for what contents was it, and how muchtransmission - and how long was made. As you get theinformation on the quantity and time of the transmission fromthe log, you can get the transmission bandwidth out of them.And from the information on the time when a request came,you can see the traffic pattern at that time.

A. Traffic Distribution

In order to look into the distribution of the traffic amongthe streaming servers, we collected the bandwidth values ofeach streaming server for each hour from January to February2011. And we counted up how many the time intervals(1 hour)exist according to bandwidth values every streaming servers.Fig. 2 shows the cumulative form of the histogram of timeintervals. This graph is leaned toward the lower bandwidthzones. Streaming servers have low traffic most of the time.

Fig. 2: Cumulative form of time interval(1hour) distribu-tion according to bandwidth(x-axis; GB/hour) every streamingservers.

B. Contents Popularity

Table 1 gives the distribution of the contents transmissionquantity of Jan. 1, 2011. Of the 2,351 contents, upper 69contents with high transmission quantities account for 52.6%of the total transmission quantity. You will see that not all thecontents are popular, but a small number of popular contentsaccount for most of the traffic of the servers. Therefore youcan figure out that if you copy only several contents to otherservers, the high load of a server can be efficiently lowered.To minimize the cost for copying while maximizing its effectis an important element of a contents management system.

III. ISHOOT CONTENTS MANAGEMENT SYSTEM

A. System Design

We formed the iSCON system, as in Fig. 3, by changing,or newly adding, functions to the existing iShoot system. TheiSCON system is formed as follows:

TABLE I: Contents Popularity Distribution of a streamingserver (01/01/2011)

Number of contents Traffic (MB) Traffic Rate (%)

3% 69 1,059,537 52.6

5% 115 1,267,243 62.9

10% 231 1,509,247 74.9

Total 2,351 2,016,179 100.0

1) Index Server: Index Server plays a role of connectingthe streaming between the client and the streaming server, asit receives a request from the client and return the locationinformation of the content through a DB searching. It checksstates of all the servers with the replicas of the contentsthrough the DB. It chooses a server whose traffic is the lowest,excluding hot servers handling high traffic, and connects it tothe client. So this server plays a role as load balancer, evenlydistributing traffic among the servers.

2) SIC(System Information Collect) Daemon: SIC Daemonexists in each streaming server and runs in the background.A streaming server, which is made up of an Apache HTTPserver, leaves a record log after giving a service. Using this,SIC module grasps the traffic value of the current server, andfinally transmits the state of the streaming server to the MobileDB every five minutes. So iSCON system can check the serverstate in real time. The iSCON load balancing algorithm checksthe server state every five minutes and balances the load amongthe servers.

3) ILM(Information Lifecycle Management) Server: ILMServer plays the most important role in the iSCON systemwhich manages the contents of the streaming servers. Thisserver efficiently copies the contents and distributes them to thestreaming servers by the load distribution algorithm. ILM playsa role of enhancing the performance of the service through thecopying, movement and deletion of the contents. We will dealwith the detailed ILM contents management algorithm in thenext chapter.

iSCON system consists of Index Server, Streaming Servers,Mobile DB and ILM Server. We had SIC Daemon for eachstreaming server, so as to update the real-time server trafficvalues onto the DB, while we let ILM Server manage thecontents.

SIC SIC SIC

Fig. 3: iSCON System Design

IV. LOAD BALANCE ALGORITHM

A. Background and Objectives

To form a video service system with a lot of streamingservers is simple, but it requires much increase in the costfor the system each time a streaming server is added. Andthe more the streaming servers, the more complicated theirmanagement gets. The analysis result of the traffic charac-teristics of the existing iShoot video service shows that thetraffic of video contents have two major characteristics. Firstly,the popularity distribution of video contents is diverse due tothe interest of the users, and a few popular contents accountfor most of the total video traffic. Secondly, the popularityof video contents severely varies and is unpredictable. Dueto such characteristics of the traffic, the load unbalance ofthe streaming servers occurs. A few hot servers and othercold servers are distinguished. Hot streaming servers are ina state of lacking available transmission bandwidth and canreach their limits of performance soon, with a problem ofthe lowering of the system QoS, including the failure or theslowing down of the servers. Cold streaming servers, on theother hand, are in a state of sufficient available transmissionbandwidth, causing the waste of the resources. Therefore,based on the above two problems, we set up following twomajor objectives for iSCON, for the implementation of anefficient load balancing algorithm. The first objective was tomake the best of the performance so as to prevent the waste ofresources and manage the system with the minimum numberof the streaming servers. The second objective was to quicklyand efficiently distribute the traffic of the users concentratedin large quantities, so as to enhance the quality of the iShootvideo streaming service.

B. Define Volume

The target of the load balance is the nodes which canindividually give I/O performances. An iShoot video streamingserver consists of an 8-bay or 24-bay storage server. An 8-bayserver has one (7+1) RAID, while a 24-bay server has two(11+1) RAIDs. Each RAID has the performance of a single I/Otransmission bandwidth. We define a formation unit of RAIDthat can give an independent I/O performance as a volume.

C. Problem Formulation

1) Traffic Detection: The popularity of video contentsseverely varies per time, repeating rapid increases and drops.As the variation of the video contents popularity is hard topredict, it is necessary to watch the system traffic in real timeso as to detect a dangerous situation and respond to it. Weset up a threshold value for the transmission bandwidth of avolume in the load balancing algorithm. If the transmissionbandwidth of a volume exceeds the threshold, it judges thatthe volume may soon reach the maximum, and redistributesthe contents to another volume to lower high traffic. In theexperiment, we set up the threshold at 70% in the volumeMAX transmission bandwidth and use the remaining margin of30% for copy bandwidth needed for running the load balancingalgorithm. The time interval on how often you check the trafficsituations of the volumes to run the load balancing algorithmis also very important. If the interval is very long, you willnot be able to efficiently deal with the momentarily-exploding

traffic situations. If the interval is very short, on the other hand,the algorithm will be run unnecessarily many times, burdeningthe system. In the experiment part of this study, we analyzedthe differences in performance per the time interval of therunning of the load balancing algorithm. In order to efficientlydeal with the traffic momentarily exploding by the contentspopularity, it is suitable to set up the time interval in minutesrather than in hours.

2) How many replicas do we need?: For the balancingof the loads among the volumes, the contents need be movedand copied. One way is to move contents with high traffic toanother volume to move the whole traffic to another volume;the other way is to copy contents to other volume so that thedifferent volumes handle the traffic together with the contentsreplicas. The target of this study is the load balancing amongthe volumes through contents copying. It should be carefullyconsidered how many volume you will have with contentsreplicas. The more replicas you have, the more traffic you candistribute effectively. Considering the capacities and the copy-ing costs, this will give you much burden. If you have too fewreplicas, however, you cannot quickly lower the traffic of highvolume. In order to decide upon the number of the replicas, weassumed a situation of the left picture in Fig. 4. The differencein the transmission bandwidth between the maximum volume(number 0) and the minimum volume (number 2) is the worstat 99%. Lets assume a simple situation of moving trafficfrom the number 0 volume to the number 2 volume for thepurpose of load balancing. The problem here is that it ispossible that the number 0 volume becomes a volume withminimum transmission bandwidth while the number 2 volumebecomes a volume with maximum transmission bandwidth.Then the problem of load unbalance between the volumeswill remain although you have tried to distribute the load.We focused on such difference between the minimum andmaximum bandwidths. We set up the constraint condition forthe load balancing between volumes as following:

BWMAX −BWMIN

BWMAX< δ (1)

Above equation is an inequality which shows the conditionthat the difference in the transmission bandwidth between twovolumes should be less than δ. This constraint condition is acriterion to show if the loads between the volumes are balancednow. The right picture of Fig. 4 shows the traffic between thevolumes meeting the above constraint condition equation. Ifthe transmission bandwidth value to be assigned to a volumewith lower transmission bandwidth from a volume with highertransmission bandwidth is ALLOC BW, the above constraintcondition should still be met after the value is assigned. Sowe can get ALLOC BW through the following equation.

ABWMIN − (ABWMAX −ALLOC BW )

ABWMIN≤ δ (2)

ALLOC BW ≤ (δ − 1)×ABWMIN +ABWMAX (3)

ABW means available bandwidth of a volume. Here theprocess in which the number of the volumes with the replicas

is determined is as follows: The volumes whose transmissionbandwidths exceed the threshold value will be the targets ofthe load balancing algorithm. The load balancing algorithmproceeds with the copying, after we take a hot content withhigh transmission bandwidth as a victim, out of the contentsthe volume has. And the transmission bandwidth of the victimcontent is set up to be REQ BW. The next loop is repeateduntil the REQ BW value becomes 0. After you choose the vol-ume with the largest available transmission bandwidth out ofall the volumes, you should get the value of ALLOC BW. Thevalue of ALLOC BW you got is subtracted from REQ BW.Finally, when the REQ BW value becomes 0, the loop isstopped, which means you have assigned all the traffics youneed to assign. The number of all the volumes chosen here isthe number of the replicas determined by the load balancingalgorithm.

network

usage

(%)

0 1 2 3 4

max

volumes 0 1 2 3 4

max

Threshold

99% 50%

Fig. 4: Difference Min volume and Max volume should bebelow δ (50%)

3) Copy Bandwidth: While you can have the replicas ofcontents in many servers to enhance the performance of thesystem, it will cost much. You should use more the systemresources in addtion to resources of the actual service. Inorder to enhance the performance of the system, you shouldinternally reorganize the system, including copying of thecontents to other servers. In order to copy contents to otherservers, you should use additional transmission bandwidth,other than the bandwidth used for the actual service. This canaffect the system QoS, so you should carefully consider thealgorithm. When you copy contents, how you set up the copybandwidth will influence the copying time, which is related tothe load balancing performance. If you set the copy bandwidthhigh, you can copy the contents quickly to other servers so thatyou can distribute the load, but then the bandwidth which canbe used for actual service will be reduced. If you set the copybandwidth low, you can get a large service bandwidth for theservers, but then the copying process will be finished later, sothat the load balance effect will be delayed.

Now lets consider the methods to use the copy bandwidth.The first one is to very simply fix bandwidth needed forcopying for every server and run a copying queue, transmittingone by one. But this method does not consider current serversituation and gives out fixed performance even in a situationwhen more copy bandwidth can be used. The second methodis one in which you let it transmit multiple contents at a timebut set the bandwidth for copying a content low so as to lowerthe total of the additional copy bandwidths. But this methodalso has its weak point that in the aspect of performance, itcannot quickly finish copying. As the final method, you cancheck the situation of the current server so as to variably set thelimit of the copy bandwidth in accordance with the bandwidthsituation of the server. When the traffic of the server is high,you will have the assignment for the copy bandwidth low, and

when the traffic is low, you will have the assignment high,managing it dynamically. The algorithm of this study uses thislast method. When the bandwidth of the server is high, youhave to copy the contents to other servers quickly to lowerthe load, but the copying process can get the bandwidth ofthe server to reach its peak, causing a problem in the service.So in such a case, you should set low the number in whichthe replicas may be made at a time so as not to let the serverreach its peak. On the other hand, when the bandwidth of theserver is low, you should increase the number of the contentswhich may be transmitted at a time so as to expand the copybandwidth, allowing quick copy requests. This way, you cancarefully lower the servers with high traffic, while you leadthe load to be quickly moved to the servers with low traffic.

D. Algorithm Details

The iSCON load balancing algorithm largely consists of thefollowing three steps (functions): iSCON calls Reallocate, themain function, every five minutes. The interval of five minutesis defined by the system and may be differently set up. The roleof the Reallocate function is first to search the whole volume tocheck if the current transmission bandwidth exceeds a specificthreshold. This threshold value shows the situation of thevolume and is defined by the system. We see that for a volumewhich exceeds this value, its load is being concentrated andso it can soon reach its peak. We take this volume as a targetto lower its concentration of traffic and run the load balancingalgorithm. If a hot volume is set up as a target, we take oneof the contents in the volume with the highest transmissionbandwidth as a victim, proceeding with the copying process bycalling Replicate function into another volume. This processis repeated until the transmission bandwidth of the volumegets less than the threshold. Replicate is a function whichdecides which volume the victim content shall be copied to andproceeds with the copying. We do not simply place one replicain a volume with the largest available bandwidth, but dividethe replica and put it in multiple volumes so that the differencebetween volumes with the largest available bandwidth and withthe smallest available bandwidth should not exceed δ. In thisprocess, the number of the replicas is determined dynamicallyin accordance with the situation, considering the victim contentand the current volume bandwidths. If the reassignment iscompleted for all the volumes, Reallocate function finally callsRecalibrate function to reset the allowable copy bandwidth foreach volume, considering the current bandwidth of the volume.When the transmission bandwidth of a volume is high, wedecrease the number of contents which may be copied at atime, and when the transmission bandwidth is low, we increasethe number of the contents which may be copied at a time.

V. EXPERIMENT

A. Workload

For the traffic analysis of the existing iShoot video stream-ing service and the implementation of an iSCON system,we collected the service result logs of the streaming serversfrom January to September of 2011. Out of them, we chosethe log of Feb. 13, 2011, which has the largest quantity oflog record to create workload for the simulation. The largequantity of the log reflects that the iShoot service handled somany user requests and that the liveliest service took place

TABLE II: Streaming server configuration

Streamingserver ID Server specification

(Volume ID)

mobileweb13 8bay, SATA3 7200rpm HDD, 16GB RAM(v1060) CPU: Intel Xeon Quad-Core E5506(2.14GHz), 4M Cache, 2U

MEMORY: DDR3 ECC PC-10600, 4UHDD: Seagate 2TB, SATA3 6.0Gbps 7200rpm, 64M Cache, 8URAID Controller: LSI MegaRaid 9260-8i SAS, 256M Cache, 1U

mobileweb15 8bay, SATA3 5900rpm, 16GB RAM(v1070), CPU: Intel Xeon Quad-Core E5506(2.14GHz), 4M Cache, 2U

mobileweb16 MEMORY: DDR3 ECC PC-10600, 4U(v1080) HDD: Seagate 2TB, SATA3 6.0Gbps 5900rpm, 64M Cache, 8U

RAID Controller: LSI MegaRaid 9260-8i SAS, 256M Cache, 1U(We assume the network link bandwidth is higher than the maximum bandwidth of

streaming servers for experimental purpose. We concentrate on the server bandwidth.)

on Feb. 13, 2011. For the experiment, we used the serviceresult logs on Feb. 13, 2011 of mobileweb13, mobileweb15 andmobileweb16 streaming servers out of the streaming servers ofthe existing iShoot system as the workload for the simulator.The configuration of the servers related to the experimentis as Table 2. Prior to the verification of the performanceof the iSCON system and the algorithm, we analyzed theworkload used for the simulation. Fig. 5 shows a graph forthe transmission bandwidth of existing three volumes, withoutthe load distribution algorithm applied. First, the overall trafficcharacteristic shows that the traffic is high from midnight,while it has the lowest bandwidth at 7 a.m. The differencesbetween the three volumes are big from midnight to 5 a.m.You will see the bandwidth of 1060 volume is different fromthose of the volumes 1070 and 1080 by the maximum of200Mbits/sec. This is a result of the concentration of the trafficonto specific contents in 1060. The 1060 volume is in a veryhot state, and if it reaches its max., this can give bad influencesto the QoS you can provide to the users. As the bandwidthsof other volumes are relatively low, you can prevent that bycopying the contents of 1060. The load balancing algorithmof this study tried to solve such a problem. The standarddevitation in the bandwidth between the volumes is large at180Mbit/sec from 2 a.m. to 3 a.m. We took lowering thestandard deviations of the transmission bandwidth between thevolumes as the main objective of the iSCON algorithm.

B. Result

Fig. 6 shows the result when we ran the iSCON loadbalancing algorithm. The result with the algorithm appliedshows that it is not far lower than the average value of v1060,v1070 and v1080 volumes. In order to grasp the load balancingperformance, we got and compared the standard deviations.The average standard deviation with the algorithm not appliedis 121.25 Mbits/sec, while it is 51.31 Mbits/sec when thealgorithm is applied. We confirmed 57.7% of load balancingresult compared to the existing method.

As in Fig. 7, we carried out an experiment adding a newvolume, in order to examine the performance of the algorithmin more detail. The added volume is in a state of the bandwidthof 0. If the algorithm is run, the hot contents in the existingthree volumes are copied into the added volume, and thebandwidth quickly moves to the empty volume. We confirmed

Fig. 5: Original transferred bandwidth of volumes(v1060,v1070,v1080) in iShoot service on Feb. 13, 2011.

Fig. 6: Balanced bandwidth after applying iSCON load balac-ing algorithm

it quickly moved below 60%, which is the threshold set-upvalue. In order to examine the performance in accordancewith the running interval of the algorithm, we carried out theexperiment adjusting the running interval of the load balancingalgorithm. As in Fig. 8, we set the algorithm running intervalat two hours, one hour and five minutes and checked how fastthe transmission bandwidth of the volume 1060 got below thethreshold for the first six hours. In case of the five-minuteinterval, we can see it drops below the threshold quickly. Inorder to detect the high bandwidths of the volumes quickly,checking of the order of a minute is necessary.

VI. RELATED WORK

In order to improve the Quality of Service(QoS) ofvideo streaming, Content Delivery Networks(CDNs) have beenwidely chosen. In [7], they defined three different class ofvideo streaming service considering Service Level Agree-ment(SLA) and proposed bandwidth allocation and requestrouting algorithms for load balancing on CDN. In [8], theyimplemented redistribution algorithm and a redirection strategyin order that the traffic is concentrated to the edges of thenetwork thus providing less congested network and a better

Fig. 7: Load balancing after 3 empty volumes added(v1090,v1140,v1141)

Fig. 8: Adujusting algorithm execution interval (5min, 1hour,2hour)

utilization of the network resources. Another important ele-ment in forming a system through installing streaming serversis energy. These days, reducing the consumption of energy asmuch as possible is an important task, so studies are activelybeing made about this. In the study of [9], they implementeda storage system proportionate to energy through power-aware dynamic storage consolidation. They run the systemby collecting the load into a few storage sections throughcopying of contents and turning off the power to the othersections of storage, so that the system runs energy-efficientlyin accordance with the load. In the study of [10], they findout the optimum formation of SSD, SAS and SATA for astorage system, in terms of cost and energy, in accordancewith the I/O characteristics of data, on the basis of the lowenergy consumption characteristic of SSD. And they seekenergy efficiency by dynamically analyzing I/O characteristicsof data and deploying them to proper devices.

VII. CONCLUSION

As N-Screen video streaming services get active, basedon clouds, the portion of video traffic of mobile devices outof the total network traffic is rapidly increasing. As requests

for video contents increase, efficient management of videoresources has become an issue. From the analysis result ofactual logs of iShoot services, it was confirmed that requestsare concentrating on a few video contents. Such differencein the popularity of the contents causes the unbalance amongthe streaming servers with the resources. We designed iSCON(iShoot Content Management System) and implemented a loadbalancing algorithm to watch the states of the servers in realtime and efficiently distribute the load. The characteristics ofthe algorithm we implemented are 1) checking of the statesof the transmission bandwidth in the order of a minute, 2) theload distribution in which the difference in the transmissionbandwidth between streaming servers does not exceed themaximum of 50%, 3) the contents copying between streamingservers in consideration of the copy bandwidth. And weanalyzed the performance of the algorithm through diversesimulations. As a result, we confirmed that high load unbalanceamong existing servers is lowered by 57%.

REFERENCES

[1] YouTube, http://www.youtube.com.[2] Netflix, https://www.netflix.com.[3] iShoot, http://www.ishoot.co.kr.[4] G. Maier, A. Feldmann, V. Paxson, and M. Allman, “On dominant

characteristics of residential broadband internet traffic,” in Proceedingsof the 9th ACM SIGCOMM conference on Internet measurement con-ference. ACM, 2009, pp. 90–102.

[5] M. Cha, H. Kwak, P. Rodriguez, Y.-Y. Ahn, and S. Moon, “Analyzingthe video popularity characteristics of large-scale user generated contentsystems,” IEEE/ACM Transactions on Networking (TON), vol. 17, no. 5,pp. 1357–1370, 2009.

[6] J. Yoo, J. Kim, Y. Won, H. Kim, S. Park, and T. Ha, “Trafficcharacteristics of modern video streaming service.”

[7] S. Kim, S.-s. Seo, J.-M. Kang, G. Pujolle, and J.-K. Hong, “Autonomicresource allocation for video streaming services in content deliverynetworks,” in Global Information Infrastructure and Networking Sym-posium (GIIS), 2012. IEEE, 2012, pp. 1–4.

[8] S. Gramatikov, F. Jaureguizar, J. Cabrera, and N. Garcı́a, “Contentdelivery system for optimal vod streaming,” in Telecommunications(ConTEL), Proceedings of the 2011 11th International Conference on.IEEE, 2011, pp. 487–494.

[9] A. Verma, R. Koller, L. Useche, and R. Rangaswami, “Srcmap: Energyproportional storage using dynamic consolidation.” in FAST, vol. 10,2010, pp. 267–280.

[10] J. Guerra, H. Pucha, J. S. Glider, W. Belluomini, and R. Rangaswami,“Cost effective storage using extent based dynamic tiering.” in FAST,2011, pp. 273–286.