How traffic-shaping queue modes work
When shaping traffic as specified by the policies, the Exinda Appliance needs to maintain a queue of packets for each policy within their respective virtual circuits. There are three different queuing methods to address the needs of different use scenarios when using a multi-processor appliance.
- Single queue mode is the default. It is good for environments that require < 1.5 Gbps of traffic shaping.
- Multi queue mode is good for environments that require 10 Gbps of traffic shaping and have many flows per virtual circuitlogical definitions that partition a a physical network circuit and used to determine what traffic passes through it and how much. Education institutions are ideal for this queuing mode.
- Multi per VC queue mode is good for environments that require < 5 Gbps of traffic shaping and there are potentially fewer flows per virtual circuit, for example, when the bandwidth of a particular virtual circuit is tested using a single-flowthe network traffic between network objects generator, such as speedtest.net.
The mode can be modified via CLI: Optimizer.
Single Queue Mode
The single queue mode uses a single global policy queue in memory to handle the traffic shaping of all virtual circuits. The bandwidth limit is due to limitations of accessing the global memory with appropriate memory locks.
Single Queue Mode
Multi-Queue Mode
The multi-queue mode uses one policy queue per CPU where the flows of a given virtual circuit are divided evenly among the policy queues. This eliminates the cross processor locking of global memory by distributing the policy queues among the processors. Each flow within each policy is handled by a single processor.
Each CPU processes 1/N of each virtual circuit’s traffic, where N is the number of CPUs. That is, if the virtual circuit is specified in the Optimizer as having 10 Mbps bandwidth, in an appliance with four CPUs, each CPU policy queue will be allowed 10 Mbps/4 = 2.5 Mbps per CPU. In order to have even distribution, it assumes multiple flows that can be distributed among the N CPUs. This queueing method is not good for environments where customers validate the amount of bandwidth they receive by sending a single long flow through their virtual circuit.
In this case, the flow is handled by a single CPU and the other CPUs are idle. It then appears that they are getting 1/N of the amount of traffic that they are expecting even though in more realistic use of the network, where the flows can be distributed more evenly, they will get the appropriate amount of bandwidth.
Multi Queue Mode
Multi Per VC Queue Mode
The multi per VC queue mode uses one policy queue per CPU where each virtual circuit is assigned to a single policy queue. That is, the virtual circuits are distributed amongst the policy queues, but any given virtual circuit exists on a single policy queue. The flows for any given virtual circuit will be handled by a single CPU policy queue and therefore will not be limited to 1/N of the traffic when a single flow is tested.
CAUTION
Each virtual circuit is assigned to individual policy queues and any given virtual circuit cannot use a policy queue that it has not been assigned to. Therefore, the virtual circuits cannot be oversubscribed, that is the sum of the desired bandwidths for the virtual circuits cannot be higher than the specified bandwidth of the circuit. This is because there can be no automatic redistribution of minimum bandwidth among the virtual circuits when the virtual circuits are oversubscribed.
If the circuits are oversubscribed, then the shaping queuing mode will revert to the multi-queue mode.
Multi per VC Queue Mode