aboutsummaryrefslogtreecommitdiffstats
path: root/docs/report/introduction/methodology_nat44.rst
diff options
context:
space:
mode:
authorVratko Polak <vrpolak@cisco.com>2022-07-20 10:18:29 +0200
committerVratko Polak <vrpolak@cisco.com>2022-07-20 10:18:29 +0200
commitb06a1adb1c26eeb5bf5c86091fef30441f6d06a1 (patch)
tree74c1139c3fd8412fd39185b75b07b230f2415f79 /docs/report/introduction/methodology_nat44.rst
parent371bac71bc789bf9d68fa1b8ba77f21c4876244f (diff)
fix(astf): avoid issues in pps tput
When more than 1 data packet is sent in the same chunk, TRex is sometimes not fully deterministic in its usage of delayed ACKs. This changes the "application protocol" to sent 5 chunks (1 data packet each), c2s and s2c interleaved, so each subsequent chunk acts as an ACK. The overall packet count remains the same, and even though this interleaved way may be more demanding on TRex CPU, preliminary results show NAT performance is still well below ip4base performance. As a side effect, the interleaved way seems to work also for 100B data frames, so we are avoiding two issues at once. Ticket: CSIT-1846 Ticket: CSIT-1830 Change-Id: Ia4dcfa7c89f2c08fc32bd6118e2e009316b33c25 Signed-off-by: Vratko Polak <vrpolak@cisco.com>
Diffstat (limited to 'docs/report/introduction/methodology_nat44.rst')
-rw-r--r--docs/report/introduction/methodology_nat44.rst16
1 files changed, 16 insertions, 0 deletions
diff --git a/docs/report/introduction/methodology_nat44.rst b/docs/report/introduction/methodology_nat44.rst
index fb4cbd0c7e..1b00ef281c 100644
--- a/docs/report/introduction/methodology_nat44.rst
+++ b/docs/report/introduction/methodology_nat44.rst
@@ -416,6 +416,9 @@ 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,6 +452,19 @@ 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
^^^^^^^^^^^^^