Effective Router Assisted Congestion Control for SDN

ABSTRACT


INTRODUCTION
Congestion control is a process to regulate the sending rate of the source on the network so the sender may adjust the entry of data according to the network condition to ensure sender's Quality of Service (QoS) requirements are fulfilled [1]. A good congestion control will ensure that there is no drop in quality and assure a good quality network [2], [3]. It is widely known that an end-to-end packet loss control such as Transmission Control Protocol (TCP) has several inefficiencies [4]. One reason of inefficiency is that TCP treats packet loss as congestion signal. Therefore, it cannot distinguish between packet loss due to congestion with packet loss due to other causes.
Packet loss as a congestion signal implies that action can only be done after congestion occurs [5]. TCP uses assumption that the network does not provide explicit feedback to the source [6], which makes each source to estimate the nature of the network path, such as round trip time (RTT) or usable bandwidth, to deliver efficient end-to-end congestion. To improve TCP performance, previous research introduced the use of explicit congestion signals to the network [7]. This method is commonly called the Router Assisted Congestion Control (RACC). In the traditional Internet, RACC method is applied to each router where the router provides feedback to the end system about the state of the network and tells the sender to send packets at a specific rate. Figure 1 gives a simple overview of routers that always provide feedback information to the end-user. RACC is modeled using the M/G/1-PS queue theory to calculate the aggregate rate on each router (node). The aggregated rate at each node l follows a simple model as described by the following equation [8]: where R l is the sending rate for a link, C l is the link capacity, and ρ l is the link utilization. There are three solutions offered for RACC in the traditional Internet. The first solution is to use a router to detect congestion and send this information to the end system. Based on this information, the end system decides to control the congestion on the network. The example of this category is Explicit Congestion Notification (ECN) [9] and Quick-Start [10]. The sending rates in both protocols are decided at the end system based on information received from the network and the characteristics of each application. The second solution is to use a router to detect congestion and available network resources, and at the same time, the router distributes network resources for each information flow. The example of this category is Explicit Congestion Control Protocol (XCP) [11], and Rate Control Protocol (RCP) [12]. In this second approach, the end system only accepts recommendations from the router to adjust its sending rate. This approach allows the router to decide the sending rate for each flow without causing congestion on the network. To calculate the change in flow sending rate, XCP calculates the aggregate bandwidth for each router. XCP uses the following equation to calculate the desired adjustment of the aggregate bandwidth [11].
In this equation, C l is the capacity of the outgoing link, ( ) is the rate of its outgoing traffic, ( ) is the persistent queue during the previous control interval and d is the average RTT. The resulted aggregate feedback ( ) can be positive or negative and is distributed among the traversing flows. The fairness controller uses the Additive-Increase/Multiplicative-Decrease (AIMD) principle to allocate the positive or negative feedback. Positive feedback is distributed equally among all flows and negative feedback is distributed proportionally to their current throughput. XCP has two disadvantages: first, the startup flow is working slowly, so the completion time of flow is not smooth for small flow [13]. Second, it requires perpacket calculation; this raises the problem of significant overhead [12].
RCP was developed by Nandita [12] with the aim of providing a simpler congestion control mechanism. RCP assumes that the sender uses a rate-based delivery mechanism. Equal to XCP, RCP requires calculating the aggregate rate to adjust the flow sending rate. RCP calculates the aggregate rate ( ) once per interval control with the following equation: Where ( ) is the common feedback rate, d is the average RTT and C l is the capacity of the outgoing link. (  conditions for α and β are fulfilled [12]. Despite these improvements, XCP and RCP still face many challenges especially in queue support. The problem of the queue support in this system is that the protocol assumes only a single queue, contrary to the design of a high-end router that rarely has only one queue. The implementation can be tricky if there are thousands of flows passing through the routers with different characteristics. Finally, the third solution is to use a router to detect congestion along the path and provide information to the end system. The example of this category is the Open Box Protocol (OBP) [14]. OBP uses a collaboration router to identify network resources along the path and deliver this information to the end system. The end system made the congestion control decision using the data received from the router. The following equation shows how the sending rate is adjusted. In OBP, The initial sending rate W(t 0 ) depends on the available bandwidth AB(t 0 ), the capacity CB(t 0 ) at the narrow link and the constants α and ß [14].
Every time a new ACK packet is received, the feedback information inside the packet is used to make adjustments in transmission rate. OBP claims that its computation is simpler than XCP and RCP. However, the sender on OBP should create decision of adjusting the sending rate using only the information on the router along the path. This information is still a local category because the recipient does not understand the actual network conditions. Consequently, the OBP should always be careful in increasing and decreasing the delivery rate to maintain the network stability.
In general, RACC can improve network performance. However, the RACC method is run by using a distributed framework as in traditional networks has some drawbacks. It requires a router (s) that supports signaling bandwidth of the set of parameters of the sending rate [15]. The presence of incomplete information about network conditions makes the issue of efficiency and stability. The congestion control scheme with network support becomes inefficient so that a global information provider mechanism is needed that can be used by congestion control mechanisms to control network congestion. Congestion control using global information has been proposed by Monia et al. [16] proposed OpenTCP, a TCP adjustment dynamics framework based on SDN. The sending rate adjustment in OpenTCP is global-based information managed by the controller. OpenTCP has filled the SDN application gaps in the congestion control field. However, OpenTCP is a new architecture and needs several modifications on some elements of the network such as having to modify the source, forwarding nodes and controllers. OpenTCP also has no specific target rate and adjustment methods. Lingyun et al. [17] present multiple active queue management algorithms. The algorithm is executed according to the location of the congestion on the network. This algorithm is adaptive to link condition.
The link condition is detected by monitoring the statistical center, if there is a congestion link, then the information flow on this link is transferred by the OpenFlow controller. This method claims to be effective for congestion control. Nevertheless, this algorithm does not fully take into account the condition of network globally. Yao [18] proposed an algorithm called Software-Defined Congestion Control (SDCC). This approach has the characteristics of centralized control and can get a global topology for integrated network management. SDCC can optimize link utilization to control network congestion. However, SDCC still only considers network performance and does not pay attention to flow performance. Congestion control using SDN approach is still in early development stage. The proposed works have not discussed the weaknesses, and performances improvements of router assisted control in traditional networks. The most extensive work for the field of congestion control in the SDN is proposed for the data center as in [19]- [21].
In this paper, we proposed a new Router Assisted Congestion Control (RACC) mechanism that we call Path Associativity Centralized Explicit Congestion Control (PACEC). PACEC works on the SDN framework to overcome the weaknesses of the RACC in traditional Internet by providing global network information. We use comprehensive information to improve the accuracy of feedback to determine the source sending rate. By using SDN technology, congestion control utilizes the global knowledge of the network in its decision making. Data monitoring collects network information, and this information is used by the controller to make centralized decisions in response to changing network conditions [22]. This approach produces accurate information so that the sender's sending rate can be customized appropriately according to network conditions. PACEC calculates the rate by involving all the nodes along the connection path through which the information flows. Therefore, the sending rate of the information flow does not need to change as long as it still passes through the same path and the update timer of the controller has not ended. PACEC can also set the source sending rate starting at high-speed so that network resources can be used more efficiently. This proposed mechanism is the novelty of this research in the congestion control domain. The rest of this paper is structured as follows: section 2 explains the related works within the topic of the RACC. Section 3 describes the design of the proposed mechanism in this paper. Section 4 describes the simulation results of the proposed mechanism, and finally, Section 5 describes the conclusions and possible future research directions.

PROPOSED METHOD
This section provides an overview of the PACEC draft [23]. To better understand the motivations behind PACEC, let us remember that RACC uses the basic equations we have written in Equation (1) to determine the aggregate rate on a link. From that equation we can see that information of available bandwidth covers only within local. Consequently, an RACC router will need to coordinate with other routers when implemented into networks with multiple routers. To avoid this drawback, PACEC implements a centralized congestion control mechanism, while the RACC router on the traditional Internet calculates the aggregate rate for a link only. PACEC can calculate the aggregate rate for a path, where the path has been provided to distribute the flow from the source to the destination. With this mechanism, the flow is guaranteed by route and rate when the flow is allowed to enter into the network. Our proposed method is described in the following sections.

Path Rate (Rp)
Similar to the case of the RACC routers, PACEC requires calculation on aggregate rates to adjust the sending rate. The difference is that the RACC calculates an aggregate rate for one link only. PACEC calculates the aggregate rate for a path. We call aggregate rate on PACEC as path rate ( ). To get the path rate, we consider a network model whose topology is characterized in Figure 2. The network model is a path consisting of several links (1, 2,..., H). The whole link is connected to a centralized controller. End system as the source of information flow is connected to the ingress switch as the gateway to the network. In this case, nodes C 1 serves as ingress switch. The source f i has an associated sending rate of r i . Flow is transmitted from source to destination via a path that has capacity C p .
Γ i is the i_th average link utilization of collected by controller i, where = + , y i is the i_th average traffic link, q i is the i_th queue link, C i is thei_th link capacity. In contrast to RACC in the traditional Internet, PACEC uses Γ i , which is a utilization matrix whose elements are global information network. Information about Γ i is obtained by the controller globally from each switch incorporated in the controlled network. The

Rp Updating
Network conditions vary from time to time. Therefore the controller needs to update the network information continuously to deliver an effective policy. The controller updates the information of R p in each update period T c and the controller will provide updated information to the ingress switch.
Available bandwidth on each link as proposed in Equation (8) differs from traditional available bandwidth model given in Equation (1). In this mechanism, we continuously update the available bandwidth based on actual utilization and queue length at every node in the path as given in Equation (5). Traditional routing, on the other hand, only relies on a specific node as given in Equation (1).

Sending Rate Update
Sending rate update aims to adjust the source sending rate (r i ) based on current network conditions. As mentioned before, the source sending rate adjustment on PACEC is based on the path rate ( ) calculated by the SDN controller. Every T C period, the controller updates R p . Then in each of these periods, the source gets a new rate corresponding to R p , which is informed by the controller to the source through the ingress switch. The new rate is independent of the previous rate. If there is N flow to be transmitted on a path and each flow is given the same rate, then R p on each controller update is divided equally. The following equation shows how the sending rate (r i ) is adjusted.
Equation (9) denotes the maximum sending rate that can be provided to transmit a flow so that the source sending rate r i meets the limit ≤ . Here, we conclude that to adjust the sending rate at the source, PACEC uses the following steps: a. The SDN controller calculates resources on a path at each period Tc. This resource calculation covers bandwidth availability which is then converted into path rate (R p ). b. Ingress switch receives information from the SDN controller for each period of controlling T c . Ingress switch passes this information to the source. c. The source adjusts its sending rate based on the information received from ingress switch. The source transmits the flow at the rate , corresponding to the rate-sharing algorithm at the source. The cannot exceed , as the upper limit. The source will stream the flow with the same rate until there is a change of information rate. If there are N flows then ∑ 1 ≤ .

RESULTS AND ANALYSIS
In this section, we report the simulation results collected with our implementation of PACEC in the Mininet Simulator. We compared the simulation results of the proposed method with other congestion control mechanisms such as RCP. Here we compared PACEC with RCP due to the reason that PACEC is a rate based congestion control such as RCP. We also compare PACEC with TCP to see PACEC improvements overs important congestion control protocol on the Internet. To measure the performance of the congestion control mechanism, we evaluated the throughput, efficiency, smoothness, and fairness. As a reference scenario, we write the simulation parameters in Table 1.   Figure 4 shows comparison throughput achievement of congestion control scheme. Our simulation is conducted by entering two kinds of flows consisting of large flow (flow A) and small flow (flow B) to the network. We measure the throughput for both flows. The simulation resulted in the average of throughput for PACEC is 48.9 Mbps, RCP is 46.3 Mbps, and TCP is 31, 45 Mbps for flow A. The simulation results for flow B obtained the average of throughput; PACEC is 12.27 Mbps, RCP is 11.58 Mbps, and TCP is 7.87 Mbps. In this case, PACEC outperformed RCP and TCP. PACEC increased mean throughput achievement over RCP by 5.7% and TCP by 55.7%.

Efficiency
The efficiency of the congestion control mechanism can be determined through the power parameters, i.e., the ratio between throughput and delay [24].
We summarize the simulation results in Table 2. We can see that PACEC has the highest power value compared to RCP and TCP. That indicated that PACEC is more efficient than RCP and TCP.

Smoothness
Smoothness is an essential feature of congestion control. Here we declared smoothness as the ratio of the rate change between two successive update periods to the previous rate and written as [25] where x i is the average throughput during the i-th interval for the flow (each range is T c sec). A flow smoothness index is defined as the mean throughput-change over its lifetime ratio, where T is the total time interval during the simulation. Smaller smoothness indices show smoother throughput changes [26].
We do a simulation of 10 different flows, a small flow having sizes (1-10 Kbps), medium (10Kbps-1Mbps), and large (1-100Mbps) within 100 seconds. We declare the throughput fluctuation with the smoothness parameter as in (12). Table 3 shows the comparison of smoothness index for each flow. The smoothness index captures the time series of rate changes. A smaller smoothness index indicates smoother throughput change for a flow. The simulation results show that smoothness index for PACEC varies from 0.02 to 0.05, it varies from 0.03 to 0.09 for RCP, and varies from 0.06 to 0.18 for TCP. Based on these values, indicating that PACEC is smoother compared with RCP and TCP.

Fairness
Fairness is used to decide whether the user or application receives a fair share of system resources. Here, we use the mathematical definition from Jain and Chiu [26]. Fairness can be written as (x 1 , x 2 , … . . , x n ) = (∑ x i n 1 ) 2 n. ∑ x i 2 n 1 (13) where xi is the throughput of flow i and n is the sum of flow. We consider the medium-term fairness of PACEC. To evaluate medium-term fairness, we obtain the average throughput of PACEC flows over the entire time of simulation (100 seconds). We simulated 20 identical flows (10 Mbps). Based on equation (13), we got fairness index for 20 identical flows as shown in Figure 5. The fairness index of PACEC is smaller than RCP and RCP. The fairness index of PACEC is 0.99 (close to one) which indicates that the throughput assignment for a competing flow in PACEC is fair.

CONCLUSION
In this paper, we designed a new Router Assisted Congestion Control (RACC) mechanism that works with the SDN framework. This mechanism is designed to overcome weaknesses in traditional Internet networks that cannot provide global information networks. We propose a scheme that uses explicit information from the controller as a network policy determiner. Based on the information from the controller, the sender can adjust the sender rate according to the network conditions. The sender does not need to adjust the sending rate incrementally. We have demonstrated through computer simulation that the scheme is able to use the network bandwidth more efficiently and more consistently, and also able to maintain fairness of any flow that requests network services. For future works, we plan to integrate this scheme with admission control and bandwidth allocation mechanism.