Low Latency QoS Class

What can I do here?

Use this window to define QoS Low Latency class properties. Specify the Constant Bit Rate, the rate at which packets of this class will be transmitted, and the Maximal Delay, the outer limit of the delay that will be tolerated for packets of this class, specified for active directions.

Note - UTM-1 Edge interfaces do not have DiffServ and Low Latency Class configuration options.

Avoiding Low Drops

Avoiding drops means holding (possibly long) queues, which may lead to non-negligible delays. For some types of traffic, such as voice and video, bounding this delay is important. Long queues are inadequate for these types of traffic because they lead to substantial delay. Fortunately, for most "delay sensitive" applications, there is no need to drop packets from queues in order to keep them short.

Instead, the fact that the streams of these applications have a known, bounded bit rate can be utilized. If QoS is configured to forward as much traffic as the stream delivers, then only a small number of packets accumulate in the queues and delay is negligible.

QoS Low Latency Queuing makes it possible to define special Classes of Service for "delay sensitive" applications like voice and video. Rules under these classes can be used together with other rules in the security policy Rule Base. Low Latency classes require you to specify the maximal delay that is tolerated and a Constant Bit Rate. QoS then guarantees that traffic matching rules of this type is forwarded within the limits of the bounded delay.

For each Low Latency class defined on an interface, a constant bit rate and maximal delay should be specified for active directions. QoS checks packets matched to Low Latency class rules to make sure they have not been delayed for longer than their maximal delay permits. If the maximal delay of a packet has been exceeded, it is dropped. Otherwise, it is transmitted at the defined constant bit rate for the Low Latency class to which it belongs.

If the Constant Bit Rate of the class is defined correctly (meaning that it is not smaller than the expected arrival rate of the matched traffic), packets are not dropped (provided that the delay exceeds some minimum). On the other hand, when the arrival rate is higher than the specified Constant Bit Rate, packets exceeding this constant rate are dropped to ensure that those transmitted are within the maximal delay limitations.

Note - The maximal delay set for a Low Latency class is an upper limit. This means that packets matching the class are always forwarded with a delay not greater, but often smaller, than specified.

In most cases, one Low Latency class is sufficient to serve all bounded delay traffic. In some cases, however, the user may need to define more than one Low Latency class. For this purpose, Low Latency classes are assigned one out of five priority levels (not including the Expedited Forwarding class. These priority levels are relative to other Low Latency classes.

It is advisable to define more than one Low Latency class if different types of traffic require different maximal delays.

The class with the lower maximal delay should get a higher priority than the class with the higher delay. The reason for this is that when two packets are ready to be forwarded, one for each Low Latency class, the packet from the higher priority class is forwarded first. The remaining packet (from the lower class) then encounters greater delay. This implies that the maximal delay that can be set for a Low Latency class depends on the Low Latency classes of higher priority.

Other Low Latency classes can affect the delay incurred by a class and therefore must be taken into consideration when determining the minimal delay that is feasible for the class. This is best done by initially setting the priorities for all Low Latency classes according to maximal delay, and then defining the classes according to descending priority. When you define class two, for example, class one should already be defined.