Scalable Rate Control for Traffic Engineering with Aggregated Flows in Software Defined Networks

TL;DR

This paper introduces F²ARM, a scalable SDN traffic engineering architecture that controls a minimal subset of flows to guarantee minimum rates, addressing issues with flow aggregation and TCP rate mismatches.

Contribution

Proposes a novel architecture and optimization framework for controlling a minimal set of flows in SDN to improve scalability while maintaining rate guarantees.

Findings

JFSRD algorithm performs near-optimally in small networks.

Controlled flows can be reduced by 50% in real network simulations.

Addresses flow rate guarantee issues in aggregated SDN flows.

Abstract

To increase the scalability of Software Defined Networks (SDNs), flow aggregation schemes have been proposed to merge multiple mouse flows into an elephant aggregated flow for traffic engineering. In this paper, we first notice that the user bit-rate requirements of mouse flows are no longer guaranteed in the aggregated flow since the flow rate decided by the TCP allocation is usually different from the desired bit-rate of each user. To address the above issue, we present a novel architecture, named Flexible Flow And Rate Management (F$^2$ARM), to control the rates of only a few flows in order to increase the scalability of SDN, while leaving the uncontrolled flows managed by TCP. We formulate a new optimization problem, named Scalable Per-Flow Rate Control for SDN (SPFRCS), which aims to find a minimum subset of flows as controlled flows but ensure that the flow rates of all uncontrolled flows can still satisfy the minimum required rates by TCP. We prove that SPFRCS is NP-hard and design an efficient algorithm, named Joint Flow Selection and Rate Determination (JFSRD). Simulation results based on real networks manifest that JFSRD performs nearly optimally in small-scale networks, and the number of controlled flows can be effectively reduced by 50% in real networks.

Full text

I Introduction

Software Defined Network (SDN) is an emerging network paradigm that separates the control plane from the data plane through OpenFlow [1]. This decoupling abstracts lower level functions into higher level services and allows the policy enforcement and network configuration to be very flexible. Moreover, SDN provides a global view of the network and thus enables optimal decisions in a centralized manner to meet the diverse traffic demands from various application services.

In this paper, we first notice that the user bit-rate requirements of mouse flows are no longer guaranteed in the aggregated flow since the flow rate decided by TCP fair allocation [2] is usually different from the desired bit-rate of each user application. In other words, one of the primary features in SDN to ensure the end-to-end bandwidth allocation may not sustain when end-to-end mouse flows are aggregated inside SDN. However, many mouse flows such as Youtube streaming requires the sufficient bandwidth allocation (e.g., FULL HD). To address the above issue, a possible approach is to facilitate flow rate control in every source client. However, this approach is not practically feasible because malicious users can easily overwhelm the whole network, and the network-based rate control is thereby necessary for SDN, as shown in the literature [3, 4, 5, 6]. In other words, it is desirable to provide a scalable network-based rate control mechanism for SDN mouse flows to support traffic engineering (TE) with aggregated flows.

To address the above crucial need, this paper presents a new architecture, named Flexible Flow And Rate Management (F2ARM). Given the routing of each mouse flow, our idea is to select only a few mouse flows to control the corresponding flow rates, whereas the rates of other flows are still controlled by TCP. In other words, only some mouse flows are selected by F2ARM and controlled by SDN switches, and the other uncontrolled mouse flows are aggregated and share the aggregated bandwidth by TCP. F2ARM in the SDN controller is designed to minimize the number of controlled flows in order to increase the scalability of SDN. Meanwhile, it guarantees that the bandwidth decided by TCP for every uncontrolled mouse flow exceeds its minimum user requirement. Fig. 1 presents the proof of concept in our small-scale environmental environment. Fig. 1(a) shows that as all of the flows are uncontrolled (i.e., the bandwidth is allocated by the TCP), the allocated bandwidths of them are identical, 4.3, since the link $6\rightarrow 7$ is the bottleneck link. Fig. 1(b) shows that as the flow $1\rightarrow 4$ is controlled while the other two flows are uncontrolled, by the experiment, all demands of the flows are almost satisfied.111Here we control the flow by a queue in OpenFlow. That is, partial controlling is a feasible way in SDN. The remainder of this paper is structured as follows. Section II summarizes the related work. Section III provides the problem definition and hardness result. Section IV presents the proposed algorithm. Section V shows the simulation results of our algorithm. Finally, we conclude the paper in section VI.

II Related Work

II-A TE in SDN

