Computer Modeling in Engineering & Sciences

DOI: 10.32604/cmes.2021.012230

ARTICLE

A Trusted NUMFabric Algorithm for Congestion Price Calculation at the Internet-of-Things Datacenter

Shan Chun1, Xiaolong Chen2, Guoqiang Deng3,*and Hao Liu4

1School of Electronics and Information, Guangdong Polytechnic Normal University, Guangzhou, 510665, China
2Information Engineering College, Jinhua Polytechnic, Jinhua, 32100, China
3The Information Network Engineering and Research Center, South China University of Technology, Guangzhou, 510641, China
4Qianxin Technology Group Co., Ltd., Beijing, 100044, China
*Corresponding Author: Guoqiang Deng. Email: Denggq@yeah.net
Received: 21 June 2020; Accepted: 16 October 2020

1  Introduction

1.1 Background

The Internet of Things (IoT) was one of the main sources of big data [1]. By 2020, there will be more than 50 billion devices connected to each other [2], in addition to a large number of servers and routing devices, many edge devices and mobile devices are included [3], which will generate a large amount of data [4]. In addition to the security of IoT devices [5,6], it is essential to manage and transmit such a large amount of data due to big data often comes with a certain degree of insecurity [7]. Blockchain technology can figure out part of the problem of insecurity [8,9]. Data aggregation is an important method to solve the big data problem of the IoT [10]. The network of the IoT datacenter [11] was the kernel component of the cloud computing datacenter. It is responsible not only to support the interconnections for thousands of servers, but also provide high-rate data transmission for calculating services in the application layer [12]. The introduction of Software Defined Network (SDN) in the IoT can not only improve the flexibility and scalability of the IoT, but also provide a better solution for live data aggregation mechanism of IoT [13]. Since the mature detection schemes for network attacks against SDN was already presented, the security of SDN was guaranteed.

In the traditional Internet business, network traffic usually takes place between the client outside the IoT datacenter and the requested server inside the datacenter (It is called “north-south traffic”), where the traffic between the servers (“east-west traffic”) was low [14]. In the emerging virtual-reality-calculation and online Internet business, large amounts of one-to-many or many-to-many communication between servers is required [15,16]. As a result, the internal traffic of cloud computing IoT datacenters grows rapidly and presents new characteristics different from the traditional Internet [17,18].

Different applications in the IoT datacenter have different bandwidth and latency requirements. For example, online query services such as responding to search engines are obviously more urgent than virtual machine migration or log backup. In order to satisfy the application’s disparate demands with limited bandwidth, the server needs to decide how fast to send the packet. On the other hand, the link needs to determine the queue order of packets coming from different connections [19] and which route the packets should take if there are multiple paths [20]. The whole process depends on the congestion control, traffic scheduling and load balancing of the network [21]. Among them, network congestion deserves attention because it is easy for an attacker to seize the opportunity to launch a solar eclipse attack when the network is congested [22].

Recently, there have been a lot of research studied on transmission control protocol [20,23] in the networks of cloud computing IoT datacenters. A data-driven approach for Internet routing decision modeling in the future is also proposed [24]. These works have diverse targets for bandwidth sharing management. Besides minimizing the rate of deadline, latency or average flow completion time, other goals include multi-user bandwidth sharing. As a matter of fact, each improved transmission control protocol sustains one or two objectives in the bandwidth sharing strategy. However, for cloud computing IoT datacenters, it is more beneficial to adjust for diverse targets based on the user’s demands [25].

Contrasted to the traditional networks which suffer from low bandwidth and long delay time, with a centralized design, the cloud computing IoT date center network is capable of providing massive traffic bandwidth, quick response and high throughput. It is worth noting that due to the difference in network architecture, to guarantee the data transmission performance, the transfer control algorithms used in traditional networks cannot be directly applied in the networks of cloud computing IoT datacenters.

The function model of multi-source and multi-link utility maximization was presented based on nonlinear programming theory in Jalaparti and Bliznets’s Dynamic Pricing and Transmitting [25]. The key idea of such non-centralized and nonlinear programming theory is that the link prices are dynamically changing and the TCP sending windows are adjusting at a constant interval. Further, when the networking state is in balance, the networking utility will obtain maximization [26].

Until now, congestion pricing of the enhanced transmission control protocol for the current cloud computing IoT datacenter and the active queuing management approach in the link were involved in these theoretical nonlinear programming structures [27]. The important issues of network TCP congestion control are how to compute the link price according to the link status and how to regulate the data sending rate based on link congestion pricing feedback information. To address these issues, DCTCP [11,27], D2TCP [28], ICTCP [29], D3 [30], PDQ and DeTail DCTCP were put forward to satisfy the requirements of cloud computing IoT datacenter transmission control protocol. It is worth noting that these enhanced TCP’s calculate the price of congestion link based on the ratio of network link statuses (for example the length of queuing, delay of packet queuing. length of packet queuing).

