Begin cleanup results

doc/Background.tex

@@ -234,7 +234,7 @@ like TCP~\cite{rfc793} or UDP~\cite{rfc768}. However it can also
 support ICMP~\cite{rfc792} and ICMP6~\cite{rfc4443}.
 % ----------------------------------------------------------------------
 \subsection{\label{background:transition:Protocol dependent}Higher
-  layer Protocol Dependent Translation}
+  Layer Protocol Dependent Translation}
 Further translation can be achieved by using information in higher
 level protocols like HTTP~\cite{rfc2616} or TLS~\cite{rfc4366}.
 Application proxies like

doc/Design.tex

@@ -392,32 +392,3 @@ not the full headers are used, but only a ``pseudo header'' (compare figures
 \ref{fig:ipv6pseudoheader} and \ref{fig:ipv4pseudoheader}).
 % ok
 % ----------------------------------------------------------------------
-\section{\label{design:benchmarks}Benchmarks}
-\begin{figure}[h]
-  \includegraphics[scale=0.5]{softwarenat64design}
-  \centering
-  \caption{Benchmark design for NAT64 in software implementations}
-  \label{fig:softwarenat64design}
-\end{figure}
-We use two hosts for performing benchmarks: a load generator and a
-NAT64 translator. Both hosts are equipped with a dual port
-Intel X520 10 Gbit/s network card. Both hosts are connected using DAC
-without any equipment in between. TCP offloading is enabled in the
-X520 cards. Figure \ref{fig:softwarenat64design}
-shows the network setup.
-When testing the NetPFGA/P4 performance, the X520 cards in the NAT64
-translator are disconnected and instead the NetPFGA ports are
-connected, as show in figure \ref{fig:netpfgadesign}. The load
-generator is equipped with a quad core CPU (Intel(R) Core(TM) i7-6700
-CPU @ 3.40GHz), enabled with hyperthreading and 16 GB RAM. The NAT64
-translator is also equipped with a quard core CPU (Intel(R) Core(TM)
-i7-4770 CPU @ 3.40GHz) and 16 GB RAM.
-The first 10 seconds of the benchmark are excluded to avoid the TCP
-warm up phase.\footnote{iperf -O 10 parameter, see section \ref{design:tests}.}
-\begin{figure}[h]
-  \includegraphics[scale=0.5]{netpfgadesign}
-  \centering
-  \caption{NAT64 with NetFPGA benchmark}
-  \label{fig:netpfgadesign}
-\end{figure}
-% ok

doc/Results.tex

@@ -11,8 +11,62 @@ software solutions as well as for our hardware implementation. As the
 objective of this thesis was to demonstrate the high speed
 capabilities of NAT64 in hardware, no benchmarks were performed on the
 P4 software implementation.
+% ok
 % ----------------------------------------------------------------------
 \section{\label{results:p4}P4 based implementations}
+All planned features could be realised with P4 and a controller.
+For this thesis the parsing capabilities of P4 were adequate.
+However P4, at the time of writing, cannot parse ICMP6 options in
+general, as the upper level protocol does not specify the number
+of options that follow and parsing of an undefined number
+of 64 bit blocks is required.
+
+The language has some limitations on where the placement of
+conditional statements (\texttt{if/switch}).\footnote{In general,
+if and switch statements in actions lead to errors,
+but not all constellations are forbidden.}
+Furthermore P4/BMV2 does not support for multiple LPM keys in a table,
+however it supports multiple keys with ternary matching, which is a
+superset of LPM matching.
+
+When developing P4 programs, the reason for incorrect behaviour we
+have seen were checksum problems. This is in retrospective expected,
+as the main task our implementation does is modify headers on which
+the checksums depend. In all cases we have seen Ethernet frame
+checksum errors, the effective length of the packet was incorrect.
+
+The tooling around P4 is somewhat fragile. We encountered small
+language bugs during the development~\cite{schottelius:github1675},
+\ref{appendix:expressionbug}
+or found missing features~\cite{schottelius:github745},
+~\cite{theojepsen:_get}: it is at the moment impossible to retrieve
+the matching key from table or the name of the action called. Thus
+if different table entries call the same action, it is impossible
+within the action, or if forwarded to the controller, within the
+controller to distinguish on which match the action was
+triggered. This problem is very consistent within P4, as not even the
+matching table name can be retrieved. While these information can be
+added manually as additional fields in the table entries, we would
+expect a language to support reading and forwarding this kind of meta
+information.
+
+While in P4 the P4 code and the related controller are tightly
+coupled, their data definitions are not. Thus the packet format
+definition that is used between the P4 switch and the controller has
+to be duplicated. Our experiences in software development indicate
+that this duplication is a likely source of errors in bigger software
+projects.
+
+The supporting scripts in the P4 toolchain are usually written in
+python2. However python2 ``is
+legacy''~\cite{various:_shoul_i_python_python}. During development
+errors with unicode string handling in python2 caused
+changes to IPv6 addresses.~\ref{appendix:p4:python2unicode}
+
+P4os - reusable code
+
+% idomatic problem: Security issue: not checking checksums before
+
 
 ****** TODO IPv6 udp -> IPv4
 - Got 4-5 tuple ([proto], src ip, src port, dst ip, dst port)
