Report: Add rls data, NAT44 ED TCP tput for 2n-dnv

[csit.git] / docs / report / introduction / methodology_nat44.rst

diff --git a/docs/report/introduction/methodology_nat44.rst b/docs/report/introduction/methodology_nat44.rst
index fb4cbd0..7dfd939 100644 (file)
--- a/docs/report/introduction/methodology_nat44.rst
+++ b/docs/report/introduction/methodology_nat44.rst
@@ -1,10 +1,10 @@
 .. _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
@@ -67,7 +67,7 @@ Private address ranges to be used in tests:
   - 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:
 
@@ -95,7 +95,7 @@ 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
@@ -134,7 +134,7 @@ NAT44det scenario tested:
     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
@@ -200,13 +200,13 @@ NAT44det case tested:
   - [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
 _________
@@ -347,7 +347,7 @@ does not match the transactions as defined by ASTF programs.
 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.
@@ -362,7 +362,7 @@ Transaction counts as attempted when opackets counter increases on client side.
 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.
@@ -386,7 +386,7 @@ Transaction counts as successful when tcps_connects counter increases
 on client side.
 
 UDP TPUT
-~~~~~~~~
+````````
 
 This profile uses a small transaction of "request-response" type,
 with several packets simulating data payload.
@@ -411,11 +411,14 @@ in the reading phase. This probably decreases TRex performance,
 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,
@@ -449,8 +452,21 @@ and somehow uneven rate of packets sent. This makes it hard to interpret
 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.