clear history

.gitattributes

@@ -0,0 +1,4 @@
+*.png filter=lfs diff=lfs merge=lfs -text
+*.pdf filter=lfs diff=lfs merge=lfs -text
+*.key filter=lfs diff=lfs merge=lfs -text
+*.zip filter=lfs diff=lfs merge=lfs -text

.gitignore

@@ -0,0 +1 @@
+.vscode

paper/Makefile

@@ -0,0 +1,6 @@
+fonts:
+	./fonts/install.sh
+
+build:
+	find src -type f -name 'main.tex' | xargs tectonic
+	mv src/intro/main.pdf Introduction.pdf

paper/README.md

@@ -0,0 +1,17 @@
+# Master Thesis
+
+## Building
+
+```sh
+make -B build
+```
+
+If you don't have the right fonts installed run
+
+```sh
+make -B fonts
+```
+
+## Packages
+
+- [TUD Script](https://mirror.foobar.to/CTAN/macros/latex/contrib/tudscr/doc/tudscr.pdf)

paper/fonts/install.sh

@@ -0,0 +1,6 @@
+#!/bin/sh
+
+TARGET=~/.fonts
+mkdir -p $TARGET
+unzip -o -d "$TARGET/roboto_mono" "./fonts/Roboto_Mono.zip"
+unzip -o -d "$TARGET/open_sans" "./fonts/Open_Sans.zip"

paper/src/db.bib

@@ -0,0 +1,199 @@
+@article{jedari2018survey,
+  title     = {A survey on human-centric communications in non-cooperative wireless relay networks},
+  author    = {Jedari, Behrouz and Xia, Feng and Ning, Zhaolong},
+  journal   = {IEEE Communications Surveys \& Tutorials},
+  volume    = {20},
+  number    = {2},
+  pages     = {914--944},
+  year      = {2018},
+  publisher = {IEEE}
+}
+
+@misc{vahdat2000epidemic,
+  title     = {Epidemic routing for partially connected ad hoc networks},
+  author    = {Vahdat, Amin and Becker, David and others},
+  year      = {2000},
+  publisher = {Technical Report CS-200006, Duke University}
+}
+
+@article{lindgren2003probabilistic,
+  title     = {Probabilistic routing in intermittently connected networks},
+  author    = {Lindgren, Anders and Doria, Avri and Schel{\'e}n, Olov},
+  journal   = {ACM SIGMOBILE mobile computing and communications review},
+  volume    = {7},
+  number    = {3},
+  pages     = {19--20},
+  year      = {2003},
+  publisher = {ACM New York, NY, USA}
+}
+
+@inproceedings{burgess2006maxprop,
+  title        = {MaxProp: Routing for Vehicle-Based Disruption-Tolerant Networks.},
+  author       = {Burgess, John and Gallagher, Brian and Jensen, David D and Levine, Brian Neil and others},
+  booktitle    = {Infocom},
+  volume       = {6},
+  year         = {2006},
+  organization = {Barcelona, Spain}
+}
+
+@inproceedings{balasubramanian2007dtn,
+  title     = {DTN routing as a resource allocation problem},
+  author    = {Balasubramanian, Aruna and Levine, Brian and Venkataramani, Arun},
+  booktitle = {Proceedings of the 2007 conference on Applications, technologies, architectures, and protocols for computer communications},
+  pages     = {373--384},
+  year      = {2007}
+}
+
+@techreport{RFC9171,
+  author       = {S. Burleigh and K. Fall and E. Birrane and III},
+  title        = {Bundle Protocol Version 7},
+  howpublished = {Internet Requests for Comments},
+  type         = {RFC},
+  number       = {9171},
+  year         = {2022},
+  month        = {January},
+  issn         = {2070-1721},
+  publisher    = {RFC Editor},
+  institution  = {RFC Editor}
+}
+
+@techreport{RFC5050,
+  author       = {K. Scott and S. Burleigh},
+  title        = {Bundle Protocol Specification},
+  howpublished = {Internet Requests for Comments},
+  type         = {RFC},
+  number       = {5050},
+  year         = {2007},
+  month        = {November},
+  issn         = {2070-1721},
+  publisher    = {RFC Editor},
+  institution  = {RFC Editor},
+  url          = {http://www.rfc-editor.org/rfc/rfc5050.txt}
+}
+
+@techreport{RFC5326,
+  author       = {M. Ramadas and S. Burleigh and S. Farrell},
+  title        = {Licklider Transmission Protocol - Specification},
+  howpublished = {Internet Requests for Comments},
+  type         = {RFC},
+  number       = {5326},
+  year         = {2008},
+  month        = {September},
+  issn         = {2070-1721},
+  publisher    = {RFC Editor},
+  institution  = {RFC Editor}
+}
+
+@techreport{RFC0793,
+  author       = {Jon Postel},
+  title        = {Transmission Control Protocol},
+  howpublished = {Internet Requests for Comments},
+  type         = {STD},
+  number       = {7},
+  year         = {1981},
+  month        = {September},
+  issn         = {2070-1721},
+  publisher    = {RFC Editor},
+  institution  = {RFC Editor},
+  url          = {http://www.rfc-editor.org/rfc/rfc793.txt}
+}
+
+@techreport{RFC7323,
+  author       = {D. Borman and B. Braden and V. Jacobson and R. Scheffenegger},
+  title        = {TCP Extensions for High Performance},
+  howpublished = {Internet Requests for Comments},
+  type         = {RFC},
+  number       = {7323},
+  year         = {2014},
+  month        = {September},
+  issn         = {2070-1721},
+  publisher    = {RFC Editor},
+  institution  = {RFC Editor}
+}
+
+@techreport{RFC0768,
+  author       = {J. Postel},
+  title        = {User Datagram Protocol},
+  howpublished = {Internet Requests for Comments},
+  type         = {STD},
+  number       = {6},
+  year         = {1980},
+  month        = {August},
+  issn         = {2070-1721},
+  publisher    = {RFC Editor},
+  institution  = {RFC Editor},
+  url          = {http://www.rfc-editor.org/rfc/rfc768.txt}
+}
+
+@misc{sim-theone,
+  author  = {Ari Keränen},
+  title   = {The One},
+  year    = {2015},
+  url     = {https://github.com/akeranen/the-one},
+  urldate = {2022-07-22}
+}
+
+@misc{sim-ops,
+  author  = {Communication Networks Bremen},
+  title   = {OPS},
+  year    = {2022},
+  url     = {https://github.com/ComNets-Bremen/OPS},
+  urldate = {2022-07-22}
+}
+
+@misc{sim-ns3,
+  author  = {bit-oh-my-god},
+  title   = {ns3-dtn-bit},
+  year    = {2018},
+  url     = {https://github.com/bit-oh-my-god/ns3-dtn-bit},
+  urldate = {2022-07-22}
+}
+
+@misc{sim-dtnsim,
+  author  = {Hiroyuki Ohsaki},
+  title   = {dtnsim},
+  year    = {2021},
+  url     = {https://github.com/h-ohsaki/dtnsim},
+  urldate = {2022-07-22}
+}
+
+@misc{sim-dtn,
+  author  = {Szymon Wieloch},
+  title   = {DTN},
+  year    = {2017},
+  url     = {https://github.com/szymonwieloch/DTN},
+  urldate = {2022-07-22}
+}
+
+@techreport{burleigh2011contact,
+  title  = {Contact graph routing},
+  author = {Burleigh, Scott C},
+  year   = {2011}
+}
+
+@article{7433915,
+  author  = {},
+  journal = {IEEE Std 802.1AB-2016 (Revision of IEEE Std 802.1AB-2009)},
+  title   = {IEEE Standard for Local and metropolitan area networks - Station and Media Access Control Connectivity Discovery},
+  year    = {2016},
+  volume  = {},
+  number  = {},
+  pages   = {1-146},
+  doi     = {10.1109/IEEESTD.2016.7433915}
+}
+
+
+@online{nasa-scottburleigh-2021-1,
+  author  = {Scott Burleigh},
+  title   = {Introduction to Delay/Disruption Tolerant Networking 1.1},
+  year    = {2021},
+  url     = {https://www.youtube.com/watch?v=2RHzIxbBJgo},
+  urldate = {2022-10-07}
+}
+@online{nasa-scottburleigh-2021-2,
+  author  = {Scott Burleigh},
+  title   = {Introduction to Delay/Disruption Tolerant Networking 1.2},
+  year    = {2021},
+  url     = {https://www.youtube.com/watch?v=CXqqIauO1qQ},
+  urldate = {2022-10-07}
+}

paper/src/main.tex

@@ -0,0 +1,275 @@
+\documentclass{tudscrartcl}
+
+\usepackage[utf8]{inputenc}
+\usepackage{hyperref}
+\usepackage{acro}
+\usepackage[backend=bibtex8, style=ieee]{biblatex}
+\usepackage{graphicx}
+\usepackage{datetime}
+\usepackage{bbding}
+
+
+\iftutex
+  \usepackage{fontspec}
+\else
+  \usepackage[T1]{fontenc}
+\fi
+
+% Config
+\yyyymmdddate
+\graphicspath{ {../images/} }
+\addbibresource{./db.bib}
+\acsetup{
+  make-links
+}
+
+% Acronyms
+\DeclareAcronym{dtn}{
+  short            = DTN,
+  long             = Delay/Disruption-Tolerant Networking \cite{RFC5050,RFC9171} ,
+}
+\DeclareAcronym{tcp}{
+  short            = TCP ,
+  long             = Transmission Control Protocol \cite{RFC0793,RFC7323} ,
+}
+\DeclareAcronym{udp}{
+  short            = UDP ,
+  long             = User Datagram Protocol \cite{RFC0768},
+}
+\DeclareAcronym{ltp}{
+  short            = LTP ,
+  long             = Licklider Transmission Protocol \cite{RFC5326} ,
+}
+\DeclareAcronym{lldp}{
+  short            = LLDP ,
+  long             = Link Layer Discovery Protocol \cite{7433915} ,
+}
+\DeclareAcronym{ns3}{
+  short            = ns-3 ,
+  long             = ns-3 Network Simulator \footnote{\url{https://www.nsnam.org/}}  ,
+}
+\DeclareAcronym{omnet}{
+  short            = OMNeT++ ,
+  long             = Open Modeling Network Simulator \footnote{\url{http://omnetpp.org/}} ,
+}
+\DeclareAcronym{inet}{
+  short            = INET ,
+  long             = INET \footnote{\url{https://inet.omnetpp.org/}} ,
+}
+\DeclareAcronym{bp}{
+  short            = BP ,
+  long             = Bundle Protocol \cite{RFC5050,RFC9171} ,
+}
+\DeclareAcronym{ops}{
+  short            = OPS ,
+  long             = Opportunistic Protocol Simulator ,
+}
+\DeclareAcronym{cgr}{
+  short            = CGR ,
+  long             = Contact Graph Routing \cite{burleigh2011contact} ,
+}
+
+% Custom command
+
+\newcommand{\dtn}{
+  \ac{dtn}
+}
+
+\begin{document}
+
+% Title
+\faculty{Faculty of Computer Science}
+\institute{Institute of Systems Architecture}
+\chair{Chair of Computer Networks}
+% \extraheadline{Source: \href{https://github.com/cupcakearmy/hauptseminar-rechnernetze}{github.com/cupcakearmy/hauptseminar-rechnernetze}}
+\author{Niccolo Borgioli}
+\date{\today}
+\title{Comparison of DTN simulators \\ \large Proseminar Computer Networks}
+\maketitle
+
+\tableofcontents
+
+\section{Introduction}
+
+The aim of this document is to investigate and present the current state of simulators in the field of \dtn. This paper will focus on the reasoning behind why simulators are an important and useful tool for the development and research of \dtn protocols, give a primer on \dtn in general and examine a few chosen simulators currently available in the field.
+
+\section{A primer on Delay/Disruption-Tolerant Networking}
+
+\nocite{nasa-scottburleigh-2021-1}
+\nocite{nasa-scottburleigh-2021-2}
+
+\acl{dtn} emerged in the early days of space exploration and became an apparent problem that needed to be tackled before launching the first satellites into orbit. While space is still the main area of interest for \dtn, it also has applications in other areas such as disaster and emergency response where infrastructure might be damaged or destroyed.
+
+\dtn is alternative approach to traditional computer networking protocols. \dtn focuses on allowing communication to happen between nodes in a loosely connected and every changing topology of the network. The idea is that the network does not follow a fixed topology, but rather a network that is changing over time.
+This changes can be predictable, periodic or chaotic and no assumptions are being made about the stability or reliability of links between nodes.
+
+Most \dtn protocols rely on some form of store and forward routing, where the messages are not immediately passed on to the next node, but rather stored in a queue since the availability of the next node is not always known and can vary substantially.
+Within the store and forward family of routing protocols there is a distinction between protocols that replicate data and those who only forward information onward.
+This is in stark contrast to the commonly used TCP and UDP protocols, where non availability / reachability of the next node leads to degradation of service, as those protocols require a steady connection between the two communicating nodes to ensure correct functioning. See \ref{fig:dtn-vs-tcp} for a simplified visual comparison.
+
+\begin{figure}[h]
+  \label{fig:dtn-vs-tcp}
+  \caption{Simplified message delivery comparison between DTN and TCP}
+  \centering
+  \includegraphics[width=0.75\textwidth]{dtn-vs-tcp.png}
+\end{figure}
+
+Another relevant aspect is the inherent issue with security and privacy in such a network, as it is prone to attacks by non cooperating nodes \cite{jedari2018survey}.
+
+\section{Motivation for using simulators}
+
+As in any field of science measurement is a necessary step in assessing if a newly developed technology is an actual improvement or not compared to the status quo. This means that metrics are needed to evaluate progress. Generally experimental evidence and measurements are used to gather data.
+However in \dtn the scale of the network is often on a planetary level, which makes actual testing very resource intensive and in most cases impossible. With simulations, it is possible to gather metrics and data without the need to launch actual hardware into space.
+Simulating the network by hand without automation is an time consuming and error prone process as it involves a lot of moving parts to be done correctly. Keeping an overview and correct behavior manually is not a feasible task, which can be solved by using a simulator.
+
+As simulations by comparison require almost no resources they can be used not only to evaluate, but also can be integrated into the development process of \dtn protocols. This can speed up the development process and makes comparison between different protocols and implementations much easier and efficient.
+
+\section{Required properties for a simulator}
+
+For evaluating different simulator frameworks we need to first define what criteria we want to consider and weigh the importance accordingly. Below is a short list of criteria that we will use to evaluate the quality of a simulator.
+
+\begin{itemize}
+  \item Routing
+  \item Modeling
+  \item Support for real wold protocols
+  \item Reporting
+  \item Extendibility
+  \item Documentation
+  \item Configuration
+\end{itemize}
+
+\subsection{Routing}
+
+A good simulation framework should include basic routing algorithms for \dtn.
+Examples might be Epidemic Routing, Flooding Routing, PRoPHET, MaxProp, RAPID, Spray and Wait, Bubble Rap Protocol, CafRep, RACOD. Furthermore it should be easy to add new or custom routing algorithms as needed.
+
+\subsection{Modeling}
+
+As \dtn covers a broad spectrum of possible applications and use cases, the resulting simulated network topologies can be predictable, dynamic or sometimes chaotic.
+Modeling this changing network structure is essential. This includes opportunistic and predefined links between nodes. They can be of periodic nature, randomized or anything in between.
+
+One example would be modeling orbiting satellites, where the links are periodically broken and restored in a predictable manner. An example for an opportunistic topology would be modeling random ships in the ocean that need to communicate with each other, where the next link or node is not predictable.
+
+\subsection{Support for real world protocols}
+
+Support for standard like the \ac{bp} V7 and the underlying convergence layers like \ac{tcp}, \ac{udp} or \ac{ltp} is desirable.
+
+\subsection{Reporting}
+
+Good reporting, meaning the ability to extract data and metrics from a given simulation is key to process and compare data further between different simulation runs and models in order to compare and improve the simulation.
+
+This means that generally it is required that data can be exported in a machine readable format such as csv, json or other formats that are easy to process further.
+
+\subsection{Extendibility}
+
+A good simulator would allow for extendibility and therefore the ability to customize every aspect of the simulation to the needs of the user.
+
+\subsection{Documentation}
+
+The quality of documentation determines the barrier of entry for new users. Ideally extensive documentation and examples are available so that writing simulations is intuitive and easy.
+
+\subsection{Configuration}
+
+Naturally there is a need to define simulation scenarios. This means that a user needs to somehow specify the topology and all the parameters for links, nodes, etc. to satisfy the constrains of a given scenario. This can be done by configuration files in a declarative manner, or programmatically. In either case it is desirable that this happens in a concise and intuitive way that is easy to understand and create.
+
+\section{Evaluation}
+
+The following simulators were chosen for this comparison \ref{table:dtn-simulators-chosen}. They where mostly chosen based on discoverability and being open source.
+
+\begin{table}[h]
+  \centering
+  \caption{Chosen simulators}
+  \label{table:dtn-simulators-chosen}
+  \begin{tabular}{ l|r|r }
+    Name                       & Language      & Last Update               \\
+    \hline
+    The One \cite{sim-theone}  & \verb|Java|   & \formatdate{27}{10}{2015} \\
+    OPS \cite{sim-ops}         & \verb|C++|    & \formatdate{13}{6}{2022}  \\
+    ns3-dtn-bit \cite{sim-ns3} & \verb|C++|    & \formatdate{2}{6}{2018}   \\
+    dtnsim \cite{sim-dtnsim}   & \verb|Python| & \formatdate{8}{12}{2021}  \\
+    DTN \cite{sim-dtn}         & \verb|C#|     & \formatdate{8}{8}{2017}   \\
+  \end{tabular}
+\end{table}
+
+\subsection{The One}
+
+The One is one of the most popular and well known simulators available for \dtn that started out in 2007.
+
+It has quite a number of features available and prebuilt in.
+For movement we have many prebuilt options such as map based movement, random and a few more.
+Routing also has the basic and a few more routing algorithms available, such as First Contact, Epidemic, Spray and Wait, DIrect delivery, ProPHET and MaxProp.
+There is a GUI for following the simulation in a visual manner.
+Reporting is configurable and can be done in a variety of formats.
+
+Some shortcomings are that is only supports 2D topologies and the documentation is available but not extensive, only covers some very basic settings. Everything else needs to be looked up in the code base.
+A bit problem is that The One does not support the use of real world protocols for simulating the convergence layer which is required by the \ac{bp}. This is essential for simulating current state of the art \ac{bp} protocols.
+
+\subsection{OPS}
+
+\ac{ops} is a simulator developed by the \href{https://www.uni-bremen.de/comnets}{Sustainable Communication Networks} of the \href{https://www.uni-bremen.de/}{University of Bremen}. It sits on top of \ac{omnet} and \ac{inet}, which are powerful event and network simulation frameworks. This allows \ac{ops} to be very flexible, extendable and powerful.
+
+\ac{ops} makes the distinction between link (convergence layer), routing and the the app layer. These are separate components that allow for realistic simulations for \ac{bp}. Each layer is configurable with a lot of parameters to tune.
+
+Most routing algorithms are available out of the box and it is the only project in this list that has support for 3D space / coordinates.
+
+It is the only simulator of this list that seems to be actively maintained and developed at this moment. The documentation is the most comprehensive in comparison to the other projects, but it only covers the basic features without going into details to much. Some examples/guides would be great. The setup is not easy, as \ac{ops} is made up of many software projects bundled together and takes a bit to get up and running.
+
+\subsection{ns3-dtn-bit}
+
+ns3-dtn-bit is based on \ac{ns3}, which is another network simulation framework. Unfortunately ns3-dtn-bit seems more of a proof of concept than a real simulator.
+
+It misses config driven scenarios, only implements \ac{cgr} and is not customizable. The convergence layer is not simulated here, only the routing, which makes it unsuitable for simulating \ac{bp}.
+
+Also the documentation is extremely limited.
+
+\subsection{dtnsim}
+
+dtnsim is a pure python implementation of a \dtn simulator. This makes it unsuitable for large scale simulations as python performance will be a hindrance.
+
+dtnsim includes routing protocols like PRoPHET and Epidemic, but not the underlying simulation of the convergence layer unfortunately. This, again, makes it unsuitable for simulating \ac{bp}.
+
+There is no documentation beyond reading the source code. Being in written in python lowers the barrier of entry for new users, but this is still not a real option for simulating diverse scenarios.
+Scenarios are not config driven and require coding to be defined.
+Also the simulation environment is 2D.
+
+\subsection{DTN}
+
+Originally written as a master thesis \footnote{\url{https://raw.githubusercontent.com/szymonwieloch/DTN/master/DTN.pdf}}, DTN is quite a complete simulator.
+
+It is aware of the convergence layer and includes \ac{tcp}, \ac{udp} and \ac{lldp}. Also it includes most of the common routing protocols, including Static, Epidemic, Gradient, AODV, Dijkstra and Predictable.
+It was written with the first draft of the \ac{bp} protocol in mind \cite{RFC5050}, so is specifically tailored for \ac{bp} simulations.
+
+Documentation is difficult tu judge as it's not in English. Overall this is the most mature simulator which is backed by a single person. Although it's not maintained and/or developed anymore.
+
+\section{Conclusion}
+
+Below is a short summary of the key differences between the simulators that were considered. \ref{table:comparison}
+
+\begin{table}[h!]
+  \centering
+  \label{table:comparison}
+  \begin{tabular}{c | c c c}
+    Simulator   & Convergence Layer & Config driven & Maintained \\
+    \hline
+    The One     & \XSolid           & \Checkmark    & \XSolid    \\
+    OPS         & \Checkmark        & \Checkmark    & \Checkmark \\
+    ns3-dtn-bit & \XSolid           & \XSolid       & \XSolid    \\
+    dtnsim      & \XSolid           & \XSolid       & \XSolid    \\
+    DTN         & \Checkmark        & \Checkmark    & \XSolid    \\
+  \end{tabular}
+  \caption{Comparison of the simulators}
+  \label{table:1}
+\end{table}
+
+Most simulators have some kind of shortcomings. Almost all of them lack in documentation and examples which imply a higher barrier of entry for new users.
+The most complete, up-to-date and flexible simulator seems to be \ac{ops}, which seems the most mature and reasonable choice to simulate \dtn in the present day.
+
+All other simulators seem unmaintained at this point or lack support for convergence layer simulations.
+
+\medskip
+\printacronyms
+
+\newpage
+\printbibliography
+
+\end{document}