.. _nat44_methodology:
Network Address Translation IPv4 to IPv4
-----------------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
NAT44 Prefix Bindings
-^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~
NAT44 prefix bindings should be representative to target applications,
where a number of private IPv4 addresses from the range defined by
- Used in tests for up to 1 048 576 inside addresses (inside hosts).
NAT44 Session Scale
-~~~~~~~~~~~~~~~~~~~
+```````````````````
NAT44 session scale tested is govern by the following logic:
+---+---------+------------+
NAT44 Deterministic
-^^^^^^^^^^^^^^^^^^^
+```````````````````
NAT44det performance tests are using TRex STL (Stateless) API and traffic
profiles, similar to all other stateless packet forwarding tests like
TODO: Make traffic profile names resemble suite names more closely.
NAT44 Endpoint-Dependent
-^^^^^^^^^^^^^^^^^^^^^^^^
+````````````````````````
In order to excercise NAT44ed ability to translate based on both
source and destination address and port, the inside-to-outside traffic
- [mrr|ndrpdr|soak], bidirectional stateful tests MRR, NDRPDR, or SOAK.
Stateful traffic profiles
-^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~
There are several important details which distinguish ASTF profiles
from stateless profiles.
General considerations
-~~~~~~~~~~~~~~~~~~~~~~
+``````````````````````
Protocols
_________
See TCP TPUT profile below.
UDP CPS
-~~~~~~~
+```````
This profile uses a minimalistic transaction to verify NAT44ed session has been
created and it allows outside-to-inside traffic.
Transaction counts as successful when ipackets counter increases on client side.
TCP CPS
-~~~~~~~
+```````
This profile uses a minimalistic transaction to verify NAT44ed session has been
created and it allows outside-to-inside traffic.
on client side.
UDP TPUT
-~~~~~~~~
+````````
This profile uses a small transaction of "request-response" type,
with several packets simulating data payload.
but it leads to more stable results then alternatives.
TCP TPUT
-~~~~~~~~
+````````
This profile uses a small transaction of "request-response" type,
with some data amount to be transferred both ways.
+In CSIT release 22.06, TRex behavior changed, so we needed to edit
+the traffic profile. Let us describe the pre-22.06 profile first.
+
Client connects, sends 5 data packets worth of data,
receives 5 data packets worth of data and closes its side of the connection.
Server accepts connection, reads 5 data packets worth of data,
MRR results (frequently MRR is below NDR for this reason),
but NDR and PDR results tend to be stable enough.
+In 22.06, the "ACK from the receiving side" behavior changed,
+the receiving side started sending ACK sometimes
+also before receiving the full set of 5 data packets.
+If the previous profile is understood as a "single challenge, single response"
+where challenge (and also response) is sent as a burst of 5 data packets,
+the new profile uses "bursts" of 1 packet instead, but issues
+the challenge-response part 5 times sequentially
+(waiting for receiving the response before sending next challenge).
+This new profile happens to have the same overall packet count
+(when no re-transmissions are needed).
+Although it is possibly more taxing for TRex CPU,
+the results are comparable to the old traffic profile.
+
Ip4base tests
-^^^^^^^^^^^^^
+~~~~~~~~~~~~~
Contrary to stateless traffic profiles, we do not have a simple limit
that would guarantee TRex is able to send traffic at specified load.