Most UK residences receive broadband speeds advertised at between 30Mbps and 100Mbps download (Ofcom, “UK Home Broadband Performance.”, \cite{ofcom_performance_2020}). However, it is often possible to have multiple low bandwidth connections installed. 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}}. This work focuses on a method of providing an aggregate link from multiple distinct connections, regardless of their likeness.
MultiPath TCP (Handley et al., “TCP Extensions for Multipath Operation with Multiple Addresses.”, \cite{handley_tcp_2020}) is an extension to the regular Transmission Control Protocol, allowing 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.
The first reason that MPTCP does not satisfy the motivation for this project is temporal. MPTCP is most effective at creating flows when the device has distinct interfaces or IP addresses. In the case of an IPv4 home connection, it is often the case that a single IPv4 address is provided to the home. This leads to the use of NAT for IPv4 addresses behind the router. If an MPTCP capable device lies behind a NAT router which has two external IPv4 addresses, the device itself will have no knowledge of this. This can be solved for server devices by having an IP on each NAT, but does not provide a good solution for standard devices such as laptops with a single WiFi interface, or smart televisions with no knowledge of the network structure.
Further, it is important to remember legacy devices. Many legacy devices will never support IPv6, and will never support MPTCP. Though it is possible that these devices will not require the performance benefits available from multiple Internet connections, it is likely that they would benefit particularly from a more reliable connection. Being able to apply speed and reliability benefits to an entire network without control over every device on it is a significant benefit to the proxy presented in this work.
The second reason that MPTCP can not immediately shift the Internet to supporting of multipath is the rise of alternative UDP based protocols for previous TCP use cases. Although MPTCP is now making its way into the Linux kernel, many services are switching to lighter UDP protocols such as QUIC. The most interesting example of this is HTTP/3, which was previously known as HTTP over QUIC. This shift to application controlled network connections which do not contain unnecessary overhead for each specific application is a trend in Internet applications at this time. It remains to be seen whether this will allow for faster or cause slower deployments of extensions to protocols, but it will create a less uniform Internet than one which relies entirely on TCP, making a shift of the entire Internet to supporting multipath all the more challenging.
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. This is achieved by inserting additional items into the network stack, in order to split/combine over bottlenecks, as seen in figure \ref{fig:combining-bottlenecks}.
The primary benefit of the approach presented in this work is for use cases where connection capacities are not consistent. I present a solution that effectively load balances across changing connections, such as wireless, allowing use cases which load balance across such connections in combination with existing fixed lines. This enables situations where load balancing was not previously possible to take advantage of multiple connections, potentially vastly increasing throughput capacity.
