Multimedia application model

Use this model to optimize real-time applications on your network. Examples include voice over IP, streaming audio, and video conferencing applications. See Table 19 for examples of which application model is recommended for a particular application type. When using the multimedia application model, you must use either the traceprobe or ICMP measurement modes. If you can employ only TCP, then you should use the web application model because the multimedia model requires measurements of the loss and jitter characteristics in your network to a higher degree of precision than is possible with TCP.

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

• 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. The metric-contribution parameter affects the weighting of this delay in the decision-maker’s performance calculations. Its value determines the mid-point of a curve that tells the decision-maker how strictly it should regard application delay in its decisions. A higher number for this value places greater importance on delay (for example, an application is considered to be affected more by a delay). It works in the same way as explained in Enterprise application model for application-delay.
• jitter min-buffer - sets the amount of buffer delay introduced by a client application (for example, voice over IP, video conferences), in milliseconds.
• loss half-life - 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.
• loss metric - contribution affects the weighting of the loss percentage in the decision-maker’s performance calculations. Its value determines the mid-point of a curve that tells the decision-maker process how strictly it should regard this loss in its decisions. A higher number for this value places greater importance on loss (for example, an application is considered to be affected more by packet loss). It works in the same way as explained in Enterprise application model for application-delay.
• 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.

For the application multimedia model, application performance is derived from delay, jitter, and loss measurements. Loss measurements consist of both a long term loss average and a short term loss average, and the decision-maker uses the larger of the two along with the delay and jitter measurements for its ultimate routing decision (the resulting value is called the decision metric). Table 31 shows how the computed delay correlates with the decision metric and application performance, from best (*****) to worst (*), while Table 29 shows how the measured loss percentage correlates with the decision metric and application performance.

For the multimedia application model, delay is calculated from round trip time (RTT) and jitter (as opposed to the enterprise model where RTT and loss percentage are the factors for delay). The CNA system’s default values for RTT and loss are shown, but you can adjust the metric-contribution of each when needed, in the same way as explained in Enterprise application model for application-delay.