72 lines
5.5 KiB
TeX
72 lines
5.5 KiB
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
|
|
|
|
Most UK residential broadband speeds 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 and Low Earth Orbit ISPs such as Starlink. This work focuses on a method of providing an aggregate link from multiple distinct connections, regardless of their likeness.
|
|
|
|
\section{Existing Work}
|
|
|
|
\subsection{MultiPath TCP}
|
|
|
|
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 more standard devices. These range from WiFi interfaces to IP phones and smart televisions.
|
|
|
|
\mynote{IPv6 autoconf wrt. multihoming}
|
|
|
|
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 solution provided in this work.
|
|
|
|
The second reason that MPTCP may not provide the change to the Internet that was once hoped is the UDP based protocols that are coming into existence. 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 seems to be the direction that the Internet is going in, but suggests that it will be a very long time before even modern applications can benefit from multipathing.
|
|
|
|
\mynote{Find a study on how many of the connections on the Internet are TCP or UDP, particularly over time.}
|
|
|
|
\section{Aims}
|
|
|
|
This project aimed to provide a method of combining a variety of Internet connections, such as the situations listed above.
|
|
|
|
When combining Internet connections, there are three main measures that one can prioritise: throughput, resilience and latency. This project aimed 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}.
|
|
|
|
\begin{figure}
|
|
\centering
|
|
\begin{tikzpicture}
|
|
\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, 1.7) -- (-2, 1.7);
|
|
\draw (0, 0.58) -- (-2, 0.58);
|
|
\draw (-3, 1.14) node {15Mbps};
|
|
|
|
\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} |