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-03-22 01:05:21 +00:00 committed by overleaf
parent 44b523a79e
commit 3e966e059f
3 changed files with 111 additions and 123 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

233
Evaluation/evaluation.tex
View File

@ -33,36 +33,7 @@ The tests are performed on a Dell R710 Server with the following specifications:
The majority of data presented in this chapter will be in the form of bar graphs. The majority of data presented in this chapter will be in the form of bar graphs.
\subsection{Line Graphs} \subsection{Data Gathering}
Time sensitive data will be presented in the form of line graphs. These are generated in a consistent format, using a script found in appendix (Possibly Appendix).
\begin{figure}
\centering
\begin{subfigure}{.3\textwidth}
\includegraphics[width=0.9\linewidth]{graphs/TIS0-R0-1R1-1R2-1R3-1T10S1-R0-1R1-1R2-1T10S2-R0-1R1-1T10}
\caption{No error bars}
\label{fig:errorbars-none}
\end{subfigure}
\begin{subfigure}{.3\textwidth}
\includegraphics[width=0.9\linewidth]{graphs/TIExS0-R0-1R1-1R2-1R3-1T10S1-R0-1R1-1R2-1T10S2-R0-1R1-1T10}
\caption{X error bars}
\label{fig:errorbars-x}
\end{subfigure}
\begin{subfigure}{.3\textwidth}
\includegraphics[width=0.9\linewidth]{graphs/TIEyS0-R0-1R1-1R2-1R3-1T10S1-R0-1R1-1R2-1T10S2-R0-1R1-1T10}
\caption{Y error bars}
\label{fig:errorbars-y}
\end{subfigure}
\caption{Line graphs produced with varying error bars enabled}
\label{fig:errorbars}
\end{figure}
In figure \ref{fig:errorbars}, examples are shown of the same graph without any error bars, with error bars on the X axis, and with error bars on the Y axis. Error bars for the X axis are plotted as the range of all of the results, while error bars on the Y axis are plotted as $1.5*\sigma$, where $\sigma$ represents the standard deviation of the results.
In figure \ref{fig:errorbars-x}, it is shown that the range of the timestamps provided is incredibly tight. For this reason, I will not be including error bars in the X axis on the graphs shown from this point onwards.
In figure \ref{fig:errorbars-y}, it can be seen that the error bars on the Y axis are far more significant. Thus, error bars will continue to be included in the Y axis.
To generate these results, a fresh set of VMs (Virtual Machines) are created and the software installed on them. Once this is complete, each test is repeated until the coefficient of variance ($\sigma / \mu$, where $\mu$ is the arithmetic mean and $\sigma$ the standard deviation) is below a desired level, or too many attempts have been completed. The number of attempts taken for each series will be shown in the legend of each graph. To generate these results, a fresh set of VMs (Virtual Machines) are created and the software installed on them. Once this is complete, each test is repeated until the coefficient of variance ($\sigma / \mu$, where $\mu$ is the arithmetic mean and $\sigma$ the standard deviation) is below a desired level, or too many attempts have been completed. The number of attempts taken for each series will be shown in the legend of each graph.
@ -107,48 +78,59 @@ The network structure of all standard tests is shown in figure \ref{fig:standard
\subsection{Bidirectional Performance Gains} \subsection{Bidirectional Performance Gains}
The performance gains measured are visible in both directions (inbound and outbound to the client). The graphs shown in this evaluation section are inbound unless stated otherwise, with the outbound graphs being available in Appendix \ref{appendix:outbound-graphs}. To demonstrate that all performance gains are bidirectional, I will provide graphs both inbound and outbound to the client for each performance test executed in this evaluation. This will sufficiently show the performance gains in each case. Inbound tests occur with the test server running on the proxy client and the test client running outside, while outbound tests occur with the test server running outside of the proxy and reaching in.
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 in this evaluation, the graph for the alternative direction will be provided in appendix \ref{appendix:outbound-graphs}.
\begin{figure} \begin{figure}
\centering \centering
\begin{subfigure}{.49\textwidth} \begin{subfigure}{.49\textwidth}
\includegraphics[width=0.9\linewidth]{graphs/IES0-R0-1R1-1T10S1-R0-1R1-2T10S2-R0-2R1-2T10} \includegraphics[width=0.9\linewidth]{graphs/bidirectional-inbound}
\caption{The inbound graph} \caption{Throughput of proxied connections inbound to the client.}
\label{fig:example-inbound} \label{fig:bidirectional-inbound}
\end{subfigure} \end{subfigure}
\begin{subfigure}{.49\textwidth} \begin{subfigure}{.49\textwidth}
\includegraphics[width=0.9\linewidth]{graphs/OES0-R0-1R1-1T10S1-R0-1R1-2T10S2-R0-2R1-2T10} \includegraphics[width=0.9\linewidth]{graphs/bidirectional-outbound}
\caption{The outbound graph} \caption{Throughput of proxied connections outbound from the client.}
\label{fig:example-outbound} \label{fig:bidirectional-outbound}
\end{subfigure} \end{subfigure}
\caption{The same test performed both inbound and outbound} \caption{Throughput results both inbound to the client and outbound from the client.}
\label{fig:example-inbound-outbound} \label{fig:bidirectional-gains}
\end{figure} \end{figure}
Figure \ref{fig:example-inbound-outbound} shows two graphs of the same test - one for the inbound performance and one for the outbound. It can be seen that both graphs show the same shape. Figure \ref{fig:bidirectional-gains} shows two graphs of the same set of tests - one for the inbound performance and one for the outbound. It can be seen that both graphs show the same shape, satisfying that the performance gains of this proxy apply in both directions.
\subsection{IP Spoofing} \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 portal, 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 portal and local portal 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 portal to the client. The IP addresses of the interfaces shown in figure \ref{fig:standard-network-structure} are listed in \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} \begin{figure}
\begin{minted}{shell-session} \centering
#IPv4 Forwarding \begin{tabular}{c|c|c}
sysctl -w net.ipv4.ip_forward=1 Machine & Interface & IP Address \\
\hline
# Route packets from the remote portal address on the client interface via the tunnel Speed Test Server & eth0 & \emph{A} \\
ip route flush 12 \hline
ip route add table 12 to 1.1.1.0/24 via 172.19.152.2 dev nc0 Remote Portal & eth0 & \emph{B} \\
ip rule add from 1.1.1.3 iif eth3 table 12 priority 12 \hline
\multirow{5}{*}{Local Portal} & eth0 & \emph{C0} \\
# Route packets to the remote portal address out of the client interface & eth1 & \emph{C1} \\
ip route flush 13 & \vdots & \vdots \\
ip route add table 13 to 1.1.1.3 dev eth3 & ethN & \emph{CN} \\
ip rule add to 1.1.1.3 table 13 priority 13 & eth\{N+1\} & 192.168.1.1 \\
\end{minted} \hline
\caption{The script necessary for the Local Portal to accept packets from a client with the spoofed IP.} Client & eth0 & \emph{B}
\label{fig:policy-based-routing-script-local-portal} \end{tabular}
\caption{The IP layout of the standard test network structure.}
\label{fig:standard-network-structure-ips}
\end{figure} \end{figure}
This goal was to ensure the Client could use its network interface as if it really had that IP. This is achieved through Policy Based Routing. Example scripts are shown in figure \ref{fig:policy-based-routing-script-local-portal}. Linux also requires the kernel parameter \mintinline{shell-session}{net.ipv4.ip_forward} to be set to 1. It is shown that the client in this testing setup shares an IP address with the remote portal. 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 portal. The details of this configuration are provided in \ref{section:implementation-systems-routing}.
Given that the client shares the IP address of the remote portal in these cases, it is demonstrated that this success criteria is met. Sharing the IP of the remote portal allows most routers to be configured behind the local portal as a client, allowing it to act as a standard Internet connection. An alternative approach, where the local portal acts as a router, is detailed in section \ref{section:real-world-testing}.
\subsection{Security} \subsection{Security}
@ -156,94 +138,97 @@ This goal was to ensure the Client could use its network interface as if it real
\subsection{More Bandwidth over Two Equal Connections} \subsection{More Bandwidth over Two Equal Connections}
This success criteria is satisfied, as seen in figure \ref{fig:two-equal-connections}. This graph compares the combined performance of two equal connections to one connection of the same speed and one connection of double the speed. It can be seen that the connection comes very close to the double speed connection, showing that this is an effective method of combining, in terms of raw TCP throughput. These tests are conducted using the TCP method of congestion control. To demonstrate that more bandwidth is available over two equal connections through this proxy than one without, I will compare the performance between the two cases. Further, I will provide a comparison point against a single connection of the higher bandwidth, as this is the maximum theoretical performance of combining the two lower bandwidth connections.
\begin{figure} \begin{figure}
\centering \centering
\includegraphics[width=10cm]{graphs/IES0-DR0-1T10S1-R0-1R1-1T10S2-DR0-2T10} \begin{subfigure}{.49\textwidth}
\caption{A graph demonstrating that two connections proxied lie between one connection of the same speed and one connection of double the speed in terms of throughput} \includegraphics[width=0.9\linewidth]{graphs/more-bandwidth-equal-a-inbound}
\label{fig:two-equal-connections} \caption{Throughput of proxied connections inbound to the client.}
\label{fig:more-bandwidth-equal-lesser}
\end{subfigure}
\begin{subfigure}{.49\textwidth}
\includegraphics[width=0.9\linewidth]{graphs/more-bandwidth-equal-b-inbound}
\caption{Throughput of proxied connections outbound from the client.}
\label{fig:more-bandwidth-equal-greater}
\end{subfigure}
\caption{Graphs demonstrating that the throughput of two connections proxied lie between one connection of the same speed and one connection of double the speed}
\label{fig:more-bandwidth-equal}
\end{figure} \end{figure}
The results of these tests are given in figure \ref{fig:more-bandwidth-equal}, for both a pair of 1MBps connections and a pair of 2MBps connections. To satisfy this success criteria, the proxied bar on each graph should exceed the throughput of the direct bar of equal bandwidth. It can be seen in both cases that this occurs, and thus the success criteria is met. The throughput far exceeds the single direct connection, and is closer to the single double bandwidth connection than the single equal bandwidth connection, demonstrating a good portion of the maximum performance is achieved.
\section{Extended Goals} \section{Extended Goals}
\subsection{More Bandwidth over Unequal Connections} \subsection{More Bandwidth over Unequal Connections}
\begin{figure} For showing improved throughput over connections which are not equal, three results will be compared. That of two pairs of equal connections, one lower and one higher, and one of unequal connections, composed of the one of each of the pairs. To show that unequal connections exceed the performance of a pair of lower connections, the results for the unequal proxied connections should lie between the other two. Further, to show that percentage throughput is invariant to the balance of connection throughput, the unequal connections should lie halfway between the two equal connection results.
\centering
\includegraphics[width=10cm]{graphs/IES0-R0-2R1-2T10S1-R0-1R1-2T10S2-R0-1R1-1T10}
\caption{A graph demonstrating that two unequal connections proxied lie between two connections of the lower bandwidth and two connections of the higher bandwidth}
\label{fig:unequal-connections}
\end{figure}
This is demonstrated by showing that $1x1MB + 1x2MB$ connections can exceed the performance of $2x1MB$ connections. The results for this can be seen in figure \ref{fig:unequal-connections}, compared against $2x2MB$ and $1x2MB$. It can be seen that the uneven connections fall between the two, which is as expected.
\subsection{More Bandwidth over Four Equal Connections}
\begin{figure}
\centering
\begin{subfigure}{.49\textwidth}
\includegraphics[width=0.9\linewidth]{graphs/IES0-R0-1R1-1R2-1R3-1T10S1-R0-1R1-1R2-1T10S2-R0-1R1-1T10}
\caption{1MB connections}
\label{fig:four-equal-connections-1MB}
\end{subfigure}
\begin{subfigure}{.49\textwidth}
\includegraphics[width=0.9\linewidth]{graphs/IES0-R0-2R1-2R2-2R3-2T10S1-R0-2R1-2R2-2T10S2-R0-2R1-2T10}
\caption{2MB connections}
\label{fig:four-equal-connections-2MB}
\end{subfigure}
\caption{Scaling of equal connections}
\label{fig:four-equal-connections}
\end{figure}
This criteria is about throughput increasing with the number of equal connections added. It is demonstrated by comparing the throughput of $2x1MB$, $3x1MB$ and $4x1MB$ connections. This can be seen in figure \ref{fig:four-equal-connections-1MB}. A further example is provided of $2x2MB$, $3x2MB$ and $4x2MB$ in figure \ref{fig:four-equal-connections-2MB}.
\subsection{Bandwidth Variation}
This criteria is about the adaptability of the congestion control system. This can be seen in figure \ref{fig:bandwidth-variation}, a graph in which the capacity of one of the two links is decreased. For $0 < t \leq 10$, both links are $2MB$. For $10 < t \leq 20$, one link is decreased to $1MB$ and the other remains at $2MB$. For $20 < t \leq 30$, both links are returned to $2MB$.
\begin{figure} \begin{figure}
\centering \centering
\includegraphics[width=10cm]{graphs/TIEyS0-R0-2R1-2E10R0-1E20R0-2T30} \begin{subfigure}{.49\textwidth}
\caption{A graph demonstrating the effect of decreasing the bandwidth of one of the two connections} \includegraphics[width=0.9\linewidth]{graphs/more-bandwidth-unequal-a-inbound}
\label{fig:bandwidth-variation} \caption{Throughput of proxied connections inbound to the client.}
\label{fig:more-bandwidth-unequal-lesser}
\end{subfigure}
\begin{subfigure}{.49\textwidth}
\includegraphics[width=0.9\linewidth]{graphs/more-bandwidth-unequal-b-inbound}
\caption{Throughput of proxied connections outbound from the client.}
\label{fig:more-bandwidth-unequal-greater}
\end{subfigure}
\caption{Graphs demonstrating that the throughput of two two connections proxied lie between one connection of the same speed and one connection of double the speed}
\label{fig:more-bandwidth-unequal}
\end{figure} \end{figure}
It can be seen in the graph that the bandwidth initially stabilises at approximately $30Mbps$, before decreasing at just after $t = 10$. The connection then quickly recovers at $t=20$, to the initial rate. Two sets of results are provided - one for 1MBps and 2MBps connections, and another for 2MBps and 4MBps connections. In both cases, it can be seen that the proxy with unequal connections lies between the equal connection proxies. Further, it can be seen that both unequal proxied connections lie approximately halfway between the equal pairs. This suggests that the proxy design is successful in being invariant to the static balance of connection throughput.
\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}.
\begin{figure}
\centering
\begin{subfigure}{.49\textwidth}
\includegraphics[width=0.9\linewidth]{graphs/more-bandwidth-four-a-inbound}
\caption{1MB connections}
\label{fig:more-bandwidth-four-a}
\end{subfigure}
\begin{subfigure}{.49\textwidth}
\includegraphics[width=0.9\linewidth]{graphs/more-bandwidth-four-b-inbound}
\caption{2MB connections}
\label{fig:more-bandwidth-four-b}
\end{subfigure}
\caption{Scaling of equal connections}
\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 performance from adding further connections.
\subsection{Bandwidth Variation}
This criteria judges the adaptability of the congestion control system in changing network conditions. To test this, the bandwidth of one of the local portal's connections is varied during an iperf3 bandwidth test. Thus far, bar graphs have been sufficient to show the results of each test. In this case, as the performance should now be time sensitive, I will be presenting a line graph. The error bars on the x-axis represent the range of continuous time results included in each discrete plotted point, while the y-axis error bars again represent the inter-quartile range of the gathered data. The target rates will be plotted as a fixed line for each of the speeds, as opposed to time-series. The error bar for these series will be omitted, as they occlude much of the graph, and are visible in figure (ref needed).
The criteria will be met if the following are true: the throughput begins at the rate of a time constant connection; the throughput stabilises at the altered rate after alteration; the throughput returns to the original rate after the rate is reset.
\mynote{Re-gather data and include graph.}
Two graphs are presented here. Figure \ref{fig:bandwidth-variation-down} presents a situation where the speed of a connection decreases, before returning to its original rate. This test begins with two 2MBps connections, changing to 1MBps + 2MBps at $t=10$, and returning to two 2MBps connections at $t=20$. Figure \ref{fig:bandwidth-variation-up} presents a situation where the speed of a connection increases, before returning to its original rate. This test begins with two 2MBps connections, changing to 3MBps + 2MBps at $t=10$, and returning to two 2MBps connections at $t=20$.
\subsection{Connection Loss} \subsection{Connection Loss}
\mynote{Write this.} This criteria judges the ability of the proxy as a whole to handle a complete connection loss. 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.}
\subsection{Single Interface Remote Portal} \subsection{Single Interface Remote Portal}
\begin{figure} Similarly to section \ref{section:ip-spoofing-evaluation}, a remote portal with a single interface is employed within the standard testing structure for this section, using techniques detailed in section \ref{section:implementation-systems-routing}. By altering the routing tables such that all local traffic for the remote portal is sent to the local portal via the proxy, excluding the traffic for the proxy itself, the packets can be further forwarded from the local portal to the client which holds that IP address.
\begin{minted}{shell-session}
# IPv4 Forwarding
sysctl -w net.ipv4.ip_forward=1
sysctl -w net.ipv4.conf.eth0.proxy_arp=1
# Deliberately break local routing As the standard testing structure employs a remote portal with a single interface, it is shown in each test result that this is a supported configuration, and thus this success criteria is met.
ip rule add from all table local priority 20
ip rule del 0 || true
# Route packets to the interface but for nc to this host
ip rule add to 1.1.1.3 dport 1234 table local priority 9
# Route packets to the interface but not for nc via the tunnel
ip route flush 10
ip route add table 10 to 1.1.1.3 via 172.19.152.3 dev nc0
ip rule add to 1.1.1.3 table 10 priority 10
\end{minted}
\caption{The scripts necessary to allow the Remote Portal to only use a single interface.}
\label{fig:policy-based-routing-script-remote-portal}
\end{figure}
The single interface Remote Portal is achieved using a similar set of commands to IP Spoofing. The majority of the work is again done by policy based routing, with some kernel parameters needing to be set too. A sample script is shown in figure \ref{fig:policy-based-routing-script-remote-portal}.
\subsection{Connection Metric Values} \subsection{Connection Metric Values}
Not implemented yet. The extended goal of connection metric values has not been implemented at this point.
\section{Stretch Goals} \section{Stretch Goals}
@ -253,7 +238,7 @@ The project is only tested with IPv4.
\subsection{UDP Proxy Flows} \subsection{UDP Proxy Flows}
\mynote{Write this.} Although UDP proxy flows are implemented, they are unable to provide improved performance over a TCP connection.
\subsection{IP Proxy Packets} \subsection{IP Proxy Packets}
@ -262,17 +247,19 @@ The project only supports TCP and UDP flows for carrying the proxied data.
\section{Performance Evaluation} \section{Performance Evaluation}
\label{section:performance-evaluation} \label{section:performance-evaluation}
The discussion of success criteria above used slow network connections to test scaling in certain situations. This section will focus on testing how the solution scales, in terms of faster individual connections, and with many more connections. Further, all of the above tests were automated and carried out entirely on virtual hardware. This section will show some 'real-world' data, using a Raspberry Pi 4B and real Internet connections. The discussion of success criteria above used relatively slow network connections to test scaling in certain situations. This section will focus on testing how the solution scales, in terms of faster individual connections, and with many more connections. Further, all of the above tests were automated and carried out entirely on virtual hardware. This section will show some 'real-world' data, using a Raspberry Pi 4B and real Internet connections.
\subsection{Faster Connections Scaling} \subsection{Faster Connections Scaling}
\mynote{Write this.} \mynote{Write this.}
\subsection{Number of Connections Scaling} \subsection{Number of Connections Scaling}
\label{section:number-of-connections-scaling}
\mynote{Write this.} \mynote{Write this.}
\subsection{Real World Testing} \subsection{Real World Testing}
\label{section:real-world-testing}
\mynote{Write this.} \mynote{Write this.}

1
Implementation/implementation.tex
View File

@ -274,6 +274,7 @@ To achieve the same curve as New Reno, there are two phases: exponential growth
\mynote{Write this.} \mynote{Write this.}
\subsection{Routing} \subsection{Routing}
\label{section:implementation-systems-routing}
\mynote{Left for now. I have a bit of an idea about why this might/might not be necessary, and want to discuss it with slightly more context (it differs massively between use cases).} \mynote{Left for now. I have a bit of an idea about why this might/might not be necessary, and want to discuss it with slightly more context (it differs massively between use cases).}

0
import-graphs.sh Executable file → Normal file
View File