Recently, flow aggregation has been explored for exploiting limited TCAM to achieve the scalable SDN. OFFICER [7] reduced the TCAM consumption by routing many segments of flows into default paths between nodes. Bhatia et al. [8] properly determined the optimal routing parameters for each default path (i.e., segment) in both the offline and online cases, whereas Hao et al. [9] further investigated restoration optimization for network failure in the segment routing. Moreover, to efficiently exploit the limited TCAM, a novel rule multiplexing scheme [10] was proposed to minimize the rule space in TCAM. Meiners et al. [11] proved that the non-prefix aggregation problem is NP-Hard and proposed to compress a given classifier into a non-prefix ternary classifier. Luo et al. [12] introduced the first online non-prefix aggregation scheme to shrink the flow-table size and support fast online updates. However, none of the above research focused on scalable rate control for aggregated flows in SDN.

II-B TCP

To support scalable rate control in the Internet, many TCP variations [13, 14, 15, 16, 17] have been proposed to achieve fair allocation of the network bandwidth by AIMD [2]. TCP-Reno [13] first introduced fast recovery to increase the network connection utilization, while TCP-NewReno [14] further addressed multiple packet losses. BIC [15] employed two window size control policies to alleviate unfairness of round-trip time (RTT). On the other hand, CUBIC [16] simplified BIC by replacing the concave and convex window growth with a cubic function. TCP-Illinois [17] exploited the queueing delay to determine an increase factor and multiplicative decrease factor instantaneously during the congestion. Recently, fine-grained per-flow control with TCP in SDN switches has drawn increasing attention. FlowQoS [5] delegated application identification and QoS configuration from user clients to SDN controller for achieving per-flow QoS, while OMCoFlow [6] minimized the average co-flow completion time in SDN. However, the above research targeted on per-flow rate control on individual flows with different objectives, instead of scalable rate control of the whole SDN with aggregated flows.

III Problem and Hardness

The network is modeled as a directed graph $G=\{V,E\}$, where $V$ and $E$ denote the sets of SDN switches and links, respectively. Each link $e\in E$ has an individual limited link capacity $c(e)\in\mathbb{R}^{+}$. Let $F$ denote the set of flows, where each flow $f\in F$ with a bandwidth demand $d(f)$ is assigned a routing path $p(f)$. The state information of each controlled flow is maintained for rate control. In contrast, the flow rates of uncontrolled flows are decided by TCP.

In the SPFRCS problem, each flow can be either controlled or uncontrolled. Once it is controlled, the allocated bandwidth can be decided by the controller; otherwise, the allocated bandwidth is decided by TCP. Each uncontrolled flow has a bottleneck link that limits the allocated bandwidth of the flow. In addition, every link $e$ that has a uncontrolled flow will exhaust its bandwidth, and all of the flows whose bottleneck link is $e$ will equally share the bandwidth. It is trivial that SPFRCS is NP-hard. It can be proved by a reduction from the set cover problem [18]. We have the following theorem.

Theorem 1**.**

The SPFRCS problem is NP-hard.

Since the set cover problem cannot be approximated within a factor of $(1-\epsilon)\ln n$, where $\epsilon>0$ and $n$ denotes the number of elements [18], we have the following corollary.

Corollary 1**.**

The SPFRCS problem cannot be approximated within a factor of $(1-\epsilon)\ln\frac{|V|}{2}$, where $\epsilon>0$ and $|V|$ denotes the number of switches in $G$.

IV Algorithm

IV-A Algorithm Concept

To solve the problem, we propose algorithm Joint Flow Selection and Rate Determination (JFSRD) for SPFRCS to minimize the number of controlled flows in SDN. JFSRD first selects suitable controlled flows and then sets their rates to their minimum requirements. After controlled flow rates are extracted, TCP fair allocation is applied to assign the residual bandwidth to the uncontrolled flows. Then, JFSRD further reduces the number of controlled flows by adjusting the controlled flow rates. It is necessary to ensure that the allocated flow rate of each uncontrolled flow satisfies the minimum user requirement. Therefore, JFSRD consists of two phases: 1) Flow Selection (FS), and 2) Rate Determination (RD)

IV-B Algorithm Details

To obtain a good solution for SPFRCS, we propose an ordering scheme to iteratively extract the controlled flows and assign their data rates by considering the correlation among different flows. JFSRD includes the following two phases.

1) Flow Selection (FS)

JFSRD aims to find a configuration (i.e., controlled or not) for all flows in the network. However, enumerating all possibilities (i.e., every flow can be controlled or not) is very computation intensive. Therefore, in order to reduce the computation complexity while ensuring the quality of solution, JFSRD first finds a set of candidate configurations instead of every possible configuration of the flows on each link, and then selects the most suitable configuration among the candidate set for each link. More specifically, the FS phase includes two stages, 1) configuration and 2) selection.

