See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/304287577

Experimental performance comparison between TCP vs UDP tunnel using

OpenVPN

Conference Paper · December 2015

DOI: 10.1109/CCCS.2015.7374133

CITATIONS READS
6 312

3 authors, including:

Irfaan Coonjah K.M.s. Soyjaudah

University of Mauritius University of Mauritius
6 PUBLICATIONS   8 CITATIONS    175 PUBLICATIONS   333 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Keystroke View project

All content following this page was uploaded by Irfaan Coonjah on 28 August 2018.

The user has requested enhancement of the downloaded file.

 Experimental Performance Comparison between
TCP vs UDP tunnel using OpenVPN
Irfaan Coonjah Pierre Clarel Catherine
Faculty of Engineering School of Innovative Technologies and Engineering
University of Mauritius University of technology, Mauritius
Réduit, Mauritius La Tour Koenig, Pointes aux Sables
irfaan.coonjah@umail.uom.ac.mu ccatherine@umail.utm.ac.mu
Abstract—The comparison between TCP and UDP tunnels
have not been sufficiently reported in the scientific literature.
In this work, we use OpenVPN as a platform to demonstrate the
performance between TCP/UDP. The de facto belief has been
that TCP tunnel provides a permanent tunnel and therefore
ensures a reliable transfer of data between two end points.
However the effects of transmitting TCP within a UDP tunnel
has been explored and could provide a valuable attempt. The
results provided in this paper demonstrates that indeed TCP in
UDP tunnel provides better latency. Throughout this paper, a
series of tests have been performed, UDP traffic was sent inside
UDP tunnel and TCP tunnel successively. The same tests was
performed using TCP traffic.
I. I NTRODUCTION
An IP tunnel [1] is an Internet Protocol (IP) network
communications channel between two networks. It is used to
transport another network protocol through encapsulation. It
does so by encapsulating its own network protocol within the
TCP/IP packets carried by the Internet. IP tunnels are used
to connect two separate IP networks that are not directly
connected to each other. Tunneling protocol allows a user
to access a network service which the underlying network
does not support. Tunneling [2] can hide the nature of the
traffic that is run through the tunnel, using encryption standard
to repackage traffic data into a different form. The tunnel-
ing protocol works by using the data portion of a packet
(the payload) to carry the packets that provide the service,
making use of a layered protocol model such as those of
the Open Systems Interconnection model (OSI) or TCP/IP
protocol suite. Tunneling is used in all VPNs; one common
open source application layer solution available is OpenVPN
(Open Virtual Private Network). The popularity of VPNs has
increased due to its low cost and the security it provides. The
trade-offs between TCP and UDP regardless of VPN usage is
always said to be the same: Speed is sacrifice for reliability
as UDP is connectionless and the server sending the data
theoretically does not ensure if it reaches the destination or
not. UDP is claimed to be faster but TCP is meant to be
more reliable. This paper focuses on such comparison and
evaluates the efficiency between UDP tunnel and TCP tunnel
using OpenVPN. Throughout this paper, a series of tests have
been performed, UDP traffic was sent inside UDP tunnel and
TCP tunnel successively. The same tests was performed using
K. M. S. Soyjaudah
Faculty of Engineering
University of Mauritius
Réduit, Mauritius
ssoyjaudah@uom.ac.mu
TCP traffic.
This document is organized into the following sections:
• Section II covers Virtual Private Network, with different
layers in the OSI model.
• Section III covers Transmission Control Protocol, TCP
tunnel.
• Section IV covers User Datagram Protocol, UDP tunnel.
• Section V makes a comparison between TCP and UDP.
• Section VI details the experimental testing.
• Section VII describes the Physical framework.
• Section VIII details the performance measures.
• We then conclude by giving the results and observations
in section IX.
II. V IRTUAL P RIVATE N ETWORK (VPN)
A virtual private network (VPN) [3] makes use of a public
network to connect multiple remote locations. A VPN expands
a private network using a public network, such as the In-
ternet by establishing a point-to-point connection and virtual
tunneling protocols. It allows a computer to communicate
across public networks as if it is plugged directly to the
private network. A VPN is a logical network on top of an
already existing network. Different VPN solutions work on
different layers in the Open System Interconnect (OSI) model
[4]. In the tunnels, the traffic is encrypted and sent through
using the lower layers in the OSI model. The VPN traffic
is split up from any other network traffic by using encrypted
tunnels between the VPN hosts. Inside a tunnel, the forwarded
traffic is encapsulated into a special packet format on which
a block cipher is used to encrypt the traffic [5]. As mentioned
in the previous paragraph, a VPN can work on different
layers of the OSI model. Three common types of VPNs are
Application Layer VPNs, Network Layer VPNs and Datalink
Layer VPNs. Secure Shell (SSH), Secure Sockets Layer (SSL),
and OpenVPN are VPNs that work on the Application layer
of the OSI model [6]. The tunneled traffic is encapsulated into
application specific headers before being sent to the other side
using the available Transport Layer Protocol [7], such as User
Datagram Protocol (UDP) or Transmission Control Protocol
(TCP).
 III. T RANSMISSION C ONTROL P ROTOCOL (TCP)
