Browse Source

update all

Signed-off-by: Nico Schottelius <nico@nico-notebook.schottelius.org>
master
Nico Schottelius 3 years ago
parent
commit
df2c52a37f
  1. 10
      doc/Background.tex
  2. 11
      doc/Conclusion.tex
  3. 4
      doc/Introduction.tex
  4. 339
      doc/Results.tex
  5. BIN
      doc/Thesis.pdf
  6. 214
      doc/appendix.tex
  7. 52
      doc/plan.org
  8. 0
      iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P1-run1
  9. 0
      iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P1-run2
  10. 0
      iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P1-u-b0-run1
  11. 0
      iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P1-u-b0-run2
  12. 0
      iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P10-run1
  13. 0
      iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P10-run2
  14. 0
      iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P10-u-b0-run1
  15. 0
      iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P10-u-b0-run2
  16. 0
      iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P20-run1
  17. 0
      iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P20-run2
  18. 0
      iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P20-u-b0-run1
  19. 0
      iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P20-u-b0-run2
  20. 0
      iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P50-run1
  21. 0
      iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P50-run2
  22. 0
      iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P50-u-b0-run1
  23. 0
      iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P1-run1
  24. 0
      iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P1-run2
  25. 0
      iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P1-run3
  26. 0
      iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P1-u-b0-run1
  27. 0
      iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P1-u-b0-run2
  28. 0
      iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P1-u-b0-run3
  29. 0
      iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P10-run1
  30. 0
      iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P10-run2
  31. 0
      iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P10-run3
  32. 0
      iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P10-u-b0-run1
  33. 0
      iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P10-u-b0-run2
  34. 0
      iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P10-u-b0-run3
  35. 0
      iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P20-run1
  36. 0
      iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P20-run2
  37. 0
      iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P20-run3
  38. 0
      iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P20-u-b0-run1
  39. 0
      iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P20-u-b0-run2
  40. 0
      iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P20-u-b0-run3
  41. 0
      iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P50-run1
  42. 0
      iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P50-run2
  43. 0
      iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P50-run3
  44. 0
      iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P50-u-b0-run1
  45. 0
      iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P50-u-b0-run2
  46. 0
      iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P50-u-b0-run3

10
doc/Background.tex

@ -9,14 +9,14 @@ bits that are parsed and then accessible in the (self) defined
structures, also called headers. The general flow can be seen in
figure \ref{fig:p4fromnsg}: a parser parses the incoming packet and
prepares it for processing in the switching logic. Afterwards the
packets is output and deparsing of the parsed data might follow.
packets are output and deparsing of the parsed data might follow.
In the context of NAT64 this is a very important feature: while the
parser will read and parse in the ingress pipeline one protocol
(f.i. IPv6), the deparser will output a different protocol (f.i. IPv4).
\begin{figure}[h]
\includegraphics[scale=0.9]{p4-from-nsg}
\centering
\caption{P4 protocol independence, \cite{vanbever:_progr_networ_data_planes}}
\caption{P4 protocol independence~\cite{vanbever:_progr_networ_data_planes}}
\label{fig:p4fromnsg}
\end{figure}
The \textit{target independence} is the second very powerful feature
@ -24,10 +24,12 @@ of P4: it allows code to be compiled to different targets. While in
theory the P4 code should be completely target independent, in reality
there are some modifications needed on a per-target basis and each
target faces different restrictions. The challenges arising from this
are discussed in section \ref{conclusion:P4}.
are discussed in section \ref{results:p4}.
As opposed to general purpose programming languages, P4 lacks some
features, most notably loops. However within its constraints, P4 can guarantee
features, most notably loops, floating point operations and the
modulo operator.
However within its constraints, P4 can guarantee
operation at line speed, which general purpose programming languages
cannot guarantee and also fail to achieve in reality
(see section \ref{results:softwarenat64} for details).

11
doc/Conclusion.tex

@ -52,3 +52,14 @@ technologie DNS64\cite{rfc6147} could also be implemented in P4, thus
completing the translation mechanism.
Proxies / higher level protocols could be next level
Add helper in P4 to support checksum analysis a frequent problem and
helper
Allow ICMP6 option parsing: specify xtimes 64 bit blocks resulting in
an array
Adding support for passing on meta information to controller: key or
table
Support a meta language to define used types and/or export to popular languages.
Long term supporting python3 would be helpful. P4OS.

4
doc/Introduction.tex

@ -16,7 +16,9 @@
\chapter{\label{introduction}Introduction}
In this chapter we give an introduction about the topic of the master
thesis, the motivation and problemes that we address.
thesis, the motivation and problemes that we address. We explain the
current state of IPv4 exhaustion and IPv6 adoption and describe how
it motivates our work to support ease transition to IPv6 networks.
% ----------------------------------------------------------------------
\section{\label{introduction:ipv4ipv6}IPv4 exhaustion and IPv6 adoption}

