docs/content/methodology/trex_traffic_generator.md

   1 ---
   2 bookToc: false
   3 title: "TRex Traffic Generator"
   4 weight: 5
   5 ---
   6
   7 # TRex Traffic Generator
   8
   9 ## Usage
  10
  11 [TRex traffic generator](https://trex-tgn.cisco.com) is used for majority of
  12 CSIT performance tests. TRex is used in multiple types of performance tests,
  13 see [Data Plane Throughtput]({{< ref "data_plane_throughput/data_plane_throughput/#Data Plane Throughtput" >}})
  14 for more detail.
  15
  16 ## Traffic modes
  17
  18 TRex is primarily used in two (mutually incompatible) modes.
  19
  20 ### Stateless mode
  21
  22 Sometimes abbreviated as STL.
  23 A mode with high performance, which is unable to react to incoming traffic.
  24 We use this mode whenever it is possible.
  25 Typical test where this mode is not applicable is NAT44ED,
  26 as DUT does not assign deterministic outside address+port combinations,
  27 so we are unable to create traffic that does not lose packets
  28 in out2in direction.
  29
  30 Measurement results are based on simple L2 counters
  31 (opackets, ipackets) for each traffic direction.
  32
  33 ### Stateful mode
  34
  35 A mode capable of reacting to incoming traffic.
  36 Contrary to the stateless mode, only UDP and TCP is supported
  37 (carried over IPv4 or IPv6 packets).
  38 Performance is limited, as TRex needs to do more CPU processing.
  39 TRex suports two subtypes of stateful traffic,
  40 CSIT uses ASTF (Advanced STateFul mode).
  41
  42 This mode is suitable for NAT44ED tests, as clients send packets from inside,
  43 and servers react to it, so they see the outside address and port to respond to.
  44 Also, they do not send traffic before NAT44ED has created the corresponding
  45 translation entry.
  46
  47 When possible, L2 counters (opackets, ipackets) are used.
  48 Some tests need L7 counters, which track protocol state (e.g. TCP),
  49 but those values are less than reliable on high loads.
  50
  51 ## Traffic Continuity
  52
  53 Generated traffic is either continuous, or limited (by number of transactions).
  54 Both modes support both continuities in principle.
  55
  56 ### Continuous traffic
  57
  58 Traffic is started without any data size goal.
  59 Traffic is ended based on time duration, as hinted by search algorithm.
  60 This is useful when DUT behavior does not depend on the traffic duration.
  61 The default for stateless mode.
  62
  63 ### Limited traffic
  64
  65 Traffic has defined data size goal (given as number of transactions),
  66 duration is computed based on this goal.
  67 Traffic is ended when the size goal is reached,
  68 or when the computed duration is reached.
  69 This is useful when DUT behavior depends on traffic size,
  70 e.g. target number of NAT translation entries, each to be hit exactly once
  71 per direction.
  72 This is used mainly for stateful mode.
  73
  74 ## Traffic synchronicity
  75
  76 Traffic can be generated synchronously (test waits for duration)
  77 or asynchronously (test operates during traffic and stops traffic explicitly).
  78
  79 ### Synchronous traffic
  80
  81 Trial measurement is driven by given (or precomputed) duration,
  82 no activity from test driver during the traffic.
  83 Used for most trials.
  84
  85 ### Asynchronous traffic
  86
  87 Traffic is started, but then the test driver is free to perform
  88 other actions, before stopping the traffic explicitly.
  89 This is used mainly by reconf tests, but also by some trials
  90 used for runtime telemetry.
  91
  92 ## Trafic profiles
  93
  94 TRex supports several ways to define the traffic.
  95 CSIT uses small Python modules based on Scapy as definitions.
  96 Details of traffic profiles depend on modes (STL or ASTF),
  97 but some are common for both modes.
  98
  99 Search algorithms are intentionally unaware of the traffic mode used,
 100 so CSIT defines some terms to use instead of mode-specific TRex terms.
 101
 102 ### Transactions
 103
 104 TRex traffic profile defines a small number of behaviors,
 105 in CSIT called transaction templates. Traffic profiles also instruct
 106 TRex how to create a large number of transactions based on the templates.
 107
 108 Continuous traffic loops over the generated transactions.
 109 Limited traffic usually executes each transaction once
 110 (typically as constant number of loops over source addresses,
 111 each loop with different source ports).
 112
 113 Currently, ASTF profiles define one transaction template each.
 114 Number of packets expected per one transaction varies based on profile details,
 115 as does the criterion for when a transaction is considered successful.
 116
 117 Stateless transactions are just one packet (sent from one TG port,
 118 successful if received on the other TG port).
 119 Thus unidirectional stateless profiles define one transaction template,
 120 bidirectional stateless profiles define two transaction templates.
 121
 122 ### TPS multiplier
 123
 124 TRex aims to open transaction specified by the profile at a steady rate.
 125 While TRex allows the transaction template to define its intended "cps" value,
 126 CSIT does not specify it, so the default value of 1 is applied,
 127 meaning TRex will open one transaction per second (and transaction template)
 128 by default. But CSIT invocation uses "multiplier" (mult) argument
 129 when starting the traffic, that multiplies the cps value,
 130 meaning it acts as TPS (transactions per second) input.
 131
 132 With a slight abuse of nomenclature, bidirectional stateless tests
 133 set "packets per transaction" value to 2, just to keep the TPS semantics
 134 as a unidirectional input value.
 135
 136 ### Duration stretching
 137
 138 TRex can be IO-bound, CPU-bound, or have any other reason
 139 why it is not able to generate the traffic at the requested TPS.
 140 Some conditions are detected, leading to TRex failure,
 141 for example when the bandwidth does not fit into the line capacity.
 142 But many reasons are not detected.
 143
 144 Unfortunately, TRex frequently reacts by not honoring the duration
 145 in synchronous mode, taking longer to send the traffic,
 146 leading to lower then requested load offered to DUT.
 147 This usualy breaks assumptions used in search algorithms,
 148 so it has to be avoided.
 149
 150 For stateless traffic, the behavior is quite deterministic,
 151 so the workaround is to apply a fictional TPS limit (max_rate)
 152 to search algorithms, usually depending only on the NIC used.
 153
 154 For stateful traffic the behavior is not deterministic enough,
 155 for example the limit for TCP traffic depends on DUT packet loss.
 156 In CSIT we decided to use logic similar to asynchronous traffic.
 157 The traffic driver sleeps for a time, then stops the traffic explicitly.
 158 The library that parses counters into measurement results
 159 than usually treats unsent packets/transactions as lost/failed.
 160
 161 We have added a IP4base tests for every NAT44ED test,
 162 so that users can compare results.
 163 If the results are very similar, it is probable TRex was the bottleneck.
 164
 165 ### Startup delay
 166
 167 By investigating TRex behavior, it was found that TRex does not start
 168 the traffic in ASTF mode immediately. There is a delay of zero traffic,
 169 after which the traffic rate ramps up to the defined TPS value.
 170
 171 It is possible to poll for counters during the traffic
 172 (fist nonzero means traffic has started),
 173 but that was found to influence the NDR results.
 174
 175 Thus "sleep and stop" stategy is used, which needs a correction
 176 to the computed duration so traffic is stopped after the intended
 177 duration of real traffic. Luckily, it turns out this correction
 178 is not dependend on traffic profile nor CPU used by TRex,
 179 so a fixed constant (0.112 seconds) works well.
 180 Unfortunately, the constant may depend on TRex version,
 181 or execution environment (e.g. TRex in AWS).
 182
 183 The result computations need a precise enough duration of the real traffic,
 184 luckily server side of TRex has precise enough counter for that.
 185
 186 It is unknown whether stateless traffic profiles also exhibit a startup delay.
 187 Unfortunately, stateless mode does not have similarly precise duration counter,
 188 so some results (mostly MRR) are affected by less precise duration measurement
 189 in Python part of CSIT code.
 190
 191 ## Measuring Latency
 192
 193 If measurement of latency is requested, two more packet streams are
 194 created (one for each direction) with TRex flow_stats parameter set to
 195 STLFlowLatencyStats. In that case, returned statistics will also include
 196 min/avg/max latency values and encoded HDRHistogram data.