dissertation-4-dissertation/1_Introduction/introduction.tex

%!TEX root = ../thesis.tex
%*******************************************************************************
%*********************************** First Chapter *****************************
%*******************************************************************************

\chapter{Introduction}  %Title of the First Chapter

\ifpdf
    \graphicspath{{1_Introduction/Figs/Raster/}{1_Introduction/Figs/PDF/}{1_Introduction/Figs/}}
\else
    \graphicspath{{1_Introduction/Figs/Vector/}{1_Introduction/Figs/}}
\fi

The advertised broadband download speed of most UK residences lies between 30Mbps and 100Mbps \citep{ofcom_performance_2020}, which is often the highest available speed. However, in most cases, more of these connections can be installed at a price linear in the number of connections. More generally, a wider variety of Internet connections for fixed locations are becoming available with time. These include: DSL, Fibre To The Premises, 4G, 5G, Wireless ISPs such as LARIAT\footnote{\url{http://lariat.net}} and Low Earth Orbit ISPs such as Starlink.\footnote{\url{https://starlink.com}}

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.

\section{Existing Work}

\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.

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.

\subsection{Wireguard}

Wireguard \citep{donenfeld_wireguard_2017} is a state of the art VPN (Virtual Private Network) solution. Though Wireguard does not serve to combine multiple network connections, it is widely considered an excellent method of transmitting packets securely via the Internet.

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.

\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}.

\begin{figure}
    \centering
    \begin{tikzpicture}[scale=0.8]
        \draw (0,0.14) rectangle (1,2.14);
        \draw (7,0.14) rectangle (8,2.14);
        
        \draw (1, 1.75) .. controls (1.5, 1.75) and (2.5, 2.5) .. (3, 2.5);
        \draw (3, 2.5) -- (5, 2.5);
        \draw (5, 2.5) .. controls (5.5, 2.5) and (6.5, 1.75) .. (7, 1.75);
        \draw (4, 2.8) node {10Mbps};
        
        \draw (1, 1) .. controls (1.5, 1) and (2.5, 1.75) .. (3, 1.75);
        \draw (3, 1.75) -- (5, 1.75);
        \draw (5, 1.75) .. controls (5.5, 1.75) and (6.5, 1) .. (7, 1);

        \draw (1, 0.9) .. controls (1.5, 0.9) and (2.5, 0.15) .. (3, 0.15);
        \draw (3, 0.15) -- (5, 0.15);
        \draw (5, 0.15) .. controls (5.5, 0.15) and (6.5, 0.9) .. (7, 0.9);
        
        \draw (1, 0.53) .. controls (1.5, 0.53) and (2.5, -0.22) .. (3, -0.22);
        \draw (3, -0.22) -- (5, -0.22);
        \draw (5, -0.22) .. controls (5.5, -0.22) and (6.5, 0.53) .. (7, 0.53);
        \draw (4, -0.52) node {5Mbps};
        
        \draw (0.5, 2.5) node {Proxy};
        
        \draw (0, 1.7) -- (-2, 1.7);
        \draw (0, 0.58) -- (-2, 0.58);
        \draw (-3, 1.14) node {15Mbps};
        
        \draw (7.5, 2.5) node {Proxy};
        
        \draw (8, 1.7) -- (10, 1.7);
        \draw (8, 0.58) -- (10, 0.58);
        \draw (11, 1.14) node {15Mbps};
    \end{tikzpicture}
    \caption{A high level overview of the bottlenecks that are combined in this solution.}
    \label{fig:combining-bottlenecks}
\end{figure}

The approach presented in this work achieves throughput superior to a single connection by using congestion control to split packets appropriately between each available connection. Further, resilience increases, as a connection loss results in decreased throughout, but does not lose any connection state. Latency, however, increases, as packets must travel via a proxy server.