several fixups discussed on tuesday

2026-03-06 17:34:31 +01:00
parent ec32331bae
commit c168a1b441
5 changed files with 102 additions and 129 deletions
--- a/Chapters/Methodology.tex
+++ b/Chapters/Methodology.tex
@@ -72,53 +72,6 @@ and reordering. These impairments are applied symmetrically on all
 machines, meaning effective round-trip impairment is approximately
 double the per-machine values.

-\section{VPNs Under Test}
-
-Ten VPN implementations were selected for evaluation, spanning a range
-of architectures from centralized coordination to fully decentralized
-mesh topologies. Table~\ref{tab:vpn_selection} summarizes the selection.
-
-\begin{table}[H]
-  \centering
-  \caption{VPN implementations included in the benchmark}
-  \label{tab:vpn_selection}
-  \begin{tabular}{lll}
-    \hline
-    \textbf{VPN} & \textbf{Architecture} & \textbf{Notes} \\
-    \hline
-    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 \\
-    Yggdrasil & Fully decentralized & Spanning-tree routing \\
-    Mycelium & Fully decentralized & End-to-end encrypted IPv6 overlay \\
-    Hyprspace & Fully decentralized & libp2p-based, IPFS-compatible \\
-    EasyTier & Fully decentralized & Rust-based, multi-protocol \\
-    VpnCloud & Fully decentralized & Lightweight, kernel bypass option \\
-    WireGuard & Point-to-point & Reference baseline (not a mesh VPN) \\
-    \hline
-    Internal (no VPN) & N/A & Baseline for raw network performance \\
-    \hline
-  \end{tabular}
-\end{table}
-
-WireGuard is included as a reference point despite not being a mesh VPN.
-Its minimal overhead and widespread adoption make it a useful comparison
-for understanding the cost of mesh coordination and NAT traversal logic.
-
-\subsection{Selection Criteria}
-
-VPNs were selected based on:
-\begin{itemize}
-    \bitem{NAT traversal capability:} All selected VPNs can establish
-    connections between peers behind NAT without manual port forwarding.
-    \bitem{Decentralization:} Preference for solutions without mandatory
-    central servers, though coordinated-mesh VPNs were included for comparison.
-    \bitem{Active development:} Only VPNs with recent commits and
-    maintained releases were considered.
-    \bitem{Linux support:} All VPNs must run on Linux.
-\end{itemize}

 \subsection{Configuration Methodology}

@@ -129,12 +82,7 @@ under \texttt{pkgs/} in the flake.

 Cryptographic material (WireGuard keys, Nebula certificates, ZeroTier
 identities) is generated deterministically via Clan's vars generator
-system. For example, WireGuard keys are generated as:
-
-\begin{verbatim}
-wg genkey > "$out/private-key"
-wg pubkey < "$out/private-key" > "$out/public-key"
-\end{verbatim}
+system. 

 Generated keys are stored in version control under
 \texttt{vars/per-machine/\{name\}/} and read at NixOS evaluation time,
@@ -273,11 +221,6 @@ bursts, because a packet that was lost or reordered increases the
 probability that the next packet suffers the same fate. This produces
 realistic bursty degradation rather than uniformly distributed drops.

-The ``Low'' profile approximates a well-provisioned continental
-connection, ``Medium'' represents intercontinental links or congested
-networks, and ``High'' simulates severely degraded conditions such as
-satellite links or highly congested mobile networks.
-
 A 30-second stabilization period follows TC application before
 measurements begin, allowing queuing disciplines to settle.

@@ -405,6 +348,8 @@ typical observations, while min and max capture outlier behavior.
 The nix-cache benchmark additionally reports standard deviation via
 hyperfine's built-in statistical output.

+
+
 \section{Source Code Analysis}

 To complement the performance benchmarks with architectural
@@ -571,3 +516,53 @@ test-specific payload, and a \texttt{meta} object recording
 wall-clock duration, number of attempts, VPN restart count and
 duration, connectivity wait time, source and target machine names,
 and on failure, the relevant service logs.
