Probabilistic-Bandwidth Guarantees with Pricing in Data-Center Networks Dinil Mon Divakaran ([email protected]), Mohan Gurusamy ([email protected]) Department of Electrical and Computer Engineering, National University of Singapore Abstract—Bandwidth-sharing in data-center networks is an important problem that affects the growth of multi-tenant datacenters. A promising solution approach is the use of advance reservations. Such systems are usually based on deterministic models, assuming users to have precise knowledge of bandwidth they require, which is unlikely. This work takes a deviation and proposes a probabilistic model, where bandwidth requirements are specified along with some probabilities. As user-estimate of bandwidth depends on the cost they incur, we tie up the model with differential pricing; and formulate bandwidth allocation as a two-phase—static and dynamic—optimization problem. We show that the problem in each phase is NP-hard. We develop a bandwidth-allocator that processes requests and defines bandwidth profiles for accepted requests by solving the optimization problems. Numerical studies show that, in comparison to the deterministic model, our model brings down the number of rejected requests significantly, while allocating more bandwidth and thereby increasing revenue for providers. Keywords—data-center, bandwidth, reservation, pricing

I.

I NTRODUCTION

An important resource in a data-center is the network bandwidth, required for communication between VMs (virtual machines) of a tenant. Lack of bandwidth guarantees, even while computing and storage resources are guaranteed, can severely impact the performance of applications running on VMs in a data-center [2]. A promising approach for guaranteeing predictable performance is to use advance bandwidthreservations to allocate bandwidth to competing tenants. In a system with advance reservation, a user submits request for bandwidth between two end-hosts, specifying a start-time and duration for the reservation. An admission-controller decides on the admission of each request depending on the available bandwidth along the paths, and allocates the specified bandwidths respecting the time constraints for accepted requests. Bandwidth reservation suits data-centers, as they (unlike the Internet) are under single administrative controls, besides having small (and often fixed) number of hops between servers. But a disadvantage with traditional reservation systems persists in data-centers too—users may not really be able to predict, both, the amount of bandwidth they require for communication between VMs, as well as the exact duration of bandwidthrequirement. Instead, tenants may have a good estimate of the minimum bandwidth they require, and a rough estimate of, both, the additional bandwidth required as well as the duration of the request. Importantly, the additional bandwidth specified by a tenant is tied up with the pricing of the bandwidth. Envisioning bandwidth-reservation capabilities in future data-centers [6], this work takes steps to tackle the problems facing adaptation of advance bandwidth-reservation in

data-center networks. We propose a model for probabilisticbandwidth guarantees between VMs of tenants (Sec. II), wherein, a tenant requests not only a minimum bandwidth from one VM to another, but also a probabilistic bandwidth, for an estimated duration. In the process, we also introduce differential pricing for probabilistic bandwidth. To elaborate, R is a set of requests, where each r ∈ R corresponds to a bandwidth-reservation request from one VM, say ur , to another VM, say v r , of a tenant. A request r specifies a minimum bandwidth brm , probabilistic bandwidth brp , with probabilities q1r , q2r (q2r ≥ q1r ) associated with brp , an estimated duration E r , and a pricing policy (chosen from a pre-defined list made available by the provider). The provider is to guarantee to the user of an accepted request r, brm units of bandwidth (from ur to v r ) as long as the request is active, besides allocating brp units with a probability between q1r and q2r depending on the pricing policy chosen, while giving flexibility to terminate the request at a potentially different (but bounded) time. Note, q1r specifies the minimum probability with which bandwidth brp should be made available, while q2r can be used by tenants to reduce costs by limiting the bandwidth being allocated. We first split the bandwidth-allocation problem into two phases—static and dynamic—associated with different pricing schemes (defined in Sec. II-C), and formulate them as separate optimization problems in Sec. III-A. We observe both as NP-hard problems (Sec. III-B). In the static-allocation phase, newly arriving requests are processed to decide on the admissibility (without affecting already-accepted requests) such that the revenue is maximized. In the dynamic-allocation phase, the surplus bandwidth available is shared among the active requests depending on their demands as well as the pricing policy opted for. We then develop an online bandwidthallocator in Sec. III-C that processes bandwidth-reservation requests from users and defines bandwidth profiles for accepted requests. Numerical analyses (in Sec. IV) show that this model, in comparison to a deterministic model, rejects 40−75% lesser number of requests depending on the input load. It is also able to allocate more bandwidth due to dynamic allocations, thereby increasing revenue for providers. Before concluding, we discuss the related works in Section V. II.

