Evaluation of TCP and UDP Traffic over Software-Defined Networking
May Thae Naing, Thiri Thitsar Khaing, Aung Htein Maw
University of Information Technology, Yangon, Myanmar
maythae@uit.edu.mm, thirithitsarkhaing@uit.edu.mm, ahmaw@uit.edu.mm
Abstract
In Software-Defined Networking (SDN), the decoupling of
control and data planes brings advantages in terms of
logically centralized control and application
programming. This paper presents an analysis of the SDN
traffic flow based on the transmission control protocol
(TCP) and the user datagram protocol (UDP) generated
from source host to the destination host over SDN
infrastructure. For system evaluation, the Mininet
Emulator is used to build the SDN infrastructure, the
Network Performance Measurement Tool (iPerf) to
generate the traffic according to the specified command-
line options, and the Wireshark packet analyzer analyzes
the protocol especially TCP and UDP. The analysis
shows throughput and packet loss in three network
topologies: single, linear, and custom tree topology.
According to the evaluation results, the throughput of
TCP falls off dramatically during the retransmission
sequence. In the evaluation of UDP traffic, the single
topology can handle the packet loss, the linear topology
can take place 10 ~ 30 % packet loss and the custom tree
topology can only occur a negligible amount of packet
loss in two testing environments.
Key Words- Software Defined Networking (SDN),
SDN Components, SDN Controller, TCP, UDP
1. Introduction
Software-Defined Networking (SDN) is used to
enhance network orchestration and management through
the separation of the control plane and data plane. SDN
serves a smart way of looking at how networks are
configured, controlled, and operated, and is also be
promised to simplify network management, decrease
network resource utilization, reduce operational costs, and
stimulate innovation of network evolution and new
network services [1].
For the basic concept, SDN separate control plane and
data plane entities. SDN promised to get network
intelligence and state are logically centralized. The
underlying network infrastructure is abstracted from the
applications.
Software-defined networking provides many
components, such as network controller providing high-
level management API (ONOS, POX, RYU) providing
7
virtual switches on the hypervisor (OpenVSwitch), as
well as, overlay protocols connecting the virtual switches
(VXLAN, VMware NSX, …) also supporting physical
switches (OpenFlow protocol). And then, the virtual
machine’s connected to the data Plane and managed via
Network Controller providing high-level services like
firewall, load balancing, VPN, intrusion detection.
SDN controller is the centralized repository of policy
and control directions for the application or network
infrastructure. The controller performs a programmatic
interface (also called a northbound interface) for
introducing policies and provisioning services over the
network. To overcome the burden of managing the
network, the controller interprets business policy directly
into network device-level policy. There is also an open
communication protocol between the controller and the
infrastructure nodes (sometimes called a southbound
interface or protocol).
Both TCP and UDP give for logical communication
among application processes running on different hosts.
These protocols are used for sending bits of data also
known as packets over the network. Because transmission
control protocol (TCP) is a connection-oriented
communications protocol using the three-way handshake
to establish a connection, and a four-way handshake for
connection termination., it ensures a connection is
established and keep until the exchange between sending
and receiving message is complete. UDP is considered a
connectionless protocol because it doesn’t require a three-
way handshake to be established before any data transfer
occurs.
The rest of the paper is as follows: the related work is
described in section 2. The experimental setup is
presented in section 3. The evaluation results of TCP and
UDP traffic is discussed in section 4. Finally, this paper is
concluded in section 5.
2. Related Work
Many species of investigation have been presented to
manipulate and optimize TCP and UDP Traffic with
SDN. In paper [2], two analytical models are produced for
deciding the performance of TCP and UDP flows over
SDN. The simulation issues prove that TCP significantly
outperforms UDP in SDN networks. The work of [3]
suggests reliable transmission framework schemes topologies are available today, such as single topology,
provide applications and this scheme analyzed packet linear topology, bus topology, tree topology, and star
format transformations, packet buffering, and topology.
retransmission mechanisms on switches. Analyzing TCP and UDP traffic are used the three
Diyar et al [4] observed the traffic and measured the different topologies to determine the performance of the
network traffic statistics from network devices in the SDN infrastructure. Testing and evaluation of topologies
SDN. To obtain traffic statistics offered a mechanism by are as follows:
using OpenFlow characteristics and investigated the effect Firstly, the single topology described in figure 1,
of the querying frequency on the information accurate and consists of 12 hosts (h1, h2, h3, …, h12), 1 OpenFlow
network load. In paper [5], the authors presented that switch (s1), and an OpenFlow SDN controller (c0)
maximum throughput and minimum delay to achieve for controlling the switch. To create a single topology, we use
the non-saturated case. the command “mn --topo single,12 --mac --switch ovsk --
Al-Somaidai et al [6] reviewed five different versions controller remote,ip=127.0.0.1” as in figure 1.
of OpenFlow switch standard including 1.0 to 1.4, four
different platforms for simulation and emulation of SDN
containing Mininet, EstiNet, NS-3 and Trema, seven
brands of controllers including NOX, POX, Beacon, Ryu,
Mul, Floodlight, OpenDaylight, and also various switch
software and tools. They discussed floodlight and
OpenDaylight as the controllers with good documentation
and adaptability.
Orebaugh et al [7] introduced the network analysis and
provided an understanding of Wireshark and its features
and also supported troubleshooting over network
architecture. Wang et al [8] introduced the characteristics
and functions of Wireshark, and explained the analysis of
Wireshark and described the various applications in the
TCP/IP protocol by some specific examples.

