From 200c8ba0043a2be378815356d12f676c0c8bdb16 Mon Sep 17 00:00:00 2001 From: Qubasa Date: Mon, 16 Feb 2026 21:19:41 +0100 Subject: [PATCH] Finished cover page --- Chapters/Methodology.tex | 25 +++++++++++++------------ Chapters/Motivation.tex | 24 ++++++++++++++++-------- main.tex | 12 +++++++----- 3 files changed, 36 insertions(+), 25 deletions(-) diff --git a/Chapters/Methodology.tex b/Chapters/Methodology.tex index 341294f..35cb6c4 100755 --- a/Chapters/Methodology.tex +++ b/Chapters/Methodology.tex @@ -6,8 +6,8 @@ This chapter describes the methodology used to benchmark peer-to-peer mesh VPN implementations. The experimental design prioritizes -reproducibility at every layer---from dependency management to network -conditions---enabling independent verification of results and +reproducibility at every layer; from dependency management to network +conditions; enabling independent verification of results and facilitating future comparative studies. \section{Experimental Setup} @@ -20,7 +20,8 @@ identical specifications: \begin{itemize} \item \textbf{CPU:} Intel Model 94, 4 cores / 8 threads \item \textbf{Memory:} 64 GB RAM - \item \textbf{Network:} 1 Gbps Ethernet (e1000e driver; one machine uses r8169) + \item \textbf{Network:} 1 Gbps Ethernet (e1000e driver; one machine + uses r8169) \item \textbf{Cryptographic acceleration:} AES-NI, AVX, AVX2, PCLMULQDQ, RDRAND, SSE4.2 \end{itemize} @@ -56,7 +57,8 @@ mesh topologies. Table~\ref{tab:vpn_selection} summarizes the selection. \hline \textbf{VPN} & \textbf{Architecture} & \textbf{Notes} \\ \hline - Tailscale (Headscale) & Coordinated mesh & Open-source coordination server \\ + Tailscale (Headscale) & Coordinated mesh & Open-source + coordination server \\ ZeroTier & Coordinated mesh & Global virtual Ethernet \\ Nebula & Coordinated mesh & Slack's overlay network \\ Tinc & Fully decentralized & Established since 1998 \\ @@ -208,9 +210,9 @@ effective round-trip impairment is approximately doubled. \begin{tabular}{lccccc} \hline \textbf{Profile} & \textbf{Latency} & \textbf{Jitter} & - \textbf{Loss} & \textbf{Reorder} & \textbf{Correlation} \\ + \textbf{Loss} & \textbf{Reorder} & \textbf{Correlation} \\ \hline - Baseline & --- & --- & --- & --- & --- \\ + Baseline & ; & ; & ; & ; & ; \\ Low & 2 ms & 2 ms & 0.25\% & 0.5\% & 25\% \\ Medium & 4 ms & 7 ms & 1.0\% & 2.5\% & 50\% \\ High & 12 ms & 30 ms & 5.0\% & 10\% & 50\% \\ @@ -289,7 +291,8 @@ Key pinned inputs include: \item \textbf{nixpkgs:} Follows \texttt{clan-core/nixpkgs}, ensuring a single version across the dependency graph \item \textbf{clan-core:} The Clan framework, pinned to a specific commit - \item \textbf{VPN sources:} Hyprspace, EasyTier, Nebula locked to exact commits + \item \textbf{VPN sources:} Hyprspace, EasyTier, Nebula locked to + exact commits \item \textbf{Build infrastructure:} flake-parts, treefmt-nix, disko, nixos-facter-modules \end{itemize} @@ -312,7 +315,7 @@ configuration entirely or rolls back. Clan's inventory system maps machines to service roles declaratively. For each VPN, the orchestrator writes an inventory entry assigning machines to roles (e.g., Nebula lighthouse vs.\ peer). The Clan module -system translates this into NixOS configuration---systemd services, +system translates this into NixOS configuration; systemd services, firewall rules, peer lists, and key references. The same inventory entry always produces the same NixOS configuration. @@ -364,12 +367,11 @@ environments across benchmark runs. Lackorzynski et al.\ \cite{lackorzynski_comparative_2019} evaluate VPN protocols in the context of industrial communication systems (Industry 4.0), benchmarking OpenVPN, IPSec, Tinc, Freelan, MACsec, and WireGuard. -Their analysis focuses on point-to-point protocol performance---throughput, -latency, and CPU overhead---rather than overlay network behavior. +Their analysis focuses on point-to-point protocol performance; throughput, +latency, and CPU overhead; rather than overlay network behavior. In contrast, this thesis evaluates VPNs that provide a full data plane with peer-to-peer connectivity, NAT traversal, and dynamic peer discovery. - \subsection{Full-Mesh VPN Performance Evaluation} Kjorveziroski et al.\ \cite{kjorveziroski_full-mesh_2024} provide a @@ -388,4 +390,3 @@ This thesis extends their work in several ways: \item Fully reproducible experimental framework via Nix/NixOS/Clan \end{itemize} - diff --git a/Chapters/Motivation.tex b/Chapters/Motivation.tex index 18e88f8..ebdd035 100644 --- a/Chapters/Motivation.tex +++ b/Chapters/Motivation.tex @@ -3,8 +3,10 @@ \label{Motivation} 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 +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. @@ -14,7 +16,8 @@ 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 cloud providers. -More concerning, these providers operate under overlapping regulatory jurisdictions, +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, @@ -28,7 +31,8 @@ data disclosure, or traffic manipulation across a majority of the network. \label{fig:ethernodes_hosting} \end{figure} -Why does this centralization persist despite the explicit goals of decentralization? +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 @@ -36,8 +40,10 @@ 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. +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, @@ -57,7 +63,8 @@ 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. +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 @@ -79,7 +86,8 @@ benchmarks a subset of mesh 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, +Furthermore, that study relied exclusively on iperf3 for performance +measurement, whereas our benchmark suite includes real-world workloads to better reflect practical usage patterns. diff --git a/main.tex b/main.tex index 13ce769..95d5f2e 100644 --- a/main.tex +++ b/main.tex @@ -152,17 +152,19 @@ and Management}} % Your department's name and URL, this is used in \begin{minipage}[t]{0.4\textwidth} \begin{flushleft} \large \emph{Author:}\\ - \href{http://www.johnsmith.com}{\authorname} % Author name - - % remove the \href bracket to remove the link + \textcolor{mdtRed}{\authorname} \end{flushleft} \end{minipage} \begin{minipage}[t]{0.4\textwidth} \begin{flushright} \large + \emph{First Examiner:} \\ + \textcolor{mdtRed}{Prof.\ Dr.\ \textsc{Stefan Schmidt}}\\[1em] + \emph{Second Examiner:} \\ + \textcolor{mdtRed}{\textsc{[TBD]}}\\[1em] \emph{Supervisor:} \\ - \href{http://www.jamessmith.com}{\supname} % Supervisor name - % - remove the \href bracket to remove the link + \textcolor{mdtRed}{\supname} \end{flushright} - \end{minipage}\\[3cm] + \end{minipage}\\[2cm] \vfill