M ODEL DESCRIPTION

Below we put down the assumptions made, and define the requests as well as the pricing models. A. Assumptions •

Time is discrete and slotted. Bandwidth is requested and reserved for equal-length slots, called communication-slots or c-slots, denoted as Ω. Assume |Ω| to be in tens of minutes.

• •

•

For a request, start-time is the c-slot from when the resource is required. End-time is not known in advance; instead, each request specifies an estimate. Bandwidths are allocated as step functions within cslots. The steps for this function are over fixed number of sub-intervals of equal length formed by partitioning the c-slots. We assume n sub-intervals within every cslot; i.e., Ω = ∪nj=1 τj where τj , 1 ≤ j ≤ n, denote sub-intervals. Requests are taken up for scheduling at regular intervals, called scheduling slots, or s-slots, separated in time by |Ω|. Let σi denote the ith s-slot. All sslots are of same length and equal to |σ|, such that |σ| << |Ω|. Furthermore, assume σi and Ωi finish at the same time.

Solutions to the optimization problems give the bandwidth profiles (as step functions) for each request, which should be enforced at the end-hosts to guarantee performance. A profile with frequent variations in bandwidth is practically difficult to be enforced at the end-host, given that the transport protocol (TCP, primarily) will take time to converge before using the assigned bandwidth efficiently. Therefore, we limit the bandwidth profile of a request to a step function over intervals, as is common in the literature; e.g., [8] solves for step functions to perform deadline-constrained data transfers. B. Requests A tenant may submit multiple requests, two for each VM-pair having bandwidth requirements. Besides, there are multiple tenants wanting resources from a data-center. Let R denote the set of all user-requests. For each r ∈ R, • • • • • • • •

αr is the arrival time of the request into the system, tr is the start-time of the request, ur denotes source VM, and v r the destination VM, E r is the estimated duration, in number of c-slots, brm , the minimum bandwidth required from ur to v r , brp > brm , bandwidth required with some probability, q1r and q2r are probabilities (q2r ≥ q1r ), demanding brp to be allocated with a probability between q1r and q2r , Pdr is the price chosen from a pre-defined set, for dynamic allocation of probabilistic bandwidth.

To accept a request r, the allocator has to allocate (from ur to v r ) a minimum bandwidth of brm for the entire duration E r , besides allocating probabilistic bandwidth brp with probability not less than q1r . We call this the statically-allocated bandwidth for an accepted request. If there is surplus bandwidth, the allocator can dynamically allocate (from ur to v r ) brp units of bandwidth with a probability higher than q1r , but not greater than q2r ; and we call this dynamically-allocated bandwidth. Probabilistic-bandwidth allocation is achieved by mapping probabilities onto time-slots: for each accepted request r, brp is statically allocated for q1r fraction of E r c-slots, and dynamically allocated for up to q2r fraction of E r c-slots. C. Pricing models The cost incurred by a user is a function of both the bandwidth and the duration for which the request was active. There is also fees for reservation, which is dependent on the duration and the units of bandwidth requested. We find it appropriate to have the price (per unit) for statically-allocated bandwidth, Ps ,

different from the price for dynamically-allocated bandwidth, Pdr . If Tar denotes the actual duration of request r (possibly different from E r ), revenue due to r, ψ r = Ps × (brm Tar + brδ Tsr ) + Pdr × (brδ Tdr ),

(1)

where brδ = brp − brm , Tsr = Tar q1r is the duration brp is allocated statically to the request r, and Tdr is the duration for which brp is allocated dynamically. Evidently, Tdr ≤ Tar q2r . We combine bandwidth-price and reservation-fee into Ps . Define Ps , ks ; ks ∈ R+ . For dynamic allocation of probabilistic bandwidth, as noted before, users need to be given different pricing policies from which they can choose the policy that suits them. Let k1 , k2 , k3 ∈ R+ . We define three simple, but effective, pricing policies; i.e., Pdr in request r will be one of the following: •

