ElasticVirtualNetworkFunctionPlacementCloudNet 2015M.GHAZNAVI , A. KHAN, N . SHAHRIAR , KH. ALSUBHI , R . AHMED, R . BOUTABADAVIDR . CHER ITON SCHOOLOFCOMPUTER SC IENCE

UNIVERSITYOFWATERLOO

OutlineIntroduction

StateoftheArt

Problem:ElasticVirtualNetworkFunctionPlacement

Solution:SimpleLazyFacilityLocation

Evaluation

Conclusion

2 /30

IntroductionMIDDLE-BOXESNETWORKFUNCT IONVIRTUALIZAT ION

VNF SERVICESIN CLOUD

3 /30

Middle-Boxes“anyintermediarydeviceperformingfunctionsotherthanthenormal,standardfunctionsofanIProuteronthedatagrampathbetweenasourcehostanddestinationhost”[1]

Expensive hardware

Hard todeploy

Hard tomodify

Hard toscale

Provisionforpeak-load

[1]CARPENTER,B.,ANDBRIM,S.Middleboxes:TaxonomyandIssues.RFC3234,https://tools.ietf.org/rfc/rfc3234.txt,2002.[2]V.Sekar,N.Egi,S.Ratnasamy,M.K.Reiter,andG.Shi.Designandimplementationofaconsolidatedmiddlebox architecture.InProceedingsofNSDI12,2012.

𝑠𝑟𝑐 𝑡𝑟𝑔𝑚

Sourcehost

Middle-box

DestinationhostIDSFirewallIPS…

for in-network capabilities [9]. The lack of extensibil-ity in middleboxes today inevitably leads to further ap-pliance sprawl, with associated increases in capital andoperating expenses.

Despite these concerns, administrators reiterated thevalue they find in such appliances, particularly in sup-porting new applications (e.g., teleconferencing), in-creasing security (e.g., IDS), and improving performance(e.g., WAN optimizers).

3 CoMb: Overview and OpportunitiesThe previous discussion shows that even though middle-boxes are a critical part of the network infrastructure,they remain expensive, closed platforms that are diffi-cult to extend, and difficult to manage. This motivates usto rethink how middleboxes are designed and managed.We envision an alternative architecture, called CoMb,wherein software-centric implementations of middle-box applications are consolidated to run on a sharedhardware platform, and managed in a logically central-ized manner.

The qualitative benefits of this proposed architectureare easy to see. Software-based solutions reduce the costand development cycles to build and deploy new mid-dlebox applications (as independently argued in paral-lel work [12]). Consolidating multiple applications onthe same physical platform reduces device sprawl; wealready see early commercial offerings in this regard(e.g., [3]). Finally, the use of centralization to simplifynetwork management is also well known [31, 21, 15].

While the qualitative appeal is evident, there are prac-tical concerns with respect to efficiency. Typically, mov-ing from a specialized architecture to one that is moregeneral and extensible results in less efficient resourceutilization. However, as we show next, CoMb introducesnew efficiency opportunities that do not arise with to-day’s middlebox deployments.

3.1 Application multiplexingConsider a WAN optimizer and IDS running at an enter-prise site. The former optimizes file transfers betweentwo enterprise sites and may see peak load at night whensystem backups are run. In contrast, the IDS may seepeak load during the day because it monitors users’ webtraffic. Suppose the volumes of traffic processed by theWAN optimizer and IDS at two time instants t1, t2 are10,50 packets and 50,10 packets respectively. Todayeach hardware device must be provisioned to handle itspeak load resulting in a total provisioning cost corre-sponding to 2 ⇤ max{10,50} = 100 packets. A CoMbbox, running both a WAN optimizer and the IDS on thesame hardware can flexibly allocate resources as the loadvaries. Thus, it needs to be provisioned to handle thepeak total load of 60 packets or 40% fewer resources.

0

0.2

0.4

0.6

0.8

1

0

7

-

0

9

,

0

6

:

0

0

0

7

-

0

9

,

1

7

:

0

0

0

7

-

1

0

,

0

4

:

0

0

0

7

-

1

0

,

1

5

:

0

0

0

7

-

1

1

,

0

2

:

0

0

Norm

alized utilization

Time (mm-dd,hr)

WAN optimizer

Proxy

Load Balancer

Firewall

Figure 1: Middlebox utilization peak at different times

Session'Management'

Protocol'Parsers'

VPN WanOpt IDS Proxy

Firewall