+
+
+
+\section{VPNs Under Test}
+
+VPNs were selected based on:
+\begin{itemize}
+    \bitem{NAT traversal capability:} All selected VPNs can establish
+    connections between peers behind NAT without manual port forwarding.
+    \bitem{Decentralization:} Preference for solutions without mandatory
+    central servers, though coordinated-mesh VPNs were included for comparison.
+    \bitem{Active development:} Only VPNs with recent commits and
+    maintained releases were considered (with the exception of VPN Cloud).
+    \bitem{Linux support:} All VPNs must run on Linux.
+\end{itemize}
+
+
+Ten VPN implementations were selected for evaluation, spanning a range
+of architectures from centralized coordination to fully decentralized
+mesh topologies. Table~\ref{tab:vpn_selection} summarizes the selection.
+
+\begin{table}[H]
+  \centering
+  \caption{VPN implementations included in the benchmark}
+  \label{tab:vpn_selection}
+  \begin{tabular}{lll}
+    \hline
+    \textbf{VPN} & \textbf{Architecture} & \textbf{Notes} \\
+    \hline
+    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 \\
+    Yggdrasil & Fully decentralized & Spanning-tree routing \\
+    Mycelium & Fully decentralized & End-to-end encrypted IPv6 overlay \\
+    Hyprspace & Fully decentralized & libp2p-based, IPFS-compatible \\
+    EasyTier & Fully decentralized & Rust-based, multi-protocol \\
+    VpnCloud & Fully decentralized & Lightweight, kernel bypass option \\
+    WireGuard & Point-to-point & Reference baseline (not a mesh VPN) \\
+    \hline
+    Internal (no VPN) & N/A & Baseline for raw network performance \\
+    \hline
+  \end{tabular}
+\end{table}
+
+WireGuard is included as a reference point despite not being a mesh VPN.
+Its minimal overhead and widespread adoption make it a useful comparison
+for understanding the cost of mesh coordination and NAT traversal logic.
+
--- a/Chapters/Preliminaries.tex
+++ b/Chapters/Preliminaries.tex
@@ -1,44 +0,0 @@
-\chapter{Preliminaries} % Main chapter title
-
-\label{Preliminaries}
-
-\subsection{Nix: A Safe and Policy-Free System for Software Deployment}
-
-Nix addresses significant issues in software deployment by utilizing
-cryptographic hashes to ensure unique paths for component instances
-\cite{dolstra_nix_2004}. Features such as concurrent installation of
-multiple versions, atomic upgrades, and safe garbage collection make
-Nix a flexible deployment system. This work uses Nix to ensure that
-all VPN builds and system configurations are deterministic.
-
-\subsection{NixOS: A Purely Functional Linux Distribution}
-
-NixOS extends Nix principles to Linux system configuration
-\cite{dolstra_nixos_2008}. System configurations are reproducible and
-isolated from stateful interactions typical in imperative package
-management. This property is essential for ensuring identical test
-environments across benchmark runs.
-
-\subsection{UDP NAT and Firewall Puncturing in the Wild}
-
-Halkes and Pouwelse~\cite{halkes_udp_2011} measure UDP hole punching
-efficacy on a live P2P network using the Tribler BitTorrent client.
-Their study finds that 79\% of peers are unreachable due to NAT or
-firewall restrictions, yet 64\% reside behind configurations amenable
-to hole punching. Among compatible peers, over 80\% of puncturing
-attempts succeed, establishing hole punching as a practical NAT
-traversal technique. Their timeout measurements further indicate that
-keep-alive messages must be sent at least every 55 seconds to maintain
-open NAT mappings.
-
-These findings directly inform the evaluation criteria for this thesis.
-All mesh VPNs tested rely on UDP hole punching for NAT traversal;
-the 80\% success rate sets a baseline expectation, while the 55-second
-timeout informs analysis of each implementation's keep-alive behavior
-during source code review.
-
-\subsection{An Overview of Packet Reordering in TCP}
-TODO \cite{leung_overview_2007}
-
-\subsection{Performance Evaluation of  TCP over QUIC Tunnels}
-TODO \cite{guo_implementation_2025}
--- a/Chapters/Results.tex
+++ b/Chapters/Results.tex
@@ -12,9 +12,11 @@ The chapter concludes with findings from the source code analysis.

 \section{Baseline Performance}

-Under the baseline impairment profile (no added latency, loss, or
-reordering), the overhead introduced by each VPN relative to the
-internal (no VPN) baseline and WireGuard can be measured in isolation.
+
+
+% Under the baseline impairment profile (no added latency, loss, or
+% reordering), the overhead introduced by each VPN relative to the
+% internal (no VPN) baseline and WireGuard can be measured in isolation.

 \subsection{Throughput Overhead}

--- a/MastersDoctoralThesis.cls
+++ b/MastersDoctoralThesis.cls
@@ -250,8 +250,7 @@
 \newcommand{\decoRule}{\rule{.8\textwidth}{.4pt}} % New command for a
 % rule to be used under figures

-\setcounter{tocdepth}{3} % The depth to which the document sections
-% are printed to the table of contents
+\setcounter{tocdepth}{1} % Only show chapters and sections in table of contents
 \ProvideDocumentCommand{\addchaptertocentry}{ m }{%
  \addcontentsline{toc}{chapter}{#1}%
 }
@@ -390,8 +389,6 @@ KOMA-script documentation for details.}]{fancyhdr}
      {\normalsize \degreename\par}% Degree name
      \bigskip
      {\normalsize\bfseries \@title \par}% Thesis title
-      \medskip
-      {\normalsize \byname{} \authorname \par}% Author name
      \bigskip
    \end{center}
  }
