An Improved Bound for Minimizing the Total Weighted Completion Time of Coflows in Datacenters

TL;DR

This paper presents a new polynomial-time deterministic algorithm for scheduling coflows in datacenter networks, achieving better approximation ratios than previous methods for minimizing total weighted completion time.

Contribution

It introduces an improved linear programming formulation and a simple list scheduling policy that together yield a better approximation ratio for coflow scheduling.

Findings

The algorithm achieves an approximation ratio of 5, improving from 12.

For coflows released at time zero, the ratio improves to 4 from 8.

Simulation results confirm the algorithm's superior performance over prior approaches.

Abstract

In data-parallel computing frameworks, intermediate parallel data is often produced at various stages which needs to be transferred among servers in the datacenter network (e.g. the shuffle phase in MapReduce). A stage often cannot start or be completed unless all the required data pieces from the preceding stage are received. \emph{Coflow} is a recently proposed networking abstraction to capture such communication patterns. We consider the problem of efficiently scheduling coflows with release dates in a shared datacenter network so as to minimize the total weighted completion time of coflows. Several heuristics have been proposed recently to address this problem, as well as a few polynomial-time approximation algorithms with provable performance guarantees. Our main result in this paper is a polynomial-time deterministic algorithm that improves the prior known results. Specifically, we propose a deterministic algorithm with approximation ratio of $5$, which improves the prior best known ratio of $12$. For the special case when all coflows are released at time zero, our deterministic algorithm obtains approximation ratio of $4$ which improves the prior best known ratio of $8$. The key ingredient of our approach is an improved linear program formulation for sorting the coflows followed by a simple list scheduling policy. Extensive simulation results, using both synthetic and real traffic traces, are presented that verify the performance of our algorithm and show improvement over the prior approaches.

Figures

Tables

Table 1. TABLE I : Performance guarantees (Approximation ratios)

Case	Best known	This paper
	deterministic   randomized	deterministic
Without release dates	$8$ [17, 18]    $2e$ [18]	$4$
With release dates	$12$ [17, 18]    $3e$ [18]	$5$

Table 2. TABLE II : Performance Ratio of Algorithm  1

Case	Equal weights	Random weights
Without release dates	$1.05$	$1.06$
With release dates	$1.034$	$1.038$

Equations

$$f_k=\underset{i\in \mathcal{I},j\in \mathcal{J}}{\max }{f}_{ij}^k,$$

$$T=\underset{k\in \mathcal{K}}{\max }{r}_k+\sum _{k\in \mathcal{K}}\sum _{i\in \mathcal{I}}\sum _{j\in \mathcal{J}}{d}_{ij}^k.$$

$$\sum _{k=1}^K{w}_k{f}_k$$

$$f_k\ge f_{ij}^k,i\in \mathcal{I},j\in \mathcal{J},k\in \mathcal{K}$$

$$d_{ij}^k={\int }_0^{f_{ij}^k}{x}_{ij}^k(t)dt,i\in \mathcal{I},j\in \mathcal{J},k\in \mathcal{K}$$

$$\sum _j\sum _k{x}_{ij}^k(t)\le 1,i\in \mathcal{I},t\in [0,T]$$

$$\sum _i\sum _k{x}_{ij}^k(t)\le 1,j\in \mathcal{J},t\in [0,T]$$

$$x_{ij}^k(t)=0,\forall t<r_k,i\in \mathcal{I},j\in \mathcal{J},k\in \mathcal{K}$$

$$x_{ij}^k(t)\ge 0,i\in \mathcal{I},j\in \mathcal{J},k\in \mathcal{K},t\in [0,T]$$

$$d_i^k=\sum _{j\in \mathcal{J}}{d}_{ij}^k;d_j^k=\sum _{i\in \mathcal{I}}{d}_{ij}^k,$$

$$W(k)=\max \{\underset{i\in \mathcal{I}}{\max }{d}_i^k,\underset{j\in \mathcal{J}}{\max }{d}_j^k\}.$$

$${\Gamma }^k=\max \{\underset{i\in \mathcal{I}}{\max }\frac{d_i^k}{Rem(i)},\underset{j\in \mathcal{J}}{\max }\frac{d_j^k}{Rem(j)}\},$$

$$\displaystyle\mathbf{(IP)}\ \min\ \$$

$$f_k\ge d_i^k+\sum _{k^{\prime }\in \mathcal{K}}{d}_i^{k^{\prime }}{\delta }_{k^{\prime }k}i\in \mathcal{I},k\in \mathcal{K}$$

$$f_k\ge d_j^k+\sum _{k^{\prime }\in \mathcal{K}}{d}_j^{k^{\prime }}{\delta }_{k^{\prime }k}j\in \mathcal{J},k\in \mathcal{K}$$

$$f_k\ge W(k)+r_{k}k\in \mathcal{K}$$

$${\delta }_{k{k}^{\prime }}+{\delta }_{k^{\prime }k}=1k,k^{\prime }\in \mathcal{K}$$

$${\delta }_{k{k}^{\prime }}\in \{0,1\}k,k^{\prime }\in \mathcal{K}$$

$$\displaystyle\delta_{12}=1,\ \$$

$$\displaystyle\delta_{13}=1,\ \$$

$$\displaystyle f_{1}=1,\ \$$

$$\displaystyle f_{3}=3,\ \$$

$$\displaystyle\mathbf{(LP)}\ \min\ \$$

$$\text{(refmatching1) – (refprec1)},$$

$${\delta }_{k{k}^{\prime }}\in [0,1]k,k^{\prime }\in \mathcal{K}$$

$${\tilde{f}}_1\le {\tilde{f}}_2\le ...\le {\tilde{f}}_K.$$

$${\tilde{f}}_1\le {\tilde{f}}_2\le ...\le {\tilde{f}}_K,$$

$$W(1,\cdots ,k;s)=\sum _{l=1}^k{d}_s^l$$

$$W(1,\cdots ,k)=\underset{s\in \mathcal{I}\cup \mathcal{J}}{\max }W(1,\cdots ,k;s)$$