Figure 2: Reusing lower-layer software modules acrossmiddlebox applications

Figure 1 shows a time series of the utilization of fourmiddleboxes at an enterprise site, each normalized by itsmaximum observed value. Let NormUtiltapp denote thenormalized utilization of the device app at time t. Now,to quantify the benefits of multiplexing, we compare thesum of the peak utilizations Âapp maxt{NormUtiltapp}= 4and the peak total utilization maxt{Âapp NormUtiltapp}=2.86. For the workload shown in Figure 1, multiplexingrequires 4�2.86

4 = 28% fewer resources.

3.2 Reusing software elementsEach middlebox typically needs low-level modules forpacket capture, parsing headers, reconstructing sessionstate, parsing application-layer protocols and so on. Ifthe same traffic is processed by many applications—e.g.,HTTP traffic is processed by an IDS, proxy, and an appli-cation firewall—each appliance has to repeat these com-mon actions for every packet. When these applicationsrun on a consolidated platform, we can potentially reusethese basic modules (Figure 2).

Consider an IDS and proxy. Both need to recon-struct session- and application-layer state before runninghigher-level actions. Suppose each device needs 1 unitof processing per packet. For the purposes of this ex-ample, let us assume that these common tasks contribute50% of the overall processing cost. Both appliances pro-cess HTTP traffic, but may also process traffic uniqueto each context; e.g., IDS processes UDP traffic whichthe proxy ignores. Suppose there are 10 UDP packetsand 45 HTTP packets. The total resource requirement is(IDS = 10+45)+ (Proxy = 45) = 100 units. The setup

Middle-box utilizationpeakatdifferenttimes[2]

4 /30

NetworkFunctionVirtualizationVirtualization(Softwarization)ofmiddle-boxes

Softwaremiddle-boxesarecalledVirtualNetworkFunction(VNF)

NFV”involvestheimplementationofnetworkfunctionsinsoftware thatcanrunonarangeofindustrystandardserverhardware,andthatcanbemoved to,orinstantiated in,variouslocationsinthenetworkasrequired,withouttheneedforinstallationofnewequipment.”[1]

[1]"NetworkFunctionsVirtualization".ISGwebportal:https://portal.etsi.org/nfv/nfv_white_paper.pdf

𝑣𝑠𝑟𝑐 𝑡𝑟𝑔

Sourcehost

VNF

Targethost

5 /30

NetworkFunctionVirtualizationMIDDLE-BOXES

Expensive hardware

Hard todeploy

Hard tomodify

Hard toscale

Provisionforpeak-load

VIRTUALNETWORKFUNCTIONS

Low-costsoftware

Easy todeploy

Easy tomodify

Easy toscale

Scaleresourcesondemand

6 /30

VNFServicesinCloudOfferedbycloudproviders◦ IBMBluemix◦ MicrosoftAzure◦ AmazonEC2

Services◦ RiverbedSTEELHEADWANoptimizer [1]◦ McAfeeNextGenerationfirewall[2]◦ VirtualLoadMaster loadbalancer[3]

[1]http://media-cms.riverbed.com/documents/Spec+Sheet+-+Steelhead+Family+-+05.06.2015.pdf[2] https://kc.mcafee.com/resources/sites/MCAFEE/content/live/PRODUCT_DOCUMENTATION/25000/PD25151/en_US/NGFW_57_HW_Requirements.pdf[3] http://kemptechnologies.com/files/downloads/documentation/Datasheets/VLM-AWS.pdf

Client Cloud-Provider

VNFServiceRequest

7 /30

VNFServicesinCloudWHATCLOUDPROVIDERSHOULDSUPPORT

Payperuse◦ Clientspayonly forrealusedresources

Elasticity◦ Scaleresourcesondemand◦ Uponarrivalordepartureofservicerequest◦ Variationofworkloadofadmittedservicerequest

CHALLENGESOFCLOUDPROVIDER

MinimizingCosts:◦ Trade-off betweenHost&BandwidthResources

Elasticity◦ Whichmechanismstoapply◦ Elasticitybenefitvs.itsoverhead

8 /30

VNFServicesinCloudWhere toplaceVNFinstances?

Whichrequestmustbeassigned towhichVNFinstance?

𝑠𝑟𝑐( 𝑡𝑟𝑔(

𝑠𝑟𝑐)

𝑡𝑟𝑔) 𝑠𝑟𝑐* 𝑡𝑟𝑔*𝑠𝑟𝑐+ 𝑡𝑟𝑔+

