Software-Defined Congestion Control Algorithm for IP...
9
Research Article Software-Defined Congestion Control Algorithm for IP Networks Yao Hu, Ting Peng, and Lianming Zhang College of Physics and Information Science, Key Laboratory of Internet of ings Technology and Application, Hunan Normal University, Changsha 410081, China Correspondence should be addressed to Lianming Zhang; [email protected] Received 7 October 2017; Revised 28 November 2017; Accepted 11 December 2017; Published 27 December 2017 Academic Editor: Basilio B. Fraguela Copyright © 2017 Yao Hu et al. is is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. e rapid evolution of computer networks, increase in the number of Internet users, and popularity of multimedia applications have exacerbated the congestion control problem. Congestion control is a key factor in ensuring network stability and robustness. When the underlying network and flow information are unknown, the transmission control protocol (TCP) must increase or reduce the size of the congestion window to adjust to the changes of traffic in the Internet Protocol (IP) network. However, it is possible that a soſtware-defined approach can relieve the network congestion problem more efficiently. is approach has the characteristic of centralized control and can obtain a global topology for unified network management. In this paper, we propose a soſtware-defined congestion control (SDCC) algorithm for an IP network. We consider the difference between TCP and the user datagram protocol (UDP) and propose a new method to judge node congestion. We initially apply the congestion control mechanism in the congested nodes and then optimize the link utilization to control network congestion. 1. Introduction In recent years, the development of science and technology has increased user demand for computer networks, which has accelerated the severity of network congestion problems. e increase in devices having applications that require file down- loading and sharing, Internet browsing, voice over Internet phone, and multimedia has also contributed to the severity of network congestion problems. us, efficient congestion control is a key factor to ensure IP network stability and robustness. ere are two approaches in solving the network con- gestion problem. e first is the end-to-end approach, where research is focused on the mechanism of terminal congestion control to relieve congestion. e second is the network side approach, where congestion control is achieved through data stream scheduling and line management on the forwarding nodes. e initial research focused on the end-to-end con- gestion control, such as the widespread use of transmission control protocol (TCP). Because of its good adaptability and extensible capability, TCP has received widespread interest and became the main congestion control algorithm presently. Researchers in this area have conducted significant exploration and investigation and have put forward many improvements. For example, the latest versions of the four kinds of TCP congestion control algorithms, namely, Veno, Westwood, Hybla, and Cubic, have achieved optimization by packet loss judgment, bandwidth prediction, time delay compensation, and homogeneous compensation mechanism, respectively [1–3]. Paper [4] has studied the micro-level behaviour characteristics of TCP congestion control algo- rithm in multihop wireless networks. Paper [5] has proposed an adaptive cross-layer-based TCP congestion control for 4G wireless mobile cloud access. A deadline-aware congestion control mechanism, based on a parametrization of the tradi- tional TCP New Reno congestion control strategy, has been proposed in [6]. e appropriate limit of the biggest transfer rate of each data flow can effectively reduce network congestion and packet loss. However, previous studies reported that when the underlying network and information flow are unknown, TCP must increase or reduce the size of congestion window to adjust to the changes of traffic [7–9]. is finding highlighted that the traditional IP network lacks the direct control Hindawi Scientific Programming Volume 2017, Article ID 3579540, 8 pages https://doi.org/10.1155/2017/3579540
Transcript of Software-Defined Congestion Control Algorithm for IP...
Research ArticleSoftware-Defined Congestion ControlAlgorithm for IP Networks
Yao Hu Ting Peng and Lianming Zhang
College of Physics and Information Science Key Laboratory of Internet of Things Technology and ApplicationHunan Normal University Changsha 410081 China
Correspondence should be addressed to Lianming Zhang zlmhunnueducn
Received 7 October 2017 Revised 28 November 2017 Accepted 11 December 2017 Published 27 December 2017
Academic Editor Basilio B Fraguela
Copyright copy 2017 Yao Hu et al This is an open access article distributed under the Creative Commons Attribution License whichpermits unrestricted use distribution and reproduction in any medium provided the original work is properly cited
The rapid evolution of computer networks increase in the number of Internet users and popularity ofmultimedia applications haveexacerbated the congestion control problem Congestion control is a key factor in ensuring network stability and robustnessWhenthe underlying network and flow information are unknown the transmission control protocol (TCP) must increase or reduce thesize of the congestion window to adjust to the changes of traffic in the Internet Protocol (IP) network However it is possible thata software-defined approach can relieve the network congestion problem more efficiently This approach has the characteristic ofcentralized control and can obtain a global topology for unified networkmanagement In this paper we propose a software-definedcongestion control (SDCC) algorithm for an IP network We consider the difference between TCP and the user datagram protocol(UDP) and propose a newmethod to judge node congestionWe initially apply the congestion control mechanism in the congestednodes and then optimize the link utilization to control network congestion
1 Introduction
In recent years the development of science and technologyhas increased user demand for computer networks which hasaccelerated the severity of network congestion problemsTheincrease in devices having applications that require file down-loading and sharing Internet browsing voice over Internetphone and multimedia has also contributed to the severityof network congestion problems Thus efficient congestioncontrol is a key factor to ensure IP network stability androbustness
There are two approaches in solving the network con-gestion problem The first is the end-to-end approach whereresearch is focused on the mechanism of terminal congestioncontrol to relieve congestion The second is the network sideapproach where congestion control is achieved through datastream scheduling and line management on the forwardingnodes The initial research focused on the end-to-end con-gestion control such as the widespread use of transmissioncontrol protocol (TCP) Because of its good adaptabilityand extensible capability TCP has received widespreadinterest and became the main congestion control algorithm
presently Researchers in this area have conducted significantexploration and investigation and have put forward manyimprovements For example the latest versions of the fourkinds of TCP congestion control algorithms namely VenoWestwood Hybla and Cubic have achieved optimizationby packet loss judgment bandwidth prediction time delaycompensation and homogeneous compensationmechanismrespectively [1ndash3] Paper [4] has studied the micro-levelbehaviour characteristics of TCP congestion control algo-rithm in multihop wireless networks Paper [5] has proposedan adaptive cross-layer-based TCP congestion control for 4Gwireless mobile cloud access A deadline-aware congestioncontrol mechanism based on a parametrization of the tradi-tional TCP New Reno congestion control strategy has beenproposed in [6]
The appropriate limit of the biggest transfer rate of eachdata flow can effectively reduce network congestion andpacket loss However previous studies reported that whenthe underlying network and information flow are unknownTCPmust increase or reduce the size of congestionwindow toadjust to the changes of traffic [7ndash9]This finding highlightedthat the traditional IP network lacks the direct control
HindawiScientific ProgrammingVolume 2017 Article ID 3579540 8 pageshttpsdoiorg10115520173579540
2 Scientific Programming
of forwarding queue and cannot guarantee link utilizationand quality of service We have considered this aspect inour research to find a solution for the network congestionproblem
In the traditional IP network architecture the controland forwarding planes are highly integrated and the net-work is difficult to extend and customize It has a longtechnology update cycle and is too dependent on networkequipment manufacturers Simultaneously the increasinglycomplex network environment makes it difficult to developthe network and make innovations related to the hardware ofphysical devices or software of related protocols and perfor-mances especially in the proprietary equipment and closedinterfaces Programmable models and code that allow datatransmission from the network to the application are neededThe technology of software-defined everything from applica-tions to infrastructure is one of the top 10 strategic technologytrends identified by Gartner [10] Software-defined network-ing (SDN) separates the network control and forwardingfunctions enabling the network to be directly programmabledynamic and manageable The separation of the controlplane and data plane allows the core technologyOpenFlow torealize the flexible control of the network traffic making thenetwork more intelligent and provide a better platform fornetwork application innovation [11ndash13]
In this study we used a software-defined approach tosolve the congestion control problem in the IP networkCompared with the existing literature this paper has thefollowing major contributions
(i) A comprehensive survey of congestion control in theIP network is presented In the traditional networksthe underlying network and flow information areunknown It must increase or reduce the size ofthe congestion window to adjust to the changes oftraffic while a software-defined approach can relievethe network congestion problem more efficiently Sowe propose a software-defined congestion control(SDCC) algorithm for the IP network
(ii) The type of data flow in the IP network is taken intoaccount The difference between TCP and UDP ispointed out Based on the different characteristics ofTCP and UDP we propose a new method in judgingcongested nodes
(iii) The simulation of our algorithm is comprehensivelyexplained We consider the packet loss rate and opti-mization of link utilizationThe simulation shows thatthe proposed algorithm achieves network congestioncontrol and optimizes the link utilization
In the following sections we first discuss the existingresearch on the congestion problem in the IP network basedon SDN in Section 2 Section 3 presents an SDCC algorithmfor the IP network The effectiveness of the algorithm isverified by a simulation experiment described in Section 4Finally the paper concludes in Section 5
2 Background
21 Related Work Network congestion control using asoftware-defined approach is still in its early stage of devel-opment Ghobadi et al [14] proposed a TCP dynamicadjustment framework based on SDN-OpenTCP OpenTCPis an SDN application deployed on an SDN controller usingthe global network view of SDNs and is established basedon the good strategy mechanism with the forwarding nodesand modifying the terminal protocol stack to continue thedynamic adjustment with the terminal congestion mecha-nism to achieve optimization It fills the SDN applicationgap in the field of congestion control and is very interestingHowever OpenTCP is a new architecture that is widelydeployed and needs to modify its source side forwardingnodes controllers and other global network to provide sup-port This framework also illustrates that the TCP dynamicmanagement strategy is open to managers and does nothave a specific adjustment method and adjustment of thetarget Long et al [15] proposed a kind of network congestioncontrol mechanism based on OpenFlow which is consid-ered as the first SDN standard This mechanism is basedon the OpenFlow network features that define a methodin judging the link congestion control threshold Whennetwork congestion occurs the corresponding congestioncontrolmechanism is immediately started and themaximumbandwidth data flow in the congested link is identified andrerouted to achieve load balance Lu et al [16] presented acongestion control algorithm that supports multiple activequeue management The algorithm is dynamically adap-tive to interactive link information and can effectively usebandwidth and network congestion control Gholami andAkbari [17] proposed amethod based on SDN andOpenFlowto solve this problem In this method link congestion isdetected by central monitoring of the port statistics of theOpenFlow enabled switches and some of the flows in anycongested link are rerouted by the OpenFlow controller Thismethod highlighted the effectiveness of SDN in solving thecongestion problem Hershberger et al [18] also proposed anew congestion optimization algorithm based on SDN Thisalgorithm chooses the 119896 shortest path for each data flowahead of schedule When network congestion occurs the119896 paths are sequentially traversed to determine which pathis not congested This method realizes the load balance tosome extent however it also has a significant computationoverhead Meanwhile these methods do not consider thetype of data flow If the selected routing involves a UDP dataflow with highly demanding timeline but allows packet lossand the delay of the new reroute shortest path is large Thenthis reroute strategymay not be an optimal choiceThereforewe considered the difference of the type of data flow in ourproposed algorithm
22 Key Principles of a Software-Defined Approach SDN is amature software-defined area that originated from StanfordUniversityrsquos Clean Slate research [19 20] It is considered anew kind of network architecture and a method of imple-menting network virtualization Its core concept is to separatethe control plane and the data plane of the network hardware
Scientific Programming 3
equipment Software programming is implemented in thecontrol planeThe SDN architecture can be divided into threelevels (1) application layer (2) control layer and (3) equip-ment layer It has the following three basic characteristics(1) centralized control (2) programmable software and (3)network virtualization
OpenFlow network is comprised of the OpenFlow switchand OpenFlow controller Switches and controllers establishthe secure connection by transport layer security (TLS) orTCP prior to OpenFlow message interaction issuing flowsheets information query reporting interface status andother functions
In OpenFlow network controllers first send the link layerdiscovery protocol (LLDP) message (encapsulated in thePacket-Out message sent) to each of the OpenFlow switchesto obtain the global network topology Then the switchesregularly send Port-Status messages to controllers to reportport information of each switch This information includingdata flowheader and transmission rate is recorded in the datainformation flow of each port in the switches
3 Software-Defined CongestionControl Algorithm
This paper investigates the use of software-defined approachin solving the congestion control problem in the IP networkWe proposed an SDCC algorithm that considered the dif-ference between TCP and UDP a new method in judgingcongested nodes and the start of the congestion controlmechanism in the congested nodes then controlling thenetwork congestion to optimize the link utilization
The main concept of the SDCC algorithm is based onthe SDN architecture where the controller obtains portinformation of each switch to monitor for congested links Ifnetwork congestion exists the congestion controlmechanismis started then one or more appropriate data flows areselected and the shortest rerouting path is calculated tocontrol the congestion This process allows the efficientuse of network bandwidth resources and increases the linkutilization
We considered the data flow condition in the real networkand mainly focused on the heterogeneity between the TCPdata flow and the UDP data flow in proposing this congestioncontrol mechanism
The process is as follows (1) the controller obtains theglobal information and regularly monitors the network con-gestion condition (2) estimate whether there are congestedlinks based on formula (1) (3) if congested link is discoveredit is removed from the topology image to generate a newtopology image (4) calculate the shortest path between thelast node of the congested node to the destination node and(5) select one or more appropriate data flows to reroute
31 Estimating Congested Links In the OpenFlow networkthe controller according to theOpenFlow v10 standard spec-ification obtains a global network topology image throughthe LLDP and then sends port status information requestmessage to each of the OpenFlow switches regularly Open-Flow switches receive this message and feedback to the
R1 R2
f1
f2
f3fn
Figure 1 Bottom switch network
Input link bandwidthOutput congested links(1) For 119891119896 in link(2) IF flow = TCP(3) 119861tcp = 119861tcp + flow(4) ELSE 119861udp = 119861udp + flow(5) IF 119861th-119861udp lt 119861tcp lt B(6) linkrarr congested(7) ELSE continue monitoring
Algorithm 1 Estimating
controller the data information flow of each port in theswitches such as data flow header and transmission rate
As shown in Figure 1 the controller detects that in theOpenFlow network there are 119899 data flows (1198911 1198912 1198913 119891119899)in R1 to R2 link and the rate of each data stream is(V1 V2 V3 V119899) Moreover there are 119894 UDP data flows and119895 TCP data flows
Assume that the total bandwidth for the link R1 toR2 is 119861 and the link congestion threshold is 119861th (specificvalue of 119861th is according to the physical properties of thenetwork environment)119861tcp is the congestion threshold of theTCP flows in this link which is the link surplus maximumbandwidth for the TCP data flows aftermeeting theUDPdataflow transmission demand as follows
1198611015840th (119905) = 119861th minus119894
sum119896=1
119891udp119896 (119905)
119861tcp =119895
sum119896=1
119891tcp119896 (119905)
(1)
where 119894 + 119895 = 119899 119861tcp is the total rate of the TCP flows and theinitial value of 119861tcp and 119861udp is 0 Then if 1198611015840th lt 119861tcp lt 119861 weconfirm that R2 is in a congestion state and the link R1 to R2is the congested linkThe algorithm for estimating congestedlinks is as in Algorithm 1
32 Calculation of Rerouting Links Now the controller needsto choose a new path for rerouting part of the data flowsin the congested link The controller removes all estimated
4 Scientific Programming
R1 R2
Figure 2 New bottom switch network
Input link and node distanceOutput new path and update the flow table(1) IF link[119886]rarr congested(2) dist[119886] = INFINITY(3) For 119894 do(4) dist[119894] = V[0] rarr V[119894](5) For 119894 do find the nearest point(6) int mindist = INFINITY(7) For 119895 do(8) If dist[119895] ltmindist(9) mindist = dist[119896](10) For 119895 do update the shortest path(11) If mindist + V[119896] rarr V[119895] lt V[0] rarr V[119895](12) dist[119895] = mindist + V[119896] rarr V[119895](13) Newlinkrarr Packet out update flowtable(14) OFPFC DELETE(15) OFPFC ADD(16) Delete OutFlowtable
Algorithm 2 Rerouting
congested links from the global network topology image andthen obtains a new noncongested network topology image asshown in Figure 2 In the concrete execution we set the linkpath distance as infinity to achieve the deletion
Then using the shortest path algorithm to calculate theshortest path with non-congestion from the last node of thecongested node to the destination node and finally choosingthe appropriate data flows transferred to this new path tocomplete the transmission the algorithm of the OpenFlownetwork rerouting is presented as in Algorithm 2 Parameter119894 represents 119894 UDP data flows and parameter 119895 represents 119895TCP data flows Parameter 119896 represents the 119896th data flow
33 Selection of Rerouted Data Flows Considering that theUDP data flows always emphasize short transfer time andhigh-efficiency requirements we selected the TCP data flowsfor the rerouting Assuming that there are 119895 TCP data flows(1198911 1198912 1198913 119891119895) on one congested link the rate of each dataflows is (V1 V2 V3 V119895) and we obtain the following
1198611015840tcp = 119861tcp minus (V119886 + V119887 + sdot sdot sdot + V119896) (2)
To ensure high link bandwidth utilization when thetotal rate of the TCP flows on this link 119861tcp minus part ofthe rate (119891119886 119891119887 119891119896) and a new total rate of TCP flows1198611015840tcp closest to 1198611015840th is obtained then we are assured that thedata flows (119891119886 119891119887 119891119896) are optimal choice for reroutingthe transmission The selection algorithm of the rerouteddata flows are as in Algorithm 3 Parameter 119908 represents thenumber of the most suitable data flows
4 Experiment and Result
41 Experiment Design We considered the data flow condi-tion in the real network and mainly focused on the hetero-geneity between the TCP data flow and the UDP data flowin proposing this congestion control mechanism In our testenvironment the controller obtains the global informationand regularly monitors the network congestion conditionThe controller estimates whether there are congested links Ifcongested link is discovered it is removed from the topologyimage to generate a new topology image The controllercalculates the shortest path between the last node of thecongested node to the destination node At last the controllerselects one or more appropriate data flows to reroute
To verify the proposed congestion control mechanismusing the OpenFlow network we built the test environmentas shown in Figure 3 OFS1 OFS2 and OFS3 are OpenFlowswitches by Mininet simulation OFC is the OpenFlow con-troller with POX [21] PC1ndashPC6 are common user terminalsand we use the Iperf tool on user terminals to send the dataflows
We added the link monitoring congestion detectionrerouted data flow selection and shortest path calculationfunction modules in the POX controller and combined themwith the existing modules of topology discovery and flowtable update to achieve the proposed congestion controlmechanism The running process of each module is shownin Figure 4
After the POX controller starts the LLDP protocol isfirst run to obtain the entire network topology and thenthe congestion detection module is triggered to regularly(the experiment is set at 2 s) query each OFS for statusinformation of each port and record the number and sizeof each flow through this port Then the controller willadd the rates of all data flows together We found that theNetFPGArsquos port line speed is 1 Gbps Aftermany experimentswhen the port rate reaches 950MBs the packet loss rate willquickly reach 2 magnitude and it is out of the standardof common business demand Therefore to simulate the realnetwork environment we set the port congestion thresholdat 950MBs in our test
42 Results and Analysis To facilitate testing we built fourdata flows with Iperf (as shown in Table 1) and sets OFS1-OFS2 as Path 1 and OFS1-OFS3-OFS2 as Path 2 As identifiedby the shortest path algorithm these four flows will betransmitted through Path 1 In this experiment the rate of 1198913will be increased over time
Scientific Programming 5
Input all data flow rates through the congested linkOutput number of selected flow(1) For 119894 do(2) sum = sum + flow[119894](3) For i do Select the appropriate flow and tag it(4) If flow = TCP ampamp congested ampamp sum-flow[119908] gt bestsum(5) bestsum = sum minus flowsize[119908](6) bestflownum = 119908(7) Return bestflownum
Algorithm 3 Selection
PC1
PC2
PC3
PC4
PC5
PC6
OFS1 OFS2
OFS3
OFC
Figure 3 OpenFlow network experiment platform
Link monitoring Congestion detection Data flow selection
Path calculation and flow table update Controller
Figure 4 Module architecture of the POX controller in SDCCalgorithm
(1) Link Bandwidth Figure 5 shows the complete process ofPath 1 and Path 2 loading with1198913 data flow rate First the twolinks maintain a stable trend without large fluctuationWhenthe 1198913 growth rate reaches around 350MBs an obvious
Table 1 Set of four data flows
Flow Type Rate1198911 TCP (PC1ndashPC4) 150MBs1198912 UDP (PC2ndashPC4) 100MBs1198913 TCP (PC3ndashPC6) Increasing1198914 UDP (PC1ndashPC6) 350MBs
turning point occurred as shown in Figure 6 At this timethe OFC detected OFS2 link is congested and the mostappropriate data flow is selected (1198911 in the experiment) fromall data flows through this link Finally the flow is rerouted to
6 Scientific Programming
0 50 100 150 200 250 300 350 4000
100
200
300
400
500
600
700
800
900
1000
Flow f3 rate (MBs)
Flow
load
(MB
s)
Path1Path2
Figure 5 Link bandwidth
300 310 320 330 340 350 360 3700
100
200
300
400
500
600
700
800
900
1000
Flow f3 rate (MBs)
Flow
load
(MB
s)
Path1Path2
Figure 6 Link bandwidth in turning point
Path 2 because we only select TCP data flows to reroute in ouralgorithm and theUDPdata flows are not adjusted consistentwith the aim of the algorithm
Figure 6 provides details of the turning point of thelink bandwidth Then Path 1 loading decreases by 150MBsfrom 950MBs to 800MBs Moreover Path 2 significantlyincreased in loading size at about 150MBs which explainsthe transmission of 1198911 to Path 2 After the congestion reliefthe loading in Path 1 continues to rise steadily with theincrease of 1198913 data flow until the next congestion
(2) Packet Loss RateThe packet loss rate is shown in Figure 7where the increase of 1198913 increases the packet loss rate ofPath 1 but the overall trend and value are small and within
0 50 100 150 200 250 300 350 4000
0002
0004
0006
0008
001
0012
0014
0016
0018
002
Pack
et lo
ss ra
te (1
00
)
Flow f3 rate (MBs)
Figure 7 Packet loss rate
0 50 100 150 200 250 300 350 400055
06
065
07
075
08
085
09
095
Flow f3 rate (MBs)
Path
1 li
nk u
sage
(100
)
SDCC algorithmLABERIO algorithm
Figure 8 Link utilization
a reasonable range When 1198913 reached 350MBs an obviousincrease in packet loss rate was observedThe packet loss ratehas increased dramatically to 2 which indicates that it hasreached a state of congestion at this time While the rate of1198913 increases from 350MBs to 400MBs there is an obviousdecline process which shows the congestion relief and thepacket loss rate return to a reasonable range
(3) Link Utilization At the full stage of flow 1198913 rate from0 to 400MBs the average link utilization of the proposedalgorithm is about 785 and the LABERIO algorithm hasan average link utilization of about 74 Figure 8 shows thatwhen congestion did not occur the link utilization rate doesnot have much difference However when congestion occursand congestion control is performed the SDCC algorithmproposed in this paper does not fluctuate significantly More-over the algorithm stillmaintainedhigh link utilization First
Scientific Programming 7
the utilization on Path 1 link starts at around 60 and showsa linear growth trend with the flow rate of flow 1198913 wherethe maximum link utilization can be up to 95 When therate of flow 1198913 reaches 350MBs the link utilization of theSDCC algorithm is about 80 Moreover a follow-up withthe growth rate of flow1198913 showed an upward trendHoweverthe LABERIO algorithm significantly declined at less than60 and the follow-up showed almost no growth trendTherefore the SDCC algorithm is superior to the LABERIOalgorithm in link utilization
(4) Complexity Finally the complexity analysis shows theconsiderable properties of the SDCC algorithm that aremainly related to the calculation of three parts namely thereal-timemonitoring and judgment of the congested link thenew shortest path calculation of rerouting and the selectionof rerouting data flows If 119896 nodes exist in a network topologyand there are 119899 data streams on the link the time complexityof these three parts is 119874(119899119896) 119874(1198962) and 119874(119899)
Therefore the results show the effectiveness of our con-gestion mechanism It effectively relieved congestion andguaranteed the packet loss rate and link utilization
5 Conclusion and Future Work
Congestion is a common problem in the IP network but thecurrent level of development in the traditional network algo-rithm is insufficient to meet the growing network demandA software-defined approach is required to find a solution tothe network congestion problem Using centralized controlfeatures of the SDN network we proposed a new networkcongestion control algorithm called SDCC algorithm TheSDCC algorithm is based on the SDN architecture and it canobtain a global topology for unified network managementSDCC algorithm can relieve the network congestion problemmore efficiently We considered the difference between TCPand UDP and proposed a new method in judging congestednodes Moreover the simulation shows the effectiveness ofour congestionmechanismTheproposed algorithm achievesnetwork congestion control guarantees the packet loss rateand optimizes the link utilization In future work we willapply a software-defined approach to the data center networkor other more complex and special network to solve thecongestion problem in depth Furthermore we can stilloptimize our algorithm considering the different attributesof UDP packets or other such factors and adding differentparameters to provide a fair and accurate data flow selectionstrategy
Conflicts of Interest
The authors declare that they have no conflicts of interest
Acknowledgments
This work is supported in part by grants from the NationalNatural Science Foundation of China (61572191 and61402170)
References
[1] C P Fu and S C Liew ldquoTCPVeno TCP enhancement for trans-mission over wireless access networksrdquo IEEE Journal on SelectedAreas in Communications vol 21 no 2 pp 216ndash228 2003
[2] C Caini and R Firrincieli ldquoTCP Hybla A TCP enhancementfor heterogeneous networksrdquo International Journal of SatelliteCommunications and Networking vol 22 no 5 pp 547ndash5662004
[3] C E Palazzi M Brunati andM Roccetti ldquoAn OpenWRT solu-tion for future wireless homesrdquo in Proceedings of the 2010 IEEEInternational Conference on Multimedia and Expo ICME 2010pp 1701ndash1706 July 2010
[4] D SreeArthi S Malini M J Jude and V C Diniesh ldquoMicrolevel analysis of TCP congestion control algorithm inmulti-hopwireless networksrdquo in Proceedings of the 2017 International Con-ference on Computer Communication and Informatics (ICCCI)pp 1ndash5 January 2017
[5] B-J Chang Y-H Liang and J-Y Jin ldquoAdaptive cross-layer-based TCP congestion control for 4G wireless mobile cloudaccessrdquo in Proceedings of the 3rd IEEE International Conferenceon Consumer Electronics-Taiwan ICCE-TW 2016 pp 1-2 May2016
[6] M Claeys N Bouten D De Vleeschauwer et al ldquoDeadline-aware TCP congestion control for video streaming servicesrdquo inProceedings of the 12th International Conference on Network andService Management pp 100ndash108 November 2016
[7] J Gruen M Karl and T Herfet ldquoNetwork supported conges-tion avoidance in software-defined networksrdquo in Proceedings ofthe 2013 19th IEEE International Conference on Networks ICON2013 p 16 December 2013
[8] A El-Mougy M Ibnkahla G Hattab and W Ejaz ldquoReconfig-urable wireless networksrdquo Proceedings of the IEEE vol 103 no7 pp 1125ndash1158 2015
[9] J-HWang K RenW-G Sun L ZhaoH-S Zhong andK XuldquoEffects of iodinated contrast agents on renal oxygenation leveldetermined by blood oxygenation level dependent magneticresonance imaging in rabbit models of type 1 and type 2 diabeticnephropathyrdquo BMC Nephrology vol 15 no 1 article 140 2014
[10] ldquoGartner Identifies the Top 10 Strategic Technology Trends for2015rdquo 2014 httpwwwgartnercomnewsroomid2867917
[11] P Sun M Yu M J Freedman J Rexford and D WalkerldquoHONE Joint Host-Network Traffic Management in Software-Defined Networksrdquo Journal of Network and Systems Manage-ment vol 23 no 2 pp 374ndash399 2015
[12] Z Ge R Gu andY Ji ldquoAn active queuemanagement adaptationframework for software defined optical networkrdquo in Proceedingsof the 2014 13th International Conference on Optical Communi-cations and Networks ICOCN 2014 p 14 November 2014
[13] L Zhang Q Deng Y Su and Y Hu ldquoA Box-Covering-BasedRouting Algorithm for Large-Scale SDNsrdquo IEEE Access vol 5pp 4048ndash4056 2017
[14] M Ghobadi S H Yeganeh and Y Ganjali ldquoRethinking end-to-end congestion control in software-defined networksrdquo in Pro-ceedings of the 11th ACM Workshop on Hot Topics in NetworksHotNets 2012 pp 61ndash66 October 2012
[15] H Long Y Shen M Guo and F Tang ldquoLABERIO dynamicload-balanced routing in OpenFlow-enabled networksrdquo inProceedings of the IEEE International Conference on AdvancedInformation Networking Applications pp 290ndash297 2013
8 Scientific Programming
[16] L Lu Y Xiao and H Du ldquoOpenFlow control for cooperatingAQM schemerdquo in Proceedings of the 2010 IEEE 10th Interna-tional Conference on Signal Processing ICSP2010 pp 2560ndash2563 October 2010
[17] M Gholami and B Akbari ldquoCongestion control in softwaredefined data center networks through flow reroutingrdquo in Pro-ceedings of the 23rd Iranian Conference on Electrical EngineeringICEE 2015 pp 654ndash657 May 2015
[18] J Hershberger M Maxel and S Suri ldquoFinding the k shortestsimple paths A new algorithm and its implementationrdquo ACMTransactions on Algorithms (TALG) vol 3 no 4 Article ID1290682 2007
[19] N McKeown T Anderson H Balakrishnan et al ldquoOpenFlowenabling innovation in campus networksrdquo Computer Commu-nication Review vol 38 no 2 pp 69ndash74 2008
[20] M-K Shin K-H Nam and H-J Kim ldquoSoftware-definednetworking (SDN) A reference architecture and open APIsrdquo inProceedings of the 2012 International Conference on ICT Con-vergence ldquoGlobal Open Innovation Summit for Smart ICT Con-vergencerdquo ICTC 2012 pp 360-361 October 2012
[21] POX 2017 httpsgithubcomnoxrepo
Submit your manuscripts athttpswwwhindawicom
Computer Games Technology
International Journal of
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Distributed Sensor Networks
International Journal of
Advances in
FuzzySystems
Hindawi Publishing Corporationhttpwwwhindawicom
Volume 2014
International Journal of
ReconfigurableComputing
Hindawi Publishing Corporation httpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 201
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
Artificial Intelligence
HindawithinspPublishingthinspCorporationhttpwwwhindawicom Volumethinsp2014
Advances inSoftware EngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Electrical and Computer Engineering
Journal of
Hindawi Publishing Corporation
httpwwwhindawicom Volume 2014
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Advances in
Hindawi Publishing Corporationhttpwwwhindawicom Volume 201
RoboticsJournal of
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Computational Intelligence and Neuroscience
Industrial EngineeringJournal of
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014
The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Human-ComputerInteraction
Advances in
Computer EngineeringAdvances in
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
2 Scientific Programming
of forwarding queue and cannot guarantee link utilizationand quality of service We have considered this aspect inour research to find a solution for the network congestionproblem
In the traditional IP network architecture the controland forwarding planes are highly integrated and the net-work is difficult to extend and customize It has a longtechnology update cycle and is too dependent on networkequipment manufacturers Simultaneously the increasinglycomplex network environment makes it difficult to developthe network and make innovations related to the hardware ofphysical devices or software of related protocols and perfor-mances especially in the proprietary equipment and closedinterfaces Programmable models and code that allow datatransmission from the network to the application are neededThe technology of software-defined everything from applica-tions to infrastructure is one of the top 10 strategic technologytrends identified by Gartner [10] Software-defined network-ing (SDN) separates the network control and forwardingfunctions enabling the network to be directly programmabledynamic and manageable The separation of the controlplane and data plane allows the core technologyOpenFlow torealize the flexible control of the network traffic making thenetwork more intelligent and provide a better platform fornetwork application innovation [11ndash13]
In this study we used a software-defined approach tosolve the congestion control problem in the IP networkCompared with the existing literature this paper has thefollowing major contributions
(i) A comprehensive survey of congestion control in theIP network is presented In the traditional networksthe underlying network and flow information areunknown It must increase or reduce the size ofthe congestion window to adjust to the changes oftraffic while a software-defined approach can relievethe network congestion problem more efficiently Sowe propose a software-defined congestion control(SDCC) algorithm for the IP network
(ii) The type of data flow in the IP network is taken intoaccount The difference between TCP and UDP ispointed out Based on the different characteristics ofTCP and UDP we propose a new method in judgingcongested nodes
(iii) The simulation of our algorithm is comprehensivelyexplained We consider the packet loss rate and opti-mization of link utilizationThe simulation shows thatthe proposed algorithm achieves network congestioncontrol and optimizes the link utilization
In the following sections we first discuss the existingresearch on the congestion problem in the IP network basedon SDN in Section 2 Section 3 presents an SDCC algorithmfor the IP network The effectiveness of the algorithm isverified by a simulation experiment described in Section 4Finally the paper concludes in Section 5
2 Background
21 Related Work Network congestion control using asoftware-defined approach is still in its early stage of devel-opment Ghobadi et al [14] proposed a TCP dynamicadjustment framework based on SDN-OpenTCP OpenTCPis an SDN application deployed on an SDN controller usingthe global network view of SDNs and is established basedon the good strategy mechanism with the forwarding nodesand modifying the terminal protocol stack to continue thedynamic adjustment with the terminal congestion mecha-nism to achieve optimization It fills the SDN applicationgap in the field of congestion control and is very interestingHowever OpenTCP is a new architecture that is widelydeployed and needs to modify its source side forwardingnodes controllers and other global network to provide sup-port This framework also illustrates that the TCP dynamicmanagement strategy is open to managers and does nothave a specific adjustment method and adjustment of thetarget Long et al [15] proposed a kind of network congestioncontrol mechanism based on OpenFlow which is consid-ered as the first SDN standard This mechanism is basedon the OpenFlow network features that define a methodin judging the link congestion control threshold Whennetwork congestion occurs the corresponding congestioncontrolmechanism is immediately started and themaximumbandwidth data flow in the congested link is identified andrerouted to achieve load balance Lu et al [16] presented acongestion control algorithm that supports multiple activequeue management The algorithm is dynamically adap-tive to interactive link information and can effectively usebandwidth and network congestion control Gholami andAkbari [17] proposed amethod based on SDN andOpenFlowto solve this problem In this method link congestion isdetected by central monitoring of the port statistics of theOpenFlow enabled switches and some of the flows in anycongested link are rerouted by the OpenFlow controller Thismethod highlighted the effectiveness of SDN in solving thecongestion problem Hershberger et al [18] also proposed anew congestion optimization algorithm based on SDN Thisalgorithm chooses the 119896 shortest path for each data flowahead of schedule When network congestion occurs the119896 paths are sequentially traversed to determine which pathis not congested This method realizes the load balance tosome extent however it also has a significant computationoverhead Meanwhile these methods do not consider thetype of data flow If the selected routing involves a UDP dataflow with highly demanding timeline but allows packet lossand the delay of the new reroute shortest path is large Thenthis reroute strategymay not be an optimal choiceThereforewe considered the difference of the type of data flow in ourproposed algorithm
22 Key Principles of a Software-Defined Approach SDN is amature software-defined area that originated from StanfordUniversityrsquos Clean Slate research [19 20] It is considered anew kind of network architecture and a method of imple-menting network virtualization Its core concept is to separatethe control plane and the data plane of the network hardware
Scientific Programming 3
equipment Software programming is implemented in thecontrol planeThe SDN architecture can be divided into threelevels (1) application layer (2) control layer and (3) equip-ment layer It has the following three basic characteristics(1) centralized control (2) programmable software and (3)network virtualization
OpenFlow network is comprised of the OpenFlow switchand OpenFlow controller Switches and controllers establishthe secure connection by transport layer security (TLS) orTCP prior to OpenFlow message interaction issuing flowsheets information query reporting interface status andother functions
In OpenFlow network controllers first send the link layerdiscovery protocol (LLDP) message (encapsulated in thePacket-Out message sent) to each of the OpenFlow switchesto obtain the global network topology Then the switchesregularly send Port-Status messages to controllers to reportport information of each switch This information includingdata flowheader and transmission rate is recorded in the datainformation flow of each port in the switches
3 Software-Defined CongestionControl Algorithm
This paper investigates the use of software-defined approachin solving the congestion control problem in the IP networkWe proposed an SDCC algorithm that considered the dif-ference between TCP and UDP a new method in judgingcongested nodes and the start of the congestion controlmechanism in the congested nodes then controlling thenetwork congestion to optimize the link utilization
The main concept of the SDCC algorithm is based onthe SDN architecture where the controller obtains portinformation of each switch to monitor for congested links Ifnetwork congestion exists the congestion controlmechanismis started then one or more appropriate data flows areselected and the shortest rerouting path is calculated tocontrol the congestion This process allows the efficientuse of network bandwidth resources and increases the linkutilization
We considered the data flow condition in the real networkand mainly focused on the heterogeneity between the TCPdata flow and the UDP data flow in proposing this congestioncontrol mechanism
The process is as follows (1) the controller obtains theglobal information and regularly monitors the network con-gestion condition (2) estimate whether there are congestedlinks based on formula (1) (3) if congested link is discoveredit is removed from the topology image to generate a newtopology image (4) calculate the shortest path between thelast node of the congested node to the destination node and(5) select one or more appropriate data flows to reroute
31 Estimating Congested Links In the OpenFlow networkthe controller according to theOpenFlow v10 standard spec-ification obtains a global network topology image throughthe LLDP and then sends port status information requestmessage to each of the OpenFlow switches regularly Open-Flow switches receive this message and feedback to the
R1 R2
f1
f2
f3fn
Figure 1 Bottom switch network
Input link bandwidthOutput congested links(1) For 119891119896 in link(2) IF flow = TCP(3) 119861tcp = 119861tcp + flow(4) ELSE 119861udp = 119861udp + flow(5) IF 119861th-119861udp lt 119861tcp lt B(6) linkrarr congested(7) ELSE continue monitoring
Algorithm 1 Estimating
controller the data information flow of each port in theswitches such as data flow header and transmission rate
As shown in Figure 1 the controller detects that in theOpenFlow network there are 119899 data flows (1198911 1198912 1198913 119891119899)in R1 to R2 link and the rate of each data stream is(V1 V2 V3 V119899) Moreover there are 119894 UDP data flows and119895 TCP data flows
Assume that the total bandwidth for the link R1 toR2 is 119861 and the link congestion threshold is 119861th (specificvalue of 119861th is according to the physical properties of thenetwork environment)119861tcp is the congestion threshold of theTCP flows in this link which is the link surplus maximumbandwidth for the TCP data flows aftermeeting theUDPdataflow transmission demand as follows
1198611015840th (119905) = 119861th minus119894
sum119896=1
119891udp119896 (119905)
119861tcp =119895
sum119896=1
119891tcp119896 (119905)
(1)
where 119894 + 119895 = 119899 119861tcp is the total rate of the TCP flows and theinitial value of 119861tcp and 119861udp is 0 Then if 1198611015840th lt 119861tcp lt 119861 weconfirm that R2 is in a congestion state and the link R1 to R2is the congested linkThe algorithm for estimating congestedlinks is as in Algorithm 1
32 Calculation of Rerouting Links Now the controller needsto choose a new path for rerouting part of the data flowsin the congested link The controller removes all estimated
4 Scientific Programming
R1 R2
Figure 2 New bottom switch network
Input link and node distanceOutput new path and update the flow table(1) IF link[119886]rarr congested(2) dist[119886] = INFINITY(3) For 119894 do(4) dist[119894] = V[0] rarr V[119894](5) For 119894 do find the nearest point(6) int mindist = INFINITY(7) For 119895 do(8) If dist[119895] ltmindist(9) mindist = dist[119896](10) For 119895 do update the shortest path(11) If mindist + V[119896] rarr V[119895] lt V[0] rarr V[119895](12) dist[119895] = mindist + V[119896] rarr V[119895](13) Newlinkrarr Packet out update flowtable(14) OFPFC DELETE(15) OFPFC ADD(16) Delete OutFlowtable
Algorithm 2 Rerouting
congested links from the global network topology image andthen obtains a new noncongested network topology image asshown in Figure 2 In the concrete execution we set the linkpath distance as infinity to achieve the deletion
Then using the shortest path algorithm to calculate theshortest path with non-congestion from the last node of thecongested node to the destination node and finally choosingthe appropriate data flows transferred to this new path tocomplete the transmission the algorithm of the OpenFlownetwork rerouting is presented as in Algorithm 2 Parameter119894 represents 119894 UDP data flows and parameter 119895 represents 119895TCP data flows Parameter 119896 represents the 119896th data flow
33 Selection of Rerouted Data Flows Considering that theUDP data flows always emphasize short transfer time andhigh-efficiency requirements we selected the TCP data flowsfor the rerouting Assuming that there are 119895 TCP data flows(1198911 1198912 1198913 119891119895) on one congested link the rate of each dataflows is (V1 V2 V3 V119895) and we obtain the following
1198611015840tcp = 119861tcp minus (V119886 + V119887 + sdot sdot sdot + V119896) (2)
To ensure high link bandwidth utilization when thetotal rate of the TCP flows on this link 119861tcp minus part ofthe rate (119891119886 119891119887 119891119896) and a new total rate of TCP flows1198611015840tcp closest to 1198611015840th is obtained then we are assured that thedata flows (119891119886 119891119887 119891119896) are optimal choice for reroutingthe transmission The selection algorithm of the rerouteddata flows are as in Algorithm 3 Parameter 119908 represents thenumber of the most suitable data flows
4 Experiment and Result
41 Experiment Design We considered the data flow condi-tion in the real network and mainly focused on the hetero-geneity between the TCP data flow and the UDP data flowin proposing this congestion control mechanism In our testenvironment the controller obtains the global informationand regularly monitors the network congestion conditionThe controller estimates whether there are congested links Ifcongested link is discovered it is removed from the topologyimage to generate a new topology image The controllercalculates the shortest path between the last node of thecongested node to the destination node At last the controllerselects one or more appropriate data flows to reroute
To verify the proposed congestion control mechanismusing the OpenFlow network we built the test environmentas shown in Figure 3 OFS1 OFS2 and OFS3 are OpenFlowswitches by Mininet simulation OFC is the OpenFlow con-troller with POX [21] PC1ndashPC6 are common user terminalsand we use the Iperf tool on user terminals to send the dataflows
We added the link monitoring congestion detectionrerouted data flow selection and shortest path calculationfunction modules in the POX controller and combined themwith the existing modules of topology discovery and flowtable update to achieve the proposed congestion controlmechanism The running process of each module is shownin Figure 4
After the POX controller starts the LLDP protocol isfirst run to obtain the entire network topology and thenthe congestion detection module is triggered to regularly(the experiment is set at 2 s) query each OFS for statusinformation of each port and record the number and sizeof each flow through this port Then the controller willadd the rates of all data flows together We found that theNetFPGArsquos port line speed is 1 Gbps Aftermany experimentswhen the port rate reaches 950MBs the packet loss rate willquickly reach 2 magnitude and it is out of the standardof common business demand Therefore to simulate the realnetwork environment we set the port congestion thresholdat 950MBs in our test
42 Results and Analysis To facilitate testing we built fourdata flows with Iperf (as shown in Table 1) and sets OFS1-OFS2 as Path 1 and OFS1-OFS3-OFS2 as Path 2 As identifiedby the shortest path algorithm these four flows will betransmitted through Path 1 In this experiment the rate of 1198913will be increased over time
Scientific Programming 5
Input all data flow rates through the congested linkOutput number of selected flow(1) For 119894 do(2) sum = sum + flow[119894](3) For i do Select the appropriate flow and tag it(4) If flow = TCP ampamp congested ampamp sum-flow[119908] gt bestsum(5) bestsum = sum minus flowsize[119908](6) bestflownum = 119908(7) Return bestflownum
Algorithm 3 Selection
PC1
PC2
PC3
PC4
PC5
PC6
OFS1 OFS2
OFS3
OFC
Figure 3 OpenFlow network experiment platform
Link monitoring Congestion detection Data flow selection
Path calculation and flow table update Controller
Figure 4 Module architecture of the POX controller in SDCCalgorithm
(1) Link Bandwidth Figure 5 shows the complete process ofPath 1 and Path 2 loading with1198913 data flow rate First the twolinks maintain a stable trend without large fluctuationWhenthe 1198913 growth rate reaches around 350MBs an obvious
Table 1 Set of four data flows
Flow Type Rate1198911 TCP (PC1ndashPC4) 150MBs1198912 UDP (PC2ndashPC4) 100MBs1198913 TCP (PC3ndashPC6) Increasing1198914 UDP (PC1ndashPC6) 350MBs
turning point occurred as shown in Figure 6 At this timethe OFC detected OFS2 link is congested and the mostappropriate data flow is selected (1198911 in the experiment) fromall data flows through this link Finally the flow is rerouted to
6 Scientific Programming
0 50 100 150 200 250 300 350 4000
100
200
300
400
500
600
700
800
900
1000
Flow f3 rate (MBs)
Flow
load
(MB
s)
Path1Path2
Figure 5 Link bandwidth
300 310 320 330 340 350 360 3700
100
200
300
400
500
600
700
800
900
1000
Flow f3 rate (MBs)
Flow
load
(MB
s)
Path1Path2
Figure 6 Link bandwidth in turning point
Path 2 because we only select TCP data flows to reroute in ouralgorithm and theUDPdata flows are not adjusted consistentwith the aim of the algorithm
Figure 6 provides details of the turning point of thelink bandwidth Then Path 1 loading decreases by 150MBsfrom 950MBs to 800MBs Moreover Path 2 significantlyincreased in loading size at about 150MBs which explainsthe transmission of 1198911 to Path 2 After the congestion reliefthe loading in Path 1 continues to rise steadily with theincrease of 1198913 data flow until the next congestion
(2) Packet Loss RateThe packet loss rate is shown in Figure 7where the increase of 1198913 increases the packet loss rate ofPath 1 but the overall trend and value are small and within
0 50 100 150 200 250 300 350 4000
0002
0004
0006
0008
001
0012
0014
0016
0018
002
Pack
et lo
ss ra
te (1
00
)
Flow f3 rate (MBs)
Figure 7 Packet loss rate
0 50 100 150 200 250 300 350 400055
06
065
07
075
08
085
09
095
Flow f3 rate (MBs)
Path
1 li
nk u
sage
(100
)
SDCC algorithmLABERIO algorithm
Figure 8 Link utilization
a reasonable range When 1198913 reached 350MBs an obviousincrease in packet loss rate was observedThe packet loss ratehas increased dramatically to 2 which indicates that it hasreached a state of congestion at this time While the rate of1198913 increases from 350MBs to 400MBs there is an obviousdecline process which shows the congestion relief and thepacket loss rate return to a reasonable range
(3) Link Utilization At the full stage of flow 1198913 rate from0 to 400MBs the average link utilization of the proposedalgorithm is about 785 and the LABERIO algorithm hasan average link utilization of about 74 Figure 8 shows thatwhen congestion did not occur the link utilization rate doesnot have much difference However when congestion occursand congestion control is performed the SDCC algorithmproposed in this paper does not fluctuate significantly More-over the algorithm stillmaintainedhigh link utilization First
Scientific Programming 7
the utilization on Path 1 link starts at around 60 and showsa linear growth trend with the flow rate of flow 1198913 wherethe maximum link utilization can be up to 95 When therate of flow 1198913 reaches 350MBs the link utilization of theSDCC algorithm is about 80 Moreover a follow-up withthe growth rate of flow1198913 showed an upward trendHoweverthe LABERIO algorithm significantly declined at less than60 and the follow-up showed almost no growth trendTherefore the SDCC algorithm is superior to the LABERIOalgorithm in link utilization
(4) Complexity Finally the complexity analysis shows theconsiderable properties of the SDCC algorithm that aremainly related to the calculation of three parts namely thereal-timemonitoring and judgment of the congested link thenew shortest path calculation of rerouting and the selectionof rerouting data flows If 119896 nodes exist in a network topologyand there are 119899 data streams on the link the time complexityof these three parts is 119874(119899119896) 119874(1198962) and 119874(119899)
Therefore the results show the effectiveness of our con-gestion mechanism It effectively relieved congestion andguaranteed the packet loss rate and link utilization
5 Conclusion and Future Work
Congestion is a common problem in the IP network but thecurrent level of development in the traditional network algo-rithm is insufficient to meet the growing network demandA software-defined approach is required to find a solution tothe network congestion problem Using centralized controlfeatures of the SDN network we proposed a new networkcongestion control algorithm called SDCC algorithm TheSDCC algorithm is based on the SDN architecture and it canobtain a global topology for unified network managementSDCC algorithm can relieve the network congestion problemmore efficiently We considered the difference between TCPand UDP and proposed a new method in judging congestednodes Moreover the simulation shows the effectiveness ofour congestionmechanismTheproposed algorithm achievesnetwork congestion control guarantees the packet loss rateand optimizes the link utilization In future work we willapply a software-defined approach to the data center networkor other more complex and special network to solve thecongestion problem in depth Furthermore we can stilloptimize our algorithm considering the different attributesof UDP packets or other such factors and adding differentparameters to provide a fair and accurate data flow selectionstrategy
Conflicts of Interest
The authors declare that they have no conflicts of interest
Acknowledgments
This work is supported in part by grants from the NationalNatural Science Foundation of China (61572191 and61402170)
References
[1] C P Fu and S C Liew ldquoTCPVeno TCP enhancement for trans-mission over wireless access networksrdquo IEEE Journal on SelectedAreas in Communications vol 21 no 2 pp 216ndash228 2003
[2] C Caini and R Firrincieli ldquoTCP Hybla A TCP enhancementfor heterogeneous networksrdquo International Journal of SatelliteCommunications and Networking vol 22 no 5 pp 547ndash5662004
[3] C E Palazzi M Brunati andM Roccetti ldquoAn OpenWRT solu-tion for future wireless homesrdquo in Proceedings of the 2010 IEEEInternational Conference on Multimedia and Expo ICME 2010pp 1701ndash1706 July 2010
[4] D SreeArthi S Malini M J Jude and V C Diniesh ldquoMicrolevel analysis of TCP congestion control algorithm inmulti-hopwireless networksrdquo in Proceedings of the 2017 International Con-ference on Computer Communication and Informatics (ICCCI)pp 1ndash5 January 2017
[5] B-J Chang Y-H Liang and J-Y Jin ldquoAdaptive cross-layer-based TCP congestion control for 4G wireless mobile cloudaccessrdquo in Proceedings of the 3rd IEEE International Conferenceon Consumer Electronics-Taiwan ICCE-TW 2016 pp 1-2 May2016
[6] M Claeys N Bouten D De Vleeschauwer et al ldquoDeadline-aware TCP congestion control for video streaming servicesrdquo inProceedings of the 12th International Conference on Network andService Management pp 100ndash108 November 2016
[7] J Gruen M Karl and T Herfet ldquoNetwork supported conges-tion avoidance in software-defined networksrdquo in Proceedings ofthe 2013 19th IEEE International Conference on Networks ICON2013 p 16 December 2013
[8] A El-Mougy M Ibnkahla G Hattab and W Ejaz ldquoReconfig-urable wireless networksrdquo Proceedings of the IEEE vol 103 no7 pp 1125ndash1158 2015
[9] J-HWang K RenW-G Sun L ZhaoH-S Zhong andK XuldquoEffects of iodinated contrast agents on renal oxygenation leveldetermined by blood oxygenation level dependent magneticresonance imaging in rabbit models of type 1 and type 2 diabeticnephropathyrdquo BMC Nephrology vol 15 no 1 article 140 2014
[10] ldquoGartner Identifies the Top 10 Strategic Technology Trends for2015rdquo 2014 httpwwwgartnercomnewsroomid2867917
[11] P Sun M Yu M J Freedman J Rexford and D WalkerldquoHONE Joint Host-Network Traffic Management in Software-Defined Networksrdquo Journal of Network and Systems Manage-ment vol 23 no 2 pp 374ndash399 2015
[12] Z Ge R Gu andY Ji ldquoAn active queuemanagement adaptationframework for software defined optical networkrdquo in Proceedingsof the 2014 13th International Conference on Optical Communi-cations and Networks ICOCN 2014 p 14 November 2014
[13] L Zhang Q Deng Y Su and Y Hu ldquoA Box-Covering-BasedRouting Algorithm for Large-Scale SDNsrdquo IEEE Access vol 5pp 4048ndash4056 2017
[14] M Ghobadi S H Yeganeh and Y Ganjali ldquoRethinking end-to-end congestion control in software-defined networksrdquo in Pro-ceedings of the 11th ACM Workshop on Hot Topics in NetworksHotNets 2012 pp 61ndash66 October 2012
[15] H Long Y Shen M Guo and F Tang ldquoLABERIO dynamicload-balanced routing in OpenFlow-enabled networksrdquo inProceedings of the IEEE International Conference on AdvancedInformation Networking Applications pp 290ndash297 2013
8 Scientific Programming
[16] L Lu Y Xiao and H Du ldquoOpenFlow control for cooperatingAQM schemerdquo in Proceedings of the 2010 IEEE 10th Interna-tional Conference on Signal Processing ICSP2010 pp 2560ndash2563 October 2010
[17] M Gholami and B Akbari ldquoCongestion control in softwaredefined data center networks through flow reroutingrdquo in Pro-ceedings of the 23rd Iranian Conference on Electrical EngineeringICEE 2015 pp 654ndash657 May 2015
[18] J Hershberger M Maxel and S Suri ldquoFinding the k shortestsimple paths A new algorithm and its implementationrdquo ACMTransactions on Algorithms (TALG) vol 3 no 4 Article ID1290682 2007
[19] N McKeown T Anderson H Balakrishnan et al ldquoOpenFlowenabling innovation in campus networksrdquo Computer Commu-nication Review vol 38 no 2 pp 69ndash74 2008
[20] M-K Shin K-H Nam and H-J Kim ldquoSoftware-definednetworking (SDN) A reference architecture and open APIsrdquo inProceedings of the 2012 International Conference on ICT Con-vergence ldquoGlobal Open Innovation Summit for Smart ICT Con-vergencerdquo ICTC 2012 pp 360-361 October 2012
[21] POX 2017 httpsgithubcomnoxrepo
Submit your manuscripts athttpswwwhindawicom
Computer Games Technology
International Journal of
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Distributed Sensor Networks
International Journal of
Advances in
FuzzySystems
Hindawi Publishing Corporationhttpwwwhindawicom
Volume 2014
International Journal of
ReconfigurableComputing
Hindawi Publishing Corporation httpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 201
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
Artificial Intelligence
HindawithinspPublishingthinspCorporationhttpwwwhindawicom Volumethinsp2014
Advances inSoftware EngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Electrical and Computer Engineering
Journal of
Hindawi Publishing Corporation
httpwwwhindawicom Volume 2014
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Advances in
Hindawi Publishing Corporationhttpwwwhindawicom Volume 201
RoboticsJournal of
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Computational Intelligence and Neuroscience
Industrial EngineeringJournal of
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014
The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Human-ComputerInteraction
Advances in
Computer EngineeringAdvances in
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Scientific Programming 3
equipment Software programming is implemented in thecontrol planeThe SDN architecture can be divided into threelevels (1) application layer (2) control layer and (3) equip-ment layer It has the following three basic characteristics(1) centralized control (2) programmable software and (3)network virtualization
OpenFlow network is comprised of the OpenFlow switchand OpenFlow controller Switches and controllers establishthe secure connection by transport layer security (TLS) orTCP prior to OpenFlow message interaction issuing flowsheets information query reporting interface status andother functions
In OpenFlow network controllers first send the link layerdiscovery protocol (LLDP) message (encapsulated in thePacket-Out message sent) to each of the OpenFlow switchesto obtain the global network topology Then the switchesregularly send Port-Status messages to controllers to reportport information of each switch This information includingdata flowheader and transmission rate is recorded in the datainformation flow of each port in the switches
3 Software-Defined CongestionControl Algorithm
This paper investigates the use of software-defined approachin solving the congestion control problem in the IP networkWe proposed an SDCC algorithm that considered the dif-ference between TCP and UDP a new method in judgingcongested nodes and the start of the congestion controlmechanism in the congested nodes then controlling thenetwork congestion to optimize the link utilization
The main concept of the SDCC algorithm is based onthe SDN architecture where the controller obtains portinformation of each switch to monitor for congested links Ifnetwork congestion exists the congestion controlmechanismis started then one or more appropriate data flows areselected and the shortest rerouting path is calculated tocontrol the congestion This process allows the efficientuse of network bandwidth resources and increases the linkutilization
We considered the data flow condition in the real networkand mainly focused on the heterogeneity between the TCPdata flow and the UDP data flow in proposing this congestioncontrol mechanism
The process is as follows (1) the controller obtains theglobal information and regularly monitors the network con-gestion condition (2) estimate whether there are congestedlinks based on formula (1) (3) if congested link is discoveredit is removed from the topology image to generate a newtopology image (4) calculate the shortest path between thelast node of the congested node to the destination node and(5) select one or more appropriate data flows to reroute
31 Estimating Congested Links In the OpenFlow networkthe controller according to theOpenFlow v10 standard spec-ification obtains a global network topology image throughthe LLDP and then sends port status information requestmessage to each of the OpenFlow switches regularly Open-Flow switches receive this message and feedback to the
R1 R2
f1
f2
f3fn
Figure 1 Bottom switch network
Input link bandwidthOutput congested links(1) For 119891119896 in link(2) IF flow = TCP(3) 119861tcp = 119861tcp + flow(4) ELSE 119861udp = 119861udp + flow(5) IF 119861th-119861udp lt 119861tcp lt B(6) linkrarr congested(7) ELSE continue monitoring
Algorithm 1 Estimating
controller the data information flow of each port in theswitches such as data flow header and transmission rate
As shown in Figure 1 the controller detects that in theOpenFlow network there are 119899 data flows (1198911 1198912 1198913 119891119899)in R1 to R2 link and the rate of each data stream is(V1 V2 V3 V119899) Moreover there are 119894 UDP data flows and119895 TCP data flows
Assume that the total bandwidth for the link R1 toR2 is 119861 and the link congestion threshold is 119861th (specificvalue of 119861th is according to the physical properties of thenetwork environment)119861tcp is the congestion threshold of theTCP flows in this link which is the link surplus maximumbandwidth for the TCP data flows aftermeeting theUDPdataflow transmission demand as follows
1198611015840th (119905) = 119861th minus119894
sum119896=1
119891udp119896 (119905)
119861tcp =119895
sum119896=1
119891tcp119896 (119905)
(1)
where 119894 + 119895 = 119899 119861tcp is the total rate of the TCP flows and theinitial value of 119861tcp and 119861udp is 0 Then if 1198611015840th lt 119861tcp lt 119861 weconfirm that R2 is in a congestion state and the link R1 to R2is the congested linkThe algorithm for estimating congestedlinks is as in Algorithm 1
32 Calculation of Rerouting Links Now the controller needsto choose a new path for rerouting part of the data flowsin the congested link The controller removes all estimated
4 Scientific Programming
R1 R2
Figure 2 New bottom switch network
Input link and node distanceOutput new path and update the flow table(1) IF link[119886]rarr congested(2) dist[119886] = INFINITY(3) For 119894 do(4) dist[119894] = V[0] rarr V[119894](5) For 119894 do find the nearest point(6) int mindist = INFINITY(7) For 119895 do(8) If dist[119895] ltmindist(9) mindist = dist[119896](10) For 119895 do update the shortest path(11) If mindist + V[119896] rarr V[119895] lt V[0] rarr V[119895](12) dist[119895] = mindist + V[119896] rarr V[119895](13) Newlinkrarr Packet out update flowtable(14) OFPFC DELETE(15) OFPFC ADD(16) Delete OutFlowtable
Algorithm 2 Rerouting
congested links from the global network topology image andthen obtains a new noncongested network topology image asshown in Figure 2 In the concrete execution we set the linkpath distance as infinity to achieve the deletion
Then using the shortest path algorithm to calculate theshortest path with non-congestion from the last node of thecongested node to the destination node and finally choosingthe appropriate data flows transferred to this new path tocomplete the transmission the algorithm of the OpenFlownetwork rerouting is presented as in Algorithm 2 Parameter119894 represents 119894 UDP data flows and parameter 119895 represents 119895TCP data flows Parameter 119896 represents the 119896th data flow
33 Selection of Rerouted Data Flows Considering that theUDP data flows always emphasize short transfer time andhigh-efficiency requirements we selected the TCP data flowsfor the rerouting Assuming that there are 119895 TCP data flows(1198911 1198912 1198913 119891119895) on one congested link the rate of each dataflows is (V1 V2 V3 V119895) and we obtain the following
1198611015840tcp = 119861tcp minus (V119886 + V119887 + sdot sdot sdot + V119896) (2)
To ensure high link bandwidth utilization when thetotal rate of the TCP flows on this link 119861tcp minus part ofthe rate (119891119886 119891119887 119891119896) and a new total rate of TCP flows1198611015840tcp closest to 1198611015840th is obtained then we are assured that thedata flows (119891119886 119891119887 119891119896) are optimal choice for reroutingthe transmission The selection algorithm of the rerouteddata flows are as in Algorithm 3 Parameter 119908 represents thenumber of the most suitable data flows
4 Experiment and Result
41 Experiment Design We considered the data flow condi-tion in the real network and mainly focused on the hetero-geneity between the TCP data flow and the UDP data flowin proposing this congestion control mechanism In our testenvironment the controller obtains the global informationand regularly monitors the network congestion conditionThe controller estimates whether there are congested links Ifcongested link is discovered it is removed from the topologyimage to generate a new topology image The controllercalculates the shortest path between the last node of thecongested node to the destination node At last the controllerselects one or more appropriate data flows to reroute
To verify the proposed congestion control mechanismusing the OpenFlow network we built the test environmentas shown in Figure 3 OFS1 OFS2 and OFS3 are OpenFlowswitches by Mininet simulation OFC is the OpenFlow con-troller with POX [21] PC1ndashPC6 are common user terminalsand we use the Iperf tool on user terminals to send the dataflows
We added the link monitoring congestion detectionrerouted data flow selection and shortest path calculationfunction modules in the POX controller and combined themwith the existing modules of topology discovery and flowtable update to achieve the proposed congestion controlmechanism The running process of each module is shownin Figure 4
After the POX controller starts the LLDP protocol isfirst run to obtain the entire network topology and thenthe congestion detection module is triggered to regularly(the experiment is set at 2 s) query each OFS for statusinformation of each port and record the number and sizeof each flow through this port Then the controller willadd the rates of all data flows together We found that theNetFPGArsquos port line speed is 1 Gbps Aftermany experimentswhen the port rate reaches 950MBs the packet loss rate willquickly reach 2 magnitude and it is out of the standardof common business demand Therefore to simulate the realnetwork environment we set the port congestion thresholdat 950MBs in our test
42 Results and Analysis To facilitate testing we built fourdata flows with Iperf (as shown in Table 1) and sets OFS1-OFS2 as Path 1 and OFS1-OFS3-OFS2 as Path 2 As identifiedby the shortest path algorithm these four flows will betransmitted through Path 1 In this experiment the rate of 1198913will be increased over time
Scientific Programming 5
Input all data flow rates through the congested linkOutput number of selected flow(1) For 119894 do(2) sum = sum + flow[119894](3) For i do Select the appropriate flow and tag it(4) If flow = TCP ampamp congested ampamp sum-flow[119908] gt bestsum(5) bestsum = sum minus flowsize[119908](6) bestflownum = 119908(7) Return bestflownum
Algorithm 3 Selection
PC1
PC2
PC3
PC4
PC5
PC6
OFS1 OFS2
OFS3
OFC
Figure 3 OpenFlow network experiment platform
Link monitoring Congestion detection Data flow selection
Path calculation and flow table update Controller
Figure 4 Module architecture of the POX controller in SDCCalgorithm
(1) Link Bandwidth Figure 5 shows the complete process ofPath 1 and Path 2 loading with1198913 data flow rate First the twolinks maintain a stable trend without large fluctuationWhenthe 1198913 growth rate reaches around 350MBs an obvious
Table 1 Set of four data flows
Flow Type Rate1198911 TCP (PC1ndashPC4) 150MBs1198912 UDP (PC2ndashPC4) 100MBs1198913 TCP (PC3ndashPC6) Increasing1198914 UDP (PC1ndashPC6) 350MBs
turning point occurred as shown in Figure 6 At this timethe OFC detected OFS2 link is congested and the mostappropriate data flow is selected (1198911 in the experiment) fromall data flows through this link Finally the flow is rerouted to
6 Scientific Programming
0 50 100 150 200 250 300 350 4000
100
200
300
400
500
600
700
800
900
1000
Flow f3 rate (MBs)
Flow
load
(MB
s)
Path1Path2
Figure 5 Link bandwidth
300 310 320 330 340 350 360 3700
100
200
300
400
500
600
700
800
900
1000
Flow f3 rate (MBs)
Flow
load
(MB
s)
Path1Path2
Figure 6 Link bandwidth in turning point
Path 2 because we only select TCP data flows to reroute in ouralgorithm and theUDPdata flows are not adjusted consistentwith the aim of the algorithm
Figure 6 provides details of the turning point of thelink bandwidth Then Path 1 loading decreases by 150MBsfrom 950MBs to 800MBs Moreover Path 2 significantlyincreased in loading size at about 150MBs which explainsthe transmission of 1198911 to Path 2 After the congestion reliefthe loading in Path 1 continues to rise steadily with theincrease of 1198913 data flow until the next congestion
(2) Packet Loss RateThe packet loss rate is shown in Figure 7where the increase of 1198913 increases the packet loss rate ofPath 1 but the overall trend and value are small and within
0 50 100 150 200 250 300 350 4000
0002
0004
0006
0008
001
0012
0014
0016
0018
002
Pack
et lo
ss ra
te (1
00
)
Flow f3 rate (MBs)
Figure 7 Packet loss rate
0 50 100 150 200 250 300 350 400055
06
065
07
075
08
085
09
095
Flow f3 rate (MBs)
Path
1 li
nk u
sage
(100
)
SDCC algorithmLABERIO algorithm
Figure 8 Link utilization
a reasonable range When 1198913 reached 350MBs an obviousincrease in packet loss rate was observedThe packet loss ratehas increased dramatically to 2 which indicates that it hasreached a state of congestion at this time While the rate of1198913 increases from 350MBs to 400MBs there is an obviousdecline process which shows the congestion relief and thepacket loss rate return to a reasonable range
(3) Link Utilization At the full stage of flow 1198913 rate from0 to 400MBs the average link utilization of the proposedalgorithm is about 785 and the LABERIO algorithm hasan average link utilization of about 74 Figure 8 shows thatwhen congestion did not occur the link utilization rate doesnot have much difference However when congestion occursand congestion control is performed the SDCC algorithmproposed in this paper does not fluctuate significantly More-over the algorithm stillmaintainedhigh link utilization First
Scientific Programming 7
the utilization on Path 1 link starts at around 60 and showsa linear growth trend with the flow rate of flow 1198913 wherethe maximum link utilization can be up to 95 When therate of flow 1198913 reaches 350MBs the link utilization of theSDCC algorithm is about 80 Moreover a follow-up withthe growth rate of flow1198913 showed an upward trendHoweverthe LABERIO algorithm significantly declined at less than60 and the follow-up showed almost no growth trendTherefore the SDCC algorithm is superior to the LABERIOalgorithm in link utilization
(4) Complexity Finally the complexity analysis shows theconsiderable properties of the SDCC algorithm that aremainly related to the calculation of three parts namely thereal-timemonitoring and judgment of the congested link thenew shortest path calculation of rerouting and the selectionof rerouting data flows If 119896 nodes exist in a network topologyand there are 119899 data streams on the link the time complexityof these three parts is 119874(119899119896) 119874(1198962) and 119874(119899)
Therefore the results show the effectiveness of our con-gestion mechanism It effectively relieved congestion andguaranteed the packet loss rate and link utilization
5 Conclusion and Future Work
Congestion is a common problem in the IP network but thecurrent level of development in the traditional network algo-rithm is insufficient to meet the growing network demandA software-defined approach is required to find a solution tothe network congestion problem Using centralized controlfeatures of the SDN network we proposed a new networkcongestion control algorithm called SDCC algorithm TheSDCC algorithm is based on the SDN architecture and it canobtain a global topology for unified network managementSDCC algorithm can relieve the network congestion problemmore efficiently We considered the difference between TCPand UDP and proposed a new method in judging congestednodes Moreover the simulation shows the effectiveness ofour congestionmechanismTheproposed algorithm achievesnetwork congestion control guarantees the packet loss rateand optimizes the link utilization In future work we willapply a software-defined approach to the data center networkor other more complex and special network to solve thecongestion problem in depth Furthermore we can stilloptimize our algorithm considering the different attributesof UDP packets or other such factors and adding differentparameters to provide a fair and accurate data flow selectionstrategy
Conflicts of Interest
The authors declare that they have no conflicts of interest
Acknowledgments
This work is supported in part by grants from the NationalNatural Science Foundation of China (61572191 and61402170)
References
[1] C P Fu and S C Liew ldquoTCPVeno TCP enhancement for trans-mission over wireless access networksrdquo IEEE Journal on SelectedAreas in Communications vol 21 no 2 pp 216ndash228 2003
[2] C Caini and R Firrincieli ldquoTCP Hybla A TCP enhancementfor heterogeneous networksrdquo International Journal of SatelliteCommunications and Networking vol 22 no 5 pp 547ndash5662004
[3] C E Palazzi M Brunati andM Roccetti ldquoAn OpenWRT solu-tion for future wireless homesrdquo in Proceedings of the 2010 IEEEInternational Conference on Multimedia and Expo ICME 2010pp 1701ndash1706 July 2010
[4] D SreeArthi S Malini M J Jude and V C Diniesh ldquoMicrolevel analysis of TCP congestion control algorithm inmulti-hopwireless networksrdquo in Proceedings of the 2017 International Con-ference on Computer Communication and Informatics (ICCCI)pp 1ndash5 January 2017
[5] B-J Chang Y-H Liang and J-Y Jin ldquoAdaptive cross-layer-based TCP congestion control for 4G wireless mobile cloudaccessrdquo in Proceedings of the 3rd IEEE International Conferenceon Consumer Electronics-Taiwan ICCE-TW 2016 pp 1-2 May2016
[6] M Claeys N Bouten D De Vleeschauwer et al ldquoDeadline-aware TCP congestion control for video streaming servicesrdquo inProceedings of the 12th International Conference on Network andService Management pp 100ndash108 November 2016
[7] J Gruen M Karl and T Herfet ldquoNetwork supported conges-tion avoidance in software-defined networksrdquo in Proceedings ofthe 2013 19th IEEE International Conference on Networks ICON2013 p 16 December 2013
[8] A El-Mougy M Ibnkahla G Hattab and W Ejaz ldquoReconfig-urable wireless networksrdquo Proceedings of the IEEE vol 103 no7 pp 1125ndash1158 2015
[9] J-HWang K RenW-G Sun L ZhaoH-S Zhong andK XuldquoEffects of iodinated contrast agents on renal oxygenation leveldetermined by blood oxygenation level dependent magneticresonance imaging in rabbit models of type 1 and type 2 diabeticnephropathyrdquo BMC Nephrology vol 15 no 1 article 140 2014
[10] ldquoGartner Identifies the Top 10 Strategic Technology Trends for2015rdquo 2014 httpwwwgartnercomnewsroomid2867917
[11] P Sun M Yu M J Freedman J Rexford and D WalkerldquoHONE Joint Host-Network Traffic Management in Software-Defined Networksrdquo Journal of Network and Systems Manage-ment vol 23 no 2 pp 374ndash399 2015
[12] Z Ge R Gu andY Ji ldquoAn active queuemanagement adaptationframework for software defined optical networkrdquo in Proceedingsof the 2014 13th International Conference on Optical Communi-cations and Networks ICOCN 2014 p 14 November 2014
[13] L Zhang Q Deng Y Su and Y Hu ldquoA Box-Covering-BasedRouting Algorithm for Large-Scale SDNsrdquo IEEE Access vol 5pp 4048ndash4056 2017
[14] M Ghobadi S H Yeganeh and Y Ganjali ldquoRethinking end-to-end congestion control in software-defined networksrdquo in Pro-ceedings of the 11th ACM Workshop on Hot Topics in NetworksHotNets 2012 pp 61ndash66 October 2012
[15] H Long Y Shen M Guo and F Tang ldquoLABERIO dynamicload-balanced routing in OpenFlow-enabled networksrdquo inProceedings of the IEEE International Conference on AdvancedInformation Networking Applications pp 290ndash297 2013
8 Scientific Programming
[16] L Lu Y Xiao and H Du ldquoOpenFlow control for cooperatingAQM schemerdquo in Proceedings of the 2010 IEEE 10th Interna-tional Conference on Signal Processing ICSP2010 pp 2560ndash2563 October 2010
[17] M Gholami and B Akbari ldquoCongestion control in softwaredefined data center networks through flow reroutingrdquo in Pro-ceedings of the 23rd Iranian Conference on Electrical EngineeringICEE 2015 pp 654ndash657 May 2015
[18] J Hershberger M Maxel and S Suri ldquoFinding the k shortestsimple paths A new algorithm and its implementationrdquo ACMTransactions on Algorithms (TALG) vol 3 no 4 Article ID1290682 2007
[19] N McKeown T Anderson H Balakrishnan et al ldquoOpenFlowenabling innovation in campus networksrdquo Computer Commu-nication Review vol 38 no 2 pp 69ndash74 2008
[20] M-K Shin K-H Nam and H-J Kim ldquoSoftware-definednetworking (SDN) A reference architecture and open APIsrdquo inProceedings of the 2012 International Conference on ICT Con-vergence ldquoGlobal Open Innovation Summit for Smart ICT Con-vergencerdquo ICTC 2012 pp 360-361 October 2012
[21] POX 2017 httpsgithubcomnoxrepo
Submit your manuscripts athttpswwwhindawicom
Computer Games Technology
International Journal of
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Distributed Sensor Networks
International Journal of
Advances in
FuzzySystems
Hindawi Publishing Corporationhttpwwwhindawicom
Volume 2014
International Journal of
ReconfigurableComputing
Hindawi Publishing Corporation httpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 201
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
Artificial Intelligence
HindawithinspPublishingthinspCorporationhttpwwwhindawicom Volumethinsp2014
Advances inSoftware EngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Electrical and Computer Engineering
Journal of
Hindawi Publishing Corporation
httpwwwhindawicom Volume 2014
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Advances in
Hindawi Publishing Corporationhttpwwwhindawicom Volume 201
RoboticsJournal of
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Computational Intelligence and Neuroscience
Industrial EngineeringJournal of
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014
The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Human-ComputerInteraction
Advances in
Computer EngineeringAdvances in
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
4 Scientific Programming
R1 R2
Figure 2 New bottom switch network
Input link and node distanceOutput new path and update the flow table(1) IF link[119886]rarr congested(2) dist[119886] = INFINITY(3) For 119894 do(4) dist[119894] = V[0] rarr V[119894](5) For 119894 do find the nearest point(6) int mindist = INFINITY(7) For 119895 do(8) If dist[119895] ltmindist(9) mindist = dist[119896](10) For 119895 do update the shortest path(11) If mindist + V[119896] rarr V[119895] lt V[0] rarr V[119895](12) dist[119895] = mindist + V[119896] rarr V[119895](13) Newlinkrarr Packet out update flowtable(14) OFPFC DELETE(15) OFPFC ADD(16) Delete OutFlowtable
Algorithm 2 Rerouting
congested links from the global network topology image andthen obtains a new noncongested network topology image asshown in Figure 2 In the concrete execution we set the linkpath distance as infinity to achieve the deletion
Then using the shortest path algorithm to calculate theshortest path with non-congestion from the last node of thecongested node to the destination node and finally choosingthe appropriate data flows transferred to this new path tocomplete the transmission the algorithm of the OpenFlownetwork rerouting is presented as in Algorithm 2 Parameter119894 represents 119894 UDP data flows and parameter 119895 represents 119895TCP data flows Parameter 119896 represents the 119896th data flow
33 Selection of Rerouted Data Flows Considering that theUDP data flows always emphasize short transfer time andhigh-efficiency requirements we selected the TCP data flowsfor the rerouting Assuming that there are 119895 TCP data flows(1198911 1198912 1198913 119891119895) on one congested link the rate of each dataflows is (V1 V2 V3 V119895) and we obtain the following
1198611015840tcp = 119861tcp minus (V119886 + V119887 + sdot sdot sdot + V119896) (2)
To ensure high link bandwidth utilization when thetotal rate of the TCP flows on this link 119861tcp minus part ofthe rate (119891119886 119891119887 119891119896) and a new total rate of TCP flows1198611015840tcp closest to 1198611015840th is obtained then we are assured that thedata flows (119891119886 119891119887 119891119896) are optimal choice for reroutingthe transmission The selection algorithm of the rerouteddata flows are as in Algorithm 3 Parameter 119908 represents thenumber of the most suitable data flows
4 Experiment and Result
41 Experiment Design We considered the data flow condi-tion in the real network and mainly focused on the hetero-geneity between the TCP data flow and the UDP data flowin proposing this congestion control mechanism In our testenvironment the controller obtains the global informationand regularly monitors the network congestion conditionThe controller estimates whether there are congested links Ifcongested link is discovered it is removed from the topologyimage to generate a new topology image The controllercalculates the shortest path between the last node of thecongested node to the destination node At last the controllerselects one or more appropriate data flows to reroute
To verify the proposed congestion control mechanismusing the OpenFlow network we built the test environmentas shown in Figure 3 OFS1 OFS2 and OFS3 are OpenFlowswitches by Mininet simulation OFC is the OpenFlow con-troller with POX [21] PC1ndashPC6 are common user terminalsand we use the Iperf tool on user terminals to send the dataflows
We added the link monitoring congestion detectionrerouted data flow selection and shortest path calculationfunction modules in the POX controller and combined themwith the existing modules of topology discovery and flowtable update to achieve the proposed congestion controlmechanism The running process of each module is shownin Figure 4
After the POX controller starts the LLDP protocol isfirst run to obtain the entire network topology and thenthe congestion detection module is triggered to regularly(the experiment is set at 2 s) query each OFS for statusinformation of each port and record the number and sizeof each flow through this port Then the controller willadd the rates of all data flows together We found that theNetFPGArsquos port line speed is 1 Gbps Aftermany experimentswhen the port rate reaches 950MBs the packet loss rate willquickly reach 2 magnitude and it is out of the standardof common business demand Therefore to simulate the realnetwork environment we set the port congestion thresholdat 950MBs in our test
42 Results and Analysis To facilitate testing we built fourdata flows with Iperf (as shown in Table 1) and sets OFS1-OFS2 as Path 1 and OFS1-OFS3-OFS2 as Path 2 As identifiedby the shortest path algorithm these four flows will betransmitted through Path 1 In this experiment the rate of 1198913will be increased over time
Scientific Programming 5
Input all data flow rates through the congested linkOutput number of selected flow(1) For 119894 do(2) sum = sum + flow[119894](3) For i do Select the appropriate flow and tag it(4) If flow = TCP ampamp congested ampamp sum-flow[119908] gt bestsum(5) bestsum = sum minus flowsize[119908](6) bestflownum = 119908(7) Return bestflownum
Algorithm 3 Selection
PC1
PC2
PC3
PC4
PC5
PC6
OFS1 OFS2
OFS3
OFC
Figure 3 OpenFlow network experiment platform
Link monitoring Congestion detection Data flow selection
Path calculation and flow table update Controller
Figure 4 Module architecture of the POX controller in SDCCalgorithm
(1) Link Bandwidth Figure 5 shows the complete process ofPath 1 and Path 2 loading with1198913 data flow rate First the twolinks maintain a stable trend without large fluctuationWhenthe 1198913 growth rate reaches around 350MBs an obvious
Table 1 Set of four data flows
Flow Type Rate1198911 TCP (PC1ndashPC4) 150MBs1198912 UDP (PC2ndashPC4) 100MBs1198913 TCP (PC3ndashPC6) Increasing1198914 UDP (PC1ndashPC6) 350MBs
turning point occurred as shown in Figure 6 At this timethe OFC detected OFS2 link is congested and the mostappropriate data flow is selected (1198911 in the experiment) fromall data flows through this link Finally the flow is rerouted to
6 Scientific Programming
0 50 100 150 200 250 300 350 4000
100
200
300
400
500
600
700
800
900
1000
Flow f3 rate (MBs)
Flow
load
(MB
s)
Path1Path2
Figure 5 Link bandwidth
300 310 320 330 340 350 360 3700
100
200
300
400
500
600
700
800
900
1000
Flow f3 rate (MBs)
Flow
load
(MB
s)
Path1Path2
Figure 6 Link bandwidth in turning point
Path 2 because we only select TCP data flows to reroute in ouralgorithm and theUDPdata flows are not adjusted consistentwith the aim of the algorithm
Figure 6 provides details of the turning point of thelink bandwidth Then Path 1 loading decreases by 150MBsfrom 950MBs to 800MBs Moreover Path 2 significantlyincreased in loading size at about 150MBs which explainsthe transmission of 1198911 to Path 2 After the congestion reliefthe loading in Path 1 continues to rise steadily with theincrease of 1198913 data flow until the next congestion
(2) Packet Loss RateThe packet loss rate is shown in Figure 7where the increase of 1198913 increases the packet loss rate ofPath 1 but the overall trend and value are small and within
0 50 100 150 200 250 300 350 4000
0002
0004
0006
0008
001
0012
0014
0016
0018
002
Pack
et lo
ss ra
te (1
00
)
Flow f3 rate (MBs)
Figure 7 Packet loss rate
0 50 100 150 200 250 300 350 400055
06
065
07
075
08
085
09
095
Flow f3 rate (MBs)
Path
1 li
nk u
sage
(100
)
SDCC algorithmLABERIO algorithm
Figure 8 Link utilization
a reasonable range When 1198913 reached 350MBs an obviousincrease in packet loss rate was observedThe packet loss ratehas increased dramatically to 2 which indicates that it hasreached a state of congestion at this time While the rate of1198913 increases from 350MBs to 400MBs there is an obviousdecline process which shows the congestion relief and thepacket loss rate return to a reasonable range
(3) Link Utilization At the full stage of flow 1198913 rate from0 to 400MBs the average link utilization of the proposedalgorithm is about 785 and the LABERIO algorithm hasan average link utilization of about 74 Figure 8 shows thatwhen congestion did not occur the link utilization rate doesnot have much difference However when congestion occursand congestion control is performed the SDCC algorithmproposed in this paper does not fluctuate significantly More-over the algorithm stillmaintainedhigh link utilization First
Scientific Programming 7
the utilization on Path 1 link starts at around 60 and showsa linear growth trend with the flow rate of flow 1198913 wherethe maximum link utilization can be up to 95 When therate of flow 1198913 reaches 350MBs the link utilization of theSDCC algorithm is about 80 Moreover a follow-up withthe growth rate of flow1198913 showed an upward trendHoweverthe LABERIO algorithm significantly declined at less than60 and the follow-up showed almost no growth trendTherefore the SDCC algorithm is superior to the LABERIOalgorithm in link utilization
(4) Complexity Finally the complexity analysis shows theconsiderable properties of the SDCC algorithm that aremainly related to the calculation of three parts namely thereal-timemonitoring and judgment of the congested link thenew shortest path calculation of rerouting and the selectionof rerouting data flows If 119896 nodes exist in a network topologyand there are 119899 data streams on the link the time complexityof these three parts is 119874(119899119896) 119874(1198962) and 119874(119899)
Therefore the results show the effectiveness of our con-gestion mechanism It effectively relieved congestion andguaranteed the packet loss rate and link utilization
5 Conclusion and Future Work
Congestion is a common problem in the IP network but thecurrent level of development in the traditional network algo-rithm is insufficient to meet the growing network demandA software-defined approach is required to find a solution tothe network congestion problem Using centralized controlfeatures of the SDN network we proposed a new networkcongestion control algorithm called SDCC algorithm TheSDCC algorithm is based on the SDN architecture and it canobtain a global topology for unified network managementSDCC algorithm can relieve the network congestion problemmore efficiently We considered the difference between TCPand UDP and proposed a new method in judging congestednodes Moreover the simulation shows the effectiveness ofour congestionmechanismTheproposed algorithm achievesnetwork congestion control guarantees the packet loss rateand optimizes the link utilization In future work we willapply a software-defined approach to the data center networkor other more complex and special network to solve thecongestion problem in depth Furthermore we can stilloptimize our algorithm considering the different attributesof UDP packets or other such factors and adding differentparameters to provide a fair and accurate data flow selectionstrategy
Conflicts of Interest
The authors declare that they have no conflicts of interest
Acknowledgments
This work is supported in part by grants from the NationalNatural Science Foundation of China (61572191 and61402170)
References
[1] C P Fu and S C Liew ldquoTCPVeno TCP enhancement for trans-mission over wireless access networksrdquo IEEE Journal on SelectedAreas in Communications vol 21 no 2 pp 216ndash228 2003
[2] C Caini and R Firrincieli ldquoTCP Hybla A TCP enhancementfor heterogeneous networksrdquo International Journal of SatelliteCommunications and Networking vol 22 no 5 pp 547ndash5662004
[3] C E Palazzi M Brunati andM Roccetti ldquoAn OpenWRT solu-tion for future wireless homesrdquo in Proceedings of the 2010 IEEEInternational Conference on Multimedia and Expo ICME 2010pp 1701ndash1706 July 2010
[4] D SreeArthi S Malini M J Jude and V C Diniesh ldquoMicrolevel analysis of TCP congestion control algorithm inmulti-hopwireless networksrdquo in Proceedings of the 2017 International Con-ference on Computer Communication and Informatics (ICCCI)pp 1ndash5 January 2017
[5] B-J Chang Y-H Liang and J-Y Jin ldquoAdaptive cross-layer-based TCP congestion control for 4G wireless mobile cloudaccessrdquo in Proceedings of the 3rd IEEE International Conferenceon Consumer Electronics-Taiwan ICCE-TW 2016 pp 1-2 May2016
[6] M Claeys N Bouten D De Vleeschauwer et al ldquoDeadline-aware TCP congestion control for video streaming servicesrdquo inProceedings of the 12th International Conference on Network andService Management pp 100ndash108 November 2016
[7] J Gruen M Karl and T Herfet ldquoNetwork supported conges-tion avoidance in software-defined networksrdquo in Proceedings ofthe 2013 19th IEEE International Conference on Networks ICON2013 p 16 December 2013
[8] A El-Mougy M Ibnkahla G Hattab and W Ejaz ldquoReconfig-urable wireless networksrdquo Proceedings of the IEEE vol 103 no7 pp 1125ndash1158 2015
[9] J-HWang K RenW-G Sun L ZhaoH-S Zhong andK XuldquoEffects of iodinated contrast agents on renal oxygenation leveldetermined by blood oxygenation level dependent magneticresonance imaging in rabbit models of type 1 and type 2 diabeticnephropathyrdquo BMC Nephrology vol 15 no 1 article 140 2014
[10] ldquoGartner Identifies the Top 10 Strategic Technology Trends for2015rdquo 2014 httpwwwgartnercomnewsroomid2867917
[11] P Sun M Yu M J Freedman J Rexford and D WalkerldquoHONE Joint Host-Network Traffic Management in Software-Defined Networksrdquo Journal of Network and Systems Manage-ment vol 23 no 2 pp 374ndash399 2015
[12] Z Ge R Gu andY Ji ldquoAn active queuemanagement adaptationframework for software defined optical networkrdquo in Proceedingsof the 2014 13th International Conference on Optical Communi-cations and Networks ICOCN 2014 p 14 November 2014
[13] L Zhang Q Deng Y Su and Y Hu ldquoA Box-Covering-BasedRouting Algorithm for Large-Scale SDNsrdquo IEEE Access vol 5pp 4048ndash4056 2017
[14] M Ghobadi S H Yeganeh and Y Ganjali ldquoRethinking end-to-end congestion control in software-defined networksrdquo in Pro-ceedings of the 11th ACM Workshop on Hot Topics in NetworksHotNets 2012 pp 61ndash66 October 2012
[15] H Long Y Shen M Guo and F Tang ldquoLABERIO dynamicload-balanced routing in OpenFlow-enabled networksrdquo inProceedings of the IEEE International Conference on AdvancedInformation Networking Applications pp 290ndash297 2013
8 Scientific Programming
[16] L Lu Y Xiao and H Du ldquoOpenFlow control for cooperatingAQM schemerdquo in Proceedings of the 2010 IEEE 10th Interna-tional Conference on Signal Processing ICSP2010 pp 2560ndash2563 October 2010
[17] M Gholami and B Akbari ldquoCongestion control in softwaredefined data center networks through flow reroutingrdquo in Pro-ceedings of the 23rd Iranian Conference on Electrical EngineeringICEE 2015 pp 654ndash657 May 2015
[18] J Hershberger M Maxel and S Suri ldquoFinding the k shortestsimple paths A new algorithm and its implementationrdquo ACMTransactions on Algorithms (TALG) vol 3 no 4 Article ID1290682 2007
[19] N McKeown T Anderson H Balakrishnan et al ldquoOpenFlowenabling innovation in campus networksrdquo Computer Commu-nication Review vol 38 no 2 pp 69ndash74 2008
[20] M-K Shin K-H Nam and H-J Kim ldquoSoftware-definednetworking (SDN) A reference architecture and open APIsrdquo inProceedings of the 2012 International Conference on ICT Con-vergence ldquoGlobal Open Innovation Summit for Smart ICT Con-vergencerdquo ICTC 2012 pp 360-361 October 2012
[21] POX 2017 httpsgithubcomnoxrepo
Submit your manuscripts athttpswwwhindawicom
Computer Games Technology
International Journal of
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Distributed Sensor Networks
International Journal of
Advances in
FuzzySystems
Hindawi Publishing Corporationhttpwwwhindawicom
Volume 2014
International Journal of
ReconfigurableComputing
Hindawi Publishing Corporation httpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 201
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
Artificial Intelligence
HindawithinspPublishingthinspCorporationhttpwwwhindawicom Volumethinsp2014
Advances inSoftware EngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Electrical and Computer Engineering
Journal of
Hindawi Publishing Corporation
httpwwwhindawicom Volume 2014
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Advances in
Hindawi Publishing Corporationhttpwwwhindawicom Volume 201
RoboticsJournal of
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Computational Intelligence and Neuroscience
Industrial EngineeringJournal of
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014
The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Human-ComputerInteraction
Advances in
Computer EngineeringAdvances in
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Scientific Programming 5
Input all data flow rates through the congested linkOutput number of selected flow(1) For 119894 do(2) sum = sum + flow[119894](3) For i do Select the appropriate flow and tag it(4) If flow = TCP ampamp congested ampamp sum-flow[119908] gt bestsum(5) bestsum = sum minus flowsize[119908](6) bestflownum = 119908(7) Return bestflownum
Algorithm 3 Selection
PC1
PC2
PC3
PC4
PC5
PC6
OFS1 OFS2
OFS3
OFC
Figure 3 OpenFlow network experiment platform
Link monitoring Congestion detection Data flow selection
Path calculation and flow table update Controller
Figure 4 Module architecture of the POX controller in SDCCalgorithm
(1) Link Bandwidth Figure 5 shows the complete process ofPath 1 and Path 2 loading with1198913 data flow rate First the twolinks maintain a stable trend without large fluctuationWhenthe 1198913 growth rate reaches around 350MBs an obvious
Table 1 Set of four data flows
Flow Type Rate1198911 TCP (PC1ndashPC4) 150MBs1198912 UDP (PC2ndashPC4) 100MBs1198913 TCP (PC3ndashPC6) Increasing1198914 UDP (PC1ndashPC6) 350MBs
turning point occurred as shown in Figure 6 At this timethe OFC detected OFS2 link is congested and the mostappropriate data flow is selected (1198911 in the experiment) fromall data flows through this link Finally the flow is rerouted to
6 Scientific Programming
0 50 100 150 200 250 300 350 4000
100
200
300
400
500
600
700
800
900
1000
Flow f3 rate (MBs)
Flow
load
(MB
s)
Path1Path2
Figure 5 Link bandwidth
300 310 320 330 340 350 360 3700
100
200
300
400
500
600
700
800
900
1000
Flow f3 rate (MBs)
Flow
load
(MB
s)
Path1Path2
Figure 6 Link bandwidth in turning point
Path 2 because we only select TCP data flows to reroute in ouralgorithm and theUDPdata flows are not adjusted consistentwith the aim of the algorithm
Figure 6 provides details of the turning point of thelink bandwidth Then Path 1 loading decreases by 150MBsfrom 950MBs to 800MBs Moreover Path 2 significantlyincreased in loading size at about 150MBs which explainsthe transmission of 1198911 to Path 2 After the congestion reliefthe loading in Path 1 continues to rise steadily with theincrease of 1198913 data flow until the next congestion
(2) Packet Loss RateThe packet loss rate is shown in Figure 7where the increase of 1198913 increases the packet loss rate ofPath 1 but the overall trend and value are small and within
0 50 100 150 200 250 300 350 4000
0002
0004
0006
0008
001
0012
0014
0016
0018
002
Pack
et lo
ss ra
te (1
00
)
Flow f3 rate (MBs)
Figure 7 Packet loss rate
0 50 100 150 200 250 300 350 400055
06
065
07
075
08
085
09
095
Flow f3 rate (MBs)
Path
1 li
nk u
sage
(100
)
SDCC algorithmLABERIO algorithm
Figure 8 Link utilization
a reasonable range When 1198913 reached 350MBs an obviousincrease in packet loss rate was observedThe packet loss ratehas increased dramatically to 2 which indicates that it hasreached a state of congestion at this time While the rate of1198913 increases from 350MBs to 400MBs there is an obviousdecline process which shows the congestion relief and thepacket loss rate return to a reasonable range
(3) Link Utilization At the full stage of flow 1198913 rate from0 to 400MBs the average link utilization of the proposedalgorithm is about 785 and the LABERIO algorithm hasan average link utilization of about 74 Figure 8 shows thatwhen congestion did not occur the link utilization rate doesnot have much difference However when congestion occursand congestion control is performed the SDCC algorithmproposed in this paper does not fluctuate significantly More-over the algorithm stillmaintainedhigh link utilization First
Scientific Programming 7
the utilization on Path 1 link starts at around 60 and showsa linear growth trend with the flow rate of flow 1198913 wherethe maximum link utilization can be up to 95 When therate of flow 1198913 reaches 350MBs the link utilization of theSDCC algorithm is about 80 Moreover a follow-up withthe growth rate of flow1198913 showed an upward trendHoweverthe LABERIO algorithm significantly declined at less than60 and the follow-up showed almost no growth trendTherefore the SDCC algorithm is superior to the LABERIOalgorithm in link utilization
(4) Complexity Finally the complexity analysis shows theconsiderable properties of the SDCC algorithm that aremainly related to the calculation of three parts namely thereal-timemonitoring and judgment of the congested link thenew shortest path calculation of rerouting and the selectionof rerouting data flows If 119896 nodes exist in a network topologyand there are 119899 data streams on the link the time complexityof these three parts is 119874(119899119896) 119874(1198962) and 119874(119899)
Therefore the results show the effectiveness of our con-gestion mechanism It effectively relieved congestion andguaranteed the packet loss rate and link utilization
5 Conclusion and Future Work
Congestion is a common problem in the IP network but thecurrent level of development in the traditional network algo-rithm is insufficient to meet the growing network demandA software-defined approach is required to find a solution tothe network congestion problem Using centralized controlfeatures of the SDN network we proposed a new networkcongestion control algorithm called SDCC algorithm TheSDCC algorithm is based on the SDN architecture and it canobtain a global topology for unified network managementSDCC algorithm can relieve the network congestion problemmore efficiently We considered the difference between TCPand UDP and proposed a new method in judging congestednodes Moreover the simulation shows the effectiveness ofour congestionmechanismTheproposed algorithm achievesnetwork congestion control guarantees the packet loss rateand optimizes the link utilization In future work we willapply a software-defined approach to the data center networkor other more complex and special network to solve thecongestion problem in depth Furthermore we can stilloptimize our algorithm considering the different attributesof UDP packets or other such factors and adding differentparameters to provide a fair and accurate data flow selectionstrategy
Conflicts of Interest
The authors declare that they have no conflicts of interest
Acknowledgments
This work is supported in part by grants from the NationalNatural Science Foundation of China (61572191 and61402170)
References
[1] C P Fu and S C Liew ldquoTCPVeno TCP enhancement for trans-mission over wireless access networksrdquo IEEE Journal on SelectedAreas in Communications vol 21 no 2 pp 216ndash228 2003
[2] C Caini and R Firrincieli ldquoTCP Hybla A TCP enhancementfor heterogeneous networksrdquo International Journal of SatelliteCommunications and Networking vol 22 no 5 pp 547ndash5662004
[3] C E Palazzi M Brunati andM Roccetti ldquoAn OpenWRT solu-tion for future wireless homesrdquo in Proceedings of the 2010 IEEEInternational Conference on Multimedia and Expo ICME 2010pp 1701ndash1706 July 2010
[4] D SreeArthi S Malini M J Jude and V C Diniesh ldquoMicrolevel analysis of TCP congestion control algorithm inmulti-hopwireless networksrdquo in Proceedings of the 2017 International Con-ference on Computer Communication and Informatics (ICCCI)pp 1ndash5 January 2017
[5] B-J Chang Y-H Liang and J-Y Jin ldquoAdaptive cross-layer-based TCP congestion control for 4G wireless mobile cloudaccessrdquo in Proceedings of the 3rd IEEE International Conferenceon Consumer Electronics-Taiwan ICCE-TW 2016 pp 1-2 May2016
[6] M Claeys N Bouten D De Vleeschauwer et al ldquoDeadline-aware TCP congestion control for video streaming servicesrdquo inProceedings of the 12th International Conference on Network andService Management pp 100ndash108 November 2016
[7] J Gruen M Karl and T Herfet ldquoNetwork supported conges-tion avoidance in software-defined networksrdquo in Proceedings ofthe 2013 19th IEEE International Conference on Networks ICON2013 p 16 December 2013
[8] A El-Mougy M Ibnkahla G Hattab and W Ejaz ldquoReconfig-urable wireless networksrdquo Proceedings of the IEEE vol 103 no7 pp 1125ndash1158 2015
[9] J-HWang K RenW-G Sun L ZhaoH-S Zhong andK XuldquoEffects of iodinated contrast agents on renal oxygenation leveldetermined by blood oxygenation level dependent magneticresonance imaging in rabbit models of type 1 and type 2 diabeticnephropathyrdquo BMC Nephrology vol 15 no 1 article 140 2014
[10] ldquoGartner Identifies the Top 10 Strategic Technology Trends for2015rdquo 2014 httpwwwgartnercomnewsroomid2867917
[11] P Sun M Yu M J Freedman J Rexford and D WalkerldquoHONE Joint Host-Network Traffic Management in Software-Defined Networksrdquo Journal of Network and Systems Manage-ment vol 23 no 2 pp 374ndash399 2015
[12] Z Ge R Gu andY Ji ldquoAn active queuemanagement adaptationframework for software defined optical networkrdquo in Proceedingsof the 2014 13th International Conference on Optical Communi-cations and Networks ICOCN 2014 p 14 November 2014
[13] L Zhang Q Deng Y Su and Y Hu ldquoA Box-Covering-BasedRouting Algorithm for Large-Scale SDNsrdquo IEEE Access vol 5pp 4048ndash4056 2017
[14] M Ghobadi S H Yeganeh and Y Ganjali ldquoRethinking end-to-end congestion control in software-defined networksrdquo in Pro-ceedings of the 11th ACM Workshop on Hot Topics in NetworksHotNets 2012 pp 61ndash66 October 2012
[15] H Long Y Shen M Guo and F Tang ldquoLABERIO dynamicload-balanced routing in OpenFlow-enabled networksrdquo inProceedings of the IEEE International Conference on AdvancedInformation Networking Applications pp 290ndash297 2013
8 Scientific Programming
[16] L Lu Y Xiao and H Du ldquoOpenFlow control for cooperatingAQM schemerdquo in Proceedings of the 2010 IEEE 10th Interna-tional Conference on Signal Processing ICSP2010 pp 2560ndash2563 October 2010
[17] M Gholami and B Akbari ldquoCongestion control in softwaredefined data center networks through flow reroutingrdquo in Pro-ceedings of the 23rd Iranian Conference on Electrical EngineeringICEE 2015 pp 654ndash657 May 2015
[18] J Hershberger M Maxel and S Suri ldquoFinding the k shortestsimple paths A new algorithm and its implementationrdquo ACMTransactions on Algorithms (TALG) vol 3 no 4 Article ID1290682 2007
[19] N McKeown T Anderson H Balakrishnan et al ldquoOpenFlowenabling innovation in campus networksrdquo Computer Commu-nication Review vol 38 no 2 pp 69ndash74 2008
[20] M-K Shin K-H Nam and H-J Kim ldquoSoftware-definednetworking (SDN) A reference architecture and open APIsrdquo inProceedings of the 2012 International Conference on ICT Con-vergence ldquoGlobal Open Innovation Summit for Smart ICT Con-vergencerdquo ICTC 2012 pp 360-361 October 2012
[21] POX 2017 httpsgithubcomnoxrepo
Submit your manuscripts athttpswwwhindawicom
Computer Games Technology
International Journal of
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Distributed Sensor Networks
International Journal of
Advances in
FuzzySystems
Hindawi Publishing Corporationhttpwwwhindawicom
Volume 2014
International Journal of
ReconfigurableComputing
Hindawi Publishing Corporation httpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 201
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
Artificial Intelligence
HindawithinspPublishingthinspCorporationhttpwwwhindawicom Volumethinsp2014
Advances inSoftware EngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Electrical and Computer Engineering
Journal of
Hindawi Publishing Corporation
httpwwwhindawicom Volume 2014
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Advances in
Hindawi Publishing Corporationhttpwwwhindawicom Volume 201
RoboticsJournal of
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Computational Intelligence and Neuroscience
Industrial EngineeringJournal of
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014
The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Human-ComputerInteraction
Advances in
Computer EngineeringAdvances in
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
6 Scientific Programming
0 50 100 150 200 250 300 350 4000
100
200
300
400
500
600
700
800
900
1000
Flow f3 rate (MBs)
Flow
load
(MB
s)
Path1Path2
Figure 5 Link bandwidth
300 310 320 330 340 350 360 3700
100
200
300
400
500
600
700
800
900
1000
Flow f3 rate (MBs)
Flow
load
(MB
s)
Path1Path2
Figure 6 Link bandwidth in turning point
Path 2 because we only select TCP data flows to reroute in ouralgorithm and theUDPdata flows are not adjusted consistentwith the aim of the algorithm
Figure 6 provides details of the turning point of thelink bandwidth Then Path 1 loading decreases by 150MBsfrom 950MBs to 800MBs Moreover Path 2 significantlyincreased in loading size at about 150MBs which explainsthe transmission of 1198911 to Path 2 After the congestion reliefthe loading in Path 1 continues to rise steadily with theincrease of 1198913 data flow until the next congestion
(2) Packet Loss RateThe packet loss rate is shown in Figure 7where the increase of 1198913 increases the packet loss rate ofPath 1 but the overall trend and value are small and within
0 50 100 150 200 250 300 350 4000
0002
0004
0006
0008
001
0012
0014
0016
0018
002
Pack
et lo
ss ra
te (1
00
)
Flow f3 rate (MBs)
Figure 7 Packet loss rate
0 50 100 150 200 250 300 350 400055
06
065
07
075
08
085
09
095
Flow f3 rate (MBs)
Path
1 li
nk u
sage
(100
)
SDCC algorithmLABERIO algorithm
Figure 8 Link utilization
a reasonable range When 1198913 reached 350MBs an obviousincrease in packet loss rate was observedThe packet loss ratehas increased dramatically to 2 which indicates that it hasreached a state of congestion at this time While the rate of1198913 increases from 350MBs to 400MBs there is an obviousdecline process which shows the congestion relief and thepacket loss rate return to a reasonable range
(3) Link Utilization At the full stage of flow 1198913 rate from0 to 400MBs the average link utilization of the proposedalgorithm is about 785 and the LABERIO algorithm hasan average link utilization of about 74 Figure 8 shows thatwhen congestion did not occur the link utilization rate doesnot have much difference However when congestion occursand congestion control is performed the SDCC algorithmproposed in this paper does not fluctuate significantly More-over the algorithm stillmaintainedhigh link utilization First
Scientific Programming 7
the utilization on Path 1 link starts at around 60 and showsa linear growth trend with the flow rate of flow 1198913 wherethe maximum link utilization can be up to 95 When therate of flow 1198913 reaches 350MBs the link utilization of theSDCC algorithm is about 80 Moreover a follow-up withthe growth rate of flow1198913 showed an upward trendHoweverthe LABERIO algorithm significantly declined at less than60 and the follow-up showed almost no growth trendTherefore the SDCC algorithm is superior to the LABERIOalgorithm in link utilization
(4) Complexity Finally the complexity analysis shows theconsiderable properties of the SDCC algorithm that aremainly related to the calculation of three parts namely thereal-timemonitoring and judgment of the congested link thenew shortest path calculation of rerouting and the selectionof rerouting data flows If 119896 nodes exist in a network topologyand there are 119899 data streams on the link the time complexityof these three parts is 119874(119899119896) 119874(1198962) and 119874(119899)
Therefore the results show the effectiveness of our con-gestion mechanism It effectively relieved congestion andguaranteed the packet loss rate and link utilization
5 Conclusion and Future Work
Congestion is a common problem in the IP network but thecurrent level of development in the traditional network algo-rithm is insufficient to meet the growing network demandA software-defined approach is required to find a solution tothe network congestion problem Using centralized controlfeatures of the SDN network we proposed a new networkcongestion control algorithm called SDCC algorithm TheSDCC algorithm is based on the SDN architecture and it canobtain a global topology for unified network managementSDCC algorithm can relieve the network congestion problemmore efficiently We considered the difference between TCPand UDP and proposed a new method in judging congestednodes Moreover the simulation shows the effectiveness ofour congestionmechanismTheproposed algorithm achievesnetwork congestion control guarantees the packet loss rateand optimizes the link utilization In future work we willapply a software-defined approach to the data center networkor other more complex and special network to solve thecongestion problem in depth Furthermore we can stilloptimize our algorithm considering the different attributesof UDP packets or other such factors and adding differentparameters to provide a fair and accurate data flow selectionstrategy
Conflicts of Interest
The authors declare that they have no conflicts of interest
Acknowledgments
This work is supported in part by grants from the NationalNatural Science Foundation of China (61572191 and61402170)
References
[1] C P Fu and S C Liew ldquoTCPVeno TCP enhancement for trans-mission over wireless access networksrdquo IEEE Journal on SelectedAreas in Communications vol 21 no 2 pp 216ndash228 2003
[2] C Caini and R Firrincieli ldquoTCP Hybla A TCP enhancementfor heterogeneous networksrdquo International Journal of SatelliteCommunications and Networking vol 22 no 5 pp 547ndash5662004
[3] C E Palazzi M Brunati andM Roccetti ldquoAn OpenWRT solu-tion for future wireless homesrdquo in Proceedings of the 2010 IEEEInternational Conference on Multimedia and Expo ICME 2010pp 1701ndash1706 July 2010
[4] D SreeArthi S Malini M J Jude and V C Diniesh ldquoMicrolevel analysis of TCP congestion control algorithm inmulti-hopwireless networksrdquo in Proceedings of the 2017 International Con-ference on Computer Communication and Informatics (ICCCI)pp 1ndash5 January 2017
[5] B-J Chang Y-H Liang and J-Y Jin ldquoAdaptive cross-layer-based TCP congestion control for 4G wireless mobile cloudaccessrdquo in Proceedings of the 3rd IEEE International Conferenceon Consumer Electronics-Taiwan ICCE-TW 2016 pp 1-2 May2016
[6] M Claeys N Bouten D De Vleeschauwer et al ldquoDeadline-aware TCP congestion control for video streaming servicesrdquo inProceedings of the 12th International Conference on Network andService Management pp 100ndash108 November 2016
[7] J Gruen M Karl and T Herfet ldquoNetwork supported conges-tion avoidance in software-defined networksrdquo in Proceedings ofthe 2013 19th IEEE International Conference on Networks ICON2013 p 16 December 2013
[8] A El-Mougy M Ibnkahla G Hattab and W Ejaz ldquoReconfig-urable wireless networksrdquo Proceedings of the IEEE vol 103 no7 pp 1125ndash1158 2015
[9] J-HWang K RenW-G Sun L ZhaoH-S Zhong andK XuldquoEffects of iodinated contrast agents on renal oxygenation leveldetermined by blood oxygenation level dependent magneticresonance imaging in rabbit models of type 1 and type 2 diabeticnephropathyrdquo BMC Nephrology vol 15 no 1 article 140 2014
[10] ldquoGartner Identifies the Top 10 Strategic Technology Trends for2015rdquo 2014 httpwwwgartnercomnewsroomid2867917
[11] P Sun M Yu M J Freedman J Rexford and D WalkerldquoHONE Joint Host-Network Traffic Management in Software-Defined Networksrdquo Journal of Network and Systems Manage-ment vol 23 no 2 pp 374ndash399 2015
[12] Z Ge R Gu andY Ji ldquoAn active queuemanagement adaptationframework for software defined optical networkrdquo in Proceedingsof the 2014 13th International Conference on Optical Communi-cations and Networks ICOCN 2014 p 14 November 2014
[13] L Zhang Q Deng Y Su and Y Hu ldquoA Box-Covering-BasedRouting Algorithm for Large-Scale SDNsrdquo IEEE Access vol 5pp 4048ndash4056 2017
[14] M Ghobadi S H Yeganeh and Y Ganjali ldquoRethinking end-to-end congestion control in software-defined networksrdquo in Pro-ceedings of the 11th ACM Workshop on Hot Topics in NetworksHotNets 2012 pp 61ndash66 October 2012
[15] H Long Y Shen M Guo and F Tang ldquoLABERIO dynamicload-balanced routing in OpenFlow-enabled networksrdquo inProceedings of the IEEE International Conference on AdvancedInformation Networking Applications pp 290ndash297 2013
8 Scientific Programming
[16] L Lu Y Xiao and H Du ldquoOpenFlow control for cooperatingAQM schemerdquo in Proceedings of the 2010 IEEE 10th Interna-tional Conference on Signal Processing ICSP2010 pp 2560ndash2563 October 2010
[17] M Gholami and B Akbari ldquoCongestion control in softwaredefined data center networks through flow reroutingrdquo in Pro-ceedings of the 23rd Iranian Conference on Electrical EngineeringICEE 2015 pp 654ndash657 May 2015
[18] J Hershberger M Maxel and S Suri ldquoFinding the k shortestsimple paths A new algorithm and its implementationrdquo ACMTransactions on Algorithms (TALG) vol 3 no 4 Article ID1290682 2007
[19] N McKeown T Anderson H Balakrishnan et al ldquoOpenFlowenabling innovation in campus networksrdquo Computer Commu-nication Review vol 38 no 2 pp 69ndash74 2008
[20] M-K Shin K-H Nam and H-J Kim ldquoSoftware-definednetworking (SDN) A reference architecture and open APIsrdquo inProceedings of the 2012 International Conference on ICT Con-vergence ldquoGlobal Open Innovation Summit for Smart ICT Con-vergencerdquo ICTC 2012 pp 360-361 October 2012
[21] POX 2017 httpsgithubcomnoxrepo
Submit your manuscripts athttpswwwhindawicom
Computer Games Technology
International Journal of
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Distributed Sensor Networks
International Journal of
Advances in
FuzzySystems
Hindawi Publishing Corporationhttpwwwhindawicom
Volume 2014
International Journal of
ReconfigurableComputing
Hindawi Publishing Corporation httpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 201
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
Artificial Intelligence
HindawithinspPublishingthinspCorporationhttpwwwhindawicom Volumethinsp2014
Advances inSoftware EngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Electrical and Computer Engineering
Journal of
Hindawi Publishing Corporation
httpwwwhindawicom Volume 2014
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Advances in
Hindawi Publishing Corporationhttpwwwhindawicom Volume 201
RoboticsJournal of
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Computational Intelligence and Neuroscience
Industrial EngineeringJournal of
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014
The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Human-ComputerInteraction
Advances in
Computer EngineeringAdvances in
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Scientific Programming 7
the utilization on Path 1 link starts at around 60 and showsa linear growth trend with the flow rate of flow 1198913 wherethe maximum link utilization can be up to 95 When therate of flow 1198913 reaches 350MBs the link utilization of theSDCC algorithm is about 80 Moreover a follow-up withthe growth rate of flow1198913 showed an upward trendHoweverthe LABERIO algorithm significantly declined at less than60 and the follow-up showed almost no growth trendTherefore the SDCC algorithm is superior to the LABERIOalgorithm in link utilization
(4) Complexity Finally the complexity analysis shows theconsiderable properties of the SDCC algorithm that aremainly related to the calculation of three parts namely thereal-timemonitoring and judgment of the congested link thenew shortest path calculation of rerouting and the selectionof rerouting data flows If 119896 nodes exist in a network topologyand there are 119899 data streams on the link the time complexityof these three parts is 119874(119899119896) 119874(1198962) and 119874(119899)
Therefore the results show the effectiveness of our con-gestion mechanism It effectively relieved congestion andguaranteed the packet loss rate and link utilization
5 Conclusion and Future Work
Congestion is a common problem in the IP network but thecurrent level of development in the traditional network algo-rithm is insufficient to meet the growing network demandA software-defined approach is required to find a solution tothe network congestion problem Using centralized controlfeatures of the SDN network we proposed a new networkcongestion control algorithm called SDCC algorithm TheSDCC algorithm is based on the SDN architecture and it canobtain a global topology for unified network managementSDCC algorithm can relieve the network congestion problemmore efficiently We considered the difference between TCPand UDP and proposed a new method in judging congestednodes Moreover the simulation shows the effectiveness ofour congestionmechanismTheproposed algorithm achievesnetwork congestion control guarantees the packet loss rateand optimizes the link utilization In future work we willapply a software-defined approach to the data center networkor other more complex and special network to solve thecongestion problem in depth Furthermore we can stilloptimize our algorithm considering the different attributesof UDP packets or other such factors and adding differentparameters to provide a fair and accurate data flow selectionstrategy
Conflicts of Interest
The authors declare that they have no conflicts of interest
Acknowledgments
This work is supported in part by grants from the NationalNatural Science Foundation of China (61572191 and61402170)
References
[1] C P Fu and S C Liew ldquoTCPVeno TCP enhancement for trans-mission over wireless access networksrdquo IEEE Journal on SelectedAreas in Communications vol 21 no 2 pp 216ndash228 2003
[2] C Caini and R Firrincieli ldquoTCP Hybla A TCP enhancementfor heterogeneous networksrdquo International Journal of SatelliteCommunications and Networking vol 22 no 5 pp 547ndash5662004
[3] C E Palazzi M Brunati andM Roccetti ldquoAn OpenWRT solu-tion for future wireless homesrdquo in Proceedings of the 2010 IEEEInternational Conference on Multimedia and Expo ICME 2010pp 1701ndash1706 July 2010
[4] D SreeArthi S Malini M J Jude and V C Diniesh ldquoMicrolevel analysis of TCP congestion control algorithm inmulti-hopwireless networksrdquo in Proceedings of the 2017 International Con-ference on Computer Communication and Informatics (ICCCI)pp 1ndash5 January 2017
[5] B-J Chang Y-H Liang and J-Y Jin ldquoAdaptive cross-layer-based TCP congestion control for 4G wireless mobile cloudaccessrdquo in Proceedings of the 3rd IEEE International Conferenceon Consumer Electronics-Taiwan ICCE-TW 2016 pp 1-2 May2016
[6] M Claeys N Bouten D De Vleeschauwer et al ldquoDeadline-aware TCP congestion control for video streaming servicesrdquo inProceedings of the 12th International Conference on Network andService Management pp 100ndash108 November 2016
[7] J Gruen M Karl and T Herfet ldquoNetwork supported conges-tion avoidance in software-defined networksrdquo in Proceedings ofthe 2013 19th IEEE International Conference on Networks ICON2013 p 16 December 2013
[8] A El-Mougy M Ibnkahla G Hattab and W Ejaz ldquoReconfig-urable wireless networksrdquo Proceedings of the IEEE vol 103 no7 pp 1125ndash1158 2015
[9] J-HWang K RenW-G Sun L ZhaoH-S Zhong andK XuldquoEffects of iodinated contrast agents on renal oxygenation leveldetermined by blood oxygenation level dependent magneticresonance imaging in rabbit models of type 1 and type 2 diabeticnephropathyrdquo BMC Nephrology vol 15 no 1 article 140 2014
[10] ldquoGartner Identifies the Top 10 Strategic Technology Trends for2015rdquo 2014 httpwwwgartnercomnewsroomid2867917
[11] P Sun M Yu M J Freedman J Rexford and D WalkerldquoHONE Joint Host-Network Traffic Management in Software-Defined Networksrdquo Journal of Network and Systems Manage-ment vol 23 no 2 pp 374ndash399 2015
[12] Z Ge R Gu andY Ji ldquoAn active queuemanagement adaptationframework for software defined optical networkrdquo in Proceedingsof the 2014 13th International Conference on Optical Communi-cations and Networks ICOCN 2014 p 14 November 2014
[13] L Zhang Q Deng Y Su and Y Hu ldquoA Box-Covering-BasedRouting Algorithm for Large-Scale SDNsrdquo IEEE Access vol 5pp 4048ndash4056 2017
[14] M Ghobadi S H Yeganeh and Y Ganjali ldquoRethinking end-to-end congestion control in software-defined networksrdquo in Pro-ceedings of the 11th ACM Workshop on Hot Topics in NetworksHotNets 2012 pp 61ndash66 October 2012
[15] H Long Y Shen M Guo and F Tang ldquoLABERIO dynamicload-balanced routing in OpenFlow-enabled networksrdquo inProceedings of the IEEE International Conference on AdvancedInformation Networking Applications pp 290ndash297 2013
8 Scientific Programming
[16] L Lu Y Xiao and H Du ldquoOpenFlow control for cooperatingAQM schemerdquo in Proceedings of the 2010 IEEE 10th Interna-tional Conference on Signal Processing ICSP2010 pp 2560ndash2563 October 2010
[17] M Gholami and B Akbari ldquoCongestion control in softwaredefined data center networks through flow reroutingrdquo in Pro-ceedings of the 23rd Iranian Conference on Electrical EngineeringICEE 2015 pp 654ndash657 May 2015
[18] J Hershberger M Maxel and S Suri ldquoFinding the k shortestsimple paths A new algorithm and its implementationrdquo ACMTransactions on Algorithms (TALG) vol 3 no 4 Article ID1290682 2007
[19] N McKeown T Anderson H Balakrishnan et al ldquoOpenFlowenabling innovation in campus networksrdquo Computer Commu-nication Review vol 38 no 2 pp 69ndash74 2008
[20] M-K Shin K-H Nam and H-J Kim ldquoSoftware-definednetworking (SDN) A reference architecture and open APIsrdquo inProceedings of the 2012 International Conference on ICT Con-vergence ldquoGlobal Open Innovation Summit for Smart ICT Con-vergencerdquo ICTC 2012 pp 360-361 October 2012
[21] POX 2017 httpsgithubcomnoxrepo
Submit your manuscripts athttpswwwhindawicom
Computer Games Technology
International Journal of
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Distributed Sensor Networks
International Journal of
Advances in
FuzzySystems
Hindawi Publishing Corporationhttpwwwhindawicom
Volume 2014
International Journal of
ReconfigurableComputing
Hindawi Publishing Corporation httpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 201
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
Artificial Intelligence
HindawithinspPublishingthinspCorporationhttpwwwhindawicom Volumethinsp2014
Advances inSoftware EngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Electrical and Computer Engineering
Journal of
Hindawi Publishing Corporation
httpwwwhindawicom Volume 2014
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Advances in
Hindawi Publishing Corporationhttpwwwhindawicom Volume 201
RoboticsJournal of
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Computational Intelligence and Neuroscience
Industrial EngineeringJournal of
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014
The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Human-ComputerInteraction
Advances in
Computer EngineeringAdvances in
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
8 Scientific Programming
[16] L Lu Y Xiao and H Du ldquoOpenFlow control for cooperatingAQM schemerdquo in Proceedings of the 2010 IEEE 10th Interna-tional Conference on Signal Processing ICSP2010 pp 2560ndash2563 October 2010
[17] M Gholami and B Akbari ldquoCongestion control in softwaredefined data center networks through flow reroutingrdquo in Pro-ceedings of the 23rd Iranian Conference on Electrical EngineeringICEE 2015 pp 654ndash657 May 2015
[18] J Hershberger M Maxel and S Suri ldquoFinding the k shortestsimple paths A new algorithm and its implementationrdquo ACMTransactions on Algorithms (TALG) vol 3 no 4 Article ID1290682 2007
[19] N McKeown T Anderson H Balakrishnan et al ldquoOpenFlowenabling innovation in campus networksrdquo Computer Commu-nication Review vol 38 no 2 pp 69ndash74 2008
[20] M-K Shin K-H Nam and H-J Kim ldquoSoftware-definednetworking (SDN) A reference architecture and open APIsrdquo inProceedings of the 2012 International Conference on ICT Con-vergence ldquoGlobal Open Innovation Summit for Smart ICT Con-vergencerdquo ICTC 2012 pp 360-361 October 2012
[21] POX 2017 httpsgithubcomnoxrepo
Submit your manuscripts athttpswwwhindawicom
Computer Games Technology
International Journal of
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Distributed Sensor Networks
International Journal of
Advances in
FuzzySystems
Hindawi Publishing Corporationhttpwwwhindawicom
Volume 2014
International Journal of
ReconfigurableComputing
Hindawi Publishing Corporation httpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 201
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
Artificial Intelligence
HindawithinspPublishingthinspCorporationhttpwwwhindawicom Volumethinsp2014
Advances inSoftware EngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Electrical and Computer Engineering
Journal of
Hindawi Publishing Corporation
httpwwwhindawicom Volume 2014
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Advances in
Hindawi Publishing Corporationhttpwwwhindawicom Volume 201
RoboticsJournal of
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Computational Intelligence and Neuroscience
Industrial EngineeringJournal of
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014
The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Human-ComputerInteraction
Advances in
Computer EngineeringAdvances in
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Submit your manuscripts athttpswwwhindawicom
Computer Games Technology
International Journal of
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Distributed Sensor Networks
International Journal of
Advances in
FuzzySystems
Hindawi Publishing Corporationhttpwwwhindawicom
Volume 2014
International Journal of
ReconfigurableComputing
Hindawi Publishing Corporation httpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 201
Applied Computational Intelligence and Soft Computing
thinspAdvancesthinspinthinsp
Artificial Intelligence
HindawithinspPublishingthinspCorporationhttpwwwhindawicom Volumethinsp2014
Advances inSoftware EngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Electrical and Computer Engineering
Journal of
Hindawi Publishing Corporation
httpwwwhindawicom Volume 2014
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Advances in
Hindawi Publishing Corporationhttpwwwhindawicom Volume 201
RoboticsJournal of
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Computational Intelligence and Neuroscience
Industrial EngineeringJournal of
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014
The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
Human-ComputerInteraction
Advances in
Computer EngineeringAdvances in
Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014