$$d_i^l\widetilde{f_l}\ge (d_i^l{)}^2+\sum _{l^{\prime }\in \mathcal{K}}{d}_i^l{d}_i^{l^{\prime }}{\delta }_{l^{\prime }l}$$

$$\sum _{l=1}^k{d}_i^l\widetilde{f_l}\ge$$

$$=$$

$$\displaystyle+\sum_{l=1}^{k}\sum_{l^{\prime}=1}^{k}\big{(}d_{i}^{l^{\prime}}d_{i}^{l}\delta_{l^{\prime}l}+d_{i}^{l^{\prime}}d_{i}^{l}\delta_{ll^{\prime}}\big{)}\bigg{)}$$

$$\sum _{l=1}^k(d_i^l{)}^2+\sum _{l=1}^k\sum _{l^{\prime }=1}^k{d}_i^{l^{\prime }}{d}_i^l=(\sum _{l=1}^k{d}_i^l{)}^2,$$

$$\sum _{l=1}^k{d}_i^l\widetilde{f_l}\ge$$

$$\ge$$

$$\sum _{l=1}^k{d}_j^l\widetilde{f_l}\ge \frac{1}{2}(W(1,\cdots ,k;j){)}^2.$$

$$\widetilde{f_k}W(1,\cdots ,k;s^{\star })$$

$$\ge \sum _{l=1}^k{d}_{s^{\star }}^l\widetilde{f_l}$$

$$\ge \frac{1}{2}(W(1,\cdots ,k;s^{\star }){)}^2$$

$$\widetilde{f_k}\ge \frac{1}{2}W(1,\cdots ,k;s^{\star })=\frac{1}{2}W(1,\cdots ,k).$$

Full text

I Introduction

Many data-parallel computing applications (e.g. MapReduce [2], Hadoop [3, 4], Dryad [5], etc.) consist of multiple computation and communication stages or have machines grouped by functionality. While computation involves local operations in servers, communication takes place at the level of machine groups and involves transfer of many pieces of intermediate data across groups of machines for further processing. In such applications, the collective effect of all the flows between the two machine groups is more important than that of any of the individual flows. A computation stage often cannot start unless all the required data pieces from the preceding stage are received, or the application latency is determined by the transfer of the last flow between the groups [6, 7]. For example, consider a MapReduce application: Each mapper performs local computations and writes intermediate data to the disk, then each reducer pulls intermediate data from different mappers, merges them, and computes its output. The job will not finish until its last reducer is completed. Consequently, the job completion time depends on the time that the last flow of the communication phase (called shuffle) is finished. Such intermediate communication stages in a data-parallel application can account for more than $50\%$ of the job completion time [8], and hence can have a significant impact on application performance. Optimizing flow-level performance metrics (e.g. the average flow completion time) have been extensively studied before from both networking systems and theoretical perspective (see, e.g., [9, 10, 11] and references there.), however, these metrics ignore the dependence among the flows of an application which is required for the application-level performance.

Recently Chowdhury and Stoica [12] have introduced the coflow abstraction to capture these communication patters. A coflow is defined as a collection of parallel flows whose completion time is determined by the completion time of the last flow in the collection. Coflows can represent most communication patterns between successive computation stages of data-parallel applications [6]. Clearly the traditional flow communication is still a coflow with a single flow. Jobs from one or more data-parallel applications create multiple coflows in a shared datacenter network. These coflows could vary widely in terms of the total size of the parallel flows, the number of the parallel flows, and the size of the individual flows in the coflows (e.g., see the analysis of production traces in [6]). Classical flow/job scheduling algorithms do not perform well in this environment [6] because each coflow consists of multiple flows– whose completion time is dominated by its slowest flow– and further, the progress of each flow depends on its assigned rate at both its source and its destination. This coupling of rate assignments between the flows in a coflow and across the source-destination pairs in the network is what makes the coflow scheduling problem considerably harder than the classical flow/job scheduling problems.

In this paper, we study the coflow scheduling problem, namely, the algorithmic task of determining when to start serving each flow and at what rate, in order to minimize the weighted sum of completion times of coflows in the system. In the case of equal weights, this is equivalent to minimizing the average completion time of coflows.

I-A Related Work

Several scheduling heuristics have been already proposed in the literature for scheduling coflows, e.g. [7, 6, 13, 14]. A FIFO-based solution was proposed in [7] which also uses multiplexing of coflows to avoid starvation of small flows which are blocked by large head-of-line flows. A Smallest-Effective-Bottleneck-First heuristic was introduced in Varys [6]: it sorts the coflows in an ascending order in a list based on their maximum loads on the servers, and then assigns rates to the flows of the first coflow in the list such that all its flows finish at the same time. The remaining capacity is distributed among the rest of the coflows in the list in a similar fashion to avoid under-utilization of the network. Similar heuristics without prior knowledge of coflows were introduced in Aalo [14]. A joint scheduling and routing of coflows in datacenter networks was introduced in [13] where similar heuristics based on a Minimum-Remaining-Time-First policy are developed. In [15], an algorithm is proposed to provide max-min fairness among the colfows.

Here, we would like to highlight three papers [16, 17, 18] that are more relevant to our work. These papers consider the problem of minimizing the total weighted completion time of coflows with release dates (i.e., coflows arrive over time.) and provide algorithms with provable guarantees. This problem is shown to be NP-complete through its connection with the concurrent open shop problem [6, 16], and then approximation algorithms are proposed which run in polynomial time and return a solution whose value is guaranteed to be within a constant fraction of the optimal (a.k.a., approximation ratio). These papers rely on linear programming relaxation techniques from combinatorial scheduling literature (see, e.g., [19, 20, 21]). In [16], the authors utilize an interval-indexed linear program formulation which helps partitioning the coflows into disjoint groups. All coflows that fall into one partition are then viewed as a single coflow, where a polynomial-time algorithm is used to optimize its completion time. Authors in [17] have recently constructed an instance of the concurrent open shop problem (see [22] for the problem definition) from the original coflow scheduling problem. Then applying the well-known approximation algorithms for the concurrent open shop problem to the constructed instance, an ordering of coflows is obtained which is then used in a similar fashion as in [16] to obtain an approximation algorithm. The deterministic algorithm in [17] has better approximation ratios compared to [16], for both cases of with and without release dates. In [18], a linear program approach based on ordering variables is utilized to develop two algorithms, one deterministic and the other randomized. The deterministic algorithm gives the same bounds as in [17], while the randomized algorithm has better performance approximation ratios compared to [16, 17], for both cases of with and without release dates.

