Begin cleanup results
This commit is contained in:
Nico Schottelius
parent
a08f757e96
commit
d99a65ed27
5 changed files with 95 additions and 80 deletions
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
138
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,
|
||||
|
|
|
|||
BIN
doc/Thesis.pdf
BIN
doc/Thesis.pdf
Binary file not shown.
|
|
@ -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}}
|
||||
|
|
|
|||
Loading…
Reference in a new issue