In each cloud computing IoT datacenter network, the rates of transfer can be related by a utility function. The goal is to maximize network utility within the limit of (subject to) link capacity as expressed by

where x is the rate vector of traffic TCP, R is the routing matrix (i.e., the element of R equals to 1 if and only if the TCP traffic i passes the respective link), and c is the link capacities vector. We assumed that the utility functions U(.) are smooth, increasing, and strictly concave. In [25,31], NUMFabric, an innovative transmission control protocol which provides nimble and quick bandwidth sharing control was proposed. Particularly, the proposed NUMFabric protocol is a decentralized protocol applied between the link end and TCP source. Further, the proposed NUMFabric protocol method can make the network converge on a certain specified equilibrium faster than any other previous protocol. The key idea of NUMFabric is based on the classic framework of non-linear programming maximization theory which tackles the TCP traffic flow resource-sharing problem by maximizing the utility function. This maximum utility function was created to benefit the diverse needs of link bandwidth sharing and could be updated by the network operator to accomplish different bandwidth and fairness intentions. Then the enhanced NUMFabric can enable the bandwidth sharing to ensure maximal total utility.

The main technical contribution of NUMFabric is a TCP congestion control which using the NUM method converges on balance faster than previous research work. The kernel idea of NUMFabric is decoupling the methods for network utility maximization and for maximum congestion link bandwidth sharing among common transport flows. The former NUM algorithms combine these goals and try to solve both of these problems at the same time via price changes at the links. This process is no longer robust because of the requirement to balance between the goal of speedy convergence towards optimal link bandwidth sharing and of avoiding a state of traffic jam or low-utilization. Although the NUMFabric achieved better performance than others, the method of calculating link price with the average residual can be improved upon using Openflow in the cloud computing IoT datacenter.

1.2 Main Idea

In this paper, the whole network structure has been obtained by the central control server in the SDN, and in order to calculate link price, we propose a kind of dual hierarchy algorithm based on non-linear programming. The idea of the upper layer method is applied in the kernel controller of the SDN (i.e., Opendaylight) network for the cloud computing IoT datacenter and the guiding parameter B is given by the improved NUMFabric method in the first layer based on all link statuses (net topological structure, state of link end and size of packet queuing are included). The second hierarchy method is applied in links and the web congestion signal price is calculated based on the guiding parameter B given by the first layer method.

1.3 Organization of the Rest of the Paper

The rest of this paper is organized as follows. We present the improved NUM framework for enhanced NUMFabric congestion signal calculation algorithm in Section 2. In Section 3, we present the detail for the dual-hierarchy network of enhanced NUM Fabric algorithm. Particularly, Subsection 3.1 introduces the first hierarchy algorithm in the central controller; the second hierarchy algorithm in Openflow link is proposed in Subsection 3.2. Scheme comparison is given in Section 4. Efficiency analysis and throughput verifiability analysis are given in Sections 5 and 6 respectively. At last, Section 7 concludes the paper.

1.4 Improved NUMFabric Algorithm General Framework

The improved NUM Fabric algorithm under the Software Defined Network structure is illustrated in Fig. 1. The kernel server is designed to implement the proposed dual-hierarchy networking congestion signal calculating method. The OpenDaylight in the kernel server comprises of the Abstract Service Layer (SAL) and basic networking services action. The basic networking services comprise of network structure control module, statistic control module, link control module, link forward rule management module, and host tracing module.

Figure 1: Multi-source and multi-link networking structure

In the Software Defined Network structure, the information in the second hierarchy kernel link including new transport flow connection and network link status will be submitted to the top hierarchy method in the kernel central service controller. The network structure control module and statistic control module capture switch status information and propose theses link state operating information to the overall net status gathering module, so the first hierarchy method allocated in the kernel central controller in the cloud computing network can obtain real-time overall link state in web link. When the state of a small number of link load is low, the kernel service controller can change the routing flow table to balance the link load while the network transport flow will continue to send the packets. Therefore, it is not necessary to promote the link congestion price and restrain the transmitting rate of the sending TCP. The first hierarchy algorithm will not provide the radical guiding parameter B. But when all links are in peak load, it is out of the question to change the forward transmitting routing table. Therefore, in order to avoid all link states becoming the peak load state and to keep the cloud datacenter from becoming crowded, the kernel service controller will calculate the radical guiding parameter B and promote the link congestion signal price to restrict the sending window sizes of the source TCP.

2  The Hierarchical Link Price Calculation Algorithm