P1 , k1 ; k1 < min(ks , k2 , k3 ). This is a discounted pricing offered to create revenues at low loads.

•

P2 , k2 . This policy gives revenue during normal load.

•

P3 , k2 1l<θ + k3 1l≥θ ; k3 > k2 . The indicator function 1A has value one if the condition A is true, and zero otherwise. The parameter l can be defined in many ways; we define it as the load due to staticallyallocated bandwidth in a c-slot, and θ is a threshold for this load determined by the provider. This is a load-dependent pricing, charging more at peak times.

A provider has to set ks > max(k1 , k2 , k3 ) to encourage tenants to specify some part of their bandwidth requirements as probabilistic bandwidths. Values of k1 , k2 and k3 need to be such that, when the load due to static allocation is greater than θ, the users who chose P3 will get priority over others (who chose P1 or P2 ) during dynamic allocation. Users who chose P1 will get dynamically-allocated bandwidth only if there is surplus bandwidth after allocation to users of P2 and P3 . III.

BANDWIDTH ALLOCATION

A. Two-phase optimization Network providers usually aim to maximize their revenue, making it natural to use Eq. 1 as the objective for optimization. But, as mentioned earlier, the actual duration, Tar (and its dependents), are not known in advance. Instead, an estimate E r is specified in the request. Assume E r ≥ Tar ; i.e., the bandwidth requirement may terminate before E r time-slots (but not after), still the provider has to reserve the bandwidth until E r (reusing the freed time-slots after request-termination) while charging only for the actual duration. Since it is not possible to indefinitely reserve resources for users, a practical approach is to mandate the estimated duration to not exceed the actual duration by more than e% (of the actual duration). We now seek to break the resource-allocation problem into two optimization phases; Phase 1 followed by Phase 2 in order, both during the s-slots. Phase 1 maximizes the revenue associated with statically-allocated bandwidth, while also defining a static-bandwidth profile for each accepted request, for the estimated duration of the request. Those requests for which the static-bandwidth demands can be met are accepted, and the

rest are rejected. This optimization phase is skipped if there is no new request-arrival since the last scheduling. Phase 2 aims to maximize the revenue from dynamically allocated bandwidth, but does so by optimizing for c-slots one at a time. This phase defines dynamic bandwidth profiles for requests that would be active in the following c-slot, depending on the available bandwidth as well as the pricing policies specified in these requests. One run of Phase 2 will define the dynamic bandwidth profile for a single c-slot. For these purposes, requests are grouped into two. At the beginning of every s-slot, say σi , Rn is the set of all new requests that arrived after the beginning of the previous s-slot σi−1 . The requests that are currently active in the system— those accepted and have not terminated yet—is maintained in the set Ra . Let A ⊂ Rn be the set of new requests accepted by the Phase 1 optimization during the s-slot σi . Ra is updated as Ra = Ra ∪ A. The set of requests given as input for Phase 2 (following a run of Phase 1) is Rd ⊂ Ra , which are the requests with start-times not later than the next c-slot Ωi+1 . For simplicity, hereafter, we consider resource allocation over a single link. Let µ denote the link-capacity. If ∆ is the set of all c–slots (that grows dynamically depending on the requests being accepted), define ρ : ∆ × Ω → [0, µ] as a step function (with steps over sub-intervals in each c-slot) representing the residual link capacity. ρ is initialized to the link capacity, and updated at the end of both optimization phases, using the bandwidth profiles of accepted requests as well as the bandwidth profiles of requests terminating before the beginning of next c-slot. For each request r, we maintain a bandwidth profile β r as the sum of two step functions: one is the profile for bandwidth allocated statically, denoted by λr , and the other is the profile for dynamically-allocated bandwidth, denoted by γ r . While λr is obtained as the solution of Phase 1 optimization, γ r is obtained from Phase 2. 1) Phase 1 optimization: Besides the revenue from static allocation, output of this phase also gives the static-bandwidth profiles, λr ’s. Let ∆r ⊂ ∆ denote the set of c-slots of request r (obtained from tr and E r ). For request r, define λr : ∆r × Ω → [0, µ]. As only new requests are considered for resource allocation here, Phase 1 decides on the admission of requests into the system. A rejected request will have zero bandwidth allocated to it (for all of its c-slots). To reduce notations, let, ∀r ∈ R, q2r = 1 and q1r = q r . Assume q r ∈ {0, 0.1, 0.2 . . . , 1}. The revenue we optimize in Phase 1 is, X X X X ψs = ψsr = Ps ∗ λrΩ,τ . (2) r∈Rn

