diff --git a/project-proposal.tex b/project-proposal.tex
index 55a39aa..9256faf 100644
--- a/project-proposal.tex
+++ b/project-proposal.tex
@@ -16,7 +16,7 @@ This project attempts to combine multiple heterogeneous network connections into
 
 The speed focus of this software is achieved by providing a single virtual connection which aggregates the speed of the individual connections. As this single connection is all that’s made visible to the client, all applications and protocols can benefit from the speed benefits, as they require no knowledge of how their packets are being split. As an example, a live video stream that only uses one flow will be able to use the full capacity of the virtual connection.
 
-The resilience focus provides similar benefits, in that the virtual connection conceals the failing of a connection from the client and applications. This again means that applications and protocols not built to handle a network failover can benefit from the resilience provided by this solution. An example is a SIP call continuing without a redial.
+The resilience focus provides similar benefits, in that the virtual connection conceals the failing of any individual network connections from the client and applications. This again means that applications and protocols not built to handle a network failover can benefit from the resilience provided by this solution. An example is a SIP call continuing without a redial.
 
 This system is useful in areas where multiple low bandwidth connections are available, but not a single higher bandwidth connection. This is often the case in rural areas in the UK. It will also be useful in areas with diverse connections of varying reliability, such as a home with both DSL and wireless connections, which may become more common with the advent of 5G and LEO systems such as Starlink. The lack of requirement for vendor support allows for this mixture of connections to be supported.
 
@@ -36,7 +36,7 @@ Some existing attempts to solve these problems, and the shortfalls of each solut
 
 \end{itemize}
 
-By providing congestion control over each interface and therefore being able to share packets without bias between connections, this project should provide a superior solution for load balancing across heterogeneous and volatile network connections. An example of a client using this is shown in Figure \ref{fig:sample-network}. It's worth noting that this solution is highly flexible, allowing the client to be a NAT Router with more devices behind it, or the flows from the Local Server to the Remote Server being tunnelled over a VPN.
+By providing congestion control over each interface and therefore being able to share packets without bias between connections, this project should provide a superior solution for load balancing across heterogeneous and volatile network connections. An example of a client using this is shown in Figure \ref{fig:sample-network}. This solution is highly flexible, allowing the client to be a NAT Router with more devices behind it, or the flows from the Local Portal to the Remote Portal being tunnelled over a VPN.
 
 \begin{figure}
   \centering
@@ -46,12 +46,12 @@ By providing congestion control over each interface and therefore being able to
 
     % Nodes
     \node[squarednode] (client) {Client};
-    \node[squarednode] (localserver)    [right=of client]                       {Local Server};
+    \node[squarednode] (localserver)    [right=of client]                       {Local Portal};
 
     \node[squarednode] (modema)       [above right=0.5 and 1 of localserver]    {Modem A};
     \node[squarednode] (modemb)       [below right=0.5 and 1 of localserver]    {Modem B};
 
-    \node[squarednode] (remoteserver) [below right=0.5 and 1 of modema]         {Remote Server};
+    \node[squarednode] (remoteserver) [below right=0.5 and 1 of modema]         {Remote Portal};
 
     \node[squarednode] (webserver)    [above right=of remoteserver]             {Web Server};
     \node[squarednode] (voipserver)   [right=of remoteserver]                   {VoIP Server};
@@ -79,15 +79,15 @@ By providing congestion control over each interface and therefore being able to
 
 I have spent some time looking into the shortfalls and benefits of the available methods for combining multiple Internet connections. The Part IB course \emph{Computer Networking} has provided the background information for this project. I have significant experience with Go, though none with lower level networking. I have no experience with Rust, and my C++ experience is limited to the Part IB course \emph{Programming in C and C++}.
 
-I have some knowledge of the Wireguard project, though as a user instead of a programmer. I intend for this to inspire the interaction between the user and the project, though this will not be in the form of code.
+While I am not aware of any existing software that accomplishes the task that I propose, Wireguard performs a similar task of tunnelling between a local and remote node, has a well regarded interface, and is a well structured project, providing both inspiration and an initial model for the structure of my project.
 
 \section*{Substance and Structure of the Project}
 