I-B Contribution

In this paper, we consider the problem of minimizing the total weighted coflow completion time. Our main contributions can be summarized as follows.

$\bullet$ Scheduling Algorithm. We use a Linear Program (LP) approach based on ordering variables followed by a simple list scheduling policy to develop a deterministic algorithm. Our approach improves the prior algorithms in both cases of with and without release dates. Table I summarizes our results in comparison with the prior best-known performance bounds. Performance of a deterministic (randomized) algorithm is defined based on approximation ratio, i.e., the ratio between the (expected) weighted sum of coflow completion times obtained by the algorithm and the optimal value. When coflows have release dates (which is often the case in practice as coflows are generated at different times), our deterministic algorithm improves the approximation ratio of $12$ [17, 18] to $5$, which is also better than the best known randomized algorithm proposed in [18] with approximation ratio of $3e$ ($\approx 8.16$). When all coflows have release times equal to zero, our deterministic algorithm has approximation ratio of $4$ while the best prior known result is $8$ [17, 18] for deterministic and $2e$ $(\approx 5.436)$ [18] for randomized algorithms.

$\bullet$ Empirical Evaluations. We evaluate the performance of our algorithm, compared to the prior approaches, using both syntectic traffic as well as real traffic based on a Hive/MapReduce trace from a large production cluster at Facebook. Both synthetic and empirical evaluations show that our deterministic algorithm indeed outperforms the prior approaches. For instance, for the Facebook trace with general release dates, our algorithm outperforms Varys [6], deterministic algorithm proposed in [16], and deterministic algorithm proposed in [18] by $24\%$, $40\%$, and $19\%$, respectively.

II System Model and Problem Formulation

Datecenter Network

Similar to [6, 16], we abstract out the datacenter network as one giant $N\times N$ non-blocking switch, with $N$ input links connected to $N$ source servers and $N$ output links connected to $N$ destination servers. Thus the network can be viewed as a bipartite graph with source nodes denoted by set ${\mathcal{I}}$ on one side and destination nodes denoted by set ${\mathcal{J}}$ on the other side. Moreover, there are capacity constraints on the input and output links. For simplicity, we assume all links have equal capacity (as in [16]); nevertheless, our method can be easily extended to the general case where the links have unequal capacities. Without loss of generality, we assume that all the link capacities are normalized to one.

Scheduling Constraints

We allow a general class of scheduling algorithms where the rate allocation can be performed continuously over time, i.e., for each flow, fractional data units can be transferred from its input link to its corresponding output link over time as long as link capacity constraints are respected. In the special case that the rate allocation is restricted to data units (packets), each source node can send at most one packet in every time unit (time slot) and each destination node can receive at most one packet in every time slot, and the feasible schedule has to form a matching of the switch’s bipartite graph. In this case, our model reduces to the model in [16] and, as it is shown later, our proposed algorithm will respect the matching constraints, therefore, it is compatible with both models.

Coflow

A coflow is a collection of flows whose completion time is determined by the completion time of the latest flow in the collection. The coflow $k$ can be denoted as an $N\times N$ demand matrix $D^{(k)}$. Every flow is a triple $(i,j,k)$, where $i\in{\mathcal{I}}$ is its source node, $j\in{\mathcal{J}}$ is its destination node, and $k$ is the coflow to which it belongs. The size of flow $(i,j,k)$ is denoted by $d_{ij}^{k}$, which is the $(i,j)$-th element of the matrix $D^{(k)}$. For simplicity, we assume that all flows within a coflow arrive to the system at the same time (as in [16]); however, our results still hold for the case that flows of a coflow are released at different times (which could indeed happen in practice [14]). A $3\times 3$ switch architecture is shown in Figure 1 as an example, where a coflow is illustrated by means of input queues, e.g., the file in the $j$-th queue at the source link $i$ indicates that the coflow has a flow from source server $i$ to destination server $j$. For instance, in Figure 1, the illustrated coflow has $7$ flows in total, while two of its flows have source server $1$, one goes to destination server $1$ and the other to destination server $3$.

Total Weighted Coflow Complettion Time

We consider the coflow scheduling problem with release dates. There is a set of $K$ coflows denoted by ${\mathcal{K}}$. Coflow $k\in{\mathcal{K}}$ is released (arrives) at time $r_{k}$ which means it can only be scheduled after time $r_{k}$. We use $f_{k}$ to denote the finishing (completion) time of coflow $k$, which, by definition of coflow, is the time when all its flows have finished processing. In other words, for every coflow $k\in{\mathcal{K}}$,

[TABLE]

where $f_{ij}^{k}$ is the completion time of flow $(i,j,k)$.

For given positive weights $w_{k}$, $k\in{\mathcal{K}}$, the goal is to minimize the weighted sum of coflow completion times: $\sum_{k=1}^{K}w_{k}f_{k}$. The weights can capture different priority for different coflows. In the special case that all the weights are equal, the problem is equivalent to minimizing the average coflow completion time.

Define

[TABLE]

Note that $T$ is clearly an upper bound on the minimum time required for processing of all the coflows. We denote by $x_{ij}^{k}(t)$ the transmission rate assigned to flow $(i,j,k)$ at time $t\in[0,T]$. Then the optimal rate control must solve the following minimization problem

[TABLE]

In the above, the constraint (3b) indicates that each coflow $k$ is completed when all its flows have been completed. Note that since the optimization (3) is a minimization problem, a coflow completion time is equal to the completion time of its latest flow, in agreement with (1). The constraint (3c) ensures that the demand (file size) of every flow, $d_{ij}^{k}$, is transmitted by its completion time, $f_{ij}^{k}$. Constraints (3d) and (3e) state the capacity constraints on source links and destination links, respectively. The fact that a flow cannot be transmitted before its release date (which is equal to release date of its corresponding coflow) is captured by the constraint (3f). Finally, the constraint (3g) simply states that the rates are non-negative.