The key idea of the improved algorithm is that the first hierarchy algorithm in kernel controller in cloud computing network provides the guiding parameter B by applying the switch link congestion signal price calculation method based on all switch link state. When small link switch status are in lower load, the central controller in the cloud computing IoT datacenter can instruct the data packet to turn to the lower load. In this case, the first hierarchy algorithm will not provide the radical guiding parameter B. However, when all links are in peak load it is out of the question to change the forward transmitting routing table. Therefore, in order to avoid all link state becoming the peak load state and to keep the cloud IoT datacenter from getting crowded, the kernel service controller will calculate the radical guiding parameter B and promote the link congestion signal price to restrict the sending windows size of the source TCP.

2.1 Upper Hierarchy Enhanced NUMFabric Method

2.1.1 All Openflow Link Running Status

See Fig. 3, the first hierarchy algorithm in central control servers often sends the LLDP (Link Discovery Protocol PACKED) to all Openflow link and gathers the network structure information. Then Opendaylight in the central control servers can build the overall network structure. By using the protocol of Openflow among the central control servers and link switches, we modify the packet that contain server and link (both symmetric and asynchronous communication packets) and add new data to these packets’ information structure. The modified data structure above contains the link status, guiding parameter B for the congestion signal calculation method and actual operating effect of the link in the cloud computing IoT datacenter.

2.1.2 Parameter Calculation

At the start time of the price calculation algorithm, based on the programming and openness of the Software Defined Network framework, the mapping relation among the network structure B of calculating link price parameter B and overall network link price are updated by the cloud computing IoT datacenter operator according to occupation history. When part Openflow link loads are light, the first hierarchy algorithm in central control servers give loose network structure B. But when all the links are under heavy load, the central control servers will provide the non-loose network structure B and promote the link congestion price to restrain the of the TCP source sending rate and avoid network congestion. The link load is , and the .

2.2 Second Hierarchy Algorithm in Openflow Link

xWI is an innovative decentralized method for solving NUM problems; it operates with weighted max–min and realizes a transport layer like Swift. xWI is applied by iterative algorithm. For each iterating step, TCP flow communicates with the Openflow link to calculate the weights to set for their traffic flows in Swift. xWI iteratively obtains the weights to arrive at the balanced state of Network Utility Maximization. The important issues in xWI are to iteratively solve the KKT equations for the NUM problem.

2.2.1 System Model

As shown in Fig. 1, the link set is , and the capacity of link is .The source set is . Each source is described by four parameters .

denotes that sources travel to the links set. is a utility function, ms, Ms are the maximum and minimum transmitting rates of the source s. Set as the range of the sources rate xs. Set as the set of sources travel to the link l. pl is price of Openflow link.

The network utility optimization model is described as followed:

Define the Lagrangian function

The dual problem of (2) is described as follows:

where

We can obtain the dual problem as follows:

where Us is strictly concave, is continuously differentiable with derivatives given by

where is the aggregate source rate at link l.

Substituting (4) to (6) we obtain the following link price adjustment rule for link :

At the time of t + 1, the prices of Openflow link are modified based on the values in iteration t. The modified rule contains two terms, corresponding to the two optimality conditions. The first part is obtained by

where is the number of links in flow i’s path.

The second part based on underutilization form is given by

  1.  For each constant time interval, the central control servers will acquire map of the relationship between the link running status and vector B.

  2.  As shown in Fig. 2, vector B is from the first hierarchy algorithm, which is based on calculating the price of Openflow link of each link.

Figure 2: Improved NUM structure based on the software defined network in cloud computing IoT datacenters

Figure 3: Dual hierarchy link price calculation algorithm of improved NUMF

The second algorithm in the openflow switch:

At time in link l

Step 1: Receives rates from all sources that travel through link l.

Step 2: Calculates a new link price

This is the refinement calculation method for link price.

Combining these two terms, we obtain as follows:

Here, is the filtering parameter. (Set to 0.5 in our experiment).

Step 3: Communicate new price to all sources that travel through link l.

Source algorithm:

Step 1: Receives rates from all sources that travel through link l.

Step 2: Chooses a new transmission rate xs(t + 1) = xs(t)(ps(t))

Step 3: Communicate new rate xs(t + 1) to links in its path.

The calculation results are shown in Tab. 1.

Table 1: The link load and the rate parameter B

The improved NUMF method makes full use of the trait that the core server control in SDN can obtain the global link status and calculate the guiding parameter B. Compared with related methods, the link calculation price rule is divided into two terms and therefore more refined. The update rule for calculating price consists of two terms, namely formula (8) and formula (10), corresponding to the two optimality conditions.

3  Related Method Comparison

We design a semi-dynamic scenario to quantify the throughput per-flow. In the semi-dynamic case, we can trigger network incident in a controlled method and meter the network throughput.

