Online Balanced Allocation of Dynamic Components
Abstract
We introduce Online Balanced Allocation of Dynamic Components (OBADC), a problem motivated by the practical challenge of dynamic resource allocation for large-scale distributed applications. In OBADC, we need to allocate a dynamic set of at most vertices (representing processes) in clusters. We consider an over-provisioned setup in which each cluster can hold at most vertices, for an arbitrary constant . The communication requirements among the vertices are modeled by the notion of a dynamically changing component, which is a subset of vertices that need to be co-located in the same cluster. At each time , a request of one of the following types arrives:
-
1.
insertion of a vertex forming a singleton component at unit cost.
-
2.
merge of requiring that the components containing and be merged and co-located thereafter.
-
3.
deletion of an existing vertex at zero cost.
Before serving any request, an algorithm can migrate vertices from one cluster to another, at a unit migration cost per vertex. We seek an online algorithm to minimize the total migration cost incurred for an arbitrary request sequence , while simultaneously minimizing the number of clusters utilized. We analyze competitiveness with respect to an optimal clairvoyant offline algorithm with identical (over-provisioned) capacity constraints.
We give an -competitive algorithm for OBADC, and a matching lower-bound. The number of clusters utilized by our algorithm is always within a factor of the minimum. Furthermore, in a resource augmented setting where the optimal offline algorithm is constrained to capacity per cluster, our algorithm obtains competitiveness and utilizes a number of clusters within factor of the minimum.
We also consider OBADC in the context of machine-learned predictions, where for each newly inserted vertex at time : i) with probability , the set of vertices (that exist at time ) in the component of is revealed and, ii) with probability , no information is revealed. For OBADC with predictions, we give a -consistent and -robust algorithm.
Keywords and phrases:
online algorithms, competitive ratio, algorithms with predictionsCopyright and License:
![[Uncaptioned image]](x1.png)
2012 ACM Subject Classification:
Theory of computation Online algorithmsAcknowledgements:
This work was partially supported by NSF award CCF-2335187.Editors:
Raghu MekaSeries and Publisher:

