JakeHillion/dissertation-4-dissertation
1
0
Fork 0
Code Issues Pull Requests Releases 1 Wiki Activity

Update on Overleaf.

Browse Source
This commit is contained in:
jsh77 2021-05-14 06:38:04 +00:00 committed by overleaf
parent 54be5311cb
commit 8fd0a3aa20
1 changed files with 19 additions and 61 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

80
4_Evaluation/evaluation.tex
View File

@ -28,25 +28,7 @@ When presenting data, error bars are given of the Inter-Quartile Range (IQR) of
\subsection{Flow Maintained}
Demonstrating that a flow is maintained under connection loss has two cases: TCP flows and UDP flows. For TCP flows, the success criteria will be met if a TCP flow can continue to provide reliable transmission under a connection loss. UDP flows are less standardised, so will be split into two categories: an artificial iperf3 test, and a less artificial SIP phone call. The iperf3 test can be used to study the packet behaviour at the time of connection loss, while the SIP phone call provides a representative example of a UDP flow that would be dropped under normal conditions, but is not dropped under this proxy.
\subsubsection{TCP}
To test whether a TCP flow is maintained, a pair of small Python scripts were written. The first creates a TCP server and listens on a port. When it receives a message, it reads the first 12 bytes as a UTF-8 string, replaces the second character with an `o', and sends back the string. The client sends messages of the form \verb'ping%s', where \verb'%s' is an 8-byte nonce. It therefore receives back messages of the form \verb'pong%s', where \verb'%s' is the nonce that it just sent. This allows the client to check that the connection to the server is actively responding.
\mynote{Fill in missing graph.}
\subsubsection{UDP}
Firstly, the effect of connection loss on a UDP flow will be judged by the packet loss statistics of an iperf3 test. The bandwidth of the test will be kept sufficiently low that packet loss would not be expected, given that loss is only introduced within the test network when bandwidth exceeds the limit. This bandwidth is chosen as 128KBps, which is sufficiently low as to not hit the bandwidth limits, but far higher than a UDP flow such as a SIP call.
If the proxy can maintain a flow under a connection loss, the expected result is a peak in packet loss of no more than 50\%, which rapidly returns to 0\%. This represents the small portion of packets needing to be sent to note that the internal flow is offline, and thus stop sending packets to it to be lost. This loss should not exceed 50\%, as the connections are of equal bandwidth and thus should receive half of the packets each.
\mynote{Fill in missing graph.}
The second test is qualitative, involving making a call and checking for disconnection. Firstly, the call is made and both connections for the local proxy disconnected. This represents a failure scenario, as no connections continue existing. It should be confirmed that the call is dropped. Secondly, a call is made from which only one connection is disconnected. To pass this success criteria, the call should continue, though may experience some minor disruption as the connection is disconnected.
\mynote{Fill in Wireshark traces and analysis.}
\mynote{TODO}
\subsection{Bidirectional Performance Gains}
@ -55,29 +37,18 @@ To demonstrate that all performance gains are bidirectional, I will provide grap
To demonstrate this somewhat succinctly, a pair of graphs for the same test in a common case will be shown. To demonstrate that this requirement is satisfied for all cases, for each graph of results presented for the basic success criteria, the graph for the alternative direction will be provided in appendix \ref{appendix:outbound-graphs}.
\begin{figure}
\centering
\begin{subfigure}{.49\textwidth}
\includegraphics[width=0.9\linewidth]{graphs/bidirectional-inbound}
\caption{Throughput of proxied connections inbound to the client.}
\label{fig:bidirectional-inbound}
\end{subfigure}
\begin{subfigure}{.49\textwidth}
\includegraphics[width=0.9\linewidth]{graphs/bidirectional-outbound}
\caption{Throughput of proxied connections outbound from the client.}
\label{fig:bidirectional-outbound}
\end{subfigure}
\caption{Throughput results both inbound to the client and outbound from the client.}
\label{fig:bidirectional-gains}
\centering
\includegraphics[width=0.75\textwidth]{graphs/bidirectional-comparison}
\caption{Comparing the performance of packets inbound to the client to outbound from the client in three different test conditions.}
\label{fig:bidirectional-comparison}
\end{figure}
Figure \ref{fig:bidirectional-gains} has two series for the same set of tests - one for the inbound (reaching in to the client, download) performance and one for the outbound (the client reaching out, upload). It can be seen that both graphs show the same shape, satisfying that the performance gains of this proxy apply in both directions.
Figure \ref{fig:bidirectional-comparison} has two series for the same set of tests - one for the inbound (reaching in to the client, or download) performance and one for the outbound (the client reaching out, or upload) performance. The graphs align neatly comparatively, however, there is a slight preference to outbound flows. This is due to the outbound flows being spread between interfaces, which avoids waiting for the OS to finish locking an interface quite as often. In each case, both inbound and outbound performance satisfy the success criteria, so this is satisfied.
\subsection{IP Spoofing}
\label{section:ip-spoofing-evaluation}
To demonstrate that the IP of the client can be set to the IP of the remote proxy, the network structure shown in Figure \ref{fig:standard-network-structure}, used for most of these tests, can be examined further. This will demonstrate that it is possible to set the IP as such, as all of the tests in this section did so.
In the given network structure, the speed test server, remote proxy and local proxy are each connected to one virtual switch, which acts as a mock Internet. There is then a separate virtual switch, which connects an additional interface of the local proxy to the client. The IP addresses of the interfaces shown in Figure \ref{fig:standard-network-structure} are listed in Figure \ref{fig:standard-network-structure-ips}. The IP addresses of the public interfaces are represented by letters, as they use arbitrary public IP addresses to ensure no local network firewall rules impact the configuration.
Demonstrating that the IP of the client can be set to the IP of the remote proxy is achieved, as each test in this evaluation relies on this fact. When allocating virtual machines to test on, the client is given the IP of the remote proxy. In the given network structure, the speed test server, remote proxy and local proxy are each connected to one virtual switch, which acts as a mock Internet. There is then a separate virtual switch, which connects an additional interface of the local proxy to the client. The IP addresses of the interfaces used in these tests are listed in Figure \ref{fig:standard-network-structure-ips}. The IP addresses of the public interfaces are represented by letters, as they use arbitrary public IP addresses to ensure no local network firewall rules impact the configuration.
\begin{figure}
\centering
@ -100,19 +71,11 @@ In the given network structure, the speed test server, remote proxy and local pr
\label{fig:standard-network-structure-ips}
\end{figure}
It is shown that the client in this testing setup shares an IP address with the remote proxy. To achieve this, the client configuration is particularly simple. A static route is added for 192.168.1.1 from the eth0 interface, and this then set as the default gateway. The IP address is set as the IP address of the remote proxy. The details of this configuration are provided in Figure \ref{section:implementation-system-configuration}.
Given that the client shares the IP address of the remote proxy in these cases, it is demonstrated that this success criteria is met. Sharing the IP of the remote proxy allows most routers to be configured behind the local proxy as a client, allowing it to act as a standard Internet connection. An alternative approach, where the local proxy acts as a router, is detailed in section \ref{section:real-world-testing}.
It is shown that the client in this testing setup shares an IP address with the remote proxy. To achieve this, the client configuration is particularly simple. A static route is added for \texttt{192.168.1.1} from the \texttt{eth0} interface, and this then set as the default gateway. The IP address is set as the IP address of the remote proxy. The details of this configuration are provided in Figure \ref{section:implementation-system-configuration}. This satisfies the success criteria.
\subsection{Security}
Success for security involves providing security no worse than a standard connection.
Success in terms of security involves providing security no worse than a standard connection. To demonstrate that this is satisfied, I refer back to Section \ref{section:layered-security}, in which I describe the ability for this proxy to be layered with other security software. Specifically, the ability to run this proxy behind the VPN solution Wireguard. By setting up a Wireguard tunnel for each connection and using a separate IP range in each, configuring the proxy to run behind Wireguard is no more complicated than the IP routing necessary. Section \ref{section:layered-security} provides an argument that the proxying of packets is made secure by operating in a secure overlay network.
Therefore, to provide security no worse than a standard connection, it is sufficient to show that the security provided is better than a standard connection. If Wireguard provides security better than a standard connection, then it is possible for this proxy to be configured such that it provides security no worse than a standard connection. Further, if any solution which this can be configured behind, such as IPsec Authentication Headers, provides the correct security guarantees, then the security is no worse.
I also presented additional security mechanisms that do not rely on other software. However, given the difficulty of proving the comparative security, I will be relying on the ability to improve security with layering to satisfy this success criteria.
Success for security involves providing security no worse than a standard connection. This is achieved by using Message Authentication Codes, Replay Protection and extra data for connection authentication, described in detail in Section \ref{section:preparation-security}. Further, Section \ref{section:layered-security} provides an argument that the proxying of packets is made secure by operating in a secure overlay network, such as a VPN. This ensures that security can be maintained, regardless of changes in the security landscape, by composing my proxy with additional security software.
\subsection{More Bandwidth over Two Equal Connections}
@ -162,7 +125,7 @@ Two sets of results are provided - one for 1MBps and 2MBps connections, and anot
\subsection{More Bandwidth over Four Equal Connections}
This criteria expands on the scalability in terms of number of connections of the proxy. Specifically, comparing the performance of three connections against four. To fulfil this, the results for each of two, three and four connections are included on each graph. This allows the trend of performance with an increasing number of connections to begin being visualised, which is expanded upon further in section \ref{section:number-of-connections-scaling}.
This criteria expands on the scalability in terms of number of connections of the proxy. Specifically, comparing the performance of three connections against four. To fulfil this, the results for each of two, three and four connections are included on each graph. This allows the trend of performance with an increasing number of connections to begin being visualised, which is expanded upon further in Section \ref{section:performance-evaluation}.
\begin{figure}
\centering
@ -180,7 +143,7 @@ This criteria expands on the scalability in terms of number of connections of th
\label{fig:more-bandwidth-four}
\end{figure}
Provided in Figure \ref{fig:more-bandwidth-four} are results for both 1MBps and 2MBps connections. Firstly, it is clear that the proxy consisting of 4 connections exceeds the throughput of the proxy consisting of 3 connections in both cases. Secondly, it appears that a linear trend is forming. This trends will be further evaluated in section \ref{section:number-of-connections-scaling}, but suggests that the structure of the proxy suffers little loss in efficiency from adding further connections.
Provided in Figure \ref{fig:more-bandwidth-four} are results for both 1MBps and 2MBps connections. Firstly, it is clear that the proxy consisting of 4 connections exceeds the throughput of the proxy consisting of 3 connections in both cases. Secondly, it appears that a linear trend is forming. This trends will be further evaluated in Section \ref{section:performance-evaluation}, but suggests that the structure of the proxy suffers little loss in efficiency from adding further connections.
\subsection{Bandwidth Variation}
@ -196,9 +159,7 @@ Two graphs are presented here. Figure \ref{fig:bandwidth-variation-down} present
\subsection{Connection Loss}
This criteria judges the ability of the proxy as a whole to handle a complete connection loss while maintaining proportional throughput. As the proxy has redundant connections, it is feasible for this to cause a minimal loss of service. Unfortunately, losing a connection causes significant instability with the proxy, so this extended goal has not been met.
\mynote{Re-evaluate with UDP.}
This criteria judges the ability of the proxy as a whole to handle a complete connection loss while maintaining proportional throughput, and later regaining that capacity when the connection becomes available again. As the proxy has redundant connections, it is feasible for this to cause a minimal loss of service. Unfortunately, losing a connection causes significant instability with the proxy, so this extended goal has not been met.
\subsection{Single Interface Remote Portal}
@ -210,23 +171,20 @@ The extended goal of connection metric values has not been implemented. Instead,
\section{Stretch Goals}
\subsection{IPv4/IPv6 Support}
The project is only tested with IPv4.
\subsection{UDP Proxy Flows}
Although UDP proxy flows are implemented, they are unable to provide improved performance over a TCP connection.
\subsection{IP Proxy Packets}
The proxy only supports TCP and UDP flows for carrying the proxied data.
\section{Performance Evaluation}
\label{section:performance-evaluation}
The discussion of success criteria above used relatively slow network connections to test scaling in certain situations. This section provides a brief analysis of how this solution would scale to providing a higher bandwidth connection, specifically by adding network connections.
The results of these tests are shown in Figure \ref{fig:n-connections-scaling}. Each of $1MB/s$, $2MB/s$ and $4MB/s$ capacity links are tested with 1 to 8 connections. The throughput demonstrated is largely linear, with a suggestion that eight $4MB/s$ connections are approaching the software's limits. This result is very promising, as it shows that the software can handle a large number of connections. While this is quite limiting for some higher download speed connections, many upload speeds are far slower, and would benefit from this quantity of links.
\mynote{Needs more data.}
\begin{figure}
\centering
\includegraphics[width=0.75\textwidth]{graphs/n_connections_scaling}
\caption{Scaling of proxy throughput based on number of connections, for three speeds of connection.}
\label{fig:n-connections-scaling}
\end{figure}