@@ -25,54 +79,6 @@ allows us to closest resemble any other translation implementation.
 Only supporting /96, not other embeddings as described in
 section \ref{background:transition:prefixnat}.
 
-
-All planned features could be realised with P4 and a controller.
-The language has some limitations on where if/switch statements can be
-used.\footnote{In general, if and switch statements in actions lead to
-  errors, but not all constellations are forbidden.}
-
-For this thesis the parsing capabilities of P4 were adequate. However
-P4 at the time of writing cannot parse ICMP6 options, as the upper
-level protocol does not specify the number of options that follow and
-parsing of 64 bit blocks is required.
-
-P4/BMV2 does not support for multiple LPM keys in a table, however it
-supports multiple keys with ternary matching.
-
-When developing P4 programs, the reason for incorrect behaviour was
-most often found in checksum problems. If frame checksum errors where
-displayed by tcpdump, usually the effective length of the packet was
-incorrect.
-
-FIXMe: IPv6: NDP: not easy to parse, as unknown number of following fields
-
-The tooling around P4 is still fragile, encountered many bugs
-in the development.~\cite{schottelius:github1675}
-
-or missing features (~\cite{schottelius:github745},
-~\cite{theojepsen:_get})
-
-Hitting expression bug (FIXME: source)
-
-1) Impossible to retrieve key from table: LPM: addr + mask -> addr and
-mask might be used in controller
-
-2) retrieving information from tables : no meta information, don't
-know which table matched
-
-3) type definitions separate   Code sharing (controller, switch)
-
-No switch in actions, No conditional execution in actions
-
-Not directly related to P4, but supporting scripts are usually written in python2, however python2
-handles unicode strings differently and thus effects like an IPv6
-address ``changing'' happen. ~\cite{appendix:p4:python2unicode}.
-
-P4os - reusable code
-
-idomatic problem: Security issue: not checking checksums before
-
-
 % ----------------------------------------------------------------------
 \subsection{\label{Results:BMV2}BMV2}
 The software implementation of P4 has most features, which is
@@ -408,11 +414,43 @@ Jool kernel module
 Integration with iptables
 Requires routing
 
+
+% ----------------------------------------------------------------------
+\section{\label{results:benchmark}NAT64 Benchmarks - FIXME: explain
+  numbers}
+% ----------------------------------------------------------------------
+\subsection{\label{results:benchmark:design}Benchmark Design}
+\begin{figure}[h]
+  \includegraphics[scale=0.5]{softwarenat64design}
+  \centering
+  \caption{Benchmark design for NAT64 in software implementations}
+  \label{fig:softwarenat64design}
+\end{figure}
+We use two hosts for performing benchmarks: a load generator and a
+NAT64 translator. Both hosts are equipped with a dual port
+Intel X520 10 Gbit/s network card. Both hosts are connected using DAC
+without any equipment in between. TCP offloading is enabled in the
+X520 cards. Figure \ref{fig:softwarenat64design}
+shows the network setup.
+When testing the NetPFGA/P4 performance, the X520 cards in the NAT64
+translator are disconnected and instead the NetPFGA ports are
+connected, as show in figure \ref{fig:netpfgadesign}. The load
+generator is equipped with a quad core CPU (Intel(R) Core(TM) i7-6700
+CPU @ 3.40GHz), enabled with hyperthreading and 16 GB RAM. The NAT64
+translator is also equipped with a quard core CPU (Intel(R) Core(TM)
+i7-4770 CPU @ 3.40GHz) and 16 GB RAM.
+The first 10 seconds of the benchmark are excluded to avoid the TCP
+warm up phase.\footnote{iperf -O 10 parameter, see section \ref{design:tests}.}
+\begin{figure}[h]
+  \includegraphics[scale=0.5]{netpfgadesign}
+  \centering
+  \caption{NAT64 with NetFPGA benchmark}
+  \label{fig:netpfgadesign}
+\end{figure}
+% ok
 % ----------------------------------------------------------------------
 
 
-% ----------------------------------------------------------------------
-\section{\label{results:benchmark}NAT64 Benchmarks - FIXME: explain numbers}
 We successfully implemented P4 code to realise
 NAT64~\cite{schottelius:thesisrepo}. It contains parsers
 for all related protocols (ipv6, ipv4, udp, tcp, icmp, icmp6, ndp,

doc/refs/refs.bib

@@ -175,3 +175,9 @@
   title =     {iPerf - The ultimate speed test tool for TCP, UDP and SCTP},
   howpublished = {\url{https://iperf.fr/}},
   note =      {Requested on 2019-08-19}}
+
+@Misc{various:_shoul_i_python_python,
+  author =    {Various},
+  title =     {Should I use Python 2 or Python 3 for my development activity?},
+  howpublished = {\url{https://wiki.python.org/moin/Python2orPython3}},
+  note =      {Requested on 2019-08-19}}