really good motivation section
This commit is contained in:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user