339
doc/Results.tex

@ -12,7 +12,7 @@ objective of this thesis was to demonstrate the high speed
capabilities of NAT64 in hardware, no benchmarks were performed on the
P4 software implementation.
% ----------------------------------------------------------------------
\section{\label{results:p4}NAT64 Overview - FIXME: verify numbers}
\section{\label{results:p4}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,
@ -24,46 +24,113 @@ Due to limitations in the P4 environment of the
NetFPGA\cite{conclusion:netfpga} environment, the BMV2 implementation
is more feature rich. Table \ref{tab:benchmark} summarises the
achieved bandwidths of the NAT64 solutions.
\begin{table}[htbp]
\begin{center}\begin{minipage}{\textwidth}
\begin{tabular}{| c | c | c | c |}
\begin{tabular}{| c | c | c | c | c |}
\hline
Implementation & \multicolumn{4}{|c|}{min/avg/max in Gbit/s} \\
\hline
Solution & \multicolumn{3}{|c|}{Parallel connections} \\
& 1 & 20 & 3 \\
Tayga & 2.79 / 3.20 / 3.43 & 3.34 / 3.36 / 3.38 & 2.57 / 3.02 / 3.27 &
2.35 / 2.91 / 3.20 \\
\hline
Tayga & 3.02 & 3.28 & 2.85\\
Jool & 8.22 / 8.22 / 8.22 & 8.21 / 8.21 / 8.22 & 8.21 / 8.23 / 8.25
& 8.21 / 8.23 / 8.25\\
\hline
Jool & 6.67 & 16.8 ?? & 20.5 udp?\\
P4 / NetPFGA & 9.28 / 9.28 / 9.29 & 9.28 / 9.28 / 9.29 & 9.28 / 9.28
/ 9.29 & 9.28 / 9.28 / 9.29\\
\hline
P4 / NetPFGA & 9.28 & 9.29 & 9.29\\
Parallel connections & 1 & 10 & 20 & 50 \\
\hline
\end{tabular}
\end{minipage}
\caption{NAT64 Benchmark (client: IPv6, server: IPv4), all results in Gbit/sec (\%loss)}
\caption{IPv6 to IPv4 TCP NAT64 Benchmark}
\label{tab:benchmarkv6}
\end{center}
\end{table}
During the benchmarks the client -- CPU usage
\begin{table}[htbp]
\begin{center}\begin{minipage}{\textwidth}
\begin{tabular}{| c | c | c | c |}
\begin{tabular}{| c | c | c | c | c |}
\hline
Implementation & \multicolumn{4}{|c|}{min/avg/max in Gbit/s} \\
\hline
Tayga & 2.90 / 3.15 / 3.34 & 2.87 / 3.01 / 3.22 &
2.68 / 2.85 / 3.09 & 2.60 / 2.78 / 2.88 \\
\hline
Jool & 7.18 / 7.56 / 8.24 & 7.97 / 8.05 / 8.09 &
8.05 / 8.08 / 8.10 & 8.10 / 8.12 / 8.13 \\
\hline
P4 / NetPFGA & 8.51 / 8.53 / 8.55 & 9.28 / 9.28 / 9.29 & 9.29 / 9.29 /
9.29 & 9.28 / 9.28 / 9.29 \\
\hline
Parallel connections & 1 & 10 & 20 & 50 \\
\hline
\end{tabular}
\end{minipage}
\caption{IPv4 to IPv6 TCP NAT64 Benchmark}
\label{tab:benchmarkv4}
\end{center}
\end{table}
\begin{table}[htbp]
\begin{center}\begin{minipage}{\textwidth}
\begin{tabular}{| c | c | c | c | c |}
\hline
Implementation & \multicolumn{4}{|c|}{avg bandwidth in gbit/s / avg loss /
adjusted bandwith} \\
\hline
Tayga & 8.02 / 70\% / 2.43 & 9.39 / 79\% / 1.97 & 15.43 / 86\% / 2.11
& 19.27 / 91\% 1.73 \\
\hline
Jool & 6.44 / 0\% / 6.41 & 6.37 / 2\% / 6.25 &
16.13 / 64\% / 5.75 & 20.83 / 71\% / 6.04 \\
\hline
P4 / NetPFGA & 8.28 / 0\% / 8.28 & 9.26 / 0\% / 9.26 &
16.15 / 0\% / 16.15 & 15.8 / 0\% / 15.8 \\
\hline
Parallel connections & 1 & 10 & 20 & 50 \\
\hline
\end{tabular}
\end{minipage}
\caption{IPv6 to IPv4 UDP NAT64 Benchmark}
\label{tab:benchmarkv4}
\end{center}
\end{table}
\begin{table}[htbp]
\begin{center}\begin{minipage}{\textwidth}
\begin{tabular}{| c | c | c | c | c |}
\hline
Implementation & \multicolumn{4}{|c|}{avg bandwidth in gbit/s / avg loss /
adjusted bandwith} \\
\hline
Solution & \multicolumn{3}{|c|}{Parallel connections} \\
& 1 & 20 & 3 \\
Tayga & 6.78 / 84\% / 1.06 & 9.58 / 90\% / 0.96 &
15.67 / 91\% / 1.41 & 20.77 / 95\% / 1.04 \\
\hline
Tayga & 3.36 & 3.29 & 3.11 \\
Jool & 4.53 / 0\% / 4.53 & 4.49 / 0\% / 4.49 & 13.26 / 0\% / 13.26 &
22.57 / 0\% / 22.57\\
\hline
Jool & 8.24 & 8.26 & 8.29\\
P4 / NetPFGA & 7.04 / 0\% / 7.04 & 9.58 / 0\% / 9.58 &
9.78 / 0\% / 9.78 & 14.37 / 0\% / 14.37\\
\hline
P4 / NetPFGA & 9.28 & 9.29 & 9.29\\
Parallel connections & 1 & 10 & 20 & 50 \\
\hline
\end{tabular}
\end{minipage}
\caption{NAT64 Benchmark (client: IPv4, server: IPv6), all results in Gbit/sec (\%loss)}
\caption{IPv4 to IPv6 UDP NAT64 Benchmark}
\label{tab:benchmarkv4}
\end{center}
\end{table}
UDP load generator hitting 100\% cpu at P20.
TCP confirmed.
Over bandwidth results
Feature comparison
speed - sessions - eamt
@ -74,15 +141,17 @@ ping6 support
ndp
controller support
netpfga consistent
% ----------------------------------------------------------------------
\section{\label{Results:BMV2}BMV2}
\section{\label{Results:BMV2}BMV2 - FIXME: write better}
The software implementation of P4 has most features, which is
mostly due to the capability of checksumming the payload: Acting
as a ``proper'' participant in NDP, requires the host to calculate
checksums over the payload.
List of features:
List of features BMV2 \cite{tab:p4bmv2features}
\begin{table}[htbp]
\begin{center}\begin{minipage}{\textwidth}
@ -144,6 +213,7 @@ Responds to icmp, icmp6
ndp \cite{rfc4861}
arp
very easy to use
Fully functional host
Can compute checksums on its own.
@ -160,19 +230,9 @@ table entries.
Jool and tayga are supported by
Trace files
\begin{verbatim}
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1555-h1.pcap
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1555-h3.pcap
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1557-h1.pcap
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1558-h3.pcap
\end{verbatim}
% ----------------------------------------------------------------------
\section{\label{results:netpfga}NetFPGA}
\section{\label{results:netpfga}NetFPGA - FIXME: writing}
The reduced feature set of the NetPFGA implementation is due to two
factors: compile time. Between 2 to 6 hours per compile run. No
payload checksum
@ -393,105 +453,28 @@ Renaming variables in the declaration of the parser or deparser lead
to compilation errors. Function syntax is not supported. For this
reason our implementation uses \texttt{\#define} statements instead of functions.
\begin{verbatim}
*** DONE 2019-07-21: Proof of v6->v4 working delta based
CLOSED: [2019-07-21 Sun 12:30]
#+BEGIN_CENTER
pcap/tcp-udp-delta-from-v6-2019-07-21-0853-h1.pcap | Bin 0 -> 4252 bytes
pcap/tcp-udp-delta-from-v6-2019-07-21-0853-h3.pcap | Bin 0 -> 2544 bytes
#+END_CENTER
\end{verbatim}
\begin{verbatim}
**** DONE Testing v4->v6 tcp: ok (version 10.0)
CLOSED: [2019-08-04 Sun 09:15]
#+BEGIN_CENTER
nico@ESPRIMO-P956:~/master-thesis/bin$ ./socat-connect-tcp-v4
+ echo from-v4-ok
+ socat - TCP:10.0.0.66:2345
TCPv6-ok
nico@ESPRIMO-P956:~/master-thesis/bin$ ./socat-listen-tcp-v6
from-v4-ok
#+END_CENTER
trace:
netfpga-nat64-2019-08-04-0907-enp2s0f0.pcap
netfpga-nat64-2019-08-04-0907-enp2s0f1.pcap
**** DONE Testing v4->v6 udp: ok (version 10.1)
trace:
create mode 100644 pcap/netfpga-nat64-udp-2019-08-04-0913-enp2s0f0.pcap
create mode 100644 pcap/netfpga-nat64-udp-2019-08-04-0913-enp2s0f1.pcap
\end{verbatim}
\begin{verbatim}
*** DONE 2019-08-04: version 10.1/10.2: new maxpacketregion: v4->v6 works
CLOSED: [2019-08-04 Sun 19:42]
#+BEGIN_CENTER
nico@ESPRIMO-P956:~/master-thesis/bin$ ./init_ipv4_esprimo.sh
nico@ESPRIMO-P956:~/master-thesis/bin$ ./set_ipv4_neighbor.sh
#+END_CENTER
Test 20 first:
- Does't work -> missed to add table entries
- Does work after setting table entries
- 300 works
- 1450 works
- 1500 does not work
Proof:
create mode 100644 pcap/netfpga-10.2-maxpacket-2019-08-04-1931-enp2s0f0.pcap
create mode 100644 pcap/netfpga-10.2-maxpacket-2019-08-04-1931-enp2s0f1.pcap
\end{verbatim}
\begin{verbatim}
*** DONE 2019-08-04: test v6 -> v4: works for 1420
CLOSED: [2019-08-04 Sun 20:30]
Proof:
#+BEGIN_CENTER
create mode 100644 pcap/netfpga-10.2-fromv6tov4-2019-08-04-1943-enp2s0f0.pcap
create mode 100644 pcap/netfpga-10.2-fromv6tov4-2019-08-04-1943-enp2s0f1.pcap
\end{verbatim}
FIXME:
General result: limited NAT64 is working, however
No Payload
checksumming - requires controller
Hash funktion in Arbeit
No NDP, no ARP - focused on key factors of NAT64 translation,
other features can be supported by controller
No Payload ; checksumming - requires controller
Hash funktion in Arbeit ; No NDP, no ARP - focused on key factors of NAT64 translation,
other features can be supported by controller
Needed to debug internal parsing errors
debugging generated tcl code to debug impl1 error
% ----------------------------------------------------------------------
\section{\label{results:tayga}Tayga}
\section{\label{results:softwarenat64}Software NAT64 with Tayga and
Jool}
Both cpu bound.
During the benchmark cpu bound, single thread
tayga: Single threaded
easy to use
% ----------------------------------------------------------------------
\section{\label{results:jool}Jool}
kernel module
100% cpu usage on 1 core for udp
Jool kernel module
100\% cpu usage on 1 core for udp
0\% visible cpu usage for tcp, might be tcp offloading
Integration with iptables
Requires routing
% ----------------------------------------------------------------------
@ -514,24 +497,7 @@ most often found in checksum problems. If frame checksum errors where
displayed by tcpdump, usually the effective length of the packet was
incorrect.
NDP parsing problem
checksumming a frequent problem and helper
IPv6: NDP: not easy to parse, as unknown number of following fields
if things don't work, often a checksum problem.
\begin{verbatim}
ipaddress.ip_network("2001:db8:61::/64")
IPv6Network(u'3230:3031:3a64:6238:3a36:313a:3a2f:3634/128')
Fix:
from __future__ import unicode_literals
\end{verbatim}
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}
@ -539,107 +505,22 @@ in the development.\cite{schottelius:github1675}
or missing features (\cite{schottelius:github745},
\cite{theojepsen:_get})
Hitting expression bug
retrieving information from tables
\begin{verbatim}
Key and mask for matching destination is in table. We need this
information in the action. However this information is not exposed, so
we need to specify another parameter with the same information as in
the key(s).
Log from slack: (2019-03-14)
nico [1:55 PM]
If I use LPM for matching, can I easily get the network address from P4 or do I have to use a bitmask myself? In the latter case it is not exactly clear how to get the mask from the table
Nate Foster [1:58 PM]
You want to retrieve the address in the packet? In a table?
And do you want to do the retrieving from the data plane or the control plane? (edited)
nico [2:00 PM]
If I have a match in a table that matches on LPM, it can be any IP address in a network
For calculating the NAT64/NAT46 translation, I will need the base address, i.e. network address to do subtractions/additions
So it is fully data plane, what I would like to do
I'll commit sample code to show the use case more clearly
https://gitlab.ethz.ch/nicosc/master-thesis/blob/master/p4src/static-mapping.p4#L73
GitLab
p4src/static-mapping.p4 · master · nicosc / master-thesis
gitlab.ethz.ch
So the action nat64_static() is used in the table v6_networks.
In v6_networks I use a match on `hdr.ipv6.dst_addr: lpm;`
What I would like to be able is to get the network address ; I can do that manually, if I have the mask
I can also re-inject this parameter by another action argument, but I'd assume that I can somewhere read this out from the table / match
Nate Foster [2:15 PM]
To make sure I understand, in the data plane, you want to retrieve the address in the lpm pattern? (edited)
Hitting expression bug (FIXME: source)
nico [2:16 PM]
I want to retrieve the key
1) Impossible to retrieve key from table: LPM: addr + mask -> addr and
mask might be used in controller
Nate Foster [2:16 PM]
Wait. The value `hdr.ipv6.dst_addr` is the thing used in the match.
So you have that.
What you don’t have is the IPv6 address and mask put into the table by the control plane.
I assume you want the latter, right?
nico [2:17 PM]
For example, if my matching key is 2001:db8::/32 and the real address is 2001:db8::f00, then I would like to retrieve 2001:db8:: and 32 from the table
exactly :slightly_smiling_face:
I can "fix" this by adding another argument, but it feels somewhat wrong to do that
Because the table already knows this information
Nate Foster [2:26 PM]
I can’t think of a way other than the action parameter hack.
nico [2:26 PM]
Oh, ok
Is it because the information is "lost in hardware"?
Nate Foster [2:31 PM]
No you’re right that most implementations have the value in memory. And one can imagine a different table API that allowed one to retrieve it in the data plane.
But unless I am missing something obvious, P4 hides it…
\end{verbatim}
no meta information
\begin{verbatim}
Is there any meta information for "from which table was the action
called" available? My use case is having a debug action that sends
packets to the controller and I use it as a default_action in various
tables; however know I don't know anymore from which table the action
was called. Is there any kind of meta information which table called
me available?
I could work around this by using if(! .. .hit) { my_action(table_id)
}, but it would not work with using default_action = ...
\end{verbatim}
type definitions separate
Code sharing (controller, switch)
\begin{verbatim}
*** DONE Synchronisation with the controller
- Double data type definition -> might differ
- TYPE_CPU for ethernet
- Port ingress offset (9 vs. 16 bit)
\end{verbatim}
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
\begin{verbatim}
Not addressed so far: how to create re-usable code fragments that can
be plugged in easily. There could be a hypothetical "P4OS" that
manages code fragments. This might include, but not limited to
downloading (signed?) source code, managing dependencies similar to
Linux package management, handling updates, etc.
\end{verbatim}
idomatic problem: Security issue: not checking checksums before