Transmission Control Protocol/Internet Protocol (TCP/IP) is
the language with which computers communicate [8]. TCP/IP
is a protocol which determines how two computers address
each other and transfer data to each other. TCP is a connection
oriented protocol [9] which means that a logical connection is
established between two devices before transferring data. This
is achieved by following a specific set of rules that specify
how a connection should be initiated, negotiated, managed
and eventually terminated. TCP/IP therefore makes use of
extensive algorithms to ensure reliable delivery of packets
with the use of 5 acknowledgments messages. TCP sender
maintains a copy of all transmitted data until the receiver
has completed an accurate transfer of the data. TCP drivers
break up data stream into discrete segments, and attach a TCP
header to each segment before the packet is transferred for
delivery [10]. TCP protocol suite feature automatic recovery
from any dropped or lost data. This protocol must be able
to recover from an outage of any host on any part of the
network and at any point in a data transfer [10]. When
TCP packets are transmitted from one end to a remote end
across the network, the data packets are reordered in the same
sequence it was generated by the sender. The protocol detects
when segments of the data stream have been discarded by the
network, reordered, duplicated, or corrupted. The sender can
even retransmit damaged segments. This process makes TCP a
reliable protocol. The retransmission problems, TCP meltdown
and double retransmit, are problems caused by tunneling TCP
in TCP. The problems can occur when both of the stacked
connections are retransmitting packets [11]. In previous work,
related to TCP in TCP tunneling, it is not entirely clear, how
severe the retransmission problems really are. In this paper
however the double retransmission will be explored in details.
IV. U SER DATAGRAM P ROTOCOL (UDP)
UDP (User Datagram Protocol) [12] is a communication
protocol with a limited amount of service when messages
are exchanged between computers in a network that uses the
Internet Protocol (IP). UDP does not provide sequencing of
data packets which means that the application program that
uses UDP must make sure that the entire message has arrived
and is in the right order. UDP uses a simple connectionless
transmission model with a minimum of protocol mechanism
which means that UDP do not establish a connection between
devices [13]. As soon as a device has data to send to another, it
just sends it. It has no handshaking dialogues, and thus exposes
any unreliability of the underlying network protocol to the
user’s program. There is no guarantee of delivery, ordering,
or duplicate protection. UDP provides checksums for data
integrity.
UDP is best suitable where error checking and correction
is not necessary, there is low processing overhead at the net-
work interface level [14]. Time-sensitive applications use UDP
because dropping packets is preferable compared to delayed
packets, which may not be suitable in a real-time system. If
error correction facilities are needed at the network interface
level, an application may use the Transmission Control Pro-
tocol (TCP) or Stream Control Transmission Protocol (SCTP)
which are designed for this purpose. Lacking reliability, UDP
applications must generally be willing to accept some loss,
errors or duplication. Streaming media, real-time multiplayer
games and voice over IP (VoIP) are examples of applications
that make use UDP. In these applications, packet loss is not
always a fatal problem. Voice and video traffic is transmitted
using UDP, real-time video and audio streaming protocols
can have occasional packet lost, so only slight degradation
in quality occurs, rather than large delays if the lost packets
has to be retransmitted.
V. C OMPARISON BETWEEN TCP AND UDP
The adjustments between TCP and UDP regardless of VPN
usage is always said to be the same: Speed is sacrifice for
reliability as UDP is connectionless and the server sending the
data theoretically does not ensure if it reaches the destination
or not.TCP is a connection-oriented protocol [15], which
means that the end-to-end communications is set up using
handshaking. Once the connection is set up, user data may be
sent bi-directionally over the connection. Compared to TCP,
UDP is a simpler message based connectionless protocol [13],
which means that the end-to-end connection is not dedicated
and information is transmitted in one direction from the
source to its destination without verifying the readiness or
state of the receiver. TCP controls message acknowledgment,
retransmission and timeout [11]. TCP makes multiple attempts
to deliver messages that get lost along the way, In TCP
therefore, there is no missing data, and if ever there are
multiple timeouts, the connection is dropped. When a UDP
message is sent there is no guarantee that the message will
reach its destination; it could get lost along the way. There
is no acknowledgment, retransmission, or timeout. If two
messages are sent in sequence, the first message will reach
the destination first. When data segments arrive in the wrong
order, TCP buffers delay data until all data can be re-ordered
before being delivered; when using UDP the order in which
messages arrive cannot be predicted.
The TCP protocol has extensive algorithms to ensure correct
delivery of the data. Having two TCP connections stacked
together will thus force the algorithms of both TCP con-
nections to work in parallel [16]. TCP was not designed to
work this way and problems are likely to occur in different
situations. The retransmission problems, TCP meltdown and
double retransmit, are problems caused by tunneling TCP
in TCP. The problems can occur when both of the stacked
connections are retransmitting packets. In previous work,
related to TCP in TCP tunneling, it is not entirely clear, how
severe the retransmission problems really are. TCP protocol
suite featured automatic recovery from any dropped or lost
data. This protocol must be able to recover from an outage
of any host on any part of the network and at any point in
a data transfer. When TCP packets are transmitted from one
end to a remote end across the network, the data packets are
reordered in the same sequence generated by the sender. The
protocol detects when segments of the data stream have been
discarded by the network, reordered, duplicated, or corrupted.
The sender can even retransmit damaged segments [11]. This
process makes TCP a reliable protocol. However, the double
retransmission creates latency.
The design of TCP was to make an efficient protocol with
low overhead, a protocol suite that had a minimal amount of
’extra’ data being transferred. This extra data called overhead,
functions as packaging for the data being transferred and
enables the data transmission. TCP tunnel is a technology
that aggregates and transfers packets sent between end hosts
as a single TCP connection. By using a TCP tunnel, the
fairness among aggregated flows can be improved and several
protocols can be transparently transmitted through a firewall.
Currently, many applications such as Secure Shell (SSH),
Virtual Tunnels (VTun), and Http Tunnel (HTun) use a TCP
tunnel. However, since most applications running on end hosts
generally use TCP, two TCP congestion controls (i.e. end-to-
end TCP and tunnel TCP) operate simultaneously and interfere
each other. Under certain conditions, using a TCP tunnel
severely degrades the end-to-end TCP performance. More
specifically it is known that using a TCP tunnel drastically
degrades the end-to-end TCP throughput for some time [17].
This is called TCP meltdown problem.
VI. E XPERIMENTAL TESTING
The experimental testing procedure consists of four parts
in the evaluation of latency. Two tunnels will be created,
TCP tunnel and UDP tunnel using OpenVPN as base. In the
TCP tunnel, TCP traffic will be sent and the latency will be
recorded in seconds. Then UDP traffic will be sent in the TCP
tunnel and the same value will be recorded. The same test
will be performed but using UDP tunnel. All measurements
will take place at the server node because of its processing
power. The tests will be performed through a Local Area
Network and Wide Area Network environment successively.
The compression for OpenVPN will be disabled since it is
not part of the tests. During the measurements, the size of
packets will be increased and two different graphs will be
plotted with axes; latency of the VPN tunnel vs size of packets.
Iperf will be used for monitoring latency. Iperf, is the network
testing tool that will be used to measure the parameters during
the experiments. Since iperf can generate TCP and UDP data
streams, this make iperf suitable for this test. Iperf is also
flexible and allows the user to set various parameters that
can be used in the test or alternatively optimize or tuning the
network. Iperf has a client and server functionality, and can
therefore measure the throughput between the two ends, either
unidirectionally or bi-directionally.
VII. E XPERIMENTAL FRAMEWORK DESCRIPTION
In this paper, the authors took into consideration the physi-
cal topology layout, setting up a complete topology by using
two computers, switch and router. The setup is identical to a
real live scenario and is expected to give more accurate values
for the performance evaluation and analysis between TCP and
UDP tunnel based on OpenVPN. The open source VPN soft-
ware, OpenVPN has been the choice for many companies and
according to technical discussions, VPN technologies using
UDP tunnel as base are predicted to provide fast speeds when
compared to using OpenVPN using TCP as base. OpenVPN
is usually slower than other protocols when used via TCP,
although TCP offers advantages in restricted networks. When
compared to stability, TCP is prognosticated to be a very
stable protocol on all kinds of connection (WLAN, wired,
mobile) and UDP is deemed to be unstable, susceptible to
disconnect with short network issues. Compression is a built-
in feature in OpenVPN and it has not been tested yet whether
compression has an impact on transfer time due to processing
power in CPU. In this experiment therefore, compression has
been disabled.
The server is connected to the switch via an Ethernet
cable and physical ip address of 10.1.24.19/24. The client is
connected to another port on the switch and has IP address
10.1.100.21/24. The switch is connected to the router, which
has the gateway IP address for the network. The server and
the client are in two different subnets, therefore they cannot
communicate making use of their physical IP address. A VPN
will be setup between the client and the server, and two
computers will have a logical IP address on the same subnet
and can then communicate with each other. The setup will
be used for measuring latency in the LAN, but for measuring
traffic in the WAN; the router will be connected to the internet
and have port-forwarding configured, and the client will be
on a remote network with internet access. The client will
therefore access the private network through port-forwarding
and OpenVPN.
VIII. PERFORMANCE MEASURES
This section provides a comparative view of the conducted
results. Also, the authors attempt to provide a better
explanation of the experiment results. But before that, the
important characteristics of the LAN that may affect the
performance of the connection must be discussed. The switch
is configured on a 10Mbps duplex setting. The maximum file
size has therefore been limited to 10Mbps for this test. All
network metrics for the tunnels are remarkably concentrated.
Standard deviation values rendered in both graphs confirm
this remark. Tunneling performance is measured using a set
of criteria or metrics. The latency is used to characterize
the performance of both tunnels. Latency is an expression
of how much time it takes for a packet of data to get from
one designated point to another. Latency through a tunnel is
dependent on the machine hardware, the link speed, and the
encapsulation time.