III Motivations and Challenges

The coflows can be widely different in terms of the number of parallel flows, the size of individual flows, the groups of servers involved, etc. Heuristics from traditional flow/task scheduling, such as shortest- or smallest-first policies [23, 24], do not have a clear equivalence in coflow scheduling. One can define a shortest or smallest-first policy based on the number of parallel flows in a coflow, or the aggregate flow sizes in a coflow, however these policies perform poorly [6], as they do not completely take all the characteristics of coflows into consideration.

Recall that the completion time of a coflow is dominated by its slowest flow (as described by (1) or (3b)). Hence, it makes sense to slow down all the flows in a coflow to match the completion time of the flow that will take the longest to finish. The unused capacity then can be used to allow other coexisting coflows to make progress and the total (or average) coflow completion time decreases. Varys [6] is the first heuristic that effectively implements this intuition by combining Smallest-Effective-Bottleneck-First and Minimum-Allocation-for-Desired-Duration policies. Before describing Varys, we present a few definitions that are used in the rest of this paper.

Definition 1** (Aggregate Size and Effective Size of a Coflow).**

Let

[TABLE]

be respectively the aggregate flow size that coflow $k$ needs to send from source node $i$ and receive at destination node $j$. The effective size of coflow $k$ is defined as

[TABLE]

Thus $W(k)$ is the maximum amount of data that needs to be sent or received by a node for coflow $k$. Note that, due to normalized capacity constraints on links, when coflow $k$ is released, we need at least $W(k)$ amount of time to process all its flows.

Overview of Varys. Varys [6] orders coflows in a list based on their effective size in an increasing order. Transmission rates of individual flows of the first coflow in the list are set such that all its flows complete at the same time. The remaining capacity of links are updated and iteratively distributed among other coflows in the list in a similar fashion. Formally, the completion time of coflow $k$, $k=1,...,K$, is calculated as follows

[TABLE]

where $Rem(i)$ (similarly, $Rem(j)$) is the remaining capacity of input link $i$ (output link $j$) after transmission rates of all coflows $k^{\prime}<k$ are set. Then for flow $(i,j,k)$, Varys assigns transmission rate $x_{ij}^{k}=d_{ij}^{k}/\Gamma^{k}$. In case that there is still idle capacity, for each input link $i\in{\mathcal{I}}$, the remaining capacity is allocated to the flows of coflows subject to capacity constraints in corresponding output links. Once the first coflow completes, all the flow sizes and the scheduling list are updated and the iterative procedure is repeated to complete the second coflow and distribute the unused capacity. The procedure is stopped when all the coflows are processed.

While Varys performs better than traditional flow scheduling algorithms, it could still be inefficient. The main reason is that Varys is oblivious to the dependency among coflows who share a (source or destination) node. To further expose this issue, we present a simple example.

Example 1** (Inefficiency of Varys).**

Consider the $2\times 2$ switch network illustrated in Figure 2 where there are $3$ coflows in the system. In Figure 2(a), the effective coflow sizes are $W(1)=W(2)=W(3)=1$, therefore, Varys cannot differentiate among coflows. Scheduling coflows in the order $\{1,2,3\}$ or $\{2,3,1\}$ are both possible under Varys but they result in different total completion times, $1+2+2=5$ and $1+1+2=4$, respectively (assuming the weights are all one for all the coflows). Next, consider a slight modification of flow sizes, as shown in Figure 2(b). In this example $W(1)=2$ and $W(2)=W(3)=3$. Based on Varys algorithm, coflow $1$ is scheduled first during time interval $(0,2]$ at rate $1$. When coflow $1$ completes, coflows $2$ and $3$ are scheduled in time interval $(2,5]$; hence, the total completion time will be $2+5+5=12$. However, if we schedule coflows $2$ and $3$ first, the total completion times will reduce to $3+3+5=11$. Note that in both examples, coflow $1$ completely blocks coflows $2$ and $3$, which is not captured by Varys. In fact, the negative impact of ignoring configuration of coflows and their shared nodes is much more profound in large networks with a large number of coflows (see simulations in Section VIII).

Overview of LP-based algorithms. The papers [16] and [18] use Linear Programs (LPs) (based on interval-indexed variables or ordering variables) that capture more information about coflows and provide a better ordering of coflows for scheduling compared to Varys [6]. At the high level, the technical approach in these papers is based on partitioning jobs (coflows) into polynomial number of groups based on solution to a polynomial-sized relaxed linear program, and minimizing the completion time of each group by treating the group as a single coflow. Grouping can have a significant impact on decreasing the completion time of coflows. For instance, in view of examples in Figure 2, grouping coflows $2$ and $3$, and scheduling them first, decreases the total completion time as explained.

NP-hardness and connection to the concurrent open shop problem. The concurrent open shop problem [22] can be essentially viewed as a special case of the coflow scheduling problem when demand matrices are diagonal (in the jargon of concurrent open shop problem, the coflows are jobs, the flows in each coflow are tasks for that job, and the destination nodes are machines with unit capacities). It is known that it is NP-complete to approximate the concurrent open shop problem, when jobs are released at time zero, within a factor better than $2-\epsilon$ for any $\epsilon>0$ [25]. Although the model we consider for coflow scheduling is different from the model used in [16], similar reduction as proposed in [16] can be leveraged to show NP-completness of the coflow scheduling problem. More precisely, every instance of the concurrent open shop problem can be reduced to an instance of coflow scheduling problem (see Appendix References for the details), hence it is NP-complete to approximate the coflow scheduling problem (without release dates) within $2-\epsilon$, for any $\epsilon>0$. There are $2$-approximation algorithms for the concurrent open shop (e.g., [22]), however, these algorithms cannot be ported to the coflow scheduling problem due to the coupling of source and destination link capacity constraints in the coflow scheduling problem (see Appendix References for a counter example).