BIN
doc/Thesis.pdf

Binary file not shown.

214
doc/appendix.tex

@ -2324,6 +2324,92 @@ Proof of stuff working, reference for each stage / feature
Stuff that needs to be cleaned up
% ----------------------------------------------------------------------
\subsection{P4/BMV NAT64 Delta based traces}
\begin{verbatim}
*** DONE 2019-07-21: Proof of v6->v4 working delta based
CLOSED: [2019-07-21 Sun 12:30]
#+BEGIN_CENTER
pcap/tcp-udp-delta-from-v6-2019-07-21-0853-h1.pcap | Bin 0 -> 4252 bytes
pcap/tcp-udp-delta-from-v6-2019-07-21-0853-h3.pcap | Bin 0 -> 2544 bytes
#+END_CENTER
\end{verbatim}
\begin{verbatim}
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1555-h1.pcap
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1555-h3.pcap
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1557-h1.pcap
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1558-h3.pcap
\end{verbatim}
% ----------------------------------------------------------------------
\subsection{P4/NetFPGA NAT64 Delta based traces}
\begin{verbatim}
**** DONE Testing v4->v6 tcp: ok (version 10.0)
CLOSED: [2019-08-04 Sun 09:15]
#+BEGIN_CENTER
nico@ESPRIMO-P956:~/master-thesis/bin$ ./socat-connect-tcp-v4
+ echo from-v4-ok
+ socat - TCP:10.0.0.66:2345
TCPv6-ok
nico@ESPRIMO-P956:~/master-thesis/bin$ ./socat-listen-tcp-v6
from-v4-ok
#+END_CENTER
trace:
netfpga-nat64-2019-08-04-0907-enp2s0f0.pcap
netfpga-nat64-2019-08-04-0907-enp2s0f1.pcap
**** DONE Testing v4->v6 udp: ok (version 10.1)
trace:
create mode 100644 pcap/netfpga-nat64-udp-2019-08-04-0913-enp2s0f0.pcap
create mode 100644 pcap/netfpga-nat64-udp-2019-08-04-0913-enp2s0f1.pcap
\end{verbatim}
Bigger packets
\begin{verbatim}
*** DONE 2019-08-04: version 10.1/10.2: new maxpacketregion: v4->v6 works
CLOSED: [2019-08-04 Sun 19:42]
#+BEGIN_CENTER
nico@ESPRIMO-P956:~/master-thesis/bin$ ./init_ipv4_esprimo.sh
nico@ESPRIMO-P956:~/master-thesis/bin$ ./set_ipv4_neighbor.sh
#+END_CENTER
Test 20 first:
- Does't work -> missed to add table entries
- Does work after setting table entries
- 300 works
- 1450 works
- 1500 does not work
Proof:
create mode 100644 pcap/netfpga-10.2-maxpacket-2019-08-04-1931-enp2s0f0.pcap
create mode 100644 pcap/netfpga-10.2-maxpacket-2019-08-04-1931-enp2s0f1.pcap
\end{verbatim}
\begin{verbatim}
*** DONE 2019-08-04: test v6 -> v4: works for 1420
CLOSED: [2019-08-04 Sun 20:30]
Proof:
#+BEGIN_CENTER
create mode 100644 pcap/netfpga-10.2-fromv6tov4-2019-08-04-1943-enp2s0f0.pcap
create mode 100644 pcap/netfpga-10.2-fromv6tov4-2019-08-04-1943-enp2s0f1.pcap
\end{verbatim}
% ----------------------------------------------------------------------
\section{Introduction}
\subsection{\label{introduction:taskdescription}The Task}
@ -2362,6 +2448,134 @@ Describe your task.
\end{verbatim}
% ----------------------------------------------------------------------
\section{\label{appendix:p4}P4 notes}
% ----------------------------------------------------------------------
\subsection{\label{appendix:p4:keyretrieval}Key retrieval chat log}
\begin{verbatim}
Key and mask for matching destination is in table. We need this
information in the action. However this information is not exposed, so
we need to specify another parameter with the same information as in
the key(s).
Log from slack: (2019-03-14)
nico [1:55 PM]
If I use LPM for matching, can I easily get the network address from P4 or do I have to use a bitmask myself? In the latter case it is not exactly clear how to get the mask from the table
Nate Foster [1:58 PM]
You want to retrieve the address in the packet? In a table?
And do you want to do the retrieving from the data plane or the control plane? (edited)
nico [2:00 PM]
If I have a match in a table that matches on LPM, it can be any IP address in a network
For calculating the NAT64/NAT46 translation, I will need the base address, i.e. network address to do subtractions/additions
So it is fully data plane, what I would like to do
I'll commit sample code to show the use case more clearly
https://gitlab.ethz.ch/nicosc/master-thesis/blob/master/p4src/static-mapping.p4#L73
GitLab
p4src/static-mapping.p4 · master · nicosc / master-thesis
gitlab.ethz.ch
So the action nat64_static() is used in the table v6_networks.
In v6_networks I use a match on `hdr.ipv6.dst_addr: lpm;`
What I would like to be able is to get the network address ; I can do that manually, if I have the mask
I can also re-inject this parameter by another action argument, but I'd assume that I can somewhere read this out from the table / match
Nate Foster [2:15 PM]
To make sure I understand, in the data plane, you want to retrieve the address in the lpm pattern? (edited)
nico [2:16 PM]
I want to retrieve the key
Nate Foster [2:16 PM]
Wait. The value `hdr.ipv6.dst_addr` is the thing used in the match.
So you have that.
What you don’t have is the IPv6 address and mask put into the table by the control plane.
I assume you want the latter, right?
nico [2:17 PM]
For example, if my matching key is 2001:db8::/32 and the real address is 2001:db8::f00, then I would like to retrieve 2001:db8:: and 32 from the table
exactly :slightly_smiling_face:
I can "fix" this by adding another argument, but it feels somewhat wrong to do that
Because the table already knows this information
Nate Foster [2:26 PM]
I can’t think of a way other than the action parameter hack.
nico [2:26 PM]
Oh, ok
Is it because the information is "lost in hardware"?
Nate Foster [2:31 PM]
No you’re right that most implementations have the value in memory. And one can imagine a different table API that allowed one to retrieve it in the data plane.
But unless I am missing something obvious, P4 hides it…
\end{verbatim}
% ----------------------------------------------------------------------
\subsection{\label{appendix:p4:tableretrieval}Table retrieval problem}
\begin{verbatim}
Is there any meta information for "from which table was the action
called" available? My use case is having a debug action that sends
packets to the controller and I use it as a default_action in various
tables; however know I don't know anymore from which table the action
was called. Is there any kind of meta information which table called
me available?
I could work around this by using if(! .. .hit) { my_action(table_id)
}, but it would not work with using default_action = ...
\end{verbatim}
\begin{verbatim}
Is there any meta information for "from which table was the action
called" available? My use case is having a debug action that sends
packets to the controller and I use it as a default_action in various
tables; however know I don't know anymore from which table the action
was called. Is there any kind of meta information which table called
me available?
I could work around this by using if(! .. .hit) { my_action(table_id)
}, but it would not work with using default_action = ...
\end{verbatim}
% ----------------------------------------------------------------------
\subsection{\label{appendix:p4:datadefinition}Data definition
redundancy}
\begin{verbatim}
*** DONE Synchronisation with the controller
- Double data type definition -> might differ
- TYPE_CPU for ethernet
- Port ingress offset (9 vs. 16 bit)
\end{verbatim}
% ----------------------------------------------------------------------
\subsection{\label{appendix:p4:python2unicode
}Python2 unicode issue}
\begin{verbatim}
ipaddress.ip_network("2001:db8:61::/64")
IPv6Network(u'3230:3031:3a64:6238:3a36:313a:3a2f:3634/128')
Fix:
from __future__ import unicode_literals
\end{verbatim}
% ----------------------------------------------------------------------
\subsection{\label{appendix:p4:p4os}P4 OS}
\begin{verbatim}
Not addressed so far: how to create re-usable code fragments that can
be plugged in easily. There could be a hypothetical "P4OS" that
manages code fragments. This might include, but not limited to
downloading (signed?) source code, managing dependencies similar to
Linux package management, handling updates, etc.
\end{verbatim}
%---------------------------------------------------------------------------------------------------------
\printnomenclature
\abbrev{ARP}{Address resolution protocol}

