diff --git a/Chapters/Motivation.tex b/Chapters/Motivation.tex index 631cd28..8708bae 100644 --- a/Chapters/Motivation.tex +++ b/Chapters/Motivation.tex @@ -2,68 +2,23 @@ \label{Motivation} -This thesis emerged from two interconnected research directions. -The initial focus was the Clan deployment framework, -which leverages Nix and NixOS to eliminate -entire classes of errors prevalent in contemporary infrastructure deployment. -By doing so, Clan reduces operational overhead to a degree -where a single administrator can reliably self-host -complex distributed services at scale. +Peer-to-peer architectures promise censorship-resistant, fault-tolerant +infrastructure by eliminating single points of failure \cite{shukla_towards_2021}. +These architectures underpin a growing range of systems---from IoT edge computing +and content delivery networks to blockchain platforms like Ethereum. +Yet realizing these benefits requires distributing nodes across +genuinely diverse hosting entities. -During the development of the Clan framework, -which depends heavily on overlay VPNs for secure peer connectivity, -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 -rather than systematic evaluation. -This observation revealed a clear need for -rigorous, evidence-based comparison of Peer-to-Peer overlay VPN implementations. - -However, existing research on benchmarking peer-to-peer overlay networks -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 -on solutions with a central point of failure. -In contrast, this thesis evaluates more widely adopted 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 -to better reflect practical usage patterns. - -A further motivation for this work was to create a fully automated -benchmarking framework 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, -we hope to encourage P2P VPN developers to optimize their implementations -in pursuit of top rankings. - -\begin{figure}[H] - \centering - \includegraphics[width=1\textwidth]{Figures/krause-js-framework.png} - \caption{js-framework-benchmark results for Chrome 144.0 - \cite{krause_krausestjs-framework-benchmark_2026}} - \label{fig:js-framework-benchmark} -\end{figure} - -\subsection{The Case for Decentralized Self-Hosting} - -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: +In practice, this diversity remains illusory. 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. +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 @@ -73,38 +28,78 @@ a handful of providers subject to common regulatory jurisdictions. \label{fig:ethernodes_hosting} \end{figure} -This centralization persists because self-hosting remains prohibitively complex. -Key challenges include: +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. -\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. +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. - \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. +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. -\begin{figure}[h!] +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 were largely grounded in anecdotal evidence +rather than systematic evaluation. +This observation revealed a clear need for rigorous, +evidence-based comparison of peer-to-peer overlay VPN implementations. + +Existing research on this topic 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 overlay VPNs but focuses primarily +on solutions with a central point of failure. +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 real-world workloads +to better reflect practical usage patterns. + +A further motivation was to create a fully automated benchmarking framework +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, +we hope to encourage P2P VPN developers to optimize their implementations +in pursuit of top rankings. + +\begin{figure}[H] + \centering + \includegraphics[width=1\textwidth]{Figures/krause-js-framework.png} + \caption{js-framework-benchmark results for Chrome 144.0 + \cite{krause_krausestjs-framework-benchmark_2026}} + \label{fig:js-framework-benchmark} +\end{figure} + +\begin{figure}[h] \centering % Row 1