3. Experimental Setup
Figure 1. Single Topology
The experimental setup for the evaluation of traffic
analysis is using the specifications shown in Table 1. Secondly, the linear topology illustrated in figure 2,
consists of 12 hosts (h1, h2, h3, …, h12), 12 OpenFlow
Table 1. Experiment Specifications switches (s1, s2, s3, …, s12), and an OpenFlow SDN
controller (c0) controlling every switch. The command
“mn --topo linear,12 --mac --switch ovsk --controller
Type Description
remote,ip=127.0.0.1” in figure 2 create the linear
Laptop (Physical Intel(R) Core (TM) i5-5200U CPU topology.
Machine) @ 2.20GHz 2.19GHz with
Microsoft Windows 8.1 Pro 64bits
OS, HP Laptop PC and 12 GB
memory.
VirtualBox (Virtual Oracle VirtualBox 6.0 hypervisor
Machine on Laptop) software (Ubuntu 16.04, 8 GB
RAM, 64bits OS).
Mininet [9] To emulate virtual SDN networks.
ONOS Controller [10] Java-based controller running on
controller port 6633.
OpenFlow Protocol Communication interface:
[11] between the control and data
plane of an SDN architecture.

This environment analyzes the traffic pattern

especially TCP and UDP traffic for the different network
topologies by using the emulated testbed (Mininet
emulator with ONOS controller). Many standard Figure 2. Linear Topology

8
 Finally, the custom tree topology exhibited in figure 3, over Mininet and save it into the PCAP file to evaluate
consists of 12 hosts (h1, h2, h3, … h12), five OpenFlow the difference between TCP and UDP traffic.
switches (s1, s2, s3, s4, s5), and an OpenFlow SDN
controller (c0) controlling every switch. The custom Table 2. Parameter Value
topology is provided with 5 switches and 12 hosts by
Parameter Test I Test II
running “topo-5sw-12hosts.py” script in the Mininet
terminal. Payload 100 M Bytes 100 M Bytes
Window Size (TCP) 85.3 Kbytes 85.3 Kbytes
Window Size (UDP) 208 Kbytes 208 Kbytes
Interval 1 second 1 second
Time 20 seconds 30 seconds

4. Evaluation Results of TCP and UDP

