Voice application model
Use the voice application model to optimize voice traffic on your network. When using the voice application model, you must use either the traceprobe or ICMP measurement modes. If you can employ only TCP, then you should use the web or other application model because the voice 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 voice 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 are 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 impacted 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, 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. 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 voice 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 24 shows how the computed delay correlates with the decision metric and application performance, from best (*****) to worst (*), while Table 25 shows how the measured loss percentage correlates with the decision metric and application performance.
Table 24: Round Trip Time Affects Application Performance
| Delay (ms) |
Decision Metric |
Application Performance |
0 - 125
|
0 - 100
|
*****
|
126 - 250
|
101 - 200
|
****
|
251 - 400
|
201 - 300
|
***
|
401 - 800
|
301 - 500
|
**
|
> 800
|
501 - 100
|
*
|
Table 25: Loss Affects Application Performance
| Loss (%) |
Decision Metric |
Application Performance |
0 - 1.5
|
0 - 100
|
*****
|
1.6 - 3.0
|
101 - 200
|
****
|
3.1 - 5.0
|
201 - 300
|
***
|
5.1 - 10
|
301 - 500
|
**
|
> 10
|
501 - 100
|
*
|
For the voice 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.