Finished cover page

.gitignore

@@ -1,4 +1,5 @@
 # LaTeX intermediate and output files
+result
 *.aux
 **/*.bak.*
 *.bbl

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 \\
@@ -210,7 +212,7 @@ effective round-trip impairment is approximately doubled.
     \textbf{Profile} & \textbf{Latency} & \textbf{Jitter} &
     \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}
 
-

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.
 

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