Update on Overleaf.

1_Introduction/introduction.tex

@@ -15,15 +15,19 @@ The advertised broadband download speed of most UK residences lies between 30Mbp
 
 Though multiple low bandwidth, low cost, connections may be accessible, a mechanism to combine multiple connections to present a single high speed, highly available connection to a user is unavailable. This work focuses on providing such a mechanism, taking multiple distinct connections and providing a single aggregate connection.
 
+Using a proxy provides three significant benefits: immediate failover of a single flow, exceeding the bandwidth of each individual connection with an individual flow, and balancing of inbound connections. For failover, this means that a flow between a user of this proxy and an external user, such as a SIP call, is maintained when one Internet connection is lost. For exceeding the bandwidth, viewing the live stream from a CCTV camera is possible at higher resolution. Finally, although methods such as load balancing routers can balance outgoing flows effectively in many cases, inbound flows cannot be handled so simply. Balancing inbound flows involves complex solutions, which rely on client support. The proxy presented here returns control to the network architect, allowing for the decided structure to be hidden from both the users behind the proxy and the remote users, and solving the presented problems.
+
 \section{Existing Work}
 
+Three pieces of existing work that will be examined for their usefulness are MultiPath TCP (MPTCP), Wireguard, and Cloudflare. Multipath TCP is an effort to expand TCP (Transmission Control Protocol) connections to multiple paths, and is implemented at the kernel layer such that applications which already use TCP can immediately take advantange of the multipath benefits. Wireguard is a state of the art VPN, providing much input on the choices that an application which successfully transmits packets securely over the Internet can make. Finally, Cloudflare shows examples of how a high bandwidth network can be used to supplement multiple smaller networks, but in a largely different context to this project. This section focuses on which parts of these items of work will be useful to study for this project, and why they themselves do not satisfy the aims of the project.
+
 \subsection{MultiPath TCP (MPTCP)}
 
 MultiPath TCP \citep{handley_tcp_2020} is an extension to the regular Transmission Control Protocol, allowing for the creation of subflows. MultiPath TCP was designed with two purposes: increasing resiliency and throughput for multi-homed mobile devices, and providing multi-homed servers with better control over balancing flows between their interfaces. Initially, MultiPath TCP seems like a solution to the aims of this project. However, it suffers for three reasons: the rise of UDP protocols, device knowledge of interfaces, and legacy devices.
 
 Although many UDP protocols have been around for a long time, using UDP protocols as a replacement for previously TCP protocols is a newer effort. An example of an older protocol is SIP \citep{schooler_sip_2002}, still widely used for VoIP calls. This is an example of a UDP protocol that would benefit particularly from increased resilience to Internet connection outage. For a replacement TCP protocol, HTTP/3 \citep{bishop_hypertext_2021} is one of the largest. Previously, HTTP requests have been sent over TCP connections, but HTTP/3 switches this to a UDP protocol. As such, HTTP requests are moving away from benefiting from MPTCP.
 
-Secondly is the reliance of MPTCP on devices having knowledge of their network infrastructure. Consider the example of a phone with a WiFi and 4G interface reaching out to a voice assistant. The phone in this case can utilise MPTCP effectively, as it has knowledge of both Internet connections, and can create subflows appropriately. However, consider instead a tablet with only a WiFi interface, but connected via NAT to a router with two WAN interfaces. In this case, the tablet will believe that it only has one connection to the Internet, while actually being able to take advantage of two. This is a problem that is difficult to solve at the client level, suggesting that it is better suited to network infrastructure.
+Secondly is the reliance of MPTCP on devices having knowledge of their network infrastructure. Consider the example of a phone with a WiFi and 4G interface reaching out to a voice assistant. The phone in this case can utilise MPTCP effectively, as it has knowledge of both Internet connections, and can create subflows appropriately. However, consider instead a tablet with only a WiFi interface, but connected via NAT (Network Address Translation) to a router with two WAN (Wide Area Network) interfaces. In this case, the tablet will believe that it only has one connection to the Internet, while actually being able to take advantage of two. This is a problem that is difficult to solve at the client level, suggesting that it is better suited to network infrastructure.
 
 Finally, it is important to remember legacy devices. Often, these legacy devices will benefit the most from resilience improvements, and they are the least likely to receive updates to new networking technologies such as MPTCP. Although MPTCP can still provide a significant balancing benefit to the servers that legacy devices also connect to, the legacy devices see little benefit if they could utilise multiple connections. Providing an infrastructure level solution benefits all devices behind it equally, regardless of their legacy status.
 
@@ -33,9 +37,21 @@ Wireguard \citep{donenfeld_wireguard_2017} is a state of the art VPN (Virtual Pr
 
 For each Layer 3 packet that Wireguard transports, it generates and sends a single UDP datagram. This is a pattern that will be followed in the UDP implementation of my software. These UDP packets suffer many of the same problems as will occur in my software, such as replay attacks, so the Wireguard implementation of such protections will be considered throughout. Finally, Wireguard provides an implementation in Go, which will be a useful reference for Layer 3 networking in Go.
 
+\subsection{Cloudflare}
+
+\mynote{TODO: Cloudflare handles inbound load balancing by collecting all of your connections at one high bandwidth point, before balancing between servers.}
+
+\mynote{TODO: Load Balancing - similar to this, if a server (met. ISP) goes down, failover instantly to another server (met. ISP).}
+
+\mynote{TODO: Magic WAN - benefits of moving network front to the Cloud. Network can absorb (D)DoS attacks without ever sending them to you.}
+
+\mynote{QUESTION: How to correctly reference these products?}
+
 \section{Aims}
 
-This project aims to provide a method of combining multiple Internet connections, possibly heterogeneous, and possibly of dynamic capacity. When combining Internet connections, there are three main measures that one can prioritise: throughput, resilience, and latency. This project aims to provide throughput and resilience at the cost of latency. By using a layer 3 proxy, connections are combined in a way that is transparent to devices on both sides of the proxy, overcoming the throughput and availability limitations of each individual connection. The insertion of the proxy combining these bottlenecks is shown in figure \ref{fig:combining-bottlenecks}.
+\mynote{Probably replace this. `This project aimed to produce proxy software that uses congestion control to manage multiple paths of data flow, intended to be across discrete Internet connections. Such a proxy should...`}
+
+This project aims to provide a method of combining multiple Internet connections, possibly heterogeneous, and possibly of dynamic capacity. When combining Internet connections, there are three main measures that one can prioritise: throughput, resilience, and latency. This project aims to provide throughput and resilience at the cost of latency. By using a layer 3 proxy (carrying entire IP packets), connections are combined in a way that is transparent to devices on both sides of the proxy, overcoming the throughput and availability limitations of each individual connection. The insertion of the proxy combining these bottlenecks is shown in figure \ref{fig:combining-bottlenecks}.
 
 \begin{figure}
     \centering

5_Conclusions/conclusions.tex

@@ -15,6 +15,8 @@
 
 \mynote{Future work: other methods of measuring link capacity dynamically than congestion control.}
 
+\mynote{Lessons learnt: split into two parts - lessons learnt about projects in general, and (after this prototype) lessons learnt about how I'd do this project again.}
+
 % -- Old stuff (to delete)
 
 The project was a success. I met all of the core success criteria, and many of the extended goals beyond that. This project has produced a piece of software that provides an interesting approach to combining Internet connections. The software is useful and has seen one real world deployment, and it's hoped that others will find it a useful tool in their circumstances.