1 Introduction
Modern large-scale applications are distributed over multiple physical machines or computing clusters in data centers, generating a considerable amount of network traffic. In a typical setting, a cloud service provider provisions computational resources (such as CPU, memory, storage) in the form of virtual machines (VMs) to users who pay a cost proportional to their resource requirements which varies over time. However, operating and allocating these resources in a “demand-aware” manner to minimize cost, and optimize performance and energy utilization while fulfilling service-level agreements (SLAs) for various users is technically challenging. This has garnered a surging interest in resource allocation strategies in cloud computing frameworks in recent years [7, 9, 1, 31].
Consider the setting where a massively distributed application attributed to a single cloud user may be spread across multiple VMs, necessitating inter-VM communication. If such VM’s are allocated in the same cluster, inter-VM communication consumes little network bandwidth, leading to low communication cost and potential energy savings [31, 32]. However if inter-VM communication happens over physically separated clusters, this may compromise quality of service, responsiveness, and incur a large consumption of network resources. Almost all virtualization systems support “live-migration” of VMs between various clusters with the aim of reducing latency, improving resource-allocation and energy savings [12, 16, 17]. However, VM migration must be performed sparingly, as it creates network overhead and may compromise the responsiveness of the VM being migrated.
In addition to inter-process communication patterns that evolve over time, another challenge is to provision resources dynamically to users under varying resource requirements. This leads to the removal of existing virtual machines and the insertion of new virtual machines [6]. Thereafter, new communication patterns emerge between newly re-allocated VMs. Such re-allocations also incur a cost for the cloud service provider which is inevitable, in addition to future defragmentation of resources caused by multiple re-allocations over time [30].
Finally, energy consumption of data centers due to an ever-increasing need for large-scale cloud computing is well documented [19]. In practice, migration of VMs together with other load-balancing strategies have been exploited to reduce the number of “active” physical machines to save energy [16, 19, 17]. For example, VMs on under-loaded clusters are migrated so that such clusters can save energy by moving to an idle state. Thus, it is highly desirable to ensure that the number of “active” clusters dynamically scales with the workload.
In this paper, we address the challenges posed by unknown communication patterns, dynamic resource requirements, and energy consumption by introducing the problem of Online Balanced Allocation of Dynamic Components (OBADC). We model the scenario where clusters and VMs are homogeneous, and migration and inter-VM communication costs are uniform across different clusters, while the communication patterns and dynamic allocation requests are unknown.
1.1 Problem Formulation and Main Results
Our problem formulation is inspired by the online balanced graph partitioning (OBGR) problem, introduced by Avin, Bienkowski, Loukas, Pacut and Schmid [2], and considers additional technical aspects including the dynamics of VMs, and a secondary goal of minimizing the number of active clusters. In OBADC, we have a set of at most vertices (representing VMs) at any given point in time, and clusters denoted by , each with capacity . Initially and for all is empty. We model the communication requirements among the vertices using the notion of a dynamically changing component, which is a subset of vertices that need to be co-located in the same cluster. The request sequence is revealed online, such that each request is of the following type:
-
1.
Insertion of a vertex : Insert (and a corresponding singleton component ) at unit cost, to any cluster which can accommodate it. The cost of insertion models a one-time “startup” cost to initialize a VM in a cluster.
-
2.
Deletion of a vertex : Delete existing vertex from its component . The cost of deletion is zero; all vertices in are still required to be co-located.
-
3.
Merge vertices and : Merge the components containing and into a single component so that vertices in the resulting component are co-located thereafter.
Insertions and deletions of vertices model VM allocation and de-allocation, while merge requests model the scenario when frequently communicating VM’s dedicated to a single application or a customer are consolidated for efficiency or energy savings [28].
The request sequence induces a unique set of components denoted by , over time. The migration cost of a single vertex is unit. All vertices of a single component are required to be assigned to the same cluster. Thus, we assume that the size of any component is most at all times, and that there exists a component assignment to clusters such that each cluster is assigned a maximum of vertices.
Competitive Analysis.
We adopt the competitive analysis framework to analyze OBADC algorithms. A deterministic (resp. randomized) online algorithm is said to be -competitive (alternatively, is the competitive ratio of ) if for any input sequence , the cost (resp. expected cost) incurred by in satisfies where is a constant independent of the length of and OPT is the cost of an optimal offline algorithm denoted by OPT, which has complete information about the request sequence in advance. Abusing notation slightly, we refer to OPT as OPT when is clear from context.
Resource Competitiveness.
To capture the practical objective of utilizing a number of clusters proportional to the total resource requirement (which varies over time), we seek algorithms which are also competitive with respect to the number of clusters utilized by OPT. Let denote the number of vertices at any time , and let denote the number of clusters used to assign all vertices at time by OPT and an online algorithm . We say that is -resource competitive if for all time , .
OBADC with Over-Provisioning.
For the sake of obtaining polynomial-time online algorithms, we consider an overprovisioned setting, similar to the one considered in a recent work [23]. Here, each cluster for has capacity for some . While seemingly similar to a resource-augmented model, we emphasize that in the over-provisioned setup, both the online algorithm and the optimal offline algorithm OPT are constrained to an identical cluster capacity of for any cluster . As a result, competitiveness is analyzed on a stricter benchmark, in that the optimal offline and online algorithm have access to the same amount of resources, in strong contrast to resource augmentation where competitiveness is analyzed with respect to an unaugmented offline algorithm (see Chapter 4 of [25]).
Our main result is a -competitive algorithm for OBADC in the over-provisioned setting. We show that the competitive ratio of our algorithm is asymptotically optimal by establishing a lower bound. Furthermore, our algorithm is -resource competitive.
Theorem 1.
Consider any instance of OBADC with clusters each of capacity and arbitrary sequence of insertion, deletion, and merge requests such that at any time the resulting components can be allocated to the clusters using capacity at most . There exists an online algorithm that achieves cost at most times the optimal, while utilizing at most times more clusters than the minimum required at each time step.
Furthermore, every online algorithm incurs cost times the optimal for the worst-case instance.
In a resource augmented setting where the optimal offline algorithm is constrained to capacity per cluster, our algorithm obtains competitiveness, while utilizing a number of clusters within factor of the minimum. The proof of resource-competitiveness is deferred to the full version of the paper.
OBADC with Machine-Learned Predictions.
We next investigate OBADC in the context of “algorithms with predictions” which is a growing research area [25, 15] with the over-arching goal of circumventing pessimistic limitations of lower and upper bounds for various problems in online, dynamic and approximation algorithms.
Prediction Model: At any time step when a vertex is inserted, with probability , we also receive a set consisting of all vertices in that lie in the same component as , where denotes the set of vertices at the beginning of time step . Note that with probability , we do not receive any information on the component of . Furthermore, only consists of vertices in ’s component which exist at time , and contains no information about future vertices in ’s component which may arrive after time .
Our “prediction error” is quantified by the confidence of the predictions, similar to [11] and we analyze the performance of a learning-augmented online algorithm for OBADC in a standard consistency-robustness framework [11, 15, 24]. An algorithm for OBADC with predictions is said to be -consistent and -robust if it is -competitive when , and -competitive where is a non-increasing function of . Roughly speaking if , and we have perfect predictions, then one would desire constant-factor competitiveness. On the other hand, as approaches 0, the performance of the algorithm should gracefully degrade to the competitive ratio obtained by the best-known online algorithm for the problem. Our second result provides a near-tight consistency-robustness tradeoff for OBADC.
Theorem 2.
There exists an -consistent and -robust algorithm for OBADC with predictions in the over-provisioned setting.
1.2 Technical Overview
In this section, we present a high level overview of our techniques towards obtaining our algorithms. We ignore several intricacies in the following discussion.
1.2.1 Overview of the Algorithms
Our algorithm for OBADC classifies components in terms of their volume (which refers to their size). A component is said to be small if it has volume at most where , and large otherwise. Let denote the set of small and large components maintained at all times. Component volumes are rounded up to the nearest power of , such that components whose size is in the interval belong to component class . Thus, the total number of small component classes is while the number of large component classes is . Our algorithm assigns volume to each component on a cluster such that the assigned volume is upper bounded by . The precise volume assigned by our algorithm is more fine-grained to further distinguish components within the same component class.
The assignment of large components is accomplished by solving an integer linear program (ILP) whose objective function seeks to minimize the number of clusters utilized. We remark that large components are assigned independently of small components. Since the number of large component classes is , the ILP can be solved in polynomial time. Invoking a result from [26] allows us to limit the total “change” in large component assignments after component merges (resp. vertex deletions), which lead to increase (resp. decrease) in a component’s class. Small components are assigned in a first-fit fashion. Our algorithm maintains a “tight” assignment of components throughout time which guarantees -resource competitiveness.
The main challenge arises in maintaining these assignments dynamically, while simultaneously minimizing the total migration cost and clusters utilized. To accomplish this, our algorithm maintains several invariants. We give an overview of our algorithm as follows.
Insertion of singleton components are handled by provisioning volume on a cluster, with sufficient residual volume whenever possible. For a merge request , if are in the same component , the algorithm does nothing; else distinct components containing and respectively, are merged into a new component where w.l.o.g. .
When is small and the volume assigned to is at least , the smaller component is migrated (unless it is assigned on the same cluster as ). Otherwise, if there is sufficient residual volume on the cluster to which is assigned, is assigned volume and vertices in are migrated (if necessary). If the residual volume is insufficient, this implies that at least vertices are assigned to this cluster. Thereafter, vertices in and are migrated to another cluster with sufficient residual volume. This may lead to a reduction in the assigned volume of ’s cluster. Whenever the residual volume of a cluster decreases below a certain threshold, our algorithm migrates small components as necessary from other clusters to ensure resource-competitiveness.
On the other hand, if is large such that belongs to a higher component class than , our algorithm solves an ILP; otherwise, vertices in are migrated (if necessary). If the ILP is solved, this may lead to multiple components (both large and small) being reassigned and migrated. We give a greedy procedure to assign large components, which together with the sensitivity analysis result from [26], allows us to bound the total migration cost by . If the request sequence consists of only vertex insertions and component merges (i.e. only monotonic increases in component sizes), we can establish -competitiveness by a relatively elegant charging argument (see Section 3).
However, for non-monotonic changes in component sizes a major challenge arises towards ensuring resource-competitiveness, since vertex deletions in one component may necessitate migration of other unrelated components to maintain a tight packing. To this end, our algorithm always maintains the property that the assigned volume of any component is within a factor of under both component merges and vertex deletions. For small components undergoing vertex deletions, volume reassignment can be done after a constant fraction of vertices in are deleted. This may require migration of small components to ’s cluster. On the other hand, if vertex deletions in lead to a drop in ’s component class we solve an ILP to reassign large components. This may be prohibitive in general because repeated vertex insertions and deletions can lead to a cost of every time an ILP is solved. To circumvent this, our algorithm works with a relaxed volume threshold (and component class categorization) when “deciding” whether to re-solve an ILP under vertex deletions. Thus, for example, certain large components may be treated as class components by our algorithm even when their volume is less than . However, once at least vertices are deleted from such components, our algorithm re-solves the ILP. We show that treating certain components in this manner does not violate resource competitiveness, since the total number of large components which can be assigned to any cluster is .
For the learning-augmented model, we enhance our algorithm of Theorem 1 by executing the merges indicated by the predictions at the time of insertion. That is, on the insertion of a vertex whose predicted set is non-empty, our algorithm issues merge requests of the form for all . This allows us to inherit several desirable properties of our algorithm of Theorem 1 while minimizing the total migration cost when augmented with predictions. The resulting algorithm also yields a smooth interpolation between our algorithm without predictions and one with full predictions.
1.3 Related Work
Online graph partitioning problems.
At a high-level, OBADC is related to previous work on online partitioning of dynamically changing graphs. Related problems include variants of online graph coloring and the OBGR problem. In recent work, Azar et al. [3] introduce an online graph recoloring problem in which edges of a graph arrive online and an algorithm needs to distribute the vertices among clusters such that for any edge, the two endpoints must be in different clusters. Subsequent work [23] considers a capacitated variant of online recoloring. A key distinction between such coloring problems and OBADC is that while an edge in the former requires the endpoints to be separated, an edge in the latter requires the endpoints to be co-located, leading to different technical considerations.
OBADC is perhaps most closely related to OBGR [2], in which there is a static set of vertices and a set of clusters each holding vertices initially. An online sequence of communication requests arrives over time. The cost of serving request is 1 if and are in distinct clusters and otherwise. Prior to serving any request, a vertex can be migrated at a cost of . The cost incurred by an online algorithm is the total communication and migration cost to serve all requests in . OBGR has a -competitive algorithm [2] in the non-augmented setting while a lower bound of is known. In recent work, a -competitive algorithm was given in [4], which is optimal for constant . In the resource augmented setting, with -augmented cluster capacity an -competitive deterministic algorithm was given in [2]. For the same setting, a polynomial time algorithm was recently presented in [10]. A lower bound of holds even in the -augmented setting where [20].
In [14], Henzinger et al. introduced the learning model of the problem in which the vertex set of the graph induced by the request sequence can be partitioned into such that for all and there are no inter-cluster requests where for . For the learning model, the lower bound of holds in the non-augmented setting. Allowing -augmentation, the best deterministic and randomized algorithms are and -competitive respectively which are shown to be tight[13].
OBADC vs. OBGR.
We describe the similarities and differences between OBADC and OBGR. OBADC resembles a “fully dynamic” version of OBGR in the learning model, but differs as follows. In OBADC, vertices arrive and depart over time, and hence the online algorithm has to adapt to communication patterns which evolve over time between both existing vertices and new vertices. The migration costs are identical between the two models; however in OBADC, an insertion of a new vertex incurs a cost of and we aim to have the total number of clusters utilized by an online algorithm to adapt with the number of vertices. This may incur strategic migrations of vertices to satisfy this additional objective, in contrast to OBGR where migrations are performed to solely minimize communication overhead.
Resource-augmentation and over-provisioning.
To circumvent pessimistic lower-bounds and obtain polyonomial time algorithms, many online algorithmic problems have been studied in the resource-augmented model (e.g., see [21, 33, 34]), going back as far as the earliest work on caching [29]. OBGR has also been studied in the resource-augmentation model [13, 22, 10, 2], where OPT is constrained to a capacity of on each cluster, while an online algorithm can utilize capacity for some . In contrast, we study OBADC in an over-provisioned setting, which yields stronger guarantees than resource-augmentation since the algorithm and the optimal have the same resources. Any competitive ratio in the over-provisioned model immediately implies the same bound in the resource augmented model; for the measure of number of clusters utilized, we are able to get stronger bounds in the resource-augmentation model (see the remark after Theorem 1 in Section 1.1).
Learning-augmented algorithms.
Another approach toward addressing pessimistic bounds in online and approximation algorithms is to incorporate the growing availability of machine-learned predictions in the design of algorithms [11, 18, 15, 5]. A central theme in this area is the following: given access to an imperfect machine-learned oracle which can “predict” characteristics of future request sequences or actions (in the context of online algorithms [24, 15]), edge updates (in the context of dynamic algorithms [5]) or optimal solutions (in the context of approximation algorithms [8]), can improved competitive ratios, running/update times, or approximation ratios be obtained? The imperfection of predictions is quantified by prediction error, which is problem and instance dependent, or a confidence parameter [11]. There is a great variation in terms of various prediction models and prediction errors which have been utilized and there is no singular notion of either, which can be useful or applicable to wide variety of problems.
Our study of online OBADC with predictions is also inspired from prior empirical work in VM allocation and migration, in which various predictions on resource utilization in clusters [17], future VM requests and migrations [19], and communication traffic from historically collected data have been utilized towards efficient provisioning of resources.
1.4 Outline and Preliminaries
Section 2 presents our main algorithm for OBADC. In Section 3, we give a proof sketch of the competitive ratio of our algorithm. The proofs of resource competitiveness and correctness are deferred to the full version of the paper. Finally, Section 4 presents a learning-augmented algorithm for OBADC with predictions, together with a proof sketch of Theorem 2.
We present some useful notation. Let denote the set of vertices at any given point in time such that . We use the notation for any to refer to the set . The volume of a component is simply its size, and denoted by .
Our algorithms maintain a set of components induced on for all time . We use to denote the set of all clusters. When there is merge a request between distinct components and , our algorithms merge and into . A merge is viewed as deletion of components and from and an insertion of to .
2 An -competitive algorithm
In this section, we present an asymptotically optimal deterministic -competitive algorithm for OBADC. We begin by giving some definitions and invariants that our algorithm maintains.
2.1 Definitions and Invariants
Component Classes.
Our algorithm classifies components according to their size. For a component , we say that is in class if , where . We say that a component is small if it is in class where where . Thus, any small component has size at most where . All the other components are said to be large.
A large component is understood to be in class if it is in class . By the above definitions, it follows that a large component of class has size in . The following lemma bounds the number of large component classes.
Lemma 3.
The number of large component classes is .
Proof.
Note that a large component has volume at least and at most . Thus, . Since for any , it follows that since .
Assigned Volume.
For every component , our algorithm provisions volume on some cluster to which it is assigned, which we refer to as the assigned volume and denote it by .
For any cluster let denote the total assigned volume for all components assigned to . Let denote the residual unassigned volume of , where . We present a fine-grained scheme to assign volumes to components as follows.
Let , for . Thus, and . Our algorithm maintains the following invariant for assigned volumes at all times.
Invariant 1 (Assigned Volume).
For all classes , and any class component such that , one of the following statements holds:
-
1.
if , then .
-
2.
if , then .
-
3.
if , then .
-
4.
if , then .
The following lemma is immediate based on the invariant above.
Lemma 4.
If Invariant 1 is maintained, then for any component , .
Active Clusters.
A cluster is said to be active if there is at least one component assigned to it. The set of all active clusters is denoted by .
Marked Clusters.
Our algorithm marks and un-marks active clusters over time. If a cluster is marked, then its residual volume is small. We denote the set of marked clusters by , where . Initially, all clusters are unmarked, i.e. . Our algorithm maintains the following invariant at all times.
Invariant 2.
For a cluster , .
Furthermore, let denote the set of clusters on which only small components (and no large components) are assigned and let denote the set of clusters to which at least one large component is assigned. To ensure that the number of active clusters is at most times the minimum needed, our algorithm maintains the following invariant.
Invariant 3.
At any time , if then both of the following hold: i) either or (i.e. all clusters in are marked) and, ii) exactly one cluster in is unmarked.
Marked Components.
Our algorithm marks and un-marks certain components when their component class decreases due to vertex deletions. If a large component of class , (resp. a small component of class ) is marked, then it is treated as a large component of class (resp. a large component of class 1). Intuitively, we mark a component to ensure that the ILP is not solved too frequently if its volume shrinks only slightly due to deletions. The set of marked components at any time is denoted by . Note that all marked components are treated as large components by our algorithm, thus . Our algorithm maintains the following invariant for marked components.
Invariant 4.
At any point in time, a marked component satisfies one of the following conditions:
-
1.
is a small component of class , such that .
-
2.
is a large component of class , such that .
Data Structures.
Our algorithms maintain the sets and of small and large components, respectively, together with the set of marked components. For a component , the assigned volume is maintained, and for all , and are maintained. Furthermore, the sets of clusters and are maintained.
In the following section, we outline our approach for assigning large components which is completely independent of the assignment of small components.
2.2 An Approach to Assign Large Components
We first define the notion of a signature, similar to [22, 13]. Intuitively, a signature encodes the number of large components of each component class that can be assigned to a single cluster while respecting cluster capacity.
Definition 5.
A signature is a non-negative vector of dimension where denotes the number of large components of class such that .
Let denote the set of all possible signatures. The following lemma bounds the size of .
Lemma 6.
The total number of signatures, is bounded by .
Proof.
We first note that for any . Thus, any entry is upper bounded by . Since the number of large component classes is by Lemma 3, the total number of signatures is at most .
We solve an integer linear program (ILP) in polynomial time, and obtain signatures which guide the placement of large components. Let denote the entry of a signature . For each signature , we let denote the number of clusters which are assigned signature . Let denote the number of class large components at any given point in time. Our ILP is as follows.
ILP.
In matrix form, our ILP has rows and columns. Thus, the ILP can be solved in polynomial time.
Our algorithm solves this ILP whenever changes for any . This could be after components are merged leading to a larger component with a higher component class or, vertex deletions from a component leading to a decrease in its component class. In both cases, at most three components in change, and as a result, at most three component classes change. We invoke a well-known result in sensitivity analysis from [27], which quantifies the change in optimal solutions of the ILP.
Theorem 7 ([27]).
Let be an integral matrix, such that each subdeterminant of is at most in absolute value; let and be column -vectors, and let be a row -vector. Suppose and are finite. Then for each optimum solution of the first maximum there exists an optimum solution of the second maximum such that
We prove the following lemma.
Lemma 8.
After a merge request or deletion request, the number of signatures which change in the optimal solution to the ILP is for constant .
Proof.
Whenever two components are merged or a deletion causes a large component’s size class to decrease, the RHS vector in our ILP changes by at most in the infinity norm. To bound the sub-determinant, we use the Hadamard inequality to derive that where denotes the maximum entry (in absolute value) of the constraint matrix . Each entry in the constraint matrix of our ILP has value either 1 or so that . As a result, . Thus, the optimal solution to the ILP changes by in the infinity norm. Since has dimension , the number of signatures which change between any two optimal solutions is .
Greedy Assignment of Signatures to Clusters.
Given the solution from the ILP, we perform a greedy assignment of signatures to clusters which minimizes the number of clusters whose assigned signatures change. Let denote the current signature, such that there are exactly clusters which are assigned signature . Our algorithm for greedy assignment, Assign-Signatures works as follows.
Let for all and denote the set of active clusters. We iterate over all : while , if there exists an active cluster in which is currently assigned signature , is decremented, is removed from and we continue. Else if no cluster in is assigned signature , we pick an arbitrary active cluster in and assigns to . If , our algorithm picks an arbitrary inactive cluster , adds to and assigns to .
Let denote the set of clusters which are assigned a new signature after the call to Assign-Signatures. Any cluster satisfies one of the following conditions prior to the call to Assign-Signatures: i) was inactive, ii) was active but its signature changed after the call to Assign-Signatures or iii) was active and was not assigned any signature prior to the call to Assign-Signatures.
Let denote the set of clusters which were assigned a signature prior to solving the ILP, and are no longer assigned a signature. Finally, let denote the set of clusters whose assigned signatures are identical before and after the call to Assign-Signatures. Our algorithm returns sets and . Clearly, the assigned signatures change only for clusters which are in .
By virtue of subroutine Assign-Signatures and Lemma 8, the following lemma is immediate.
Lemma 9.
After a call to Assign-Signatures, .
For all clusters whose assigned signatures do not change, our algorithm does not modify the assignment of large components. Let denote the set of all large components in which are not assigned to any cluster in . It follows from Lemma 9 that the total volume of all large components in is .
Components in are assigned to clusters in , corresponding to the newly assigned signatures. Let denote the set of all small components previously assigned to . From Lemma 9, it follows that the total volume of all components in is . Our algorithm re-assigns small components in in a first-fit fashion, explained in the next section. The following Lemma is immediate from Lemma 8, Lemma 9 and our preceding discussion.
Lemma 10.
The total volume of components in is bounded by .
2.3 The Full Algorithm
In this section, we present our algorithm which takes as input a request at time , and maintains an assignment of components to clusters while satisfying Invariants 1 through 4. Our algorithm relies on various subroutines, which we present in the following.
Subroutine Assign-Volume.
This subroutine takes as input a component , and a cluster and assigns volume for on . In the case when is a class marked component, it is treated as a class component and assigned volume .
Observe that Invariant 1 is satisfied for any component after a call to Assign-Volume.
Subroutine Assign-Small.
The subroutine Assign-Small is invoked whenever a small component needs to be assigned volume on a cluster. We iterate over active unmarked clusters , and if , is assigned to . Else, is marked and added to .
If all clusters are marked, i.e. we add an arbitrary cluster in to and assign volume for .
Subroutine Handle-Insertion.
The subroutine Handle-Insertion is called whenever a request at time corresponds to a vertex insertion . Subroutine Assign-Small is invoked to assign the singleton component .
Subroutine Unassign-Volume.
This subroutine takes as input a component which is currently assigned to a cluster . The quantity is decremented by and is set to . If and , is unmarked. The reason why is unmarked is that if , a small component can be assigned volume on , since the assigned volume for a small component is bounded by by Invariant 1. The pseudo-code is given as follows.
Subroutine Handle-Unmarked.
This subroutine takes as input a newly unmarked cluster . If the assigned volume , then is removed from the sets and . If , an arbitrary cluster is chosen and unmarked.
Else, if , Invariant 3 is restored as follows. Note that if and or and , nothing needs to be done since Invariant 3 is already maintained. Else, let denote an unmarked cluster where . While the residual volume of is sufficient (and is unmarked and ) small components from are migrated to . If the residual volume of is insufficient, is marked and added to . If at any point , is removed from and . Thereafter, if , and , an arbitrary cluster in is unmarked. If , and , an arbitrary cluster in is unmarked. The procedure continues while the residual volume of is sufficient. On the other hand, if is the only cluster in it is unmarked and the process terminates.
Subroutine Reassign-Large.
We give a subroutine Reassign-Large which is invoked whenever the number of large components of any class change. In Reassign-Large, the subroutine Assign-Signatures is invoked which returns the sets and of clusters (see Section 2.2).
Let denote the set of all small components assigned to clusters in . Small components currently assigned to clusters in are unassigned. Clusters in are unmarked and the set of active clusters is updated by removing clusters in and adding clusters in .
Next, let denote the set of large components which are not assigned to any cluster in . For all clusters , let be the signature assigned to cluster . For all non-zero where , a class large component is chosen from , and is invoked, concluding the the assignment of large components.
For small components , Assign-Small is invoked. Finally, for all unmarked clusters in , Handle-Unmarked is invoked. The pseudo code of Reassign-Large is deferred to the full version of the paper.
Subroutine Handle-Deletion.
We present a subroutine Handle-Deletion which takes as input a vertex to be deleted. We assume that Invariant 1 holds prior to the deletion request. Let denote the component containing prior to ’s deletion s.t. and denote the cluster to which is assigned. We consider two cases.
-
1.
is small and unmarked: Vertex is removed from . There are five sub-cases to consider.
-
(a)
If and , then is set to .
-
(b)
If and , then is set to .
-
(c)
If and , then is set to .
-
(d)
If and , then has become a class component. is set to .
-
(e)
If , is set to .
In all of the above cases, and are updated. If and , is removed from and Handle-Unmarked is invoked.
-
(a)
-
2.
is large or marked: We first remove from . We consider the following cases.
-
(a)
is large and unmarked (i.e. ): Our algorithm considers the following cases.
-
i.
If and , then is set to .
-
ii.
If and , then is set to .
-
iii.
If and , then is set to .
-
iv.
If , is marked. If then is set to .
In the above cases, if and , is removed from and Handle-Unmarked is invoked.
-
i.
-
(b)
is marked: There are two cases to consider depending on whether is large or small (after the deletion of ).
-
i.
Let be a marked large component of class where , such that . If , there is nothing to be done. Else, if , is unmarked. The counter is decremented since is now considered a class component, and is incremented. Then, the subroutine Reassign-Large is invoked.
-
ii.
Let be a marked small component of class . If , nothing is done. Else, if , is first unmarked. Then, is removed from and added to . The counter is decremented. Then, the subroutine Reassign-Large is invoked.
-
i.
-
(a)
The pseudo-code of Handle-Deletion is deferred to the full version of the paper.
Merge-Components.
The subroutine Merge-Components is invoked by our algorithm to handle a merge request . Let , denote the components of and respectively. If , nothing needs to be done. Otherwise, w.l.o.g., let and and denote the clusters on which and are currently assigned. Let .
-
1.
is small: The subroutine Handle-Small is called and considers two cases.
-
(a)
is marked: We note that cannot be a marked component since this would contradict that is small. This is because if is marked, then since . Thus, the only possibility is that is marked. Since any marked small component must have volume at least , and is small it follows that . In this case we note that so that can be set to . is removed from and is added to . If , is added to . As such, is still treated by our algorithm as a large marked component. If nothing needs to be done. Else, vertices in are migrated to , and Unassign-Volume( is invoked. Subroutine is invoked to handle the case when becomes unmarked.
-
(b)
and are not marked: In this case, there are two cases to consider.
-
i.
If , we set to and to . If , nothing needs to be done. If , vertices in are migrated to , and is invoked. Subroutine Handle-Unmarked is invoked to handle the case if becomes unmarked.
-
ii.
If , we invoke and . If , we call . If , we migrate vertices in to . We invoke Handle-Unmarked and Handle-Unmarked.
On the other hand, if , is marked and is invoked.
-
i.
-
(a)
-
2.
is large: The subroutine Handle-Large is invoked which adds to the set of large components.
Let be an integer such that . If is marked, i.e. , let be the integer where is an integer such that , else we let be the integer where is an integer such that . We consider the following cases.
-
(a)
is large or is marked or : If is marked, we let be the integer where is an integer such that . Else if is unmarked, we let be the integer where is an integer such that . We decrement and by 1, and increment by 1. We remove from to make sure that the set of marked components is updated. Thereafter, we update the component sets and call subroutine Reassign-Large to handle the assignment of large components.
-
(b)
is small and is unmarked and : In this case, we note that do not change. Thus, the ILP is not solved. We assign volume for the merged component as follows.
In the case when , vertices in are migrated to if . We invoke Unassign-Volume, and . Else, nothing needs to be done. The assigned volumes are set to . If is marked and , then is removed from and is added to . We note that in this case, .
If , then we invoke Unassign-Volume and .
If , we assign volume for on by invoking . If , we call Handle-Unmarked. Next, we call . In the case when (and as a result), we invoke .
If , we do the following. While , we call Unassign-Volume where is an arbitrary small component assigned on , and add it to a set . Once , we invoke and migrate vertices in to if needed (in the case when ) together with a call to Unassign-Volume. Next, we assign components in to as long as there is sufficient volume and is not marked. If all components in have been assigned and is unmarked, we call Handle-Unmarked.
If is unmarked, we invoke . All remaining unassigned components in (if any) are assigned by invoking . Finally, the component sets are updated.
-
(a)
The pseudo-code of subroutines Merge-Components, Handle-Small and Handle-Large are deferred to the full version of the paper.
We present the pseudo-code of our final online algorithm OBA that utilizes the aforementioned subroutines as follows.
3 Analysis of OBA
In this section, we give a proof sketch towards -competitiveness of our algorithm. Technical details of our proof, together with proofs of correctness and resource competitiveness are deferred to the full version of the paper.
Our analysis is intricate and relies on various charging arguments. At a high level, we show that a vertex can be assigned sufficient credit on insertion such that the total amount of credit on it at any point in time is sufficient to pay for the cost charged against it. The total credit on a vertex is the sum of its direct and indirect credits. Direct credit is a one-time credit assigned to on its insertion. Indirect credit on is credit passed on to it by other vertices which get deleted from ’s component.
Warm up: An insertions-only case.
Let us first consider a (finite) request sequence which only consists of insertion and merge requests. For this sequence, the assigned volume of any component containing a vertex monotonically increases over time, and no components are ever marked. We show that it suffices to charge each vertex an amount on its insertion. On ’s insertion, our algorithm assigns to an active cluster in , or makes a new cluster active and assigns to it. On a merge request between components and which are merged into a small component , where w.l.o.g., our algorithm always migrates vertices in to (in the case when ) as long as the cluster containing has sufficient residual volume. The first key observation is that for such a merge, all vertices in are now part of a component (i.e. ) with a larger component class. Thus, if or , only vertices in are migrated. Potentially some other vertices may be migrated to if becomes unmarked after volume is un-assigned due to the migration of (we ignore these costs for now). For any vertex , and the component containing , note that ’s component class increases monotonically over time due to merge requests. The number of component classes, which is bounds the number of times the component class can increase.
On the other hand, if is insufficient to accommodate vertices in (i.e. in the case when and ), vertices in both and are migrated to another cluster. Note that in this case, . Since there are at most possible values that assigned volumes can take, and assigned volume increases monotonically for any component, each vertex can migrate only times in this manner.
Crucially, we note that if the component containing becomes large (or is large and its component class increases), a total of migration cost may be incurred, by Lemma 10. This migration cost can be incurred a total of times. By definition, a has size at least ; we charge the migration cost to all vertices in . Thus, each vertex in contributes at least credit a total of times. Therefore, a credit of on a vertex is sufficient to pay for migrations of this type.
We now analyze the potential migration costs incurred when a component migrates from one cluster (say ) to , which may lead to a call to leading to components migrations to . To account for these costs, a cluster credit is left on when migrates to , and each vertex in is charged an amount . As a result, each time the residual volume of a cluster increases, there is enough cluster credit to pay for successive migrations (as part of Handle-Unmarked). Note that in subroutine Handle-Unmarked, only small components are migrated from an unmarked cluster, and the total amount of migrated components is proportional to the increase in residual volume. Thus, a vertex is charged for cluster credit each time its component is promoted to a higher class or its assigned volume increases. Since the number of choices for assigned volumes (and component classes) is , any vertex is charged in this manner.
By the above, it follows that assigning a one-time direct credit of on each vertex on its insertion is sufficient. Since is lower bounded by the number of vertex insertions, this yields competitiveness.
The General Case.
Let us consider the case when the request sequence consists of insertions, merges and deletions. In this case, the component class of any component and its assigned volume do not necessarily increase over time, in general. Thus, direct credit on is insufficient, and our analysis crucially relies on indirect credit. Indirect credit is assigned to any vertex in the following manner: whenever a vertex is deleted from ’s component , an amount of indirect credit is distributed to all remaining vertices in . Some credit is also left as cluster credit on the cluster containing on ’s deletion. Cluster credit is used to pay for re-balancing and migrating components as in the previous case. The total indirect credit assigned to vertices in , together with cluster credit that is left on ’s deletion is charged against vertex . On the other hand, the total credit assigned to a vertex is the sum of the direct credit and indirect credit distributed to it by other vertices. Let denote the component containing . We show that even in the case of deletions, it suffices to assign a direct credit of to vertex upon insertion, which is used to pay for:
-
1.
the unit migration cost incurred each time is promoted to a component class for the first time, or the assigned volume of increases for the first time as in the previous case.
-
2.
indirect credit assigned to vertices in upon the deletion of .
-
3.
cluster credit assigned to the cluster containing , upon ’s deletion.
-
4.
cluster credit assigned to the cluster containing , before is migrated to another cluster as a result of being promoted to either a component class for the first time, or an increase in its assigned volume for the first time.
Consider a vertex and let denote an (unmarked) component containing with assigned volume . Upon vertex deletions from , may decrease. Suppose for some . Consider a set of deleted vertices which lead to a reduction in ’s assigned volume to . For this to happen, . On the other hand, , after vertices in are deleted. For each vertex in , we distribute a total indirect credit of uniformly to all remaining vertices in . As a result, the total indirect credit gained by each remaining vertex in is at least after all vertices in are deleted. The indirect credit gained by any vertex in is used to pay for: i) a single future migration of a vertex which leads to an increase in either the assigned volume of ’s component or the component class of ’s component and ii) leave cluster credit when the aforementioned migration happens.
Next, consider the time when a component is marked, such that where . Once , this leads to either a call to Reassign-Large (if is large) or is treated as a small component thereafter (see Handle-Deletion). Since has size at most , this implies that at least fraction of vertices in are deleted before either of these events happen. The total migration and reassignment cost incurred due to Reassign-Large is by Lemma 10. To pay for this cost, leave an indirect credit of on each remaining vertex in , and assign a cluster credit of , it suffices to charge each deleted vertex from an amount . The cluster credit is used to pay for the migration cost of vertices to if becomes unmarked. The amount charged against a deleted vertex is paid by the direct credit assigned to upon its insertion.
By the above, it follows that assigning a direct credit of to a vertex upon its insertion is sufficient. Since is lower bounded by the number of vertices inserted over all time, this yields competitiveness for constant .
4 OBADC with Predictions
In this section, we present our algorithm for OBADC which is augmented with machine learned predictions. The problem formulation and objectives are identical as in the standard un-augmented setup. At each time step , a request which corresponds to either a vertex insertion, deletion or a merge between two components is issued. At any given point in time, an online algorithm is required to maintain an assignment of components to clusters, while respecting the over-provisioned cluster capacity of , such that all vertices in any component are assigned to the same cluster. In light of the lower bound on the competitiveness of any randomized algorithm, it is natural to ask whether this barrier can be circumvented given oracle access to machine-learned predictions to guide the assignment of components. To this end, we recap our prediction model.
Prediction Model.
Let denote the set of vertices at the beginning of time . For a request at time which corresponds to an insertion of vertex , we obtain:
-
1.
with probability , a predicted set of all vertices in which will be in the same component as .
-
2.
with probability , a null prediction, i.e. . Thus no information is revealed on the insertion of .
We present an algorithm Predicted-OBA which is -consistent and -robust. This algorithm is similar in many ways to our competitive algorithm OBA. We utilize identical data structures, definitions and subroutines as detailed in Section 2. We also maintain Invariants 1 through 4 as in Section 2.
Our algorithm Predicted-OBA is as follows.
We give an additional subroutine, Predicted-Insertion as follows.
Subroutine Predicted-Insertion.
This subroutine takes as input a vertex inserted at time and a predicted set consisting of vertices at time that will be in the same component as . If , the subroutine Handle-Insertion is invoked. Else, a set of merge requests is created where . For each merge request in , the subroutine Merge-Components is invoked.
The following lemma bounds the competitive ratio of Algorithm Predicted-OBA.
Lemma 11.
Algorithm Predicted-OBA is -competitive.
We build towards a proof of Lemma 11 in the following. We first analyze the probability of a merge request being incident to vertices in distinct components , as a function of component sizes.
Lemma 12.
Let be a merge request between components and at time , such that without loss of generality. Then, the probability that is bounded by .
Proof.
We note that if , then for at least insertions of vertices , . Since the probability that for any is , it follows that for vertex insertions, the probability that all predicted sets are empty is bounded by .
We define monotonic merges as follows.
Definition 13 (Monotonic Merge).
Let be the component containing vertex at any point in time throughout ’s lifetime. Let and be time-steps s.t. is inserted at time and deleted at time . A merge request involving components and at time is said to be a monotonic merge for if and one of the following holds:
-
1.
The assigned volume of is set to by our algorithm where for the first time during time interval .
-
2.
The component class of is set to by our algorithm for the first time during time interval .
A merge request for is non-monotonic if it is not monotonic.
Lemma 14.
The expected number of monotonic merge requests for any vertex including merge requests created by Subroutine Predicted-Insertion is bounded by .
Proof.
Let denote the component of , such that is inserted at time and deleted at time . Let , so that a class component has volume in . By Lemma 12, the probability that a merge request involving where is the smaller of the two components and belongs to class , is bounded by . Thus, the expected number of monotonic merge requests for is bounded by
Proof Sketch of Lemma 11.
Let us recall the analysis of -competitiveness of our algorithm OBA. We argued that it suffices to leave a direct credit of on any vertex upon its insertion, which is sufficient to pay for: i) migration costs and cluster credits charged against for both monotonic and non-monotonic merges and, ii) cluster and indirect credits charged against upon its deletion. The term comes from the fact a vertex can be part of monotonic merges for a total of times, and is charged times for merges while is small. On the other hand, for a non-monotonic merge, is charged an amount to pay for its migration cost and leave cluster credit if the residual volume of the cluster is assigned to, is no longer sufficient to accommodate an increase in . Since the number of choices for assigned volumes is , the total cost charged against for non-monotonic merges is .
We modify our charging argument for non-monotonic merges as follows. Ignoring the reassignment of components that takes place as a result of subroutine Handle-Unmarked for the sake of clarity, we crucially observe that whenever the residual volume of ’s cluster (denoted by ) decreases, it is due to either: i) vertices in a smaller component involved in a merge request migrate to , or ii) new vertices are inserted to ’s cluster. We modify our charging argument such that the migrated or inserted vertex in the above cases leaves extra cluster credit on . Thus, whenever the residual volume of decreases by , these extra cluster credits can be used to pay for non-monotonic merges involving vertices already assigned on . As a result, we focus on the cost charged for monotonic merges in the remainder of the analysis.
By Lemma 14, it follows that the expected number of monotonic merges for a vertex is bounded by . By our analysis of OBA, it follows that the expected cost charged to a vertex for monotonic merges is . Thus, an expected credit of is sufficient for monotonic merges. On the other hand, when a vertex is deleted, we charge an amount to it which is assigned as indirect credit and cluster credit. As a result, it follows that a total direct credit of in expectation, is sufficient to pay for all costs charged against throughout its lifetime.
This yields -competitiveness. On the other hand, as , the behavior of algorithm Predicted-OBA resembles the behavior of algorithm OBA, and thus, the competitiveness of Predicted-OBA is bounded by in the worst-case. This yields -competitiveness. The following lemma establishes competitiveness when . The proof is deferred to the full version of the paper.
Lemma 15.
Algorithm Predicted-OBA is consistent.
5 Future Work
Our model for OBADC is restrictive in the sense that component sizes decrease only as a result of vertex deletions; in particular, our model does not allow for splitting of existing components. We believe that such a model will be much more challenging to handle; indeed, it could be considered as a generalization of the general model of OBGR, for which there is a significant gap between the upper and lower bounds for the best competitive ratio achievable.
In this work, we introduced the OBADC and studied it in the context of machine-learned predictions. It would be interesting to extend our prediction model to the case when predictions are always available but may be erroneous. Other prediction models for online balanced allocation problems would be worth exploring.
References
- [1] Khaled Almi’ani, Young Choon Lee, and Bernard Mans. Resource demand aware scheduling for workflows in clouds. In 2017 IEEE 16th International Symposium on Network Computing and Applications (NCA), pages 1–5. IEEE, 2017.
- [2] Chen Avin, Marcin Bienkowski, Andreas Loukas, Maciej Pacut, and Stefan Schmid. Dynamic balanced graph partitioning. SIAM Journal on Discrete Mathematics, 34(3):1791–1812, 2020. doi:10.1137/17M1158513.
- [3] Yossi Azar, Chay Machluf, Boaz Patt-Shamir, and Noam Touitou. Competitive Vertex Recoloring. In Mikołaj Bojańczyk, Emanuela Merelli, and David P. Woodruff, editors, 49th International Colloquium on Automata, Languages, and Programming (ICALP 2022), volume 229 of Leibniz International Proceedings in Informatics (LIPIcs), pages 13:1–13:20, Dagstuhl, Germany, 2022. Schloss Dagstuhl – Leibniz-Zentrum für Informatik. doi:10.4230/LIPIcs.ICALP.2022.13.
- [4] Marcin Bienkowski, Martin Böhm, Martin Koutecký, Thomas Rothvoß, Jiří Sgall, and Pavel Veselý. Improved analysis of online balanced clustering. In Approximation and Online Algorithms: 19th International Workshop, WAOA 2021, Lisbon, Portugal, September 6–10, 2021, Revised Selected Papers, pages 224–233, Berlin, Heidelberg, 2021. Springer-Verlag. doi:10.1007/978-3-030-92702-8_14.
- [5] Jan van den Brand, Sebastian Forster, Yasamin Nazari, and Adam Polak. On dynamic graph algorithms with predictions. In Proceedings of the 2024 Annual ACM-SIAM Symposium on Discrete Algorithms (SODA), pages 3534–3557. SIAM, 2024. doi:10.1137/1.9781611977912.126.
- [6] Prasad Calyam, Sripriya Seetharam, Baisravan Homchaudhuri, and Manish Kumar. Resource defragmentation using market-driven allocation in virtual desktop clouds. In 2015 IEEE International Conference on Cloud Engineering, pages 246–255. IEEE, 2015. doi:10.1109/IC2E.2015.37.
- [7] Jiuxin Cao, Zhuo Ma, Jue Xie, Xiangying Zhu, Fang Dong, and Bo Liu. Towards tenant demand-aware bandwidth allocation strategy in cloud datacenter. Future Generation Computer Systems, 105:904–915, 2020. doi:10.1016/J.FUTURE.2017.06.005.
- [8] Vincent Cohen-Addad, Tommaso d’Orsi, Anupam Gupta, Euiwoong Lee, and Debmalya Panigrahi. Max-cut with -accurate predictions. arXiv preprint arXiv:2402.18263, 2024.
- [9] Hancong Duan, Chao Chen, Geyong Min, and Yu Wu. Energy-aware scheduling of virtual machines in heterogeneous cloud computing systems. Future Generation Computer Systems, 74:142–150, 2017. doi:10.1016/J.FUTURE.2016.02.016.
- [10] Tobias Forner, Harald Räcke, and Stefan Schmid. Online balanced repartitioning of dynamic communication patterns in polynomial time. In Symposium on Algorithmic Principles of Computer Systems (APOCS), pages 40–54, 2021. doi:10.1137/1.9781611976489.4.
- [11] Anupam Gupta, Debmalya Panigrahi, Bernardo Subercaseaux, and Kevin Sun. Augmenting online algorithms with -accurate predictions. Advances in neural information processing systems, 35:2115–2127, 2022.
- [12] Sijin He, Li Guo, and Yike Guo. Real time elastic cloud management for limited resources. In 2011 IEEE 4th International Conference on Cloud Computing, pages 622–629. IEEE, 2011. doi:10.1109/CLOUD.2011.47.
- [13] Monika Henzinger, Stefan Neumann, Harald Räcke, and Stefan Schmid. Tight Bounds for Online Graph Partitioning, pages 2799–2818. Society for Industrial and Applied Mathematics, USA, 2021.
- [14] Monika Henzinger, Stefan Neumann, and Stefan Schmid. Efficient distributed workload (re-)embedding. In Abstracts of the 2019 SIGMETRICS/Performance Joint International Conference on Measurement and Modeling of Computer Systems, SIGMETRICS ’19, pages 43–44, New York, NY, USA, 2019. Association for Computing Machinery. doi:10.1145/3309697.3331503.
- [15] Thodoris Lykouris and Sergei Vassilvitskii. Competitive caching with machine learned advice. Journal of the ACM (JACM), 68(4):1–25, 2021. doi:10.1145/3447579.
- [16] Zoltán Ádám Mann. Allocation of virtual machines in cloud data centers—a survey of problem models and optimization algorithms. Acm Computing Surveys (CSUR), 48(1):1–34, 2015. doi:10.1145/2797211.
- [17] Suhib Bani Melhem, Anjali Agarwal, Nishith Goel, and Marzia Zaman. Markov prediction model for host load detection and vm placement in live migration. IEEE Access, 6:7190–7205, 2017. doi:10.1109/ACCESS.2017.2785280.
- [18] Michael Mitzenmacher and Sergei Vassilvitskii. Algorithms with predictions. Communications of the ACM, 65(7):33–35, 2022. doi:10.1145/3528087.
- [19] Saloua El Motaki, Ali Yahyaouy, and Hamid Gualous. A prediction-based model for virtual machine live migration monitoring in a cloud datacenter. Computing, 103(11):2711–2735, 2021. doi:10.1007/S00607-021-00981-3.
- [20] Maciej Pacut, Mahmoud Parham, and Stefan Schmid. Optimal online balanced partitioning. In INFOCOM 2021, 2021.
- [21] Cynthia A. Phillips, Cliff Stein, Eric Torng, and Joel Wein. Optimal time-critical scheduling via resource augmentation (extended abstract). In Proceedings of the Twenty-Ninth Annual ACM Symposium on Theory of Computing, STOC ’97, pages 140–149, New York, NY, USA, 1997. Association for Computing Machinery. doi:10.1145/258533.258570.
- [22] Rajmohan Rajaraman and Omer Wasim. Improved bounds for online balanced graph re-partitioning. In 30th Annual European Symposium on Algorithms (ESA 2022), 2022. doi:10.4230/LIPIcs.ESA.2022.83.
- [23] Rajmohan Rajaraman and Omer Wasim. Competitive capacitated online recoloring. In 32nd Annual European Symposium on Algorithms (ESA 2024), 2024. doi:10.4230/LIPIcs.ESA.2024.95.
- [24] Dhruv Rohatgi. Near-optimal bounds for online caching with machine learned advice. In Proceedings of the Fourteenth Annual ACM-SIAM Symposium on Discrete Algorithms, pages 1834–1845. SIAM, 2020. doi:10.1137/1.9781611975994.112.
- [25] Tim Roughgarden. Beyond the worst-case analysis of algorithms. Cambridge University Press, 2021.
- [26] A. Schrijver. Theory of linear and integer programming. In Wiley-Interscience series in discrete mathematics and optimization, 1999.
- [27] Alexander Schrijver. Theory of linear and integer programming. John Wiley & Sons, 1998.
- [28] Jaspreet Singh and Navpreet Kaur Walia. A comprehensive review of cloud computing virtual machine consolidation. IEEE Access, 11:106190–106209, 2023. doi:10.1109/ACCESS.2023.3314613.
- [29] Daniel D. Sleator and Robert E. Tarjan. Amortized efficiency of list update and paging rules. Commun. ACM, 28(2):202–208, February 1985. doi:10.1145/2786.2793.
- [30] Mukundan Sridharan, Prasad Calyam, Aishwarya Venkataraman, and Alex Berryman. Defragmentation of resources in virtual desktop clouds for cost-aware utility-optimal allocation. In 2011 Fourth IEEE International Conference on Utility and Cloud Computing, pages 253–260. IEEE, 2011. doi:10.1109/UCC.2011.41.
- [31] Ruitao Xie, Xiaohua Jia, Kan Yang, and Bo Zhang. Energy saving virtual machine allocation in cloud computing. In 2013 IEEE 33rd International Conference on Distributed Computing Systems Workshops, pages 132–137. IEEE, 2013. doi:10.1109/ICDCSW.2013.37.
- [32] Hiroki Yanagisawa, Takayuki Osogami, and Rudy Raymond. Dependable virtual machine allocation. In 2013 Proceedings IEEE INFOCOM, pages 629–637. IEEE, 2013. doi:10.1109/INFCOM.2013.6566848.
- [33] N. Young. The -server dual and loose competitiveness for paging. Algorithmica, 11(6):525–541, June 1994. doi:10.1007/BF01189992.
- [34] Neal E. Young. On-line file caching. In Proceedings of the Ninth Annual ACM-SIAM Symposium on Discrete Algorithms, SODA ’98, pages 82–86, USA, 1998. Society for Industrial and Applied Mathematics. URL: http://dl.acm.org/citation.cfm?id=314613.314658.