Finish moving things from conclusion to results
This commit is contained in:
parent
2533ad653f
commit
3848ef2b96
2 changed files with 168 additions and 191 deletions
|
@ -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
|
%** Summary.tex: What have you achieved, what have you presented in this
|
||||||
% document. What are the highlights of your work.
|
% document. What are the highlights of your work.
|
||||||
% It should conclude by a conclusion.
|
% It should conclude by a conclusion.
|
||||||
|
|
||||||
Sum up what you have done and recapitulate your key findings.
|
Sum up what you have done and recapitulate your key findings.
|
||||||
|
|
||||||
%\section{\label{conclusion:overall}Overall}
|
p4 potential
|
||||||
|
|
||||||
\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
|
|
||||||
|
|
||||||
Many possibilities
|
Many possibilities
|
||||||
Protocol independent
|
Protocol independent
|
||||||
Easy architecture
|
Easy architecture
|
||||||
|
|
||||||
Limitations in
|
NDP parsing support
|
||||||
|
|
||||||
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)
|
|
||||||
|
|
||||||
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.
|
Can be deployed using the netpfga. Or Barefoot or Arista.
|
||||||
|
|
||||||
|
OUTLOOK What are the consequences of your work for future work?
|
||||||
\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?
|
|
||||||
|
|
||||||
Different HW
|
Different HW
|
||||||
|
|
||||||
|
@ -204,29 +33,20 @@ No fragmentation
|
||||||
No address / mac learning
|
No address / mac learning
|
||||||
|
|
||||||
**** No DNS64
|
**** No DNS64
|
||||||
has already been solved in a different domain - could even do
|
has already been solved in a different domain - could even do
|
||||||
transparent / in network modification
|
transparent / in network modification. DNSSEC.
|
||||||
**** Incomplete NDP
|
|
||||||
Very limited option support
|
|
||||||
|
|
||||||
No resolution of hardware addresses
|
**** Incomplete NDP
|
||||||
|
Very limited option support
|
||||||
|
|
||||||
|
No resolution of hardware addresses
|
||||||
|
|
||||||
\section{\label{conclusion:closing}Closing words (NAME?)}
|
|
||||||
While the port to NetPFGA was significantly more effort then expected,
|
While the port to NetPFGA was significantly more effort then expected,
|
||||||
the learnings of the different layers were very much appreciated / liked
|
the learnings of the different layers were very much appreciated / liked
|
||||||
|
|
||||||
It was a
|
It was a
|
||||||
|
|
||||||
|
NetFGPA - conclusion here}
|
||||||
% ----------------------------------------------------------------------
|
|
||||||
\section{\label{conclusion:netpfga2}NetFGPA2 - conclusion here}
|
|
||||||
Very time intensive development due to usability problems and
|
Very time intensive development due to usability problems and
|
||||||
uncertainty of functionality (compare sections
|
uncertainty of functionality (compare sections
|
||||||
\ref{results:netpfga:usability} and \ref{results:netpfga:stability}).
|
\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
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,
|
No NDP, no ARP - focused on key factors of NAT64 translation,
|
||||||
other features can be supported by controller
|
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:tayga}Tayga}
|
||||||
During the benchmark cpu bound, single thread
|
During the benchmark cpu bound, single thread
|
||||||
|
@ -481,3 +487,154 @@ tayga: Single threaded
|
||||||
kernel module
|
kernel module
|
||||||
high cpu usage for udp connetcinos
|
high cpu usage for udp connetcinos
|
||||||
Integration with iptables
|
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…
Reference in a new issue