Update on Overleaf.

3_Implementation/implementation.tex

@@ -307,7 +307,7 @@ To achieve the same curve as New Reno, there are two phases: exponential growth
 
 The software portion of this proxy is entirely symmetric, as can be seen in figure \ref{fig:dataflow-overview}. However, the system configuration diverges, as each side of the proxy serves a different role. Referring to figure \ref{fig:dataflow-overview}, it can be seen that the kernel routing differs between the two nodes. Throughout, these two sides have been referred to as the local and remote portals, with the local in the top left and the remote in the bottom right.
 
-As the software portion of this application is implemented in user-space, it has no control over the routing of packets. Instead, a virtual interface is provided, and the kernel is instructed how to route relevant packets via this interface. In sections \ref{section:implementation-remote-portal-routing} and \ref{section:implementation-local-portal-routing}, the configuration for routing the packets for the remote portal and local portal respectively are explained. Finally, in section \ref{section:implementation-multi-interface-routing}, some potentially unexpected behaviour of using devices with multiple interfaces is explained, such that the reader can avoid some of these pitfalls. Throughout this section, examples will be given for both Linux and FreeBSD. Though these examples are provided, they are one of many methods of achieving the same results.
+As the software portion of this application is implemented in user-space, it has no control over the routing of packets. Instead, a virtual interface is provided, and the kernel is instructed to route relevant packets to/from this interface. In sections \ref{section:implementation-remote-portal-routing} and \ref{section:implementation-local-portal-routing}, the configuration for routing the packets for the remote portal and local portal respectively are explained. Finally, in section \ref{section:implementation-multi-interface-routing}, some potentially unexpected behaviour of using devices with multiple interfaces is discussed, such that the reader can avoid some of these pitfalls. Throughout this section, examples will be given for both Linux and FreeBSD. Though these examples are provided, they are one of many methods of achieving the same results.
 
 \subsection{Remote Portal Routing}
 \label{section:implementation-remote-portal-routing}
@@ -337,14 +337,12 @@ FreeBSD:
 
 \inputminted{shell-session}{3_Implementation/Samples/shell/freebsd_remote_routing.sh}
 
-\mynote{Test this pass out line.}
-
-These settings combined will provide the proxying effect via the TUN interface configured in software. It is also likely worth firewalling much more aggressively at the remote portal side, as dropping packets before saturating the low bandwidth connections between the local and remote portal improves resilience to denial of service attacks. This can be completed either with similar routing and firewall rules to those above, or externally with many cloud providers, and is left as an exercise.
+These settings combined will provide the proxying effect via the TUN interface configured in software. It is also likely worth firewalling much more aggressively at the remote portal side, as dropping packets before saturating the low bandwidth connections between the local and remote portal improves resilience to denial of service attacks. This can be completed either with similar routing and firewall rules to those above, or externally with many cloud providers.
 
 \subsection{Local Portal Routing}
 \label{section:implementation-local-portal-routing}
 
-Routing within the local portal expects $1+N$ interfaces: one connected to the client device expecting the public IP, and $N$ connected to the wider Internet for communication with the other node. Referring to figure \ref{fig:dataflow-overview}, it can be seen that no specific rules are required to achieve this routing. Although this is true in most, the overview diagram avoids the complexity of the kernel routing to this software itself, which will be discussed in more detail here. Therefore, there are three goals: ensure the packets for the remote IP are routed from the TUN to the client device and vice versa, ensuring that packets destined for the remote portal are not routed to the client, and ensuring each connection is routed via the correct WAN connection. The first two will be covered in this section, with a discussion on the latter in the next section.
+Routing within the local portal expects $1+N$ interfaces: one connected to the client device expecting the public IP, and $N$ connected to the wider Internet for communication with the other node. Referring to figure \ref{fig:dataflow-overview}, it can be seen that no complex rules are required to achieve this routing, as each interface serves a different role. As such, there are three goals: ensure the packets for the remote IP are routed from the TUN to the client device and vice versa, ensuring that packets destined for the remote portal are not routed to the client, and ensuring each connection is routed via the correct WAN connection. The first two will be covered in this section, with a discussion on the latter in the next section.
 
 Routing the packets from/for the local portal is pleasantly easy. Firstly, enable IP forwarding for Linux or gateway mode for FreeBSD, as seen previously. Secondly, routes must be setup. Fortunately, these routes are far simpler than those for the remote portal. The routing for the local portal client interface is as follows on Linux:
 

