Develder, Chris

Jaumard, B

Wang, T

English

Ting Wang

Brigitte Jaumard

Chris Develder

Crossref

Anycast (re)routing of multi-period traffic in dimensioning resilient backbone networks for multi-site data centers

Ghent University Academic Bibliography

Anycast (re)routing of multi-period traffic indimensioning resilient backbone networks formulti-site data centersTing Wang1, Brigitte Jaumard1, Chris Develder21CSE, Concordia University, Montre´al (QC) H3G 1M8 Canada2INTEC – IBCN, Ghent University – iMinds, Ghent, BelgiumAbstractWe consider the problem of dimensioning resilient backbone networks for cloud-like scenarios wheredemand is to be served at one among several candidate data centers (DCs), and where that demandvaries over time, which we assume to be slotted. We thus consider multi-period traffic, for which we needto find routes to both a primary DC and a backup DC (in case the primary, or the network connectiontowards it, fails) and account also for synchronization traffic (following its own routes) between the twochosen DCs. We propose a path formulation and adopt a column generation approach: the (restricted)master problem (RMP) selects “configurations” to use for each demand in each of the time periods, whilepricing problems (PPs) construct new, potentially cost-reducing configurations for a given demand. Ourmodel allows for several PPs to be solved in parallel, and we demonstrate the time savings achieved bydoing so. We compare several anycast (re)routing strategies, where we allow traffic that spans multipleperiods to either (i) not be rerouted in different periods, (ii) only change the backup DC and routes, or(iii) freely change both primary and backup DC choices and routes towards them.Keywords: Network Virtualization; End-to-End Resilience; Cloud Computing; Anycast Resilience;Multi-period Virtual Network Mapping.1. IntroductionWith the proliferation of cloud computing, today’s businesses and end users increasingly rely on datacenters (DCs) that serve their applications and content. This evolution has been enabled by the underlyingoptical network technology [1], as it supports high bandwidths and low latencies. Because of the latter,the exact location of the data center does not matter much to the user it serves. Thus, to serve requests,service providers can adopt anycast routing: they may choose what particular DC to use among severalthat are distributed over multiple of their operating sites. Furthermore, this anycast principle can alsobe used for resiliency: if a failure affects either the DC or the (optical) network connection towards it,backup can be provided at an alternate location. Previous work has studied the potential benefits (interms of server and network resource capacity) of exploiting anycast in network dimensioning problemswith static traffic (e.g., [2]).The current work explicitly considers time-varying traffic (more specifically, we assume that routingand DC assignment can be revised at discrete points in time, i.e., for multiple consecutive periods amongwhich the volume of service requests may vary). We build on our latest work on this topic [3], andcontribute with (i) a new column generation model that is path-based (rather than link-based), (ii) anexploration of the effect of parallel execution of multiple so-called pricing problems (PPs), and (iii) moreextensive experiments that also consider variations in the choice of DC locations.2. Problem statement and mathematical model2.1. Problem statementWe consider a network dimensioning problem spanning multiple time periods, where we are given• The network topology, in terms of network nodes (e.g., OXCs) and links interconnecting them, as wellas the subset of nodes that host data centers (DCs), and• The service requests, with a given source node and the number of unit demands (where a unit representsan amount of bidirectional bandwidth to provide from the source to a DC to be chosen), that are startedin each of the consecutive discrete time periods. Each service request also has its specific duration (akaholding time) of 1 or more consecutive periods.1We then need to find for each request, and each time period it lasts, the routes from its source to a selectedDC, such that the total amount of required network resources (i.e., the bandwidth crossing each link,summed over all links) is minimized and each request remains operational under given failure scenarios.For the latter, we will require requests to be protected against single link or single DC failures.2.2. VNO-resilienceVNO-resiliencePIPVNOpiWpiBpiSvs dWdBFig. 1: The VNO-resilience scheme.We will adopt a VNO-resilience scheme to achieve that re-quirement. The idea thereof, as previously described in,e.g., [3], is sketched in Fig. 1: it provides 1:1 protection rout-ing in the VNet for network failures, where the working andprotection paths of a service have to be physically link/nodedisjoint. The working path (piw) routes the services fromtheir source node (vS) towards the primary DC (dw), theprotection path (pib) towards the backup DC (db), while piwand pib are disjoint in their physical layer mapping. In ad-dition, a synchronization path (pis) is established in orderto handle migration and failure routing requirements whena DC failure occurs: services then need to be rerouted fromthe primary dw to backup db. Further, we assume that thereis an automatic switch-back to the original network path andDC once a fault is repaired, and therefore we allow reusingthe same network/DC capacity to protect against other fail-ures: backup capacity is shared. Under the assumptions that (A1) the backup DC has a different locationthan the primary DC, (A2) piw and pib are link disjoint and, (A3) piw and pis are link disjoint, protectionis guaranteed against any single link failure and any single DC failure.2.3. Mathematical modelWe here describe only the general ideas of our column generation model, the actual formulas can befound in, e.g., [4] (which is available upon request from the authors). Following the general columngeneration approach, the overall optimization problem is split into a (restricted) master problem (RMP),and a pricing problem (PP). The RMP’s task is to find the optimal combination out of a set of candidate“configurations”, C, while the PP’s task is to find/create new configuration(s) that, when added to thepool C for the RMP leads to a solution with a better objective value. More concretely, a “configuration”in our model is associated with a given source node vs, and comprises a set of three paths as sketchedin Fig. 1: one primary path piw originating at vs towards a primary data center dw, one backup path piboriginating at vs towards a primary data center db, and one synchronization path pis between the primaryand the backup data center.Compared to [3], our new model improves scalability by (i) aggregating all unit demands from a singlesource node and with the same holding time into a single request, and (ii) check for reconfigurations(which we want to minimize, as a secondary objective next to the total amount of network resources)based on paths rather than links. For details, we refer to [4, Section 4.4].3. Solution strategy: Serial vs parallelFor our given column generation model, we have various options to decide what PP(s) to solve and findnew configuration(s) to add before solving the RMP (with an extended configuration set) again. Onestrategy is to add one new configuration at a time (for a selected source node, e.g., in round robin fashion).Alternatively, we can solve multiple PPs in parallel (e.g., one for each different source node). We willexplore the benefits of such a parallel strategy, sketched in Fig. 2.2RMP Selection of the best configurationsSolve PP(v1,t)Solve PP(v2,t)Solve PP(vn,t)……At least one node with a negative reduced cost for  time period tLP is optimally solved  Values of the dual variablesAt least one new promising configuration cv for requests on node v(check all cv against all the other previously generated configurations in order to avoid duplicating configurations. If there is new path π in the generated configurations, add π into path set. And goes to next time period.)YESNOAll t unsuccessfully testedYESNOFig. 2: The parallel column generation solution scheme.4. Case study4.1. Experiment setupWe consider a 24-node US network topology, with 43 undirected links, as illustrated in Fig. 3. Given thatwe adopt anycast routing, traffic is specified in terms of it source only. The amount of traffic generatedvaries in terms of time-of-day (i.e., period), as well as per region (which are assumed to have distinct,artificial time zones). The split of the total traffic volume across the various regions is as follows: (i) forthe 3-region case, 33.3% originates from Region 1, 37.5% from Region 2, and the remaining 29.2% fromRegion 3, (ii) for the 4-region case, 29.2% originates from Region 1, 16.6% from Region 2, 25% fromRegion 3, and 29.2% from Region 4. For a given Region, the traffic varies during the day, with 48% of theRegion’s traffic in 8 am–4 pm, 38% in 4 pm–12 am, and the remaining 14% from 12 am–8 am. The volumeof traffic, generated in one of the 3 time periods and a given Region, is further divided in a portion thatjust lasts that single period and the other portion that will continue into the next period. We considerthree patterns, with respectively 20%, 50% or 80% of two-period traffic.4.2. Resource savingsThe first and foremost research question we wanted to address is: What bandwidth savings can weachieve by allowing rerouting (part of) the traffic from one period to the next? Qualitatively, we indeeddo expect to see potential (overall) bandwidth savings if we are more flexible, i.e., if we go from ScenarioI (no rerouting allowed), over Scenario II (allow changes in backup and/or synchronization paths), toScenario III (also allow to change the primary working path from one period to the next). Intuitively,we expect to see potentially more substantial savings if the volume of the traffic that we are allowed toreroute increases (e.g., going from Pattern #1, with just 20% of two-period traffic, to Pattern #2 with80% two-period traffic). The experiments investigate such savings quantitatively, for the two networktopologies we defined above.Figure 4 shows the relative difference in bandwidth requirements for the various rerouting scenarios.From these numerical results, we learn that, compared to the baseline Scenario I, the total bandwidthcost is reduced with on average 5.1% (resp. 6.4%) for Scenario II (resp. Scenario III) with traffic Pattern#1, and by 6.9% (resp. 8.2%) with Pattern #2 (where the average is taken over all traffic volumes). This312 63478 10141317182423221611152120199 1210001000100010001000100010001000100010001100110011501200120012001200130013001400190026009009009009509508008508501000800800800800850900250600300700600650Region 1 Region 2 Region 35(a) 3-Region topology12 63478 10141317182423221611152120199 1210001000100010001000100010001000100010001100110011501200120012001200130013001400190026009009009009509508008508501000800800800800850900250600300700600650Region 1 Region 2 Region 4Region 3(b) 4-Region topologyFig. 3: US network topology with the assumed regions and data center locations indicated with a star.net saving mainly stems from a reduction of bandwidth for the backup paths, due to increased sharing:we note an average reduction of the backup bandwidth cost of 11.5% (resp. 13.4%) for Pattern #1(with 20% two-period traffic) and 14.2% (resp. 16.3%) for Pattern 2 (with 80% two-period traffic), whenonly changing backup/sync paths, i.e., Scenario II (resp. Scenario III, where also the working route canchange). We found that these savings do not require all two-period traffic requests to change their routingwhen going from one period to the next, but only about half of them. Further, these preliminary resultssuggest that the cost reduction (in terms of bandwidth requirements) can be achieved by only changingthe backup/synchronization paths when we consider multiple time periods together (Scenario II): Theadditional advantage of allowing also the working path to be changed (i.e., the extra benefit of Scenario IIIcompared to Scenario II) is much smaller.The net savings for this particular case study are modest, but non-negligible for this 3-Region casestudy. When we move to the more extreme 4-Region case (see Fig. 4b) the savings are a bit higher: wenow find savings from rerouting that amount to up to around 10% of the total bandwidth requirementsof the no-rerouting Scenario I. Note that these maximal savings are obtained in the 50% two-periodtraffic scenario. If the portion of two-period traffic increases further (e.g., the 80% two-period trafficcase), savings go down. The intuition behind this observed behavior is that savings are realized by wiselychoosing backup paths to increase sharing: the amount of traffic that we can share with more freely with(i.e., the next period’s newly generated one-period traffic) goes down when going from 50% to 80% oftwo-period traffic, and so do the savings.4.3. Benefit of parallellizationTo assess the performance impact of our parallel algorithm (as sketched in Fig. 2), we compared it with astraightforward serial strategy. Results are plotted in Fig. 5, where we plot the running time in functionof the number of executed rounds. We define a “round” as attempting to find a new configuration for eachsource node (by solving the corresponding pricing problems, PPs). In the Parallel scheme, we re-solvethe RMP only after adding all new configurations found by the PPs (that are executed in parallel): oneround comprises 1 restricted master problem (RMP) and for each source node one PP. In the Serial case,we solve one PP at a time, and re-solve the RMP each time we found a new configuration: one roundthus comprises multiple RMPs (1 for each source node where the PP found a new configuration). Sincewe have in the order of 20 source nodes in our topology, we find that the time per individual roundlies about a factor 20 higher for the Serial strategy compared to Parallel. In terms of the number ofrounds required by the column generation algorithm to finish (i.e., none of the PPs finds a new, betterconfiguration), the Parallel strategy takes more iterations: in our case study the number of rounds liesabout 20% higher for Parallel compared to Serial (thus, the graphs for Serial stop at a lower number ofrounds in Fig. 5). Still, the benefit in absolute wallclock time (i.e., the time a user needs to wait beforefinding the final solution) is substantial: the cumulative time over all rounds until completion lies about18 times lower for Parallel.420% two−period, total 20% two−period, backup 20% two−period, sync 20% two−period, working80% two−period, total 80% two−period, backup 80% two−period, sync 80% two−period, working−6%−4%−2%0%−15%−10%−5%0%−6%−4%−2%0%−1%0%1%2%3%4%−7.5%−5.0%−2.5%0.0%−15%−10%−5%0%−8%−6%−4%−2%0%0.0%0.2%0.4%0.6%50 100 150 200 50 100 150 200 50 100 150 200 50 100 150 20050 100 150 200 50 100 150 200 50 100 150 200 50 100 150 200Traffic volumeRelative cost differenceScenario I(no changes)Scenario II(change only backup and/or sync)Scenario III(change working, backup and/or sync)(a) 3-Region topology20% two−period, total 20% two−period, backup 20% two−period, sync 20% two−period, working80% two−period, total 80% two−period, backup 80% two−period, sync 80% two−period, working−8%−6%−4%−2%0%−15%−10%−5%0%−6%−4%−2%0%0%1%2%3%−10.0%−7.5%−5.0%−2.5%0.0%−20%−15%−10%−5%0%−6%−4%−2%0%0%1%2%3%50 100 150 200 50 100 150 200 50 100 150 200 50 100 150 20050 100 150 200 50 100 150 200 50 100 150 200 50 100 150 200Traffic volumeRelative cost differenceScenario I(no changes)Scenario II(change only backup and/or sync)Scenario III(change working, backup and/or sync)(b) 4-Region topologyFig. 4: The bandwidth requirements for time-varying traffic, for different traffic patterns and topologies.Traffic volume is expressed in number of unit requests.5cumulative per round050000100000150000010002000300040000 20 40 60 0 20 40 60roundtime (s)ParallelSerialFig. 5: Running times over subsequent rounds of the column generation algorithm, cumulative up to thecurrent round (left) as well as per individual round (right).5. ConclusionWe presented a new column generation model to solve a multi-period traffic dimensioning problem forresilient backbone networks for multi-site data centers. From the results presented above, the observationspertaining to bandwidth savings can be summarized as follows:• The reduction of bandwidth requirements mainly stems from savings in bandwidth for backup paths(because of increased sharing with the requests starting in the 2nd period of two-period requests).• A part of that backup capacity savings is lost due to longer working : these longer working paths arechosen to allow more sharing of backup capacity.• When the working paths are allowed to be rerouted (Scenario III), the bandwidth saving is better thanthe situation that only backup paths can be rerouted (Scenario II). But the difference is not significant.• The bandwidth savings from rerouting for the 3-Region topology amounts to less than 10% (in Sce-nario III, and slightly less for Scenario II).Furthermore, we also showed that by adopting a parallel pricing problem (PP) solving strategy, we canrealize a substantial amount of (wall clock) time. That overall saving is mainly caused by the reductionof the number of times that the (restricted) master problem (RMP) is solved: each iteration, multipleconfigurations (from the multiple PP solutions) are added, and moreover these PPs are solved in parallel.ACKNOWLEDGMENTB. Jaumard has been supported by a Concordia University Research Chair (Tier I) and by an NSERC(Natural Sciences and Engineering Research Council of Canada) grant.REFERENCES[1] C. Develder, M. De Leenheer, B. Dhoedt, M. Pickavet, D. Colle, F. De Turck, and P. Demeester,“Optical networks for grid and cloud computing applications,” Proc. IEEE, vol. 100, no. 5, pp. 1149–1167, May 2012.[2] C. Develder, J. Buysse, B. Dhoedt, and B. Jaumard, “Joint dimensioning of server and networkinfrastructure for resilient optical grids/clouds,” IEEE/ACM Trans. Netw., vol. 22, no. 5, pp. 1591–1606, Oct. 2014.[3] T. Wang, B. Jaumard, and C. Develder, “A scalable model for multi-period virtual network mappingfor resilient multi-site data centers,” in Proc. 17th Int. Conf. Transparent Optical Netw. (ICTON2015), Budapest, Hungary, 5–9 Jul. 2015, pp. 1–8.[4] T. Wang, “Time-varying resilient virtual networking mapping for multi-location cloud data centers,”Master’s thesis, Concordia University, Montreal, Canada, 2016.6

https://biblio.ugent.be/publication/8159334/file/8159335

Anycast (re)routing of multi-period traffic in dimensioning resilient backbone networks for multi-site data centers

Abstract

Similar works

Full text

Available Versions

Crossref

Ghent University Academic Bibliography