The snapshot below shows how the tests are performed on

iperf and how the values have being recorded.
C:\iperf-2.0.5-2-win32>iperf.exe -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[ 4] local 172.16.1.1 port 5001 connected with 172.16.1.6 port 65410
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.1 sec 21.6 MBytes 17.9 Mbits/sec

Fig. 2. Latency comparison between UDP and TCP inside a UDP tunnel

Fig. 1. Latency comparison between UDP and TCP inside a TCP tunnel
Figure 1 demonstrates the latency comparison between UDP
and TCP inside a TCP tunnel in a LAN environment, measured
in seconds and packet size in megabyte. The UDP tunnel gives
increased transfer speed compared to TCP tunnel when the
packet size increases. The latency gap in UDP tunnel becomes
wider when the packet size increases from 4Mb to 10Mb. This
can be explained with the fact that when the VPN uses TCP
tunnel, TCP connections will use IP packets sent through the
VPN, therefore creating the TCP overhead twice. The UDP
tunnel base VPN thus has the potential for slightly better
performance. TCP provides a bidirectional tunnel for data,
but relies on packets, so there will be some ”administrative”
packets, e.g. acknowledges: this is the TCP overhead. For
instance, if the server A sends 10 MB to the client B, client
B will also send some packets to A confirming reception.
When doing VPN over TCP, the VPN has its own TCP-based
overhead, and transports the administrative packets for any
connection within the VPN. The graph therefore confirm the
TCP stacking problem when transmitting TCP traffic over TCP
Fig. 3. Latency comparison between UDP and TCP inside a TCP tunnel in
WAN environment
tunnel. The TCP stacking starts when the message size reaches
2 MB, since the difference in latency before 2MB is very small
when compared to the latency gap after 2MB. On the other
hand, figure 2 shows the latency comparison between UDP
and TCP when using a UDP tunnel in a LAN environment.
When using UDP tunnel, we do not have the double stacking
problem. Compared to figure 1, the latency is smaller for
both TCP and UDP traffic. It was said that encryption, slow
down UDP traffic since when bits of data is missing the
entire message may need to be re-sent again, causing latency.
During the tests, it is shown that, UDP message is not affected
by encryption mechanism when the size is between 1MB to
10MB. Sending TCP traffic inside a TCP tunnel does not
create the double TCP stacking problem, this is proved in
figure 2. When we compare the two graphs for example, the
time taken to transmit a TCP message size of 2MB is twice

