Enterprise application model

Use the enterprise model to optimize time-critical TCP transactions on your network, such as transactional Web, file transfer, and gaming (see table Table 19 for examples of which application model is recommended for a particular application type). When using the enterprise application model, you must use either the traceprobe or ICMP measurement mode. If you can use only TCP, then you should use the Web application model because the enterprise model requires measurements of the loss characteristics in your network to a higher degree of precision than is possible with TCP.

The following parameters control the behavior of the enterprise application model:

• application-delay - represents the calculated average delay (in milliseconds) of a transaction and takes into account an average of three TCP turns for a typical transaction. The metric-contribution affects the weighting of this delay in CNA’s calculations. Its value determines the mid-point of a curve that tells CNA how strictly it should regard application delay in its decisions. A higher number for this value places greater importance on delay (an application is considered to be more affected by a delay). Table 20 shows how the weighting of application-delay affects the performance calculation, from best (*****) to worst (*).

The first column contains the application delay (in milliseconds). It correlates with the decision metric, which is used by the decision-maker process to evaluate the performance of a route for a particular subnet. The default values for application delay are shown, but you can adjust this table when needed. The range of the decision metric is from 0 (best performance) to 1000 (worst performance). You can change the distribution of this range with metric-contribution. Its default value of 1500ms means that when an application is experiencing 1500ms of delay; the decision metric is 500. For the enterprise model, when the decision metric exceeds 300, then performance for that subnet-link is considered unacceptable. Table 21 shows what happens when you change the metric-contribution to 750ms: the decision metric is affected considerably more by application delay because the metric-contribution sets a delay of 750ms as the mid-point of the decision metric (500), as opposed to the default 1500ms.

Application Delay is derived from two measurement values: Loss and Round Trip Time (RTT). Table 22 shows how the loss percentage corresponds with application delay, and Table 23 shows the effects of Round Trip Time (RTT). Together, loss and RTT determine the computed application delay and share approximately equal weight.

• delay - determines how the moving average of delay is calculated. The half-life parameter controls the smoothness of the moving average. A high value results in smaller changes in the calculated average delay because the delay contribution of past measurements is greater than when half-life is set low.
• loss - controls the smoothing factor of measured loss. A high value results in a smaller contribution of past loss events; conversely, a low value allows past loss events to have a greater influence on the decision-maker’s calculations.
• metric - this is an internal parameter, do not change it.
• short-term-loss - measures the observed loss in the last window-width packets received. Also uses a threshold to compare against the number of losses in the window to determine if there is loss. Below threshold short-term-loss is 0, above threshold it equals num losses / window-width.