JakeHillion/dissertation-4-dissertation
1
0
Fork 0
Code Issues Pull Requests Releases 1 Wiki Activity

Merge branch 'master' of https://git.overleaf.com/5fd37aafb26bc430615b7f18

Browse Source
This commit is contained in:
Jake Hillion 2021-05-14 11:14:36 +01:00
commit 25dd9d27c8
2 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
1_Introduction/introduction.tex
View File

@ -19,11 +19,11 @@ Using a proxy to combine connections provides three significant benefits: immedi
\section{Existing Work}
Three pieces of existing work that will be examined for their usefulness are MultiPath TCP (MPTCP), Wireguard, and Cloudflare. Multipath TCP is an effort to expand TCP (Transmission Control Protocol) connections to multiple paths, and is implemented at the kernel layer such that applications which already use TCP can immediately take advantage of the multipath benefits. Wireguard is a state of the art Virtual Private Network (VPN), providing an excellent example for transmitting packets securely over the Internet. Finally, Cloudflare shows examples of how a high bandwidth network can be used to supplement multiple smaller networks, but in a different context to this project. This section focuses on how these examples do not satisfy the aims of this project, and how they provide useful initial steps and considerations for this project.
Three pieces of existing work that will be examined for their usefulness are MultiPath TCP (MPTCP), Wireguard, and Cloudflare. MPTCP is an effort to expand TCP (Transmission Control Protocol) connections to multiple paths, and is implemented at the kernel layer such that applications which already use TCP can immediately take advantage of the multipath benefits. Wireguard is a state of the art Virtual Private Network (VPN), providing an excellent example for transmitting packets securely over the Internet. Finally, Cloudflare shows examples of how a high bandwidth network can be used to supplement multiple smaller networks, but in a different context to this project. This section focuses on how these examples do not satisfy the aims of this project, and how they provide useful initial steps and considerations for this project.
\subsection{MultiPath TCP (MPTCP)}
MPTCP \citep{handley_tcp_2020} is an extension to the regular Transmission Control Protocol, allowing for the creation of subflows. MPTCP 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. Initially, MPTCP seems like a solution to the aims of this project. However, it suffers for three reasons: the rise of User Datagram Protocol (UDP) -based protocols, device knowledge of interfaces, and legacy devices.
MPTCP \citep{handley_tcp_2020} is an extension to the regular Transmission Control Protocol, allowing for the creation of subflows. MPTCP 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. Initially, MPTCP seems like a solution to the aims of this project. However, it suffers for three reasons: the rise of User Datagram Protocol (UDP)-based protocols, device knowledge of interfaces, and legacy devices.
Although many UDP-based protocols have been around for a long time, using UDP-based protocols in applications to replace TCP-based protocols is a newer effort. An example of an older UDP-based protocol is SIP \citep{schooler_sip_2002}, still widely used for VoIP, which would benefit particularly from increased resilience to single Internet connection outages. For a more recent UDP-based protocol intended to replace a TCP-based protocol, HTTP/3 \citep{bishop_hypertext_2021}, also known as HTTP-over-QUIC, is one of the largest. HTTP/3 is enabled by default in Google Chrome \citep{govindan_enabling_2020} and its derivatives, soon to be enabled by default in Mozilla Firefox \citep{damjanovic_quic_2021}, and available behind an experimental flag in Apple's Safari \citep{kinnear_boost_2020}. Previously, HTTP requests have been sent over TCP connections, but HTTP/3 switches this to a UDP-based protocol, reducing the benefit of MPTCP.
@ -39,13 +39,13 @@ For each Layer 3 packet that Wireguard transports, it generates and sends a sing
\subsection{Cloudflare}
Cloudflare is a company that uses a global network of servers to provide a variety of infrastructure products, mostly pertaining to websites and security \citep{cloudflare_cloudflare_nodate}. Two of the products offered by Cloudflare are of particular interest to this project: load balancing and magic WAN.
Cloudflare uses a global network of servers to provide a variety of infrastructure products, mostly pertaining to websites and security \citep{cloudflare_cloudflare_nodate}. Two of the products offered by Cloudflare are of particular interest to this project: load balancing and magic WAN.
Cloudflare provides the option to proxy HTTPS traffic via their global network of servers to your origin server. This layer 7 (application layer) proxy operates on the level of proxying HTTP requests themselves, and can take advantage of its knowledge of connections to provide effective load balancing between origin servers. Similarly to my project, Cloudflare can use knowledge of the responsiveness of origin servers to alter the load balancing. This is a similar use case to my proxy, where items (HTTP requests / IP packets) hit one high bandwidth server (one of Cloudflare's edge servers / the remote proxy), and this server decides which path through which to proxy the item (a chosen origin server / which connection to the local proxy).
Cloudflare provides the option to proxy HTTPS traffic via their global network of servers to your origin server. This layer 7 (application layer) proxy operates on the level of HTTP requests themselves, and takes advantage of its knowledge of connections to load balance between origin servers. Cloudflare can use knowledge of origin server responsiveness to alter the load balancing. This is a similar use case to my proxy, where items (HTTP requests / IP packets) hit one high-bandwidth server (one of Cloudflare's edge servers / the remote proxy), and this server decides the path through which to proxy the item (a chosen origin server / a connection to the local proxy).
Unlike Cloudflare load balancing, the proxy presented in this work operates on layer 3. Cloudflare receives a stream of HTTPS requests and forwards each on to a chosen origin server, while my remote proxy receives a stream of IP packets and forwards them via a chosen path to my local proxy. Though these achieve different goals, Cloudflare load balancing provides an example of using a high bandwidth edge server to manage balancing between multiple lower bandwidth endpoints.
Unlike Cloudflare load balancing, the proxy presented in this work operates on layer 3. Cloudflare receives a stream of HTTPS requests and forwards each to a chosen origin server, while my remote proxy receives a stream of IP packets and forwards them via a chosen path to my local proxy. Though these achieve different goals, Cloudflare load balancing provides an example of using a high-bandwidth edge server to manage balancing between multiple low-bandwidth endpoints.
The second product of Cloudflare's that shows some similarity to my project is Magic WAN. Cloudflare Magic WAN provides a fully software defined WAN over their global network. That is, their anycast infrastructure will accept traffic to your network at any of the edge servers in their global infrastructure before forwarding it to you. This provides some significant benefits, such as DDoS mitigation and firewalling at a far higher capacity than on your origin servers. When a DDoS attack or connections against firewall policies occur, they are cut off at the Cloudflare edge, without ever reaching the limited bandwidth of your local system.
Cloudflare Magic WAN provides a fully software-defined WAN over their global network. That is, their anycast infrastructure will accept traffic to your network at any edge server in their global infrastructure before forwarding it to you. This supports DDoS mitigation and firewalling at a far higher capacity than on your origin servers. When a DDoS attack or violation of firewall policies occur, offending connections are cut off at the Cloudflare edge, without reaching the limited bandwidth of your local system.
Magic WAN demonstrates that there can be security benefits to moving your network edge to the cloud. By configuring to block bad traffic at the edge, the limited bandwidth connections at your origin are protected. It further demonstrates that WAN-as-a-Service is possible at a large scale, which is the same class of products as my proxy.

4
A3_OutboundGraphs/outboundgraphs.tex
View File

@ -58,11 +58,11 @@ Connecting to host X.X.X.Y, port 5201
\begin{figure}
\centering
\begin{subfigure}{.7\textwidth}
\includegraphics[width=0.9\linewidth]{graphs/more-bandwidth-equal-a-inbound}
\includegraphics[width=0.9\linewidth]{4_Evaluation/Figs/graphs/more-bandwidth-equal-a-outbound}
\caption{Throughput of 1+1MB/s connections compared with 1MB/s and 2MB/s (outbound).}
\end{subfigure}
\begin{subfigure}{.7\textwidth}
\includegraphics[width=0.9\linewidth]{graphs/more-bandwidth-equal-b-inbound}
\includegraphics[width=0.9\linewidth]{4_Evaluation/Figs/graphs/more-bandwidth-equal-b-outbound}
\caption{Throughput of 2+2MB/s connections compared with 2MB/s and 4MB/s (outbound).}
\end{subfigure}
\caption{Graphs showing that the throughput of two connections proxied lie between one connection of the same speed and one connection of double the speed}