really good motivation section

Chapters/Motivation.tex

@@ -2,39 +2,89 @@
 
 \label{Motivation}
 
-This thesis emerged from two interconnected research directions.
+Peer-to-peer architectures promise censorship-resistant, fault-tolerant
-The initial focus was the Clan deployment framework,
+infrastructure by eliminating single points of failure \cite{shukla_towards_2021}.
-which leverages Nix and NixOS to eliminate
+These architectures underpin a growing range of systems---from IoT edge computing
-entire classes of errors prevalent in contemporary infrastructure deployment.
+and content delivery networks to blockchain platforms like Ethereum.
-By doing so, Clan reduces operational overhead to a degree
+Yet realizing these benefits requires distributing nodes across
-where a single administrator can reliably self-host
+genuinely diverse hosting entities.
-complex distributed services at scale.
 
-During the development of the Clan framework,
+In practice, this diversity remains illusory.
-which depends heavily on overlay VPNs for secure peer connectivity,
+Amazon, Hetzner, and OVH collectively host 70\% of all Ethereum nodes
-a recurring challenge became apparent:
+(see Figure~\ref{fig:ethernodes_hosting}),
+concentrating nominally decentralized infrastructure
+within a handful of cloud providers.
+More concerning, these providers operate under overlapping regulatory jurisdictions,
+predominantly the United States and the European Union.
+This concentration undermines technical sovereignty:
+a single governmental action could compel service termination,
+data disclosure, or traffic manipulation across a majority of the network.
+
+\begin{figure}[H]
+  \centering
+  \includegraphics[width=1\textwidth]{Figures/ethernodes_hosting.png}
+  \caption{Distribution of Ethereum nodes hosted by various providers
+  \cite{noauthor_isps_nodate}}
+  \label{fig:ethernodes_hosting}
+\end{figure}
+
+Why does this centralization persist despite the explicit goals of decentralization?
+The answer lies in the practical barriers to self-hosting.
+Cloud providers offer static IP addresses and publicly routable endpoints,
+eliminating the networking complexity that plagues residential and
+small-office deployments.
+Most internet-connected devices sit behind Network Address Translation (NAT),
+which prevents incoming connections without explicit port forwarding
+or relay infrastructure.
+Combined with dynamic IP assignments from ISPs, maintaining stable peer connectivity
+from self-hosted infrastructure traditionally required significant technical expertise.
+
+Overlay VPNs offer a solution to this fundamental barrier.
+By establishing encrypted tunnels that traverse NAT boundaries,
+mesh VPNs enable direct peer-to-peer connectivity without requiring
+static IP addresses or manual firewall configuration.
+Each node receives a stable virtual address within the overlay network,
+regardless of its underlying network topology.
+This capability is transformative:
+it allows a device behind consumer-grade NAT to participate
+as a first-class peer in a distributed system,
+removing the primary technical advantage that cloud providers hold.
+
+The Clan deployment framework builds on this foundation.
+Clan leverages Nix and NixOS to eliminate entire classes of
+configuration errors prevalent in contemporary infrastructure deployment,
+reducing operational overhead to a degree where a single administrator
+can reliably self-host complex distributed services.
+Overlay VPNs are central to Clan's architecture,
+providing the secure peer connectivity that enables nodes
+to form cohesive networks regardless of their physical location or NAT situation.
+As illustrated in Figure~\ref{fig:vision-stages}, Clan envisions
+a web interface that enables users to design and deploy private P2P networks
+with minimal configuration, assisted by an integrated LLM
+for contextual guidance and troubleshooting.
+
+During the development of Clan, a recurring challenge became apparent:
 practitioners held divergent preferences for mesh VPN solutions,
 each citing different edge cases where their chosen VPN
 proved unreliable or lacked essential features.
-These discussions, however, were largely grounded in anecdotal evidence
+These discussions were largely grounded in anecdotal evidence
 rather than systematic evaluation.