r∈Rn

Ω∈∆r

is the revenue from request r due to static allocation. The Integer Linear Programming (ILP) formulation is: maximize : ψs r λrΩ,τ = xrΩ,τ brm + yΩ,τ brp r r xΩ,τ +PyΩ,τ ≤ 1 P r

λr

τ ∈Ω Ω,τ ar = |∆Ω∈∆ r ||Ω|(br +br q r ) m δ λrΩ,τ ≥ ar brm P r r∈RΩ λΩ,τ ≤ ρΩ,τ r xrΩ,τ , yΩ,τ ∈ {0, 1} ar ∈ {0, 1}

Note that λr ’s in the ILP formulation can be obtained from the binary variables xr ’s and y r ’s, but are added only for readability. Hence, the formulation in Eq. 3 is a 0-1 ILP. 2) Phase 2 optimization: Phase 2 is executed after Phase 1 optimization. Unlike in Phase 1, in this phase optimization is done only for one c-slot, precisely the c-slot following the current s-slot. If the current s-slot is σi , the next c-slot is Ωi+1 . The parameter l used in the definition of P3 will therefore correspond to Ωi+1 . The set of requests active in the next c-slot is Rd . Define γ r : ∆r ×Ω → [0, µ]. The optimal solution gives the revenue as well as the corresponding dynamic bandwidth profiles, γ r , ∀r ∈ Rd . Note, the profiles are for the next c-slot, Ωi+1 . We drop the subscripts for the c-slot in the formulation below. The revenue due to dynamic allocation in c-slot Ω is, X X X r ψdΩ = ψdrΩ = Pdr ∗ γΩ,τ , (4) r∈Rd

r∈Rd

τ ∈Ω

ψdrΩ

being the revenue from request r due to dynamic allocation in c-slot Ω. The ILP formulation is: maximize : ψdΩ
r = xrτ brp − λrΩ,τ s.t. P γΩ,τ r r∈Rd γΩ,τ ≤ ρΩ,τ r xτ ∈ {0, 1}

∀τ ∈ Ω, ∀r ∈ Rd ∀τ ∈ Ω ∀τ ∈ Ω, ∀r ∈ Rd .

(5)

As in Phase 1, γ r ’s are added for readability; i.e., the formulation in Eq. 5 can be rewritten as a 0-1 ILP. First constraint limits γ r to values within the set {0, brδ }, while ensuring that the sum of the bandwidth profiles do not exceed brp . Link capacity is respected with the second constraint. The revenue from request r due to dynamic allocation is, X ψdr = ψdrΩ , Ω∈∆r

hence the total revenue due to r, ψ r = ψsr + ψdr .

τ ∈Ω

ψsr

s.t.

The first two constraints in Eq. 3 restrict λrΩ,τ to the set {0, brm , brp }. To identify rejected requests, the static bandwidth profiles of all rejected requests are set to zero. This is achieved through the third and fourth constraints. The third constraint identifies requests with aggregate bandwidth requirement satisfied. ar is a binary variable, and hence requests that have ar ’s equal to zero are those that have to be rejected. The fourth constraint ensures that a request r with ar equal to one gets bandwidth as specified. The fifth inequality is for respecting the link capacity. RΩ ⊂ Rn is the set of requests that have bandwidth demands in the interval Ω (r ∈ RΩ if Ω ∈ ∆r ).

∀τ ∈ Ω, ∀Ω ∈ ∆r , ∀r ∈ Rn ∀τ ∈ Ω, ∀Ω ∈ ∆r , ∀r ∈ Rn ∀r ∈ Rn ∀τ ∈ Ω, ∀Ω ∈ ∆ , ∀r ∈ Rn ∀τ ∈ Ω, ∀Ω ∈ ∆ ∀τ ∈ Ω, ∀Ω ∈ ∆r , ∀r ∈ Rn ∀r ∈ Rn . (3) r

