nico
/
master-thesis
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Begin cleanup results

This commit is contained in:
Nico Schottelius 2019-08-19 17:50:00 +02:00
parent a08f757e96
commit d99a65ed27
5 changed files with 95 additions and 80 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/Background.tex
View File

@ -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

29
doc/Design.tex
View File

@ -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

138
doc/Results.tex
View File

@ -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,

BIN
doc/Thesis.pdf
View File

Binary file not shown.

6
doc/refs/refs.bib
View File

@ -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}}