52
doc/plan.org

@ -3372,7 +3372,6 @@ nico@ESPRIMO-P956:~/master-thesis/iperf/run7-jool$
../../bin/benchmark-run.sh tayga 2001:db8:23::a00:2a 2345
* TODO Thesis documentation
** Introduction
*** Related work
@ -9345,10 +9344,57 @@ nico@nsg-System:~/projects/P4-NetFPGA/contrib-projects/sume-sdnet-switch/project
| Introduction | 1 day | okayish |
| Background | 1 day | okayish |
| Design | 1-2 days | okayish |
| Results | 2-3 days | 2019-08-13 |
| Conclusion | 1 day | 2019-08-14 |
| Results | 2-3 days | okayish |
| Conclusion | 1 day | okayish |
| Proof reading | 2-3 days | until 2019-08-17 |
| SUM(max) | 12d | |
** Big steps
*** TODO Enhance Design section
*** TODO Write / describe results
*** TODO Fix smaller bugs
*** TODO Cleanup appendix
*** TODO Put figures and code into context
** Corrections v2
*** TODO Perhaps you could place figure 1.3 and 1.4 next to each other (as subfigures). Would make it easier to see the differences.
*** DONE Will there be an overview section in 1? E.g., about the next chapters.
CLOSED: [2019-08-18 Sun 12:35]
*** DONE P 13: the packets is -> the packets are
CLOSED: [2019-08-18 Sun 12:36]
*** DONE P 13: missing references to other sections
CLOSED: [2019-08-18 Sun 12:37]
*** DONE P 13: perhaps mention some more missing features, e.g. floating point operations
CLOSED: [2019-08-18 Sun 12:38]
*** TODO P 13: detail, make sure that spacing around citations is consistent. I would use: text~\cite{...}
*** TODO P 13: missing closing parentheses after [13]
*** TODO P 14: figures 2.3 and 2.2 -> 2.2 and 2.3
*** TODO P 14: why do you compare ARP and NDP to P4?
*** TODO P 15: missing reference
*** TODO P 15: the quote - perhaps put it in quotation marks. Instead of the footnote perhaps a bib entry?
*** TODO P 15: mtu vs. MTU (I would write MTU)
*** TODO P 16: missing reference
*** TODO P 16: tcp -> TCP
*** TODO P 17: the checksums for TCP and UDP is -> are
*** TODO P 17: I’m not sure if it is completely true that you cannot access the payload in the NetFPGA. It is perhaps just not yet implemented…
*** TODO P 18: missing closing parentheses
*** TODO P 18: missing references
*** TODO P 18: Perhaps the network design section should be moved out of the background section as it already contains ideas/discussion related to your implementation?
*** TODO P 21: on it own -> on its own
*** TODO P 21: the use of a control -> of a controller
*** TODO P 22+: passive -> active voice
*** TODO P 22: if you show code, make sure you also explain it in the text
*** TODO P 22: add quotation marks to the quote. Make sure you cite it in the same way as the previous quote
*** DONE P 23: perhaps move benchmark results to chapter 4?
CLOSED: [2019-08-17 Sat 15:01]
*** TODO P 25: missing reference
*** TODO P 25: explain/interpret the reported numbers
*** TODO P 25/26: personally, I would report things such as the BMV2 feature list (table 4.3) before the result section. Obviously these are „results” but not really e.g., measurements.
*** TODO P 28: this „crashes” -> these
*** TODO P 28: NetFGPA -> NetFPGA
*** TODO P 28: here you speak about the speed of your system that is nearly at the line rate of the NetFPGA but I’m not really sure if you previously introduced what the NetFPGA is capable of. Perhaps you could have a short section in the background section?
*** TODO P 29: Section 4.3.4: Although very interesting contentwise, the text could be a bit better structured/combined. Perhaps you can also adapt the title. Once again I’m not completely sure if the results section is the best place for this text. Perhaps you would need an additional chapter between design and results.General:
*** TODO I’m not a huge fan of placing the figures in the middle of ongoing text (sometimes even breaking ongoing sentences). I would rather place them e.g., at the top of the page.
*** TODO A lot of figure captions are quite pointless, e.g. „IPv6 Pseudo Header”. Try to extend them a bit.
*** TODO I know that the design section is probably not yet finished but it would be nice if it would be a bit longer. After all, this is your main work.
* DONE Initial administration
** DONE Clarify PDF / form with Denise Spicher: free form description
** DONE Create task description to be handed in mystudies