--- a/main.tex
+++ b/main.tex
@@ -76,7 +76,7 @@
 \newcommand{\bitem}[1]{
 \item \textbf{#1}}

-\setcounter{secnumdepth}{1} % Only number chapters and sections, not subsections
+\setcounter{secnumdepth}{0} % Only number chapters, not sections or subsections

 %----------------------------------------------------------------------------------------
 %  MARGIN SETTINGS
@@ -95,8 +95,7 @@
 %  THESIS INFORMATION
 %----------------------------------------------------------------------------------------

-\thesistitle{A Reproducible Analysis of P2P
-VPN Implementation and Overhead} % Your thesis title, this is used in the title
+\thesistitle{An Analysis of P2P VPN Implementation} % Your thesis title, this is used in the title
 % and abstract, print it elsewhere with \ttitle
 %\supervisor{\textsc{Ber Lorke}} % Your supervisor's name, this is
 % used in the title page, print it elsewhere with \supname
@@ -241,16 +240,44 @@ and Management}} % Your department's name and URL, this is used in
  seven benchmarks.

  Our analysis reveals that Tailscale outperforms the Linux kernel's
-  default networking stack under degraded conditions. and tuned
-  congestion control: Reno over CUBIC, with RACK disabled to avoid
-  spurious retransmits under reordering. We validate this
-  hypothesis by re-running benchmarks with tuned kernel buffer
-  parameters, demonstrating measurable throughput improvements. This
-  investigation also uncovered several critical security
-  vulnerabilities across the evaluated VPNs.
+  default networking stack under degraded conditions, owing to its
+  userspace IP stack with tuned parameters. We confirm this by
+  re-running benchmarks with matching kernel-side tuning and observe
+  comparable throughput gains. The investigation also uncovered a
+  critical security vulnerability in one of the evaluated VPNs.

 \end{abstract}

+%----------------------------------------------------------------------------------------
+%  GERMAN ABSTRACT PAGE
+%----------------------------------------------------------------------------------------
+
+\begingroup
+\renewcommand{\abstractname}{Zusammenfassung}
+\begin{abstract}
+  \addchaptertocentry{Zusammenfassung}
+
+  Diese Arbeit untersucht Peer-to-Peer-Mesh-VPNs mithilfe eines
+  reproduzierbaren, Nix-basierten Frameworks, das auf einem
+  Deployment-System namens Clan aufbaut. Wir evaluieren zehn
+  VPN-Implementierungen, darunter Tailscale (über Headscale),
+  Hyprspace, Nebula, Tinc und ZeroTier, unter vier
+  Netzwerkbeeinträchtigungsprofilen mit variierendem Paketverlust,
+  Paketumsortierung, Latenz und Jitter, was über 300 einzelne
+  Messungen in sieben Benchmarks ergibt.
+
+  Unsere Analyse zeigt, dass Tailscale unter beeinträchtigten
+  Bedingungen den Standard-Netzwerkstack des Linux-Kernels
+  übertrifft, was auf seinen Userspace-IP-Stack mit optimierten
+  Parametern zurückzuführen ist. Wir bestätigen dies, indem wir die
+  Benchmarks mit entsprechend angepassten Kernel-Parametern erneut
+  durchführen und vergleichbare Durchsatzgewinne beobachten. Die
+  Untersuchung deckte zudem eine kritische Sicherheitslücke in einem
+  der evaluierten VPNs auf.
+
+\end{abstract}
+\endgroup
+
 %----------------------------------------------------------------------------------------
 %  ACKNOWLEDGEMENTS
 %----------------------------------------------------------------------------------------
@@ -282,15 +309,6 @@ and Management}} % Your department's name and URL, this is used in

 %\listoftables % Prints the list of tables

-%----------------------------------------------------------------------------------------
-%  ABBREVIATIONS
-%----------------------------------------------------------------------------------------
-
-\section*{Abbreviations}
-\begin{acronym}[P2P] % [P2P] aligns entries to the longest label
-  \acro{P2P}{Peer to Peer}
-\end{acronym}
-
 %----------------------------------------------------------------------------------------
 %  PHYSICAL CONSTANTS/OTHER DEFINITIONS
 %----------------------------------------------------------------------------------------
@@ -339,7 +357,7 @@ and Management}} % Your department's name and URL, this is used in
 % Include the chapters of the thesis as separate files from the Chapters folder
 % Uncomment the lines as you write the chapters
 \include{Chapters/Introduction}
-\include{Chapters/Preliminaries}
+\include{Chapters/Background}
 \include{Chapters/Methodology}
 \include{Chapters/Results}
 \include{Chapters/Discussion}
@@ -361,6 +379,11 @@ and Management}} % Your department's name and URL, this is used in
 % Appendices folder
 % Uncomment the lines as you write the Appendices

+\chapter{Abbreviations}
+\begin{acronym}[P2P] % [P2P] aligns entries to the longest label
+  \acro{P2P}{Peer to Peer}
+\end{acronym}
+
 %\include{Appendices/AppendixA}
 %\include{Appendices/AppendixB}
 %\include{Appendices/AppendixC}