Next, we describe our coflow scheduling algorithm. The algorithm is based on a linear program formulation for sorting the coflows followed by a simple list scheduling policy

IV Linear Programing (LP) Relaxation

In this section, we use linear ordering variables (see, e.g., [26, 21, 27, 22]) to present a relaxed integer program of the original scheduling problem (3). We then relax these variables to obtain a linear program (LP). In the next section, we use the optimal solution to this LP as a subroutine in our deterministic algorithm.

Ordering variables. For each pair of coflows, if both coflows have some flows incident at some node (either originated from or destined at that node), we define a binary variable which indicates which coflow finishes all its flows before the other coflow does so in the schedule. Formally, for any two coflows $k,k^{\prime}$ with aggregate flow sizes $d^{k}_{m}\neq 0$ and $d^{k\prime}_{m}\neq 0$ on some node $m\in{\mathcal{I}}\cup{\mathcal{J}}$ (recall definition (4)), we introduce a binary variable $\delta_{kk^{\prime}}\in\{0,1\}$ such that $\delta_{kk^{\prime}}=1$ if coflow $k$ finishes all its flows before coflow $k^{\prime}$ finishes all its flows, and it is [math] otherwise. If both coflows finish their flows at the same time (which is possible in the case of continuous-time rate control), we set either one of $\delta_{kk^{\prime}}$ or $\delta_{k^{\prime}k}$ to $1$ and the other one to [math], arbitrarily.

Relaxed Integer Program (IP). We formulate the following Integer Program (IP):

[TABLE]

In the above, to simplify the formulation, we have defined $\delta_{kk^{\prime}}$, for all pairs of coflows, by defining $d_{m}^{k}=0$ if coflow $k$ has no flow originated from or destined to node $m$.

The constraint (6b) (similarly (6c)) follows from the definition of ordering variables and the fact that flows incident to a source node $i$ (a destination node $j$) are processed by a single link of unit capacity. To better see this, note that the total amount of traffic can be sent in the time period $(0,f_{k}]$ over the $i$-th link is at most $f_{k}$. This traffic is given by the right-hand-side of (6b) (similarly (6c)) which basically sums the aggregate size of coflows incident to node $i$ that finish their flows before coflow $k$ finishes its corresponding flows, plus the aggregate size of coflow $k$ at node $i$ itself, $d_{i}^{k}$. This implies constraint (6b) and (6c). The fact that each coflow cannot be completed before its release date plus its effective size is captured by constraint (6d). The next constraint (6e) indicates that for each two incident coflows, one precedes the other.

Note that this optimization problem is a relaxed integer program for the problem (3), since the set of constraints are not capturing all the requirements we need to meet for a feasible schedule. For example, we cannot start scheduling flows of a coflow when it is not released yet, while constraint (6d) does not necessarily avoid this, thus leading to a smaller value of finishing time compared to the optimal solution to (3). Further, release dates and scheduling constraints in optimization (3) might cause idle times in flow transmission of a node, therefore yielding a larger value of finishing time for a coflow than what is restricted by (6b), (6c), (6d). To further illustrate this issue, we present a simple example.

Example 2**.**

Consider a $2\times 2$ switch network as in Figure 3. Assume there are 4 coflows, each has one flow. Flow $(1,1,1)$ is released at time [math] with size $1$, and the other three flows are released at time $1$ with size $2$. It is easy to check that the following values for the ordering variables and flow completion times satisfy all the constraints (6b)$-$(6f). For brevity, we only report the ordering variables for coflows that actually share a node. For example, it is redundant to consider ordering variables corresponding to coflow $1$ and coflow $4$ as they are not incident at any (source/destination) node and any value for their associated pairwise ordering variables does not have any impact on the optimal value for IP (6). Below, the ordering variables and coflow completion times are presented, and all the ordering variables which are not specified can be taken as zero.

[TABLE]

While these values satisfy  (6b)$-$(6f), this is not a valid schedule since it requires transmission of flow $(2,2,4)$ starting at time [math], while it is not released yet. To see this, note that $f_{1}=1$, so to finish processing of coflow $1$ or equivalently flow $(1,1,1)$ by time $1$, we need to start its transmission at maximum rate at time [math]. Then, due to the capacity constraints, the first time flows $(1,2,2)$ and $(2,1,3)$ can start transmission is at time $1$, when flow $(1,1,1)$ has been completed. Since we require to complete both of these flows at time $3$, they need to be transmitted at maximum rate in the time interval $(1,3]$. Therefore, the only way to finish flow $(2,2,4)$ at time $4$ is to send one unit of its data in time interval $(0,1]$ and its remaining unit of data in time interval $(3,4]$, but this flow has not been released before time $1$. So the proposed IP does not address all the scheduling constraints.

Relaxed Linear Program (LP). In the linear program relaxation, we allow the ordering variables to be fractional. Specifically, we replace the constraints (6f) with the constraints (7b) below. We refer to the obtained linear problem by (LP).

[TABLE]

We use $\tilde{f}_{k}$ to denote the optimal solution to this LP for the completion time of coflow $k$. Also we use $\widetilde{\text{OPT}}=\sum_{k}w_{k}\tilde{f_{k}}$ to denote the corresponding objective value. Similarly we use $f_{k}^{\star}$ to denote the optimal completion time of coflow $k$ in the original coflow scheduling problem (3), and use $\text{OPT}=\sum_{k}w_{k}{f_{k}^{\star}}$ to denote its optimal objective value. The following lemma establishes a relation between $\widetilde{\text{OPT}}$ and OPT.

Lemma 1**.**

The optimal value of the LP, $\widetilde{\text{OPT}}$, is a lower bound on the optimal total weighted completion time OPT of coflow scheduling problem.

Proof.

