Browse Source

Finish moving things from conclusion to results

master
Nico Schottelius 3 years ago
parent
commit
3848ef2b96
  1. 202
      doc/Conclusion.tex
  2. 157
      doc/Results.tex

202
doc/Conclusion.tex

@ -1,191 +1,20 @@
\chapter{\label{summary}Conclusion}
\chapter{\label{summary}Conclusion and Outlook}
%** Summary.tex: What have you achieved, what have you presented in this
% document. What are the highlights of your work.
% It should conclude by a conclusion.
Sum up what you have done and recapitulate your key findings.
%\section{\label{conclusion:overall}Overall}
\section{\label{conclusion:softwarenat64}Software based NAT64}
\section{\label{conclusion:general}General}
\section{\label{conclusion:bmv2}BMV2}
\section{\label{conclusion:P4}P4}
NDP parsing problem
checksumming a frequent problem and helper
p4 potential
Many possibilities
Protocol independent
Easy architecture
Limitations in
if in action limitations
Limits if in actions
python2 only - unicode errors
IPv6: NDP: not easy to parse, as unknown number of following fields
No support for multiple LPM keys in a table, can be solved with
ternary matching.
switch cannot be used in actions
if things don't work, often a checksum problem.
if frame checksum, then length of packet is broken
\begin{verbatim}
p4c --target bmv2 --arch v1model --std p4-16 "../p4src/static-mapping.p4" -o "/home/p4/master-thesis/p4src"
../p4src/static-mapping.p4(366): error: Program is not supported by this target, because table MyIngress.v6_networks has multiple successors
table v6_networks {
^^^^^^^^^^^
\end{verbatim}
\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}
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
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)
NDP parsing support
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}
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}
No switch in actions, No conditional execution in actions
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
% ----------------------------------------------------------------------
\section{\label{conclusion:netpfga}NetFGPA - all HERE}
Needed to debug internal parsing errors
debugging generated tcl code to debug impl1 error
\section{\label{conclusion:realworld}Real world applications}
Can be deployed using the netpfga. Or Barefoot or Arista.
\section{\label{conclusion:outlook}Outlook}
%** Outlook.tex: What needs to be done further, what is planed
%
What are the consequences of your work for future work?
OUTLOOK What are the consequences of your work for future work?
Different HW
@ -204,29 +33,20 @@ No fragmentation
No address / mac learning
**** No DNS64
has already been solved in a different domain - could even do
transparent / in network modification
**** Incomplete NDP
Very limited option support
has already been solved in a different domain - could even do
transparent / in network modification. DNSSEC.
**** Incomplete NDP
Very limited option support
No resolution of hardware addresses
No resolution of hardware addresses
\section{\label{conclusion:closing}Closing words (NAME?)}
While the port to NetPFGA was significantly more effort then expected,
the learnings of the different layers were very much appreciated / liked
It was a
% ----------------------------------------------------------------------
\section{\label{conclusion:netpfga2}NetFGPA2 - conclusion here}
NetFGPA - conclusion here}
Very time intensive development due to usability problems and
uncertainty of functionality (compare sections
\ref{results:netpfga:usability} and \ref{results:netpfga:stability}).
\section{todo - FIXME: remove}
\begin{verbatim}
***** Summary eher kurz
***** Outlook als subsection!
\end{verbatim}

157
doc/Results.tex

@ -471,6 +471,12 @@ General result: limited NAT64 is working, however
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}
During the benchmark cpu bound, single thread
@ -481,3 +487,154 @@ tayga: Single threaded
kernel module
high cpu usage for udp connetcinos
Integration with iptables
% ----------------------------------------------------------------------
\section{\label{results:p4}P4}
NDP parsing problem
checksumming a frequent problem and helper
if in action limitations
switch cannot be used in actions
python2 only - unicode errors
IPv6: NDP: not easy to parse, as unknown number of following fields
No support for multiple LPM keys in a table, can be solved with
ternary matching.
if things don't work, often a checksum problem.
if frame checksum, then length of packet is broken
\begin{verbatim}
p4c --target bmv2 --arch v1model --std p4-16 "../p4src/static-mapping.p4" -o "/home/p4/master-thesis/p4src"
../p4src/static-mapping.p4(366): error: Program is not supported by this target, because table MyIngress.v6_networks has multiple successors
table v6_networks {
^^^^^^^^^^^
\end{verbatim}
\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}
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
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)
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}
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}
No switch in actions, No conditional execution in actions
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

Loading…
Cancel
Save