Figure 3. Custom Tree Topology
3.1. Traffic Generation
Traffic is generated using an iPerf command line tool
[12]. IPerf is a widely used tool for network performance
measurement. It is utilized in TCP or UDP connections,
through the modulation of various parameters. It must be
configured on both clients and servers, then it must be
started as a server on one node, and as a client on the
other one. To analyze the traffic, iPerf TCP and UDP
clients are parallel requested to the iPerf TCP and UDP
servers.
Traffics
This section evaluates the simulation results by
analyzing the TCP vs UDP traffic from Wireshark
capturing traffic PCAP file and iPerf results. Figure 4
presents the logical connection between iPerf clients and
servers with defining the port number. To get better
outcomes of analyzing TCP and UDP traffic flow, this
experiment used the multiple iPerf scripts as presented in
figure 5. These scripts provided the simultaneous request
and reply connections for both iPerf servers and iPerf
clients. Table 3 describes the shell script file for the iPerf
TCP server (10.0.0.1). Table 4 presents the shell script
file for the iPerf TCP client (10.0.0.7). Figure 6 shows the
results retrieved from the PCAP file for the single
topology (Test I) to analyze the TCP and UDP traffic.
Wireshark protocol analyzer captures the simultaneous
traffic generated from each topology using iPerf
command-line tool and then it saves to the PCAP file for
each testing.

3.2. Traffic Parameter Settings

The experiment testbed is based on the different

parameters for three different topologies (see in Figures 1,
2, and 3). Table 2 describes the parameter settings for two Figure 4. Logical connections between clients
testing. In this test, this parameter used to generate the and servers
TCP and UDP traffic while analyzing throughput and
packet loss.

3.3. Traffic Analyzing

Traffic is analyzed using Wireshark to capture packets

in real-time and is the world’s foremost and widespread
use network protocol analyzer [13]. Wireshark is captured
TCP and UDP traffic generated from single topology,
linear topology, and custom tree topology by using iPerf
Figure 5. Shell script files for the iPerf parallel
command-line tool. Wireshark is monitoring all traffic
connections

9
 Table 3. Shell script file for the iperf-server1 Table 4. Shell script file for the iperf-client1
(10.0.0.1) (10.0.0.7)

#!/bin/bash #!/bin/bash

… …

base_port=6000 base_port=6000

… …

# Run iperf # Run iperf

iperf -s -p $server_port $iperf_options &> $report_file & iperf -c $server_ip -p $server_port -t $test_duration
$iperf_options &> $report_file &
done
done

Figure 6. Wireshark Capturing Results for Single Topology (Test I)

4.1. Throughput client nodes. It is usually measured in bits per second

(bit/s), and sometimes in data packets per second (p/s) or
Throughput is described as the number of bytes data packets per time slot. Furthermore, the following
transferred per second from server nodes to all concurrent equation is used to calculate the throughput.

10
 𝑇ℎ𝑟𝑜𝑢𝑔ℎ𝑝𝑢𝑡 = 𝑊𝑖𝑛𝑑𝑜𝑤 𝑆𝑖𝑧𝑒 ∗ 𝑅𝑇𝑇 (1) 4.2. Packet Loss

where, the window size is the packet size of TCP and
UDP traffic, and round-trip time (RTT) is the amount of
time for a packet to travel from source to destination and
then back to the source.
After the two testings, the default TCP buffer length is
85.3 Kbytes and the UDP buffer length is 208 Kbytes.
According to the packet size, the throughput of both TCP
and UDP traffic is described for three different network
topologies which simulation results as shown in figure 7.
The throughput fell off dramatically during the retransmit
sequence. By analyzing the simulation results, throughput
is changing depending on different payload sizes with a
time interval for both traffic flow.
The packet cannot arrive at the destination due to
including timeout errors and traffic congestions. In this
section, packet loss of both TCP and UDP traffic is
discussed for three different network topologies, which
evaluation results as shown in figure 8. Also, the
following formula is used to determine the packet loss.
𝑃𝑎𝑐𝑘𝑒𝑡 𝐿𝑜𝑠𝑠 = 𝛴 𝑃𝑠𝑒𝑛𝑡 - 𝑃𝑟𝑒𝑐𝑒𝑖𝑣𝑒 (2)
Notably, 𝑃𝑠𝑒𝑛𝑡 stands for the total number of the
transmitted packets and 𝑃𝑟𝑒𝑐𝑒𝑖𝑣𝑒 stands for the total
number of received packets.
TCP must surely for no packet loss because TCP is a
connection-oriented and reliable data transfer protocol.
According to the evaluation results, as shown in Table 5,
some UDP traffic has the datagram out of order.
However, the single topology didn't occur the datagram
out of order, the linear topology is increased in datagram
out of analyzes, and also the custom tree topology has
some packet loss.

