% performance analysis

This section exposes the analysis on the security controls offered by the cloud infrastructure, that leads to future choices that weigh on the design implementation.

The main purpose is to find how the behaviour of different technologies changes based on the number of filtering rules that are enforced. OpenStack infrastructure bases its security on \textit{Iptables}, as mentioned before, but there are different filtering points that could be exploited, for this reason it is needed to find the best way to enforce security actions. 

Security controls are critical devices from the performance point of view. The resource\break consumption such as CPU usage and memory occupation, could be bottleneck when these controls are implemented in software. Performance degradation is often associated to large rule sets.

For this reason the most interesting and significant metrics are taking in accounts, especially the ones regarding 
network devices and security controls.

The metrics that are evaluated are the following:
\begin{itemize}
	\item 
	latency
	\item
	bandwidth
	\item
	CPU consumption
\end{itemize}

The performance evaluation are done on an OpenStack deployment running on two machines whose technical specifics are described:

\begin{itemize}
	\item 
	\textbf{TYPE}: Intel NUC NUC5i5MYHE
	\item
	\textbf{CPU}: Intel Core i5-5300U, dual-core, 2.30 GHz
	\item
	\textbf{RAM}: 16 GB, DDR3
	\item
	\textbf{OS}: Ubuntu Server 18.04 LTS
\end{itemize}
\clearpage

The three metrics measures different aspects of a communication between two virtual machines and for each metric different tools are used to evaluate the performances.
\begin{itemize}
	\item 
	\code{ping} and \code{nping}: these tools are useful to compute the delay and the Round Trip Time\break between two end-points, Nping is an open source tool for network packet generation,\break response analysis and response time measurement. Nping can generate network packets for a wide range of protocols, allowing users full control over protocol headers~\cite{Nping}. The following commands are the ones launched to evaluate the performance.
	
	
\HRule
\begin{lstlisting}
$ sudo ping -c 1000 -i 0.005 -q -s 1000 destination-IP
$ sudo nping -H --no-crypto -c 1000 --send-eth --data-len 1000 --delay 5ms --tcp -p 80 destination-IP
\end{lstlisting}
\HRule

	Both of them send a packet of \textit{1000 Bytes} every \textit{5 ms} to the \textit{destination-IP} address.
	
	\item
	\code{iperf3}: iperf3 is a tool to perform network throughput measurements. It can test either TCP or UDP throughput. To perform an iperf3 test the user must establish both a server and a client~\cite{iperf3}.
	
\HRule
\begin{lstlisting}
$ iperf3 -s -f K
$ iperf3 -c server-IP -f K
\end{lstlisting}
\HRule
	
	The former command starts the server on one virtual machine and the latter starts the client on the second virtual machine, which starts a TCP connection to \textit{server-IP} address and gives the output in KBytes per second.
	
	\item
	\code{top}: this tool provides a dynamic real-time view of a running	system. It can display system summary information as well as a list	of processes or threads currently being managed by the Linux kernel~\cite{top}.
	
\HRule
\begin{lstlisting}
$ top

$ top - 18:53:02 up 0 min,  0 users,  load average: 0.52, 0.58, 0.59
$ Tasks: 4 total, 1 running, 3 sleeping, 0 stopped, 0 zombie
$ %Cpu(s): 0.3 us, 0.8 sy, 0.0 ni, 98.8 id, 0.0 wa, 0.1 hi, 0.0 si, 0 st
$ KiB Mem: 16663516 total, 10118300 free, 6315864 used,  229352 buff/cache
$ KiB Swap: 29221116 total, 29221116 free,      0 used. 10213920 avail Mem

$ PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
$ 1 root      20   0    8892    312    272 S   0.0  0.0   0:00.07 init
$ 7 user      20   0   16776   3440   3328 S   0.0  0.0   0:00.08 bash
$ 39 user      20   0   17624   2048   1516 R   0.0  0.0   0:00.00 top
\end{lstlisting}
\HRule

	This command displays the $\mathcal{\%}$ of CPU used by the system or specific of a program.
\end{itemize}

Each filtering controls is implemented with a different technology. For these reasons different tested were developed.
The following subsections exposes the results of the performance tests implemented on each technology used.
\pagebreak

\subsection{Iptables}
\input{latex_files/component_analysis/iptables.tex}

\subsection{Open Virtual Switch}
\input{latex_files/component_analysis/ovs.tex}

\subsection{Analysis conclusion}

The tests show us that Open Virtual Switch technology has better scale-up feature based on the number of rules then Iptables. This behaviour is due to the different internal data structure of the two systems, the former implements that \textit{exact-match cache (EMC)} (Figure \ref{fig:EMC}) that is a fast mechanism the Open Virtual Switch uses to determine the action to be performed on an incoming packet. This is like how the CPUs checks the memory caches when accessing data.
Otherwise Iptables has a linear data structure with no cache or hash table, that means a packet needs to scan all the filtering rule list until the one that matches.
The implementation of the data structure has a big impact on the computational cost that in the first case, with OVS the trend is \textit{$\sim$O(1)}, contrarily Iptables has a computational cost of \textit{O(n)}.

\begin{figure}[H]
	\centerline{\includegraphics[width=0.7\textwidth]
		{EMC_ovs.png}}
	\caption{The Open vSwitch table hierarchy.
		\label{fig:EMC}}
\end{figure}