Update on Overleaf.

Evaluation/evaluation.tex

@@ -103,7 +103,7 @@ The network structure of all standard tests is shown in figure \ref{fig:standard
 
 \subsection{Flow Maintained}
 
-TODO.
+\mynote{Write and gather results.}
 
 \subsection{Bidirectional Performance Gains}
 
@@ -152,7 +152,7 @@ This goal was to ensure the Client could use its network interface as if it real
 
 \subsection{Security}
 
-TODO.
+\mynote{Write this.}
 
 \subsection{More Bandwidth over Two Equal Connections}
 
@@ -213,7 +213,7 @@ It can be seen in the graph that the bandwidth initially stabilises at approxima
 
 \subsection{Connection Loss}
 
-TODO.
+\mynote{Write this.}
 
 \subsection{Single Interface Remote Portal}
 
@@ -253,7 +253,7 @@ The project is only tested with IPv4.
 
 \subsection{UDP Proxy Flows}
 
-TODO
+\mynote{Write this.}
 
 \subsection{IP Proxy Packets}
 
@@ -266,13 +266,13 @@ The discussion of success criteria above used slow network connections to test s
 
 \subsection{Faster Connections Scaling}
 
-TODO
+\mynote{Write this.}
 
 \subsection{Number of Connections Scaling}
 
-TODO
+\mynote{Write this.}
 
 \subsection{Real World Testing}
 
-TODO
+\mynote{Write this.}
 

Introduction/introduction.tex

@@ -21,13 +21,13 @@ MultiPath TCP (Handley et al., “TCP Extensions for Multipath Operation with Mu
 
 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.
 
-TODO: IPv6 autoconf wrt. multihoming
+\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.
 
-TODO: Find a study on how many of the connections on the Internet are TCP or UDP, particularly over time
+\mynote{Find a study on how many of the connections on the Internet are TCP or UDP, particularly over time.}
 
 \section{Aims}
 

Proforma/proforma.tex

@@ -2,6 +2,6 @@
 
 \begin{proforma}
 
-TODO
+\mynote{Fill in closer to the time.}
 
 \end{proforma}