docs/report/introduction/methodology_dut_state.rst

   1 DUT state considerations
   2 ------------------------
   3
   4 This page discusses considerations for Device Under Test (DUT) state.
   5 DUTs such as VPP require configuration, to be provided before the aplication
   6 starts (via config files) or just after it starts (via API or CLI access).
   7
   8 During operation DUTs gather various telemetry data, depending on configuration.
   9 This internal state handling is part of normal operation,
  10 so any performance impact is included in the test results.
  11 Accessing telemetry data is additional load on DUT,
  12 so we are not doing that in main trial measurements that affect results,
  13 but we include separate trials specifically for gathering runtime telemetry.
  14
  15 But there is one kind of state that needs specific handling.
  16 This kind of DUT state is dynamically created based on incoming traffic,
  17 it affects how DUT handles the traffic, and (unlike telemetry counters)
  18 it has uneven impact on CPU load.
  19 Typical example is NAT where opening sessions takes more CPU than
  20 forwarding packet on existing sessions.
  21 We call DUT configurations with this kind of state "stateful",
  22 and configurations without them "stateless".
  23 (Even though stateless configurations contain state described in previous
  24 paragraphs, and some configuration items may have "stateful" in their name,
  25 such as stateful ACLs.)
  26
  27 Stateful DUT configurations
  28 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
  29
  30 Typically, the level of CPU impact of traffic depends on DUT state.
  31 The first packets causing DUT state to change have higher impact,
  32 subsequent packets matching that state have lower impact.
  33
  34 From performance point of view, this is similar to traffic phases
  35 for stateful protocols, see
  36 `NGFW draft <https://tools.ietf.org/html/draft-ietf-bmwg-ngfw-performance-05#section-4.3.4>`.
  37 In CSIT we borrow the terminology (even if it does not fit perfectly,
  38 see discussion below). Ramp-up traffic causes the state change,
  39 sustain traffic does not change the state.
  40
  41 As the performance is different, each test has to choose which traffic
  42 it wants to test, and manipulate the DUT state to achieve the intended impact.
  43
  44 Ramp-up trial
  45 _____________
  46
  47 Tests aiming at sustain performance need to make sure DUT state is created.
  48 We achieve this via a ramp-up trial, specific purpose of which
  49 is to create the state. Subsequent trials need no specific handling,
  50 as state remains the same.
  51
  52 For the state to be set completely, it is important DUT (nor TG) loses
  53 no packets, we achieve this by setting the profile multiplier (TPS from now on)
  54 to low enough value.
  55
  56 It is also important each state-affecting packet is sent.
  57 For size-limited traffic profile it is guaranteed by the size limit.
  58 For continuous traffic, we set a long enough duration (based on TPS).
  59
  60 At the end of the ramp-up trial, we check telemetry to confirm
  61 the state has been created as expected.
  62 Test fails if the state is not complete.
  63
  64 State Reset
  65 ___________
  66
  67 Tests aiming at ramp-up performance do not use ramp-up trial,
  68 and they need to reset the DUT state before each trial measurement.
  69 The way of resetting the state depends on test,
  70 usually an API call is used to partially de-configure
  71 the part that holds the state, and then re-configure it back.
  72
  73 In CSIT we control the DUT state behavior via a test variable "resetter".
  74 If it is not set, DUT state is not reset.
  75 If it is set, each search algorithm (including MRR) will invoke it
  76 before all trial measurements (both main and telemetry ones).
  77 Any configuration keyword enabling a feature with DUT state
  78 will check whether a test variable for ramp-up (duration) is present.
  79 If it is present, resetter is not set.
  80 If it is not present, the keyword sets the apropriate resetter value.
  81 This logic makes sure either ramp-up or state reset are used.
  82
  83 ..
  84     TODO: Classify trials into main and telemetry, in a separate place.
  85
  86 Notes: If both ramp-up and state reset were used, the DUT behavior
  87 would be identical to just reset, while test would take longer to execute.
  88 If neither were used, DUT will show different performance in subsequent trials,
  89 violating assumptions of search algorithms.
  90
  91 DUT versus protocol ramp-up
  92 ___________________________
  93
  94 There are at least three different causes for bandwidth possibly increasing
  95 within a single measurement trial.
  96
  97 The first is DUT switching from state modification phase to constant phase,
  98 it is the primary focus of this document.
  99 Using ramp-up traffic before main trials eliminates this cause
 100 for tests wishing to measure the performance of the next phase.
 101 Using size-limited profiles eliminates the next phase
 102 for tests wishing to measure performance of this phase.
 103
 104 The second is protocol such as TCP ramping up their throughput to utilize
 105 the bandwidth available. This is the original meaning of "ramp up"
 106 in the NGFW draft (see above).
 107 In existing tests we are not distinguishing such phases,
 108 trial measurment reports the telemetry from the whole trial
 109 (e.g. throughput is time averaged value).
 110
 111 The third is TCP increasing throughput due to retransmissions triggered by
 112 packet loss. In CSIT we currently try to avoid this behavior
 113 by using small enough data to transfer, so overlap of multiple transactions
 114 (primary cause of packet loss) is unlikely.
 115 But in MRR tests packet loss is still probable.
 116 Once again, we rely on using telemetry from the whole trial,
 117 resulting in time averaged throughput values.
 118
 119 Stateless DUT configuratons
 120 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 121
 122 These are simply configurations, which do not set any resetter value
 123 (even if ramp-up duration is not configured).
 124 Majority of existing tests are of this type, using continuous traffic profiles.
 125
 126 In order to identify limits of Trex performance,
 127 we have added suites with stateless DUT configuration (VPP ip4base)
 128 subjected to size-limited ASTF traffic.
 129 The discovered throughputs serve as a basis of comparison
 130 for evaluating the results for stateful DUT configurations (VPP NAT44ed)
 131 subjected to the same traffic profiles.
 132
 133 DUT versus TG state
 134 ~~~~~~~~~~~~~~~~~~~
 135
 136 Traffic Generator profiles can be stateful (ASTF) or stateless (STL).
 137 DUT configuration can be stateful or stateless (with respect to packet traffic).
 138
 139 In CSIT we currently use all four possible configurations:
 140
 141 - Regular stateless VPP tests use stateless traffic profiles.
 142
 143 - Stateless VPP configuration with stateful profile is used as a base for
 144   comparison.
 145
 146 - Some stateful DUT configurations (NAT44DET, NAT44ED unidirectional)
 147   are tested using stateless traffic profiles.
 148
 149 - The rest of stateful DUT configurations (NAT44ED bidirectional)
 150   are tested using stateful traffic profiles.