Low Latency Queuing
356
. . . . .
If burstiness is detected, the minimum delay of the class should be no
smaller than this:
[(burst size + 1) * packet size] / bit rate
4. The maximal delay for a class should be between the greatest and smallest
delay. Set the delay close to the greatest value, only if the application
occasionally bursts.
When you set the maximal delay, you will see an error message, if
the value is lower than the value set for other Low Latency Classes
of higher priority. Check Point QoS will also display an error
message, if the maximal delay is incompatible with interface
speed. Both error messages include a minimum acceptable
maximal-delay value. Set the maximal delay to a value no smaller
than the one printed in the message.
PREVENTING UNWANTED DROPS
If the aggregate bit rate going through the Low Latency Class exceeds the
constant bit rate of the class, drops occur. This situation may occur when the
number of streams actually opened exceeds the number you expected, when
you set the constant bit rate.
Limit the number of connections allowed to the number of connections used to
compute the class’s constant bit rate, by modifying the QoS Policy as follows:
1. Define a single rule under the class, with a per-connection guarantee as its
Action.
2. In the Per Connection Guarantee field of the QoS Action Properties screen,
define the per-connection bit rate you expect.
3. In the Number of guaranteed connections field, define the maximum
number of connections allowed in this class.
4. Do not select Accept additional non-guaranteed connections.
When to Use Low Latency Queueing
Use Low Latency Queueing when the bit rate of the stream is known and
controlling delay is important. Low Latency Classes do not receive TOS
markers. If preferential treatment is required beyond the QoS Module, DiffServ
should be used instead.