Consider an optimal solution to the optimization problem (3). We set ordering variables so as $\delta_{kk^{\prime}}=1$ if coflow $k$ precedes coflow $k^{\prime}$ in this solution, and $\delta_{kk^{\prime}}=0$, otherwise. If both coflows finish their corresponding flows at the same time, we set either one to $1$ and the other one to [math]. We note that this set of ordering variables and coflow completion times satisfies constraints (6b) and (6c) (by taking integral from both side of constraint (3d) and (3e) from time [math] to $f_{k}$) and also constraint (6d) (by combining constraints (3c) and (3f)). Furthermore, the rest of (LP) constraints are satisfied by the construction of ordering variables. Therefore, optimal solution of problem (3) can be converted to a feasible solution to (LP). Hence, the optimal value of LP, $\widetilde{\text{OPT}}$, is at most equal to OPT. ∎

V Approximation Algorithm

In this section, we describe our polynomial-time coflow scheduling algorithm and state the main results about its performance guarantees.

The algorithm has three steps: (i) solve the relaxed LP (7), (ii) use the solution of the relaxed LP to order flows of coflows, and (iii) apply a simple list scheduling algorithm based on the ordering. The relaxed LP (7) has $O(K^{2})$ variables and $O(K^{2}+KN))$ constraints and can be solved efficiently in polynomial time, e.g. using interior point method [28].

The approximation algorithm is depicted in Algorithm 1. We order coflows based on values of $\tilde{f}_{k}$ (optimal solution to LP) in nondecreasing order. More precisely, we re-index coflows such that,

[TABLE]

Ties are broken arbitrarily. The algorithm then maintains a list of flows such that for every two flows $(i,j,k)$ and $(i^{\prime},j^{\prime},k^{\prime})$ with $k<k^{\prime}$, flow $(i,j,k)$ is placed before flow $(i^{\prime},j^{\prime},k^{\prime})$ in the list. Flows of the same coflow are listed in an arbitrary order. The algorithm scans the list starting from the first flow and schedules a flow if both its corresponding source and destination links are idle at that time. Upon completion of a flow or arrival of a coflow, the algorithm preempts the schedule, updates the list, and starts scheduling the flows in the updated list.

The main result regarding the performance of Algorithm 1 is stated in Theorem 1.

Theorem 1**.**

Algorithm 1 is a deterministic $5$-approximation algorithm for the problem of minimizing total weighted completion time of coflows with release dates.

When all coflows are released at time [math], we can improve the algorithm performance ratio.

Corollary 1**.**

If all coflows are released at time [math], then Algorithm 1 is a deterministic $4$-approximation algorithm.

VI Proof Sketch of Main Results

In this section, we present the sketch of proofs of the main results for our polynomial-time coflow scheduling algorithm. Before proceeding with the proofs, we make the following definitions.

Definition 2** (Aggregate Size and Effective Size of a List of Coflows).**

For a list of $K$ coflows and for a node $s\in{\mathcal{I}}\cup{\mathcal{J}}$, we define $W(1,\cdots,k;s)$ to be the amount of data needs to be sent or received by node $s$ in the network considering only the first $k$ coflows. We also denote by $W(1,\cdots,k)$ the effective size of the aggregate coflow constructed by the first $k$ coflows, $k\leq K$. Specifically,

[TABLE]

[TABLE]

VI-A Bounded completion time for the collection of coflows

Consider the list of coflows according to the ordering in (8) and define $W(1,\cdots,k)$ based on Definition 2. The following lemma demonstrates a relationship between completion time of coflow $k$ obtained from (LP) and $W(1,\cdots,k)$ which is used later in the proofs.

Lemma 2**.**

$\tilde{f}_{k}\geq\frac{W(1,\cdots,k)}{2}$.

Proof.

The proof uses similar ideas as in Gandhi, et al. [27] and Kim [20]. Using constraint (6b), for any source node $i\in{\mathcal{I}}$, we have

[TABLE]

which implies that,

[TABLE]

We simplify the right-hand side of (13), using constraint (6e), combined with the following equality

[TABLE]

and conclude that

[TABLE]

Where the last equality follows from Definition 10. Similar argument results in the following inequality for any destination node $j\in{\mathcal{J}}$, i.e.,

[TABLE]

Now consider the node $s^{\star}$ which has the maximum load induced by the first $k$ coflows, namely, $W(1,\cdots,k)=W(1,\cdots,k;s^{\star})$.

[TABLE]

This implies that,

[TABLE]

This completes the proof. ∎

Note that $W(1,\cdots,k)$ is a lower bound on the time that it takes for all the first $k$ coflows to be completed (as a result of the capacity constraints in the optimization (3)). Hence, Lemma 2 states that by allowing ordering variables to be fractional, completion time of coflow $k$ obtained from (LP) is still lower bounded by half of $W(1,\cdots,k)$.

VI-B Proof of Theorem 1 and Corollary 1

Proof of Theorem 1.

Recall that we use $\hat{f}_{k}$ to denote the actual coflow completion times under our deterministic algorithm. Suppose flow $(i,j,k)$ is the last flow of coflow $k$ that is completed. In general, Algorithm 1 may preempt a flow several times during its execution. For now, suppose flow $(i,j,k)$ is not preempted and use $t_{k}$ to denote the time when its transmission is started (the arguments can be easily extended to the preemption case as we show at the end of the proof). Therefore

[TABLE]

From the algorithm description, $t_{k}$ is the first time that both links $i$ and $j$ are idle and there are no higher priority flows to be scheduled (i.e., there is no flow $(i,j,k^{\prime})$ from $i$ to $j$ with $k^{\prime}<k$ in the list). By definition of $W(1,\cdots,k;s)$, node $s$, $s\in\{i,j\}$, has $W(1,\cdots,k;s)-d_{ij}^{k}$ data units to send or receive by time $t_{k}$. Since the capacity of all links are normalized to $1$, it should hold that

[TABLE]

where the last inequality is by Definition 11. Combining this inequality with equality (18) yields the following bound on $\hat{f_{k}}$.

[TABLE]

Using Lemma 2 and constraint (6d), we can conclude that

[TABLE]

which implies that

[TABLE]

This shows an approximation ratio of $5$ for Algorithm 1 using Lemma 1. Finally, if flow $(i,j,k)$ is preempted, the above argument can still be used by letting $t_{k}$ to be the starting time of its last piece and $d_{ij}^{k}$ to be the remaining size of its last piece at time $t_{k}$. This completes the proof. ∎