-This observation revealed a clear need for
+This observation revealed a clear need for rigorous,
-rigorous, evidence-based comparison of Peer-to-Peer overlay VPN implementations.
+evidence-based comparison of peer-to-peer overlay VPN implementations.
 
-However, existing research on benchmarking peer-to-peer overlay networks
+Existing research on this topic remains sparse.
-remains sparse.
 One notable work from 2024, ``Full-mesh VPN performance evaluation
 for a secure edge-cloud continuum'' \cite{kjorveziroski_full-mesh_2024},
-benchmarks a subset of available overlay VPNs but focuses primarily
+benchmarks a subset of overlay VPNs but focuses primarily
 on solutions with a central point of failure.
-In contrast, this thesis evaluates more widely adopted VPNs
+In contrast, this thesis evaluates more widely adopted mesh VPNs
 with an emphasis on fully decentralized architectures.
 Furthermore, that study relied exclusively on iperf3 for performance measurement,
-whereas our benchmark suite includes additional real-world workloads
+whereas our benchmark suite includes real-world workloads
 to better reflect practical usage patterns.
 
-A further motivation for this work was to create a fully automated
+A further motivation was to create a fully automated benchmarking framework
-benchmarking framework capable of generating a public leaderboard,
+capable of generating a public leaderboard,
 similar in spirit to the js-framework-benchmark
 (see Figure~\ref{fig:js-framework-benchmark}).
 By providing an accessible web interface with regularly updated results,
@@ -49,62 +99,7 @@ in pursuit of top rankings.
   \label{fig:js-framework-benchmark}
 \end{figure}
 
-\subsection{The Case for Decentralized Self-Hosting}
+\begin{figure}[h]
-
-The need for reliable overlay VPNs extends beyond the Clan project.
-Peer-to-peer architectures underpin a wide range of modern systems---from
-IoT edge computing to content delivery networks and blockchain platforms
-like Ethereum---enabling censorship-resistant, fault-tolerant infrastructure
-by eliminating single points of failure \cite{shukla_towards_2021}.
-
-However, realizing these benefits requires distributing nodes across
-diverse hosting entities.
-In practice, this diversity remains elusive:
-Amazon, Hetzner, and OVH collectively host 70\% of all Ethereum nodes
-(see Figure~\ref{fig:ethernodes_hosting}),
-concentrating nominally decentralized infrastructure within
-a handful of providers subject to common regulatory jurisdictions.
-
-\begin{figure}[H]
-  \centering
-  \includegraphics[width=1\textwidth]{Figures/ethernodes_hosting.png}
-  \caption{Distribution of Ethereum nodes hosted by various providers
-  \cite{noauthor_isps_nodate}}
-  \label{fig:ethernodes_hosting}
-\end{figure}
-
-This centralization persists because self-hosting remains prohibitively complex.
-Key challenges include:
-
-\begin{itemize}
-  \item \textbf{Network Connectivity:}
-    NAT traversal, dynamic IP addresses, and firewall configurations
-    require technical workarounds such as port forwarding, relay servers,
-    or Dynamic DNS services.
-
-  \item \textbf{Security:}
-    Operators must secure data in transit, authenticate connections,
-    and defend against attacks---responsibilities that cloud providers
-    typically abstract away.
-
-  \item \textbf{Reliability:}
-    Ensuring data durability, maintaining uptime during hardware failures
-    or power outages, and handling peer churn in dynamic networks
-    demand continuous attention.
-
-  \item \textbf{Operational Overhead:}
-    System administration tasks---updates, troubleshooting, configuration
-    management---present a steep learning curve for non-technical users.
-\end{itemize}
-
-The Clan project addresses these barriers by making self-hosting
-as straightforward as using a cloud provider.
-As illustrated in Figure~\ref{fig:vision-stages}, Clan envisions
-a web interface that enables users to design and deploy private P2P networks
-with minimal configuration, assisted by an integrated LLM
-for contextual guidance and troubleshooting.
-
-\begin{figure}[h!]
   \centering
 
   % Row 1