We make the simulation at a cloud computing IoT datacenter network which is built using a leaf-spine structure with NS3. There are 32 servers connected to 4 leaf openflow links and the link bandwidths is 1000 Mbps. Each leaf openflow link is connected to 4 spine links and the link bandwidth is 10 Gbps, so it can guarantee full bisection bandwidth. The openflow links are intended to be standard output-queued links, with a buffer of size 1 MB per port. We have compared the convergence time with the following method.

3.1 FAST TCP

Fast TCP optimizes TCP traffic over wide area networks and wireless data networks, especially in TCP environments with high latency and packet loss. Fast TCP does not change the standard format of TCP Packet Header, but the traffic control algorithm is optimized, which greatly improves the efficiency of TCP traffic and the utilization of WAN bandwidth.

3.2 DCTCP

We will extensively deploy TCP’s congestion control algorithm like DCTCP. DCTCP adopts Explicit Congestion Notification (ECN) in switches to detect and respond to network congestion signal by sequencing ECN marks via the switch [32]. DCTCP provides the same or better throughput than TCP, while reducing the router buffer space by 90% and ensuring security. In the link, DCTCP adopts a very simple active queue management mechanism. When the queue takes up more than a certain threshold value k, the arriving packet is marked with the CE (Capacity Experience) flag. On the DCTCP receiving end, DCTCP returns the ECN and accurately conveys which packets have experienced congestion.

3.3 Improved NUM

This improved NUMFabric method propose a dual hierarchy method. The first hierarchy algorithm in the kernel controller produce the guiding parameter B for calculating switch link congestion signal price by taking full advantage of all switch link state information. The update rule for calculating price in the second hierarchy method consists of two terms, corresponding to the two optimality conditions.

4  Experimental on NS3

In this section, according to evaluation of improved NUMFabric, we give a NS3 simulation. The goal is to simulate the throughput of NUMFabric to maximize the allocation in dynamic settings and to achieve bandwidth allocation goals precisely and robustly. We choose one-to-one communication, where our server communicates randomly with another server once a time. The results are demonstrated in Figs. 5 and 6.

Convergence: Fig. 4 displays the CDF convergence time of FAST TCP, DCTCP, and improved NUMFabric. The average convergence time of Improved NUMFabric is 591 (s). The average convergence time of FAST TCP is 726 (s). And the average convergence time of DCTCP is 813 (s).

Figure 4: CDF of convergence time for improvedNUM, FAST and DCTCP

Figure 5: Rate of FAST TCP

Figure 6: Rate of DCTCP

The main reason for the improvement in NUMFarbic convergence speed is that the link price is calculated by the global guiding parameter B which takes into consideration the global network running status. Further, the update rule for price calculation was also more refined designed; it made up with two terms, each according with two optimum conditions. From above CDF of convergence time, we can see that the improved NUMFabric achieves better convergence performance.

4.1 Rate Stability Comparison

Fig. 5 displays the rate achieved by a typical FAST TCP flow during several network events. The expected rate of the FAST flow is shown by the blue line connecting the datapoints. It is clear from Fig. 5 that the FAST TCP flow does not ever converge to within 10%.

Fig. 6 displays the rate reached a representative DCTCP flow when few network-events happen. The anticipant rate of FAST flow is given from the blue one. that the Fig. 6 depicted syllabify that the DCTCP flow does not ever converge to within 10%.

Compared to Figs. 5–7 displays a better rate reached by the according flow the Improved NUMFabric.

Figure 7: Rate of Improved NUMFabric

5  Conclusion

The IoT data aggregation scheme based on SDN designed in this paper can improve NUMFabric algorithm for calculating overall congestion signal. We get the most advantage out of the trait that the whole network structure has been obtained by the central control server in the Software Defined Network and proposed a kind of dual hierarchy method for calculating overall network congestion signal. The first hierarchy method is set up in a central control server like Opendaylight and obtains the guiding parameter B based on the overall link state information. The second hierarchy method is assigned in Openflow link and the link price is calculated based on guiding parameter B given by the first method. The update rule for calculating price in the second hierarchy method consists of two terms, which correspond to the two optimality conditions. The simulation results demonstrate that this improved NUMFabric method can indeed provide better rate stability, reduce the time delay of data aggregation, improve the accuracy of data aggregation and the performance of the network.

Funding Statement: The authors thank all the reviewers and editors for their valuable comments and works. This work is supported by National Key R&D Program of China–-Industrial Internet Application Demonstration-Sub-topic Intelligent Network Operation and Security Protection (2018YFB1802400).

Conflicts of Interest: The authors declare that they have no conflicts of interest to report regarding the present study.

This work is licensed under a Creative Commons Attribution 4.0 International License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.