several fixups discussed on tuesday
This commit is contained in:
@@ -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.
|
||||
|
||||
|
||||
@@ -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}
|
||||
@@ -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}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user