0
iperf/run5-netfpga/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P1-run1 → iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P1-run1

0
iperf/run5-netfpga/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P1-run2 → iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P1-run2

0
iperf/run5-netfpga/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P1-u-b0-run1 → iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P1-u-b0-run1

0
iperf/run5-netfpga/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P1-u-b0-run2 → iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P1-u-b0-run2

0
iperf/run5-netfpga/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P10-run1 → iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P10-run1

0
iperf/run5-netfpga/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P10-run2 → iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P10-run2

0
iperf/run5-netfpga/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P10-u-b0-run1 → iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P10-u-b0-run1

0
iperf/run5-netfpga/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P10-u-b0-run2 → iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P10-u-b0-run2

0
iperf/run5-netfpga/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P20-run1 → iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P20-run1

0
iperf/run5-netfpga/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P20-run2 → iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P20-run2

0
iperf/run5-netfpga/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P20-u-b0-run1 → iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P20-u-b0-run1

0
iperf/run5-netfpga/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P20-u-b0-run2 → iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P20-u-b0-run2

0
iperf/run5-netfpga/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P50-run1 → iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P50-run1

0
iperf/run5-netfpga/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P50-run2 → iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P50-run2

0
iperf/run5-netfpga/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P50-u-b0-run1 → iperf/run5-netfpga-v6-to-v4/iperf-netfpga-from-v6-c2001:db8:42::a00:2a-p2345-O10-t190-6-P50-u-b0-run1

