%!TEX root = ../thesis.tex
%*******************************************************************************
%****************************** Fifth Chapter **********************************
%*******************************************************************************
\chapter{Conclusions}

% **************************** Define Graphics Path **************************
\ifpdf
    \graphicspath{{5_Conclusions/Figs/Raster/}{5_Conclusions/Figs/PDF/}{5_Conclusions/Figs/}}
\else
    \graphicspath{{5_Conclusions/Figs/Vector/}{5_Conclusions/Figs/}}
\fi

The software produced in this project provides a method of combining multiple Internet connections, prioritising throughput and resilience in the resultant aggregate connection.

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

Though this project provides an approach that can work very well in today's Internet, it's hoped that the modernisation of the Internet will make it largely redundant. At present, the solution presented in this dissertation provides a highly effective solution for combining Internet connections in the following circumstances: when a single flow needs to exceed the capacity of a single connection, when connections are unreliable and flows must be maintained, and when connections have unpredictable performance characteristics. In each of these cases, this solution can currently be implemented to provide benefits to an entire network. However, using this system involves forwarding packets, increasing latency and cost. Some further work will be presented that solves these problems in different ways.

Potential further work focuses on providing the same abilities as this work on a per-device level, as opposed to for the entire network. That is, rather than inserting a middlebox to provide a combined connection, each device would be able to observe those benefits individually. One such solution is MultiPath TCP, discussed previously, which is close to seeing deployment in the Linux kernel\footnote{\url{https://kernel.org}}. Consider the case where a mobile device, such as a laptop, connects to a WiFi network. This device gains only a single IP from this WiFi network, but the network has access to two Internet connections. To obtain optimal performance, MultiPath TCP should create a flow that takes advantage of each Internet connection. However, work is needed to establish the most effective method to achieve this. Some options are creating multiple exploratory flows and checking if they're split between IPs, or the router informing the device that more IPs are available for flows. This could be taken one step further, with an MPTCP capable router expanding a non-MPTCP capable TCP flow to MPTCP at the router level, and continuing to show it as a standard TCP flow to the end device, allowing older devices to experience the benefits of multipath.

UDP connections such as for phone calls are also seeing improvements for multipath, though less uniformly than TCP. Multipath usage with UDP flows is often highly application specific. Considering a phone call, the tiny bandwidth usage suggests that it might be feasible to simply duplicate the packets for resilience, with appropriate timing. Further work in the UDP space will likely focus on providing modern protocols with specific resilience for existing uses of UDP. Further, QUIC is seeing work on a multipath version, though this shares many similarities with MPTCP.

I learnt throughout this project the importance of producing a minimum viable product. Very early in the project, I produced a working proof of concept. Nearing the end of the project, once the design was mostly settled and with a view of how the program would be deployed, the code was refactored to produce a user friendly piece of software. This approach of fast development that did not commit early to a usage pattern served me very well with this project, as details of the deployment only became clear after some use.

To conclude, the proxy built in this project provides an effective method to combine dynamic Internet connections, that works in today's Internet. Though future work may make much of this redundant, the performance gains seen today are useful in many situations. As it becomes more common to see a variety of connections in homes, such as 5G, Low Earth Orbit and DSL, a method to combine these that dynamically adapts to the variability of the wireless connections can be a huge advantage, especially in situations where gaining a single faster link is difficult.