𝑣 VNF instance

𝑠𝑟𝑐 Source of Service Traffic

𝑡𝑟𝑔 Target of Service Traffic

Network Switch

Host

9 /30

VNFServicesinCloudAsolutioncanbe◦ 𝑣) servesthefirstandsecondservicetraffics◦ 𝑣( servesthethirdandforthservicetraffics

𝑠𝑟𝑐( 𝑡𝑟𝑔(

𝑠𝑟𝑐)

𝑡𝑟𝑔) 𝑠𝑟𝑐* 𝑡𝑟𝑔*𝑠𝑟𝑐+ 𝑡𝑟𝑔+

𝑣) 𝑣(

𝑣 VNF instance

𝑠𝑟𝑐 Source of Service Traffic

𝑡𝑟𝑔 Target of Service Traffic

Network Switch

Host

10 /30

StateoftheArtCOMPARISONOFSTATEOFTHEART

11 /30

ComparisonofStateoftheArtPaper HostRes.Cost BandwidthRes. Cost Elasticity

ElasticVirtualNetwork FunctionPlacement(EVNFP) ✔ ✔ ✔

ElasticityinCloud [1,2,3] ✔ ✕ ✔

Dynamic VMPlacement[2,4] ✔ ✕ ✔

NetworkAwareVM Placement[5,6,7] ✔ ✔ ✕

VirtualDPIPlacement[8] ✔ ✔ ✕

[1]Z.Gong,X.Gu,andJ.Wilkes.Press:Predictiveelasticresourcescalingforcloudsystems.InIEEECNSM,2010[2]U.Sharma,P.Shenoy,S.Sahu,andA.Shaikh.Acost-awareelasticityprovisioningsystemforthecloud.InIEEEICDCS2011.[3] Z.Shen,S.Subbiah,X.Gu,andJ.Wilkes.Cloudscale:Elasticresourcescalingformulti-tenantcloudsystems.InACMSoCC,2011.[4] A.Verma,P.Ahuja,andA.Neogi.pmapper:Powerandmigrationcostawareapplicationplacementinvirtualizedsystems.InACM/IFIP/USENIXMiddleware,2008.[5]O.Biranetal.A stablenetwork-awarevm placementforcloudsystems.InCCGRID,pages498–506,2012.[6] V.Mann,A.Kumar,P.Dutta,andS.Kalyanaraman.Vmflow:Leveragingvm mobilitytoreducenetworkpowercostsindatacenters.InIFIPNETWORKING,2011.[7] X.Meng,V.Pappas,andL.Zhang.Improvingthescalabilityofdatacenternetworkswithtraffic-awarevirtualmachineplacement.InIEEEINFOCOM,2010.[8]M.Bouet,J.Leguay,andV.Conan.Cost-basedplacementofvdpi functionsinnfv infrastructures.InNetSoft,2015.

12 /30

Problem:ElasticVirtualNetworkFunctionPlacement(EVNFP)SCOPEANDASSUMPTIONSCONFLICT ING OBJECT IVES

ELAST IC ITYMECHANISMSANDOVERHEAD

13 /30

ScopeandAssumptionsSCOPE

Singlecloudprovider

Singledata-center

Centralizedoptimization

ASSUMPTIONS

OneVNFinstance-type

Multi-tenancy

ElasticityMechanisms◦ HorizontalScaling◦ MigrationofVNFinstances◦ Reassignmentofworkload

14 /30

ConflictingObjectivesMinimizingthebandwidthcost,and

MinimizingthenumberofinstalledVNFs

𝑠𝑟𝑐( 𝑡𝑟𝑔(

𝑠𝑟𝑐)

𝑡𝑟𝑔) 𝑠𝑟𝑐* 𝑡𝑟𝑔*𝑠𝑟𝑐+ 𝑡𝑟𝑔+

𝑣 VNF instance

𝑠𝑟𝑐 Source of Service Traffic

𝑡𝑟𝑔 Target of Service Traffic

Network Switch

Host

15 /30

ConflictingObjectivesMinimizingthebandwidthcost:◦ 12 UnitofBandwidthover12 Links◦ 4 VNFinstances

𝑠𝑟𝑐( 𝑡𝑟𝑔(

𝑠𝑟𝑐)

𝑡𝑟𝑔) 𝑠𝑟𝑐* 𝑡𝑟𝑔*𝑠𝑟𝑐+ 𝑡𝑟𝑔+𝑣)