Proof of Corollary 1.

When all coflows are released at time [math], $t_{k}\leq W(1,\cdots,k)-d_{ij}^{k}+W(1,\cdots,k)-d_{ij}^{k}$. The rest of the argument is similar to the proof of Theorem 1. Therefore, the algorithm has approximation ratio of $4$ when all coflows are release at time [math]. ∎

VII Extension to Online Algorithm

Similar to previous work [16, 17], Algorithm 1 is an offline algorithm, and requires the complete knowledge of the flow sizes and release times. While this knowledge can be learned in long running services, developing online algorithms that deal with the dynamic nature and unavailability of this information is of practical importance. One natural extension of our algorithm to an online setting, assuming that the coflow information revealed at its release time, is as follows: Upon each coflow arrival, we re-order the coflows by re-solving the (LP) using the remaining coflow sizes and the newly arrived coflow, and update the list. Given the updated list, the scheduling is done as in Algorithm 1. To reduce complexity of the online algorithm, we may re-solve the LP once in every $T$ seconds, for some $T$ that can be tuned, and update the list accordingly. We leave theoretical and experimental study of this online algorithm as a future work.

VIII Empirical Evaluations

In this section, we present our simulation results and evaluate the performance of our algorithm for both cases of with and without release dates, under both synthetic and real traffic traces. We also simulate the deterministic algorithms proposed in [18, 16] and Varys [6] and compare their performance with the performance of our algorithm.

VIII-A Workload

We evaluate algorithms under both synthetic and real traffic traces.

Synthetic traffic: To generate synthetic traces we slightly modify the model used in [29]. We consider the problem of size $K=160$ coflows in a switch network with $N=16$ input and output links. We denote by $M$ the number of non-zero flows in each coflow. We consider two cases:

• •

Dense instance: For each coflow, $M$ is chosen uniformly from the set $\{N,N+1,...,N^{2}\}$. Therefore, coflows have $O(N^{2})$ non-zero flows on average.

• •

Combined instance: Each coflow is sparse or dense with probability $1/2$. For each sparse coflow, $M$ is chosen uniformly from the set $\{1,2,...,N\}$, and for each dense coflow $M$ is chosen uniformly from the set $\{N,N+1,...,N^{2}\}$.

Given the number $M$ of flows in each coflow, $M$ pairs of input and output links are chosen randomly. For each pair that is selected, an integer flow size (processing requirement) $d_{ij}$ is randomly selected from the uniform distribution on $\{1,2,...,100\}$. For the case of scheduling with release dates, we generate the coflow inter-arrival times uniformly from $[1,100]$. We generate $100$ instances for each case and report the average algorithms’ performance.

Real traffic: This workload was also used in [6, 16, 18]. The workload is based on a Hive/MapReduce trace at Facebook that was collected from a 3000-machine cluster with $150$ racks. In this trace, the following information is provided for each coflow: arrival time of the coflow in millisecond, locations of mappers (rack number to which they belong), locations of reducers (rack number to which they belong), and the amount of shuffle data in Megabytes for each reducer. We assume that shuffle data of each reducer in a coflow is evenly generated from all mappers specified for that coflow. The data trace consists of $526$ coflows in total from very sparse coflows (the most sparse coflow has only $1$ flow) to very dense coflows (the most dense coflow has $21170$ flows.). Similar to [16], we filter the coflows based on the number of their non-zero flows, $M$. Apart from considering all coflows ($M\geq 1$), we consider three coflow collections filtered by the conditions $M\geq 10$, $M\geq 30$, and $M\geq 50$. In other words, we use the following 4 collections:

• •

All coflows,

• •

Coflows with $M\geq 10$,

• •

Coflows with $M\geq 30$,

• •

Coflows with $M\geq 50$.

Furthermore, the original cluster had a $10:1$ core-to-rack oversubscription ratio with a total bisection bandwidth of $300$ Gbps. Hence, each link has a capacity of $128$ MBps. To obtain the same traffic intensity offered to our network (without oversubscription), for the case of scheduling coflows with release dates, we need to scale down the arrival times of coflows by $10$. For the case of without release dates, we assume that all coflows arrive at time [math].

VIII-B Algorithms

We simulate four algorithms: the algorithm proposed in this paper, Varys [6], the deterministic algorithm in [16], and the deterministic algorithm in [18]. We briefly overview these algorithms and also elaborate on the backfilling strategy that has been combined with the deterministic algorithms in [16, 18] to avoid under utilization of network resources.

1. Varys [6]: Scheduling and rate assignments under Varys were explained in detail in Section III. There is a parameter $\delta$ in the original design of Varys that controls the tradeoff between fairness and completion time. Since we focus on minimizing the total completion time of coflows, we set $\delta$ to [math] which yields the best performance of Varys. In this case, upon arrival or completion of a coflow, the coflow ordering is updated and the rate assignment is done iteratively as described in Section III.

2. Interval-Indexed-Grouping [16]: The algorithm requires discrete time (i.e., time slots) and is based on an interval-indexed formulation of a polynomial-time linear program (LP) as follows. The time is divided into geometrically increasing intervals. The binary decision variables $x_{lk}$ are introduced which indicate whether coflow $k$ is scheduled to complete within the $l$-th interval $(t_{l},t_{l+1}]$. Using these binary variables, a lower bound on the objective function is formulated subject to link capacity constraints and the release date constraints. The binary variables are then relaxed leading to an LP whose solution is used for ordering coflows. More precisely, the relaxed completion time of coflow $k$ is defined as $f_{k}=\sum_{l}t_{l}x_{lk},$ where $t_{l}$ is the left point of the $l$-th interval and $x_{lk}\in[0,1]$ is the relaxed decision variable. Based on the optimal solution to this LP, coflows are listed in an increasing order of their relaxed completion time. For each coflow $k$ in the list, $k=1,...,K$, we compute effective size of the cumulated first $k$ coflows in the list, $W(1,\cdots,k)$. All coflows that fall within the same time interval according to value of $W(1,\cdots,k)$ are grouped together and treated as a single coflow and scheduled so as to minimize its completion time. Scheduling of coflows within a group makes use of the Birkhoff-von Neumann decomposition. If two data units from coflows $k$ and $k^{\prime}$ within the same group use the same pair of input and output, and $k$ is ordered before $k^{\prime}$, then we always process the data unit from coflow $k$ first. For backfilling, when we use a schedule that matches input $i$ to output $j$, if there is no more service requirement on the pair of input $i$ and output $j$ for some coflow in the current partition, we backfill in order from the flows on the same pair of ports in the subsequent coflows. We would like to emphasize that this algorithm needs to discretize time and is based on matching source nodes to destination nodes. We select the time unit to be $1/128$ second as suggested in [16] so that each port has a capacity of $1$ MB per time unit. We refer to this algorithm as ‘LP-II-GB’, where II stands for Interval-Indexed, and GB stands for Grouping and Backfilling.