-The system will involve load balancing multiple congestion controlled flows between the Local Server and the Remote Server. The Local Server will receive packets from the client, and use load balancing and congestion control algorithms to send individual packets along one of the multiple available connections to the Remote Server, which will extract the original packets and forward them along a high bandwidth connection to the wider network.
+The system will involve load balancing multiple congestion controlled flows between the Local Portal and the Remote Portal. The Local Portal will receive packets from the client, and use load balancing and congestion control algorithms to send individual packets along one of the multiple available connections to the Remote Portal, which will extract the original packets and forward them along a high bandwidth connection to the wider network.
 
 To achieve this congestion control, I will initially use TCP flows, which include congestion control. However, TCP also provides other guarantees, which will not benefit this task. For this reason, the application should be structured in such a way that it can support alternative protocols to TCP. An improved alternative is using UDP datagrams with a custom congestion control protocol, that only guarantees congestion control as opposed to packet delivery. Another alternative solution would be a custom IP packet with modified source and destination addresses and a custom preamble. Having a variety of techniques available would be very useful, as each of these has less overhead than the last, while also being less likely to work with more complicated network setups.
 
-When the Local Server has a packet it wishes to send outbound, it will place the packet and some additional security data in a queue. The multiple congestion controlled links will each be consuming from this queue when they are not congested. This will cause greedy load balancing, where each connection takes all that it can get from the packet queue. As congestion control algorithms adapt to the present network conditions, this load balancing will alter the balance between links as the capacity of each link changes.
+When the Local Portal has a packet it wishes to send outbound, it will place the packet and some additional security data in a queue. The multiple congestion controlled links will each be consuming from this queue when they are not congested. This will cause greedy load balancing, where each connection takes all that it can get from the packet queue. As congestion control algorithms adapt to the present network conditions, this load balancing will alter the balance between links as the capacity of each link changes.
 
 Security is an important consideration in this project. Creating a multipath connection and proxies in general can create additional attack vectors, so I will perform a review of some existing security literature for each of these. However, as the tunnel created here transports entire IP packets, any security added by the application or transport layer will be maintained by my solution.
 
@@ -138,12 +138,12 @@ A sample network is provided in Figure \ref{fig:sample-network-session-based}.
 A sample network is provided in Figure \ref{fig:sample-network}.
 
 \begin{enumerate}
-  \item Local Server receives the packet from the client.
-  \item Local Server wraps the packet with additional information.
-  \item Local Server sends the wrapped packet along whichever connection has available capacity.
-  \item Wrapped packet travels across the Internet to the Remote Server.
-  \item Remote Server receives the packet.
-  \item Remote Server dispatches the unwrapped packet via its high speed WAN interface.
+  \item Local Portal receives the packet from the client.
+  \item Local Portal wraps the packet with additional information.
+  \item Local Portal sends the wrapped packet along whichever connection has available capacity.
+  \item Wrapped packet travels across the Internet to the Remote Portal.
+  \item Remote Portal receives the packet.
+  \item Remote Portal dispatches the unwrapped packet via its high speed WAN interface.
   \item Destination receives the packet.
 \end{enumerate}
 
@@ -151,11 +151,11 @@ A sample network is provided in Figure \ref{fig:sample-network}.
 \section*{Success Criteria}
 \begin{enumerate}
 
-  \item Allow either a TCP flow or a UDP flow to continue if one or more (but not all) of the connections between the Local Server and the Remote Server are lost.
+  \item Allow either a TCP flow or a UDP flow to continue if one or more (but not all) of the connections between the Local Portal and the Remote Portal are lost.
 
   \item Any and all performance gains stated below should function bidirectionally (inbound/outbound to/from the client).
 
-  \item Allow the network client behind the main client to treat its IP address on the link to the Local Server as the IP of the Remote Server.
+  \item Allow the network client behind the main client to treat its IP address on the link to the Local Portal as the IP of the Remote Portal.
 
   \item Provide security that is no worse than not using this solution at all.
 
@@ -163,7 +163,7 @@ A sample network is provided in Figure \ref{fig:sample-network}.
 
   \item Demonstrate that a flow can be maintained over two connections of equal bandwidth with this solution if one of the connections becomes unavailable.
 
-  \item Provide full support for both IPv4 and IPv6. This includes reaching the Remote Server over IPv6 but proxying IPv4 packets, and vice versa.
+  \item Provide full support for both IPv4 and IPv6. This includes reaching the Remote Portal over IPv6 but proxying IPv4 packets, and vice versa.
 
 \end{enumerate}
 