𝑣+𝑣( 𝑣*

𝑣 VNF instance

𝑠𝑟𝑐 Source of Service Traffic

𝑡𝑟𝑔 Target of Service Traffic

Network Switch

Host

16 /30

ConflictingObjectivesMinimizingthenumberofinstalledVNFs◦ 1VNFinstance◦ 34 UnitofBandwidthover20 Links

𝑠𝑟𝑐( 𝑡𝑟𝑔(

𝑠𝑟𝑐)

𝑡𝑟𝑔) 𝑠𝑟𝑐* 𝑡𝑟𝑔*𝑠𝑟𝑐+ 𝑡𝑟𝑔+

𝑣)

𝑣 VNF instance

𝑠𝑟𝑐 Source of Service Traffic

𝑡𝑟𝑔 Target of Service Traffic

Network Switch

Host

17 /30

ElasticityMechanismsandOverheadMECHANISMS

HorizontalScalingofVNFinstance◦ Installing anewVNFinstance◦ RemovinganexistingVNFinstance

MigrationofaVNFinstance

Reassignment ofworkloadtoanotherVNFinstance

OVERHEAD

Migration overhead

Reassignment overhead

18 /30

ElasticityMechanismsandOverhead

�

����

����

���

����

����

���

�

����

���

���

����

���

���

��

�

����

���

����

���

��

�

���� ������

�

����

����

VNF instance

Source of service traffic �

Target of service traffic �

Service traffic increase

Service traffic decrease

InitialPlacement

Migrationof𝑣

𝑣∗ InstallationandReassignment

Removing𝑣

1 2

3 4

19 /30

Solution:SimpleLazyFacilityLocation(SLFL)IDEA

SLFL:SIMPLELAZYFACILITYLOCATION

20 /30

IdeaArrivalanddepartureofarequest,orworkloadvariationalterthelocality

SLFLlocallyoptimizes theplacementofVNFinstancesinagreedymanner

𝑠𝑟𝑐( 𝑡𝑟𝑔(

𝑠𝑟𝑐)

𝑡𝑟𝑔) 𝑠𝑟𝑐* 𝑡𝑟𝑔*𝑠𝑟𝑐+ 𝑡𝑟𝑔+