B. Problem complexity Both the optimization formulations presented above are special cases of the multi-dimensional knapsack problem (MKP), and are NP-hard. MKP can be defined by the following ILP: Pκ maximize : j=1 cj xj Pκ (6) s.t. i = 1...n j=1 wi,j xj ≤ ρi xj ∈ {0, 1} j = 1 . . . κ. xj ’s select some of the given κ items, each of which requires wi,j ≥ 0 share of the common resource ρi in such a way so as to maximize profit, given cj is the profit from item j.

For Phase 2, observe that bandwidth-allocation in each subinterval (within a c-slot) is independent of other sub-intervals. A knapsack instance, which is a special case of the MKP, can be readily reduced to the sub-problem that maximizes revenue in the sub-interval, say τ , of a given interval, say Ω. The items of the knapsack instance are requests, the price of each request r being Pdr ∗ (brp − λrΩ,τ ), and the ‘size’ being (brp − λrΩ,τ ).

25

D (deterministic) P (probabilistic)

20 Rejection percentage

For Phase 1, consider an instance where q1r = 0, ∀r ∈ R; the problem then reduces to the bandwidth allocation problem (BAP) in literature—where brm , ∀r ∈ R, is the bandwidth to be allocated for the specified time duration. As noted in [3], BAP can be obtained from MKP with |R| = κ, by setting all ρi ’s equal to the link capacity µ, all cj ’s to the cost, and wi,j to bjm for all i ∈ {tj , tj + E j }, j ∈ R and zero otherwise.

15

10

5

0 0.5

0.6

0.7

0.8

0.9

1

Input load

Fig. 1.

Comparing rejection percentage for both scenarios