@@ -178,7 +178,7 @@ A sample network is provided in Figure \ref{fig:sample-network}.
 
   \item Demonstrate that if one of two connections is lost and then regained, the bandwidth available reaches the levels of before the connection was lost.
 
-  \item My initial design requires the Remote Server to have two interfaces: one for communicating with the Local Server, and one for communicating with the wider network. This criteria is achieved by supporting both of these actions over one interface.
+  \item My initial design requires the Remote Portal to have two interfaces: one for communicating with the Local Portal, and one for communicating with the wider network. This criteria is achieved by supporting both of these actions over one interface.
 
   \item Support a metric value for connections, such that connections with higher metrics are only used for load balancing if no connection with a lower metric is available.
 
@@ -210,21 +210,21 @@ Milestone: Example programs in each language that read all packets from a specif
 Set up the infrastructure to effectively test any produced work from this point onwards.
 
 \noindent \\
-Milestone: A virtual router acting as a virtual Internet for these tests. 3 standard VMs below this level for each: the Local Server, the Remote Server and a speed test server to host iPerf3. Behind the Local Server should be another virtual machine, acting as the client to test the speed from. Backups of this setup should also have been made.
+Milestone: A virtual router acting as a virtual Internet for these tests. 3 standard VMs below this level for each: the Local Portal, the Remote Portal and a speed test server to host iPerf3. Behind the Local Portal should be another virtual machine, acting as the client to test the speed from. Backups of this setup should also have been made.
 
 \subsection*{16/11/2020 - 29/11/2020 (Weeks 6-7)}
 
-This section should focus on the security of the application. This would include the ability for someone to maliciously use a Remote Server to perform a DoS attack. Draft the introduction chapter.
+This section should focus on the security of the application. This would include the ability for someone to maliciously use a Remote Portal to perform a DoS attack. Draft the introduction chapter.
 
 \noindent \\
 Milestone: An analysis of how the security of this solution compares, both with other multipath solutions and a network without any multipath solution applied. A drafted introduction chapter.
 
 \subsection*{30/11/2020 - 20/12/2020 (Weeks 8-10)}
 
-Implementation of the transport aspect of the Local Server and Remote Server. The first data structure for transport should also be created. This does not include the load sharing between connections - it is for a single connection. To enable testing, this will also require the setup of configuration options for each side. At this stage, it would be reasonable for the Remote Server to require two different IPs - one for server communication, and one as the public IP of the Local Router. The initial implementation should use TCP, but if time is available, UDP with a custom datagram should be explored for reduced overhead.
+Implementation of the transport aspect of the Local Portal and Remote Portal. The first data structure for transport should also be created. This does not include the load sharing between connections - it is for a single connection. To enable testing, this will also require the setup of configuration options for each side. At this stage, it would be reasonable for the Remote Portal to require two different IPs - one for server communication, and one as the public IP of the Local Router. The initial implementation should use TCP, but if time is available, UDP with a custom datagram should be explored for reduced overhead.
 
 \noindent \\
-Milestone: A piece of software that can act either as the Local Server or Remote Server based on configuration. Any IP packets sent to the Local Server should emerge from the Remote Server.
+Milestone: A piece of software that can act either as the Local Portal or Remote Portal based on configuration. Any IP packets sent to the Local Portal should emerge from the Remote Portal.
 
 \subsection*{21/12/2020 - 10/01/2021 (Weeks 11-13)}
 
@@ -238,7 +238,7 @@ Milestone: Mock connections and tests for the existing single transport. A final
 Implement the load balancing between multiple connections for both servers. At this point, connection losses should be tested too. The progress report is due soon after this work segment, so that should be completed in here.
 
 \noindent \\
-Milestone: The Local Server and Remote Server are capable of balancing load between multiple connections. They can also suffer a network failure of all but one connection with minimal packet loss. The progress report should be prepared.
+Milestone: The Local Portal and Remote Portal are capable of balancing load between multiple connections. They can also suffer a network failure of all but one connection with minimal packet loss. The progress report should be prepared.
 
 \subsection*{08/02/2021 - 21/02/2021 (Weeks 18-19)}