3. Ordering-Variable-Grouping [18]: We implement the deterministic algorithm in [18]. Linear programming formulation is the same as LP in (7). Coflows are then grouped based on the optimal solution to the LP. To schedule coflows of each group, we construct a single aggregate coflow denote by $D$ and schedule its flows to optimize its completion time. We assign transmission rate $x_{ij}=d_{ij}/W(D)$ to the flow from source node $i$ to destination node $j$ until its completion. Moreover, the continuous backfilling is done as follows: After assigning rates to aggregate coflow, we increase $x_{ij}$ until either capacity of link $i$ or link $j$ is fully utilized. We continue until for any node, either source or destination node, the summation of rates sum to one. We also transmit flows respecting coflow order inside of each partition. When there is no more service requirement on the pair of input $i$ and output $j$ for coflows of current partition, we backfill (transmit) in order from the flows on the same pair of ports from the subsequent coflows. We refer to this algorithm as ‘LP-OV-GB’, where OV stands for ordering variables, and GB stands for Grouping and Backfilling.

4. Algorithm 1: We implement our algorithm as described in Algorithm 1, and refer to it as ‘LP-OV-LS’, where LS stands for list scheduling.

VIII-C Evaluation Results

Performance of Our Algorithm. We report the ratios of total weighted completion time obtained from Algorithm 1 and the optimal value of relaxed linear program (7) (which is a lower bound on the optimal value of the coflow scheduling problem) to verify Theorem 1 and Corollary 1. We only present results of the simulations using the real traffic trace, with equal weights and random weights. For the case of random weights, the weight of each coflow is chosen uniformly at random from the interval $[0,1]$. The results are more or less similar for other collections and for synthetic traffic traces and all are consistent with our theoretical results.

Table II shows the performance ratio of the deterministic algorithm for the cases of with and without release dates. All performances are within our theoretical results indicating the approximation ratio of at most $4$ when all coflows release at time [math] and at most $5$ when coflows have general release dates. In fact, the approximation ratios for the real traffic trace are much smaller than $4$ and $5$ and very close to $1$.

Performance Comparison with Other Algorithms. Now, we compare the performance of Algorithm 1 with LP-II-GB, LP-OV-GB, and Varys. We set all the weights of coflows to be equal to one.

1. Performance evaluation under synthetic traffic: For each of the two instances explained in Section VIII-A, we randomly generate $100$ different traffic traces and compute the average performance of algorithms over the traffic traces.

Figure 4 and 5 depict the average result of our simulations (over $100$ dense and $100$ combined instances) for the zero release dates and general release dates, respectively. As we see, Algorithm 1 (LP-OV-LS) outperforms Varys and LP-II-GB by almost $30\%$, and LP-OV-GB by almost $11\%$ in dense instance for both general and zero release dates. In combined instance, the improvements are $35\%$, $30\%$, and $17\%$ when all coflows are released at time [math], and $28\%$, $29\%$, and $17\%$ for the case of general release dates over Varys, LP-II-GB, and LP-OV-GB, respectively.

This workload is more intensive in the number of non-zero flows; however, more uniform in the flow sizes and source-destination pairs in comparison to the real traffic trace. The real traffic trace (described in Section VIII-A) contains a large number of sparse coflows; namely, about $50\%$ of coflows have less than $10$ flows. Also, it widely varies in terms of flow sizes and source-destination pairs in the network. We now present evaluation results under this traffic.

2. Performance evaluation under real traffic: We ran simulations for the four collections of coflows described in Section VIII-A. We normalize the total completion time under each algorithm by the total completion time under Algorithm 1 (LP-OV-LS).

Figure 6 shows the performance of different algorithms for different collections of coflows when all coflows are released at time [math]. LP-OV-LS outperforms Varys by almost $112-117\%$ in different collections. It also constantly outperforms LP-II-GB and LP-OV-GB by almost $74-78\%$ and $63-68\%$, respectively.

Figure 7 shows the performance of different algorithms for different collections of coflows for the case of release dates. LP-OV-LS outperforms Varys by almost $24\%$, $65\%$, $91\%$, and $99\%$ for all coflows, $M\geq 10$, $M\geq 30$, $M\geq 50$, respectively. It also outperforms LP-II-GB for $40\%$, $62\%$, $71\%$, and $82\%$, and LP-OV-GB by $19\%$, $54\%$, $64\%$, and $73\%$, respectively.

IX Concluding Remarks

In this paper, we studied the problem of scheduling of coflows with release dates to minimize their total weighted completion time, and proposed an algorithm with improved approximation ratio. We also conducted extensive experiments to evaluate the performance of our algorithm, compared with three algorithms proposed before, using both real and synthetic traffic traces. Our experimental results show that our algorithm in fact performs very close to optimal.

As future work, other realistic constraints such as precedence requirement or deadline constraints need to be considered. Also, theoretical and experimental evaluation of the performance of the proposed online algorithm is left for future work. While we modeled the datacenter network as a giant non-blocking switch (thus focusing on rate allocation), the routing of coflows in the datacenter network is also of great importance for achieving the quality of service.