C. Algorithm for bandwidth-allocator The steps for bandwidth-allocation is given in Algorithm 1 (comments are preceded by ‘##’). Rit ⊂ Ra denotes the subset of requests that terminate in c-slot Ωi (the current c-slot); and, Rd ⊂ Ra is the set of requests that have bandwidth demands for the c-slot Ωi+1 (thereby excluding those accepted requests starting after Ωi+1 ). β r is the bandwidth profile that gets enforced at end-host, as and when the profile is updated. Algorithm 1 schedule requests(Rn , Ra , i) 1: Rn : set of requests that arrived after the last scheduling 2: Ra : previously accepted requests, but not terminated yet 3: i : slot index ## same for c-slot and s-slot 4: if Rn 6= {} then 5: Execute Phase 1 optimization on Rn (Eq. 3) 6: A ← newly accepted requests from Rn 7: λr ← static bandwidth-profile of r ∈ A 8: β r ← λr , ∀r ∈ A. 9: Update residual bandwidth ρ using λr s 10: Ra = Ra ∪ A 11: end if 12: Ra ← Ra \Rit ## Remove requests terminating in Ωi 13: Rd = {r|(r ∈ Ra ) ∧ r active in c-slot Ωi+1 } 14: if Rd 6= {} then 15: Execute Phase 2 optimization on Rd for Ωi+1 (Eq. 5) r 16: γΩ ← dynamic bandwidth profile of requests r ∈ Rd i+1 17: for r ∈ Rd do r r r 18: βΩ ← βΩ + γΩ ## for c-slot Ωi+1 i+1 i+1 i+1 19: end for 20: Update residual bandwidth ρ using γ r s 21: end if IV.

P ERFORMANCE STUDY

We perform numerical studies comparing two scenarios: (i) deterministic (D) refers to the case where tenants request for exact bandwidth for communication between VMs, and (ii) probabilistic (P), where tenants request for probabilistic bandwidth as described in Sec. II-B. We use Algorithm 1 to schedule requests in both scenarios, with the difference being that, Phase 2 will not be executed for requests in Scenario 1. Values are set for fair comparisons of the two scenarios. All values pertaining to requests are generated randomly. Interarrival time between requests, bandwidths and actual durations follow the exponential distribution. Requests of Scenario (i)

can be fit into the description for probabilistic requests by setting brp and q r to zero, brm to the bandwidth demand and E r to the actual duration, for every request r. With this setting, the pricing policies for dynamic bandwidth allocation as well as Phase 2 become meaningless in Scenario (i). For every request r in Scenario (i), there was a corresponding request ˆ rˆ in Scenario (ii), where the changes were (only) with brm , brpˆ, q rˆ and E rˆ. Of these, the first three were generated such that the mean bandwidth of request rˆ in Scenario (ii) was set to the minimum bandwidth brm of request r in Scenario (i). The estimated duration of a request is the sum of the actual duration and a uniformly distributed random number between zero and e fraction of the actual duration. For each request in Scenario (ii), a pricing policy is randomly and uniformly selected from the list of three policies (defined in Sec. II-C). Six settings differing in input loads (and not the actual system loads) were considered—from 0.5 to 1.0 at steps of 0.1. The link capacity was 1000 units. With the mean duration of requests set to 12 c-slots and the mean request-arrival rate (per c-slot) close to one, the mean bandwidth for each requestset was obtained. The values for q r were taken from a Normal distribution with mean 0.4 and variance 0.2. The value of e was 0.2. The number of sub-intervals, n, in each c-slot, was 10. For a unit of bandwidth in a sub-interval, ks , k1 , k2 and k3 , were set to 10, 8.5, 9.0 and 9.5, respectively. The relative values of these were chosen such that, there is incentive in demanding probabilistic bandwidth (max(k1 , k2 , k3 ) < ks ), in addition to following the definitions of the pricing policies (as given in Sec. II-C). The threshold of the load due to staticallyallocated bandwidth in a slot, θ, was set to 0.4. One run of each scenario had 1000 requests. All data presented here are (rounded) mean values from 25 runs. Fig. 1 plots, with 95% confidence interval, the rejection percentage under different loads for each scenario. Bandwidth allocated and revenue generated, for the two scenarios, under different loads indicated by the subscripts to D and P, are given in Table I. The first three columns in Table I list the bandwidth (in 1000s) due to static (SB), dynamic (DB), and both allocations (TB), respectively, by summing over sub-intervals. The last three columns, in order, give revenues (in 1000s) from static (SR), dynamic (DR), and both allocations (TR). The dynamic bandwidth allocated for users who chose a particular pricing policy are given in Table II. For all values in the tables, 95% confidence intervals were within 1-3% of the reported data.

TABLE I.

D0.5 P0.5 D0.6 P0.6 D0.7 P0.7 D0.8 P0.8 D0.9 P0.9 D1.0 P1.0

SB 2407 1275 2740 1497 2873 1626 3069 1800 3161 1910 3240 1990

TABLE II.

Load P1 P2 P3

C OMPARISON OF TWO SCENARIOS

DB 0 1300 0 1473 0 1547 0 1627 0 1646 0 1673

TB 2407 2575 2740 2970 2873 3173 3069 3427 3161 3556 3240 3663

SR 24070 12750 27400 14970 28723 16260 30690 18000 31610 19100 32400 19900

DR 0 11536 0 13121 0 13808 0 14575 0 14767 0 15008

TR 24070 24286 27400 28091 28723 30068 30690 32575 31610 33867 32400 34908

AGGREGATE DYNAMIC BANDWIDTH ALLOCATED

0.5 429 444 427

0.6 473 504 496

0.7 485 519 543

0.8 498 539 590

0.9 486 558 602

1.0 511 551 611

Observe from the figure that the probabilistic model reduces rejection by ≈ 40% at high input load of 1.0, and by ≈ 75% at low input load of 0.5. Table I shows that our model also allocated ≈ 7−13% more bandwidth in comparison to the deterministic models (column TB), of which, ≈ 45 − 50% was allocated dynamically (column DB). The revenue comparisons are dependent on the values of k1 , k2 , k3 and ks , as well as the definition of pricing policies. Nevertheless, the important observation is, by carefully defining the pricing policies, providers can potentially increase their revenues without the risk of rejecting tenants. Table II gives, for different input loads, the aggregate dynamic bandwidth obtained by requests of users who chose a particular pricing policy. Recall, θ = 0.4. At (low) input load of 0.5, users who chose P3 collectively got almost the same amount of bandwidth as users of P1 . But as the load increased, P3 users obtained higher aggregate bandwidth dynamically in comparison to users of P1 ; P3 users getting around 18 − 23% more than P1 users under high input loads ≥ 0.8. Between users of P2 and P3 , the latter generate more revenue at high loads, thereby also obtaining higher share of bandwidth. V.

Recently, authors of [7] observed the inability of tenants to accurately specify their requirements, and proposed to reserve a minimum bandwidth while allocating a fraction of predicted demand dynamically with a certain risk. The pricing policy studied there was independent of the absolute demand, instead was a function of the minimum bandwidth, the fraction specified and the risk factor that tenant was willing to take. In addition, the focus of the work was to efficiently solve the optimization problems as well as to predict demand statistics. VI.

This paper introduced a new model, tied to pricing, to achieve probabilistic-bandwidth guarantees for communication between VMs of tenants in a data-center. Our model is able to accept more number of requests in comparison to the deterministic model, at the same time allocating more aggregate bandwidth, thereby also increasing provider’s revenue. Through this work, we took the first steps in solving bandwidth-sharing problem in data-centers using a novel approach, in the process opening up interesting future directions. The pricing policies considered here are not exhaustive, but they do give insights on the possibility of providing costeffective probabilistic bandwidth to tenants, while increasing the number of accepted requests. For future work, we plan to explore more policies for differential pricing that will be (largely) independent of the utility functions of tenants. One could also extend the model to allow tenants to modify and re-submit one (or more) of the parameters (say q1r and q2r ) dynamically. Another possibility is to alter the model to have bandwidth profile as step functions over intervals (instead of sub-intervals), where bandwidth can vary (only) between intervals, within the range specified by tenant. Last but not the least, as the allocation problem is hard, we also plan to work on developing near-optimal algorithms for both phases. VII.

Bandwidth reservation was proposed in the context of grid networks to transfer bulk data with deadlines [4]; as the problem turns out to be a variant of the maximum concurrent flow problem, it can be solved using polynomial-time algorithms. Ballani et al. introduced a pricing in Clouds that is independent of the location of VMs of a tenant [1]. The idea is to decouple cost to tenants from the performance of the underlying network, such that the providers find incentives in improving performance. The link-capacity distribution ensures a minimum bandwidth to each tenant (based on its quota) and shares the spare bandwidth in proportion to tenants’ quotas.

ACKNOWLEDGEMENT

This work was supported by Singapore A*STAR-SERC research grant No: 112-172-0015 (NUS WBS No: R-263-000665-305). R EFERENCES [1]

R ELATED WORKS

The decision versions of the optimization formulations for bandwidth allocations are often variants of the general multicommodity flow problem. The integer multi-commodity flow problem with just two commodities was shown to be NPcomplete [5]. As mentioned earlier, BAP is NP-hard [3].

C ONCLUSIONS

[2] [3] [4]

[5]

[6]

[7]

[8]

H. Ballani, P. Costa, T. Karagiannis, and A. Rowstron, “The price is right: towards location-independent costs in datacenters,” in Proc. ACM HotNets ’11, pp. 23:1–23:6. ——, “Towards predictable datacenter networks,” in SIGCOMM ’11. ACM, 2011, pp. 242–253. B. Chen, R. Hassin, and M. Tzur, “Allocation of bandwidth and storage,” IIE Transactions, vol. 34, pp. 501–507, 2002. B. B. Chen and P. V.-B. Primet, “Supporting bulk data transfers of highend applications with guaranteed completion time,” in IEEE ICC, 2007, pp. 575–580. S. Even, A. Itai, and A. Shamir, “On the Complexity of Timetable and Multicommodity Flow Problems,” SIAM J. Comput., vol. 5, no. 4, pp. 691–703, 1976. C. Guo, G. Lu, H. J. Wang, C. Yang, Shuang an d Kong, P. Sun, W. Wu, and Y. Zhang, “SecondNet: a data center network virtualization architecture with bandwidth guarantees,” in Proc. ACM Co-NEXT ’10. D. Niu, C. Feng, and B. Li, “Pricing cloud bandwidth reservations under demand uncertainty,” SIGMETRICS Perform. Eval. Rev., vol. 40, no. 1, pp. 151–162, Jun. 2012. S. Soudan, B. B. Chen, and P. Vicat-Blanc Primet, “Flow scheduling and endpoint rate control in Grid Networks,” Future Gener. Comput. Syst., vol. 25, no. 8, pp. 904–911, Sep. 2009.