4_Evaluation/evaluation.tex

@@ -75,7 +75,7 @@ Demonstrating that a flow is maintained under connection loss has two cases: TCP
 
 \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 still responding.
+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.}
 
@@ -120,7 +120,7 @@ Figure \ref{fig:bidirectional-gains} shows two graphs of the same set of tests -
 
 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.
+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 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
@@ -143,21 +143,21 @@ In the given network structure, the speed test server, remote portal and local p
     \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 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-system-configuration}.
+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 figure \ref{section:implementation-system-configuration}.
 
 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}
 
-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.
+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 \label{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.
 
-Further, I presented an additional security mechanism that does 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.
+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.
 
 \subsection{More Bandwidth over Two Equal Connections}
 
-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.
+To demonstrate that more bandwidth is available over two equal connections through this proxy than one without, I will compare the iperf3 throughput 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}
     \centering
@@ -181,7 +181,7 @@ The results of these tests are given in figure \ref{fig:more-bandwidth-equal}, f
 
 \subsection{More Bandwidth over Unequal Connections}
 
-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.
+For showing improved throughput over connections which are not equal, three results will be compared. Connections of speed $x+x$, speeds $x+y$, and speeds $y+y$ will be shown, where $x < y$. To show that unequal connections exceed the performance of a pair of slower connections, the results for speeds $x+y$ should lie between $x+x$ and $y+y$. 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.
 
 \begin{figure}
     \centering
@@ -221,11 +221,13 @@ 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 performance 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:number-of-connections-scaling}, but suggests that the structure of the proxy suffers little loss in efficiency 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).
+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 throughput 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).
+
+\mynote{Reference the graph which shows the errors.}
 
 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.
 
@@ -241,13 +243,11 @@ This criteria judges the ability of the proxy as a whole to handle a complete co
 
 \subsection{Single Interface Remote Portal}
 
-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-system-configuration}. 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.
-
-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.
+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-system-configuration}. 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. 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.
 
 \subsection{Connection Metric Values}
 
-The extended goal of connection metric values has not been implemented at this point.
+The extended goal of connection metric values has not been implemented. Instead, peers which only transfer data in one direction were implemented, which covers some of the use cases for metric values. Though metric values for connections would have been useful in some cases, they do not represent the standard usage of the software, and the added complexity of managing live peers was deemed unnecessary for the core software. Instead, I would consider providing a better interface to control the software externally, which would allow a separate piece of software to manage live peers. This has not been completed at this time.
 
 \section{Stretch Goals}
 
@@ -261,12 +261,12 @@ Although UDP proxy flows are implemented, they are unable to provide improved pe
 
 \subsection{IP Proxy Packets}
 
-The project only supports TCP and UDP flows for carrying the proxied data.
+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 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}
 
@@ -275,7 +275,7 @@ The discussion of success criteria above used relatively slow network connection
 \subsection{Number of Connections Scaling}
 \label{section:number-of-connections-scaling}
 
-\mynote{Once automated testing is up, grab the data for this and plot a couple of graphs.}
+\mynote{Needs more data.}
 
 \subsection{Real World Testing}
 \label{section:real-world-testing}

5_Conclusions/conclusions.tex

@@ -11,7 +11,7 @@
     \graphicspath{{5_Conclusions/Figs/Vector/}{5_Conclusions/Figs/}}
 \fi
 
-The software produced in this project provides a method of combining multiple Internet connections, prioritising throughput and resilience in the resultant aggregate connection.
+%The software produced in this project provides a method of combining multiple Internet connections, prioritising throughput and resilience in the resultant aggregate connection.
 
 % -- Old stuff (to delete)