𝑣) 𝑣(

𝑣 VNF instance

𝑠𝑟𝑐 Source of Service Traffic

𝑡𝑟𝑔 Target of Service Traffic

Network Switch

Host

𝑠𝑟𝑐*

𝑡𝑟𝑔*

21 /30

SLFL:SimpleLazyFacilityLocationUPONREQUESTARRIVALORWORKLOADINCREASEInstallationpotential◦ Installing aVNFinstance◦ Setofreassignments◦ Thedifferenceofoperationalcostbefore andafter installing theVNFinstanceandreassignments

Migrationpotential◦ Migration ofaVNFinstance◦ Thedifference ofoperationalcostbefore andafter migrationoftheVNFinstance

UPONREQUESTDEPARTUREORWORKLOADDECREASERemovingpotential◦ Removing aVNFinstance◦ Setofreassignments◦ Thedifference ofoperationalcostbefore andafter removingtheVNFinstanceandreassignments

Emigrationpotential◦ Migration ofaVNFinstance◦ Thedifference ofoperationalcostbefore andafter migrationoftheVNFinstance

22 /30

SLFL:SimpleLazyFacilityLocationUPONREQUESTARRIVALORWORKLOADINCREASEApplythebestactionamong:◦ InstallingaVNFinstance◦ Considering theinstallationpotential

◦ MigratingaVNFinstance◦ Considering themigrationpotentialoftheVNFinstance

◦ Assign tooneofexistingVNFs◦ Considering bandwidthcost

UPONREQUESTDEPARTUREORWORKLOADDECREASEApplythebestactionamong:◦ RemovingaVNFinstance◦ Considering theinstallationpotential

◦ MigratingaVNFinstance◦ Considering theemigrationpotentialoftheVNFinstance

23 /30

EvaluationEXPERIMENTALSETUPANDOBJECT IVESACCEPTANCERAT IOANDOPERAT IONALCOST

RESOURCEUT ILIZAT ION

24 /30

ExperimentalSetupandObjectivesEXPERIMENTALSETUP

Network◦ Fat-treeof99nodes◦ 54hostswith8CoreCPU◦ 1GBfullbisectionbandwidth

VNF◦ BroIDS[2]:80Mbps,1vCPU,1GBofmemory

Requests◦ 20,000requests◦ Arrival:Poissondistribution◦ Duration:Exponentialdistribution

OBJECTIVES

Evaluating◦ Theacceptanceratio◦ Operationalcost◦ Balancingbandwidth andhostresourcecosts

◦ ResourceUtilization◦ Balancingbandwidth andhostresourceutilization?

Comparisonto◦ RandomPlacement◦ First-FitPlacement

25 /30

AcceptanceRatioandOperationalCostACCEPTANCERATIO TOTALOPERATIONALCOST

0500

0100

00150

00200

00250

00300

00350

00400

00

Time (s)

0

20

40

60

80

100RandomSLFLFirstFit

0500

0100

00150

00200

00250

00300

00350

00400

00

Time (s)

0

20

40

60

80

100

120

140

Cos

t(¢p

er20

0se

c.) Random

SLFLFirstFit

SLFLaccepts~2×workloadvsbasicalgorithmsSLFL 97% acceptanceratioRandom 48% acceptanceratioFirstFit 45% acceptanceratio

SLFLaccepts~2×workloadwithlesscost9%operationalcost lessthanRandom4% operationalcostlessthanFirstFit

26 /30

ResourceUtilizationBANDWIDTHRESOURCEUTILIZATION HOSTRESOURCEUTILIZATION

0500

0100

00150

00200

00250

00300

00350

00400

00

Time (s)

0

20

40

60

80

100RandomSLFLFirstFit

0500

0100

00150

00200

00250

00300

00350

00400

00

Time (s)

0

20

40

60

80

100RandomSLFLFirstFit

82% Utilizationofbandwidth resources91% Utilizationofhostresources

27 /30

ConclusionSUMMARY

28 /30

SummaryElasticVirtualNetworkFunctionProblem◦ Bandwidthandhostresourcescosttrade-off◦ ElasticityOverhead

SimpleLazyFacilityLocation◦ Balancingthebandwidthandhostresourcecosttrade-off◦ Carefullyselectingthecorrectelasticitymechanisms◦ Optimizing theelasticityoverhead◦ Accepting~2× workloadvsbasicalgorithms

29 /30

30

AcceptanceRatioandResourceUtilization

BandwidthResourceUtil.

VNFsUtil.

0500

0100

00150

00200

00250

00300

00350

00400

00

Time (s)

0

20

40

60

80

100RandomSLFLFirstFit

0500

0100

00150

00200

00250

00300

00350

00400

00

Time (s)

0

20

40

60

80

100RandomSLFLFirstFit

0500

0100

00150

00200

00250

00300

00350

00400

00

Time (s)

0

20

40

60

80

100RandomSLFLFirstFit

AcceptanceRatioHostResourceUtil.

0500

0100

00150

00200

00250

00300

00350

00400

00

Time (s)

0

20

40

60

80

100RandomSLFLFirstFit

OperationalCost

0500

0100

00150

00200

00250

00300

00350

00400

00

Time (s)

0

20

40

60

80

100

120

140

Cos

t(¢p

er20

0se

c.) Random

SLFLFirstFit

0500

0100

00150

00200

00250

00300

00350

00400

00

Time (s)

0

20

40

60

80

100

120

140

Cos

t(¢p

er20

0se

c.) Random

SLFLFirstFit

0500

0100

00150

00200

00250

00300

00350

00400

00

10−5

10−4

10−3

10−2

10−1

100

101

¢per

200

sec.

ReassignmentMigration

0500

0100

00150

00200

00250

00300

00350

00400

00

Time (s)

0

20

40

60

80

100

120

140

Cos

t(¢p

er20

0se

c.) Random

SLFLFirstFit

TotalOperationalCost

BandwidthResourceCost

HostResourceCost

ElasticityOverheadCost

Assumptions-HorizontalScalingWhyhorizontalscalingandignoringverticalscaling◦ Ontheflyverticalresourcescalingisnotsupported inmostcases◦ Mightrequiresystemreboot◦ SLAviolation

Assumptions-OneVNFinstance-typeScenario Onesmall flavor Multiple flavors

ResourceConsumption

Host Res. ~ - Worse +Better

BandwidthRes. ~ +Better - Worse

Elasticity

Installation Ina samemachine +Better - Worse

Removal Ina samemachine +Better - Worse

Migrationoverhead ~ +Better - Worse

Reassign. overhead ~ =Equal =Equal