0
iperf/run6-netfpga/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P1-run1 → iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P1-run1

0
iperf/run6-netfpga/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P1-run2 → iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P1-run2

0
iperf/run6-netfpga/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P1-run3 → iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P1-run3

0
iperf/run6-netfpga/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P1-u-b0-run1 → iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P1-u-b0-run1

0
iperf/run6-netfpga/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P1-u-b0-run2 → iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P1-u-b0-run2

0
iperf/run6-netfpga/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P1-u-b0-run3 → iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P1-u-b0-run3

0
iperf/run6-netfpga/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P10-run1 → iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P10-run1

0
iperf/run6-netfpga/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P10-run2 → iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P10-run2

0
iperf/run6-netfpga/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P10-run3 → iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P10-run3

0
iperf/run6-netfpga/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P10-u-b0-run1 → iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P10-u-b0-run1

0
iperf/run6-netfpga/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P10-u-b0-run2 → iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P10-u-b0-run2

0
iperf/run6-netfpga/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P10-u-b0-run3 → iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P10-u-b0-run3

0
iperf/run6-netfpga/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P20-run1 → iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P20-run1

0
iperf/run6-netfpga/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P20-run2 → iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P20-run2

0
iperf/run6-netfpga/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P20-run3 → iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P20-run3

0
iperf/run6-netfpga/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P20-u-b0-run1 → iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P20-u-b0-run1

0
iperf/run6-netfpga/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P20-u-b0-run2 → iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P20-u-b0-run2

0
iperf/run6-netfpga/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P20-u-b0-run3 → iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P20-u-b0-run3

0
iperf/run6-netfpga/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P50-run1 → iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P50-run1

0
iperf/run6-netfpga/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P50-run2 → iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P50-run2

0
iperf/run6-netfpga/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P50-run3 → iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P50-run3

0
iperf/run6-netfpga/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P50-u-b0-run1 → iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P50-u-b0-run1

0
iperf/run6-netfpga/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P50-u-b0-run2 → iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P50-u-b0-run2

0
iperf/run6-netfpga/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P50-u-b0-run3 → iperf/run6-netfpga-v4-to-v6/iperf-netfpga-from-v4-c10.0.0.66-p2345-O10-t190-4-P50-u-b0-run3

Loading…
Cancel
Save