Fig. 4. Latency comparison between UDP and TCP inside a UDP tunnel in
WAN environment
when using TCP tunnel; the latency in TCP tunnel is around
10 seconds whereas in UDP tunnel, the latency is around 5
seconds. Figure 3 is a replication of the test perform in figure
1, that is, latency comparison between UDP and TCP inside a
TCP tunnel in a WAN environment. The latency gap increases
proportionally when the message size increases. The pattern is
similar to figure 1, except that the latency is higher. The test
in figure 4 has been performed in a WAN environment, that
is latency comparison between UDP and TCP inside a UDP
tunnel in a WAN environment. In a WAN environment, the
latency graphs for both TCP and UDP are two straight lines
and the difference in latency is constant.
IX. C ONCLUSION
This paper addresses performance comparison between TCP
and UDP tunnel connections. Two distinct scenarios were
used to test the two VPN tunneling mechanisms. The results
disclose that UDP tunnel utilizes the link better and thus
provides radically improved transfer times and speed when
compared with TCP tunnel. The results also demonstrates that
indeed TCP in UDP tunnel provides better latency.
As future work it would be good to expand this study by
investigating the performance of the tunnels on Mobile net-
work. OpenVPN can be installed on mobile devices, therefore
another direction is to test the VPN on mobile device, and
detect how much energy is required for this sort of secure
connections, as mobile devices cannot afford batteries with
unlimited capacity.
R EFERENCES
[1] S. Zhou and J. Luo, “A novel ip over udp tunneling based firewall traver-
sal for peer-to-peer networks,” in Service Operations and Logistics, and
Informatics (SOLI), 2013 IEEE International Conference on, pp. 382–
386, July 2013.
View publication stats
[2] P. Rawat, J. Bonnin, and L. Toutain, “Designing a tunneling header
compression (tucp) for tunneling over ip,” in Wireless Communication
Systems. 2008. ISWCS ’08. IEEE International Symposium on, pp. 273–
278, Oct 2008.
[3] R. Bush and T. Griffin, “Integrity for virtual private routed networks,” in
INFOCOM 2003. Twenty-Second Annual Joint Conference of the IEEE
Computer and Communications. IEEE Societies, vol. 2, pp. 1467–1476
vol.2, March 2003.
[4] Y. Li, W. Cui, D. Li, and R. Zhang, “Research based on osi model,”
in Communication Software and Networks (ICCSN), 2011 IEEE 3rd
International Conference on, pp. 554–557, May 2011.
[5] A. Mayer, B. Collini-Nocker, F. Vieira, J. Lei, and M. Castro, “Analytical
and experimental ip encapsulation efficiency comparison of gse, mpe,
and ule over dvb-s2,” in Satellite and Space Communications, 2007.
IWSSC ’07. International Workshop on, pp. 114–118, Sept 2007.
[6] M. Mimura and H. Tanaka, “Behavior shaver: An application based
layer 3 vpn that conceals traffic patterns using sctp,” in Broadband,
Wireless Computing, Communication and Applications (BWCCA), 2010
International Conference on, pp. 666–671, Nov 2010.
[7] D. Sarkar and H. Narayan, “Transport layer protocols for cognitive net-
works,” in INFOCOM IEEE Conference on Computer Communications
Workshops , 2010, pp. 1–6, March 2010.
[8] I.-S. Yoon, S.-H. Chung, and J.-S. Kim, “Implementation of lightweight
tcp/ip for small, wireless embedded systems,” in Advanced Information
Networking and Applications, 2009. AINA ’09. International Conference
on, pp. 965–970, May 2009.
[9] N. Morita, I. Inoue, M. Mito, and T. Akaike, “Service specific connection
oriented protocol for the atm adaptation layer,” in Network Protocols,
1993. Proceedings., 1993 International Conference on, pp. 128–135, Oct
1993.
[10] Y.-T. Li, D. Leith, and R. Shorten, “Experimental evaluation of tcp pro-
tocols for high-speed networks,” Networking, IEEE/ACM Transactions
on, vol. 15, pp. 1109–1122, Oct 2007.
[11] M.-Y. Park and S.-H. Chung, “Distinguishing the cause of tcp retrans-
mission timeouts in multi-hop wireless networks,” in High Performance
Computing and Communications (HPCC), 2010 12th IEEE International
Conference on, pp. 329–336, Sept 2010.
[12] T. Le, G. Kuthethoor, C. Hansupichon, P. Sesha, J. Strohm, G. Hadynski,
D. Kiwior, and D. Parker, “Reliable user datagram protocol for airborne
network,” in Military Communications Conference, 2009. MILCOM
2009. IEEE, pp. 1–6, Oct 2009.
[13] E. Bethel and J. Shalf, “Grid-distributed visualizations using connec-
tionless protocols,” Computer Graphics and Applications, IEEE, vol. 23,
pp. 51–59, Mar 2003.
[14] S. Jung, S. Hong, and K. Kim, “On achieving high performance
wireless mesh networks with data fusion,” in World of Wireless, Mobile
and Multimedia Networks, 2007. WoWMoM 2007. IEEE International
Symposium on a, pp. 1–8, June 2007.
[15] Y.-L. Chang and C.-C. Hsu, “Connection-oriented routing in ad hoc
networks based on dynamic group infrastructure,” in Computers and
Communications, 2000. Proceedings. ISCC 2000. Fifth IEEE Symposium
on, pp. 587–592, 2000.
[16] D. Lu, Y. Qiao, P. Dinda, and F. Bustamante, “Modeling and taming
parallel tcp on the wide area network,” in Parallel and Distributed
Processing Symposium, 2005. Proceedings. 19th IEEE International,
pp. 68b–68b, April 2005.
[17] K.-C. Leung, V. Li, and D. Yang, “An overview of packet reorder-
ing in transmission control protocol (tcp): Problems, solutions, and
challenges,” Parallel and Distributed Systems, IEEE Transactions on,
vol. 18, pp. 522–535, April 2007.