In the configuration stage, JFSRD initially assigns the data rate $r_{f}$ of each flow $f$ on $e$ as $d(f)$. The residual bandwidth of $e$, $\rho(e)$, is acquired accordingly, i.e., $\rho(e)=c(e)-\sum_{f:p(f)\ni e}r_{f}$. Afterward, in order to minimize the number of controlled flows in each configuration for each link $e$, JFSRD maximizes the number of flows with the same rates on $e$, so that many of them are potential to be uncontrolled flows via TCP.

Therefore, for link $e$, JFSRD iteratively picks a target rate in ascending order. For each target rate, JFSRD generates a candidate configuration for $e$ by distributing the residual bandwidth to the flows with a smaller rate, in order to maximize the number of flows with the rate identical to the target rate. To limit the number of configurations for each link $e$, JFSRD picks the target rates for each link $e$ from the rates of the flows on $e$. The number of configurations for each link $e$ is at most $|F(e)|$ since there are at most $|F(e)|$ flows on $e$.

Afterward, in the selection stage, an intuitive approach is to randomly pick a candidate configuration for each link. However, this approach tends to generate more controlled flows since it does not consider the common controlled flows among different links. Furthermore, the selected configuration of a more important link (i.e., the link visited by a larger number of flows and including more overlapping flows) may have more opportunities to significantly affect the total number of controlled flows. Therefore, JFSRD globally considers the importance of each link to decide its configuration. We define the correlation of link $e$, $\gamma(e)$, which denotes the number of overlapping flows correlated to the flows on $e$. To address the above issue, therefore, JFSRD starts from the link $e$ with the highest correlation. Subsequently, for a link, the candidate configuration with a larger proportion of controlled flows that are also controlled flows in the candidate configurations of other links has more opportunities to reduce the total controlled flows in the network. We call it the profit of configuration $n$ on link $e$. As a result, JFSRD selects the configuration with the highest profit for $e$; that is, JFSRD prefers the configuration with a larger proportion of the controlled flows that are also controlled flows in the candidate configurations of other links. Afterward, JFSRD examines the next link with the highest correlation from all the links that have not been examined until the configurations of all links are selected. After the FS phase, each flow is decided to be controlled if and only if it is controlled in the selected configuration of any link. Note that the FS phase must satisfy the rate demands of all flows. Otherwise, assume that there is an unsatisfied uncontrolled flow $f$ whose bottleneck link is $e$. Then, it implies that the allocated rate of each uncontrolled flows on $e$ is at most the allocated rate of $f$, which is smaller than the target rate of the selected configuration of $e$. It contradicts since in such cases TCP does not exploit the available bandwidth of $e$ for each unsatisfied uncontrolled flow.

2) Rate Determination (RD)

In the RD phase, JFSRD further reduces the number of controlled flows that are selected in the FS phase. By observation, a flow $f$ that must be controlled implies that either 1) it will acquire the redundant bandwidth such that the other flows are unsatisfied or 2) it will not be satisfied, if it is uncontrolled. To solve condition 1 (or 2), a possible solution is to increase (or decrease) the rates of other controlled flows which visit a common link with $f$ such that the rate of $f$ can be bounded (or satisfied) without control. It is an implicit trade-off. Since the determined rate of each controlled flow in the FS phase cannot decrease anymore, JFSRD only increases the rates of controlled flows. More specifically, similarly, JFSRD starts from the link $e$ with the highest $\gamma(e)$ and then examines the temporarily controlled (TC) flows of $e$, where TC means that the flows are uncontrolled in the selected configuration on $e$, but they are controlled in the selected configurations on the other links. These TC flow rates can be limited by increasing the other controlled-flow rates on $e$. Therefore, it is envisaged that their rates can be assigned properly by TCP even they are not controlled. To fairly allocate the bandwidth, JFSRD proportionally allocates the residual bandwidth of $e$ to the controlled flows according to their priority that can be specified by the network owner or applications. A flow with a higher priority will acquire more residual bandwidth. Note that during the allocation, if there is a link to be exhausted on the path of some controlled flow $f$, the residual bandwidth of $e$ is then proportionally assigned to the other controlled flows (i.e., not $f$) on $e$ according to the priority.

The above allocation process repeats until the residual bandwidth of $e$ is exhausted, or no controlled flow on $e$ can increase its rate. Then, JFSRD examines whether the allocation can satisfy all the flow demands if the TC flows on $e$ are set as uncontrolled flows . If all the flows can be satisfied, the TC flows on $e$ are assigned as uncontrolled flows; otherwise, they become controlled flows. Afterward, JFSRD updates the status and examines the next link with the highest correlation among all the links that have not been examined. The RD phase stops when all the TC flows on each link are examined.

V Performance Evaluation

V-A Simulation Setup

We conduct extensive simulations to evaluate the performance of JFSRD in two real networks: Claranet and Columbus [19]. Claranet includes 15 nodes and 18 links, while Columbus has 70 nodes and 85 links. The number of flows in Claranet ranges from 30 to 80, whereas there are more than 1000 flows in Columbus. Two routing policies in SDN are tested in the simulation: shortest-path routing[20] and OFFICER[7] that supports SDN TE with aggregated flows. Since this paper targets on flow control, the link capacity is set to 25$\%$ more than the total flow demands in each link. The flow demands are generated by traffic matrices according to[21], and the source and destination of each flow are randomly chosen.

In the simulation, since there is no related work exploring scalable rate control for SDN TE with aggregated flows, we compare JFSRD with three algorithms: 1) traditional TCP, where the link bandwidth are shared by all flows, 2) the baseline algorithm that iteratively selects the flow with the smallest ID as a controlled flow until the remaining unselected flows can be satisfied by TCP, and 3) IBM CPLEX to find the optimal solutions of SPFRCS problem with the MILP formulation in Section III. Note that the running time of each instance by CPLEX is over ten minutes even if there are more than 80 source-destination pairs, and thus we do not compare JFSRD with the optimal solution in the large case – Columbus. To evaluate JFSRD, we vary the following parameters: 1) number of flows and 2) load of networks. When the number of flows varies, the average load of the network is fixed at 75$\%$. When the load of networks varies, the number of flows is fixed at 60 and 1500 for Claranet and Columbus, respectively. We measure the following two performance metrics: 1) number of controlled flows and 2) number of flows not meeting the user requirements. Each result is averaged over 100 samples.

V-B Simulation Result

Figs. 2 and 3 manifest that JFSRD greatly outperforms the baseline approach over 50 $\%$ on the number of controlled flows in almost all cases, and all user requirements can be satisfied. Moreover, the solution of JFSRD is very close to the optimal solution in Claranet because JFSRD selects the controlled flows and adjusts the flow rates according to the correlation of overlapping links among different sets of flows, instead of simply iteratively selecting the controlled flows based on their ID and setting the rate as their demands. It is worth noting that the FS phase in JFSRD has already obtained a fairly good solution. In addition, for TCP nearly 25 $\%$ of flows cannot meet the corresponding rate requirements.

In the following, we first investigate the number of flows versus the number of controlled flows with two routing schemes in SDN. Fig. 2 first shows that JFSRD significantly outperforms the baseline approach for both routing policies in both networks and generates the solution very close to the optimal solution in Claranet network. This is because JFSRD attempts to select the minimal number of controlled flows for each link, and it also carefully examines the number of links that can benefit from the selection. In other words, JFSRD selects the flows that are usually the common controlled flows of several configurations in different links. On the other hand, the baseline approach selects a huge number of unnecessarily controlled flows due to the naive ID-based selection, and it usually misses some flows that are highly correlated to the other flows to limit their rates on some links. Moreover, Fig. 2 and Fig. 3 demonstrate that although TCP automatically control the flow rates, 25% of the users are not satisfied since it fairly allocates bandwidth to the flows without considering their rate demands. Also, Fig. 2 (a) and (c) (or (b) and (d)) manifest that the number of controlled flows with OFFICER TE is slightly larger than that with shortest-path routing because OFFICER tends to route the traffic along the default path toward the controller before it reaches the selected branch switch. Therefore, it produces more highly-utilized links in the network.

VI Conclusion

To the best of our knowledge, this paper is the first attempt to minimize the number of controlled flows by assigning the rate of subset of flows so that the rates for uncontrolled flows by TCP can exceed the corresponding user requirements. We first introduce F2ARM for the SDN controller to extract a subset of controlled flows in order to increase the scalability of SDN, while the remaining uncontrolled flows are managed by TCP. However, the selection of controlled flows is challenging since an uncontrolled flow may meet different competing flows in different links to share the bandwidth. Therefore, we formulate a new optimization problem, SPFRCS, and prove that the hardness of the problem. To solve the problem, we devise an effective algorithm JFSRD to iteratively select the controlled flows and determine their rates by carefully examining the overlapping links among different sets of flows. Simulation results demonstrate that the number of controlled flows can be effectively reduced by $50\%$ in most cases, and the performance of JFSRD is very close to the optimal solution in real networks.