TCP TCP
UDP UDP

(a) (b)

TCP TCP
UDP UDP

(c) (d)

TCP TCP
UDP UDP

(e) (f)
Figure 7. Comparison of Throughput (a) Test I single topology, (b) Test II single topology, (c) Test I
linear topology, (d) Test II linear topology, and, (e) Test I custom tree topology, (f) Test II custom tree
topology

11
Table 5. Comparison of UDP Packet Loss (Clients is sending parallel UDP Packets for 20 seconds and
30 seconds testing with every interval 1 second)

Custom Custom
Single Linear Single Linear
Tree Tree
Topology Topology Topology Topology
Packet Loss Topology Topology
(20 sec) (20 sec) (30 sec) (30 sec)
(clients connect to (20 sec) (30 sec)
servers with UDP) UDP UDP UDP UDP UDP UDP

Lost/Total Lost/Total Lost/Total Lost/Total Lost/Total Lost/Total

Server 4 <==> Client 4 0/178 13/ 178 1/178 0/267 57/267 0/267

Server 5 <==> Client 5 0/178 9/ 178 0/178 0/267 68/267 0/267

Server 6 <==> Client 6 0/178 1/ 178 1/178 0/267 108/267 0/267

5. Conclusion
This paper mainly focuses on TCP vs UDP traffic
flows over SDN architecture. The emulation results
obtained from the TCP and UDP traffic flows for three
different topologies with different parameter settings. It is
also monitoring the traffic flow scenario (i.e. how the
packet flows from source host to the destination host) by
capturing from the Wireshark network protocol analyzer
generated from iPerf while analyzing throughput and
packet loss. According to the evaluation results, the
throughput of TCP falls off dramatically during the
retransmission sequence. It has also been observed that
throughput is changing according to varying the packet
size (payload size) with a different buffer size of TCP and
UDP traffic.
In future work, we will further investigate to provide
the performance of the traffic flows to handle the different
traffic load based on the traffic flow pattern especially
TCP and UDP traffic to provide availability and
reliability.
6. References
[1] B. Underdahl, G. Kinghorn, Software Defined
Networking For Dummies, Cisco Special Edition, John
Wiley & Sons, Inc., Hoboken, New Jersey, 2015.
[2] Lai, Y.-C., Ali, A., Hossain, M.S., Lin, Y.-D.
Performance modeling and analysis of TCP and UDP
flows over software-defined networks. J. Netw. Comput.
Appl. 130, 76–88, 2019.
[3] Wang, M.H., Chen, L.W., Chi, P.W. and Lei, C.L.
SDUDP: A reliable UDP-based transmission protocol
over SDN. IEEE Access, 5, pp.5904-5916, 2017.
[4] Diyar, H.J, Khirota, Y.G, Okumus, I.T. Getting traffic
statistics from network devices in an SDN environment
using OpenFlow. Information Technology and Systems.
Sep:951-6, 2015.
[5] Umeh, O.A., Akpado, K.A., Okechukwu, G.N.,
Ejiofor, H.C. Throughput and delay analysis in a real-time
network. Int. J. Eng. Appl. Sci. (IJEAS), 2, 27–34, 2015.
[6] Al-Somaidai MB, Yahya EB. Survey of software
components to emulate OpenFlow protocol as an SDN
implementation. American Journal of Software
Engineering and Applications; 3(6):74-82, Dec 2014.
[7] Orebaugh A, Ramirez G, Beale J. Wireshark &
Ethereal network protocol analyzer toolkit. Elsevier; 18-
Dec-2006.
[8] Wang S, Xu D, Yan S. Analysis and application of
Wireshark in TCP/IP protocol teaching. In2010
International Conference on E-Health Networking Digital
Ecosystems and Technologies (EDT), Vol. 2, pp. 269-
272, IEEE, 17-April-2010.
[9] Mininet Network Emulator, http://mininet.org.
[10] ONOS Controller, http://www.onosproject.org.
[11] OpenFlow Switch Specification, version 1.3.5,
https://www.opennetworking.org/, 26-March-2015.
[12] IPerf, https://www.iperf.fr/.
[13] Wireshark, https://www.wireshark.org/.

12