further introduction and conclusions

Chapter5/chapter5.tex

@@ -1,13 +0,0 @@
-%!TEX root = ../thesis.tex
-%*******************************************************************************
-%****************************** Fifth Chapter **********************************
-%*******************************************************************************
-\chapter{Conclusions}
-
-% **************************** Define Graphics Path **************************
-\ifpdf
-    \graphicspath{{Chapter5/Figs/Raster/}{Chapter5/Figs/PDF/}{Chapter5/Figs/}}
-\else
-    \graphicspath{{Chapter5/Figs/Vector/}{Chapter5/Figs/}}
-\fi
-

Conclusions/conclusions.tex

@@ -0,0 +1,27 @@
+%!TEX root = ../thesis.tex
+%*******************************************************************************
+%****************************** Fifth Chapter **********************************
+%*******************************************************************************
+\chapter{Conclusions}
+
+% **************************** Define Graphics Path **************************
+\ifpdf
+    \graphicspath{{Chapter5/Figs/Raster/}{Chapter5/Figs/PDF/}{Chapter5/Figs/}}
+\else
+    \graphicspath{{Chapter5/Figs/Vector/}{Chapter5/Figs/}}
+\fi
+
+\section{Future Work}
+
+The most interesting future work on multi-homed devices would focus on adding additional features to gateways.
+
+Work on the most effective method of allowing a gateway to inform a device behind it that it is worth adding additional MPTCP subflows.
+
+Work on gateways understanding the Layer 4 concepts of MPTCP and adapting their load balancing algorithms to ensure that multiple subflows of the same MPTCP flow are split appropriately between the available links.
+
+Work on gateways that understand MPTCP to take a non-MPTCP flow and transparently convert it into a MPTCP flow at the gateway, and back again as it reaches the device behind.
+
+Work on IPv6 multi-homing to more effectively inform devices behind it of when they have multiple homes.
+
+TODO: Check, for all of these, whether they should actually be in past work. Particularly the IPv6 multi-homing one.
+

Introduction/introduction.tex

@@ -13,13 +13,29 @@
 
 \section{Motivation}
 
-Most UK residential broadband speeds do not have advertised speeds greater than 30Mbps (Ofcom 2020, \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.
+Most UK residential broadband speeds receive broadband speeds advertised at between 30Mbps and 100Mbps download (Ofcom 2020, \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.
 
 \section{Existing Work}
 
+\subsection{MultiPath TCP}
+
+MultiPath TCP (Wischik et al. 2011, \cite{wischik_design_2011}) 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.
+
+TODO: IPv6 autoconf wrt. multihoming
+
+Further, it is important to remember legacy devices. Many legacy devices will never support IPv6, and certainly 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 particularly benefit from a more reliable connection. Being able to apply speed benefits to an entire network without control over every device on it is a significant benefit to the solution provided in this dissertation.
+
+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.
+
+TODO: 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.
 
+
+

References/references.bib

@@ -69,3 +69,13 @@
 	year = {2020},
 	file = {Snapshot:/home/jake/Zotero/storage/437YQTVF/home-broadband-performance-2019.html:text/html;2020 - UK home broadband performance, measurement period .pdf:/home/jake/Zotero/storage/HPR3TALB/2020 - UK home broadband performance, measurement period .pdf:application/pdf},
 }
+
+@article{wischik_design_2011,
+	title = {Design, implementation and evaluation of congestion control for multipath {TCP}},
+	abstract = {Multipath TCP, as proposed by the IETF working group mptcp, allows a single data stream to be split across multiple paths. This has obvious benefits for reliability, and it can also lead to more efficient use of networked resources. We describe the design of a multipath congestion control algorithm, we implement it in Linux, and we evaluate it for multihomed servers, data centers and mobile clients. We show that some ‘obvious’ solutions for multipath congestion control can be harmful, but that our algorithm improves throughput and fairness compared to single-path TCP. Our algorithm is a drop-in replacement for TCP, and we believe it is safe to deploy.},
+	language = {en},
+	author = {Wischik, Damon and Raiciu, Costin and Greenhalgh, Adam and Handley, Mark},
+	year = {2011},
+	pages = {14},
+	file = {Wischik et al. - Design, implementation and evaluation of congestio.pdf:/home/jake/Zotero/storage/5EIJG455/Wischik et al. - Design, implementation and evaluation of congestio.pdf:application/pdf},
+}

thesis.tex

@@ -139,7 +139,7 @@
 \include{Preparation/preparation}
 \include{Implementation/implementation}
 \include{Evaluation/evaluation}
-\include{Chapter5/chapter5}
+\include{Conclusions/conclusions}
 
 
 % ********************************** Back Matter *******************************