To begin queue configuration, navigate to Firewall | Traffic Shaper. You have a choice of clicking on either the By Interface or By Queue tabs. If you choose the By Interface tab, you will see a list of interfaces at the root level, along with a list of queues that are available on each interface (which ones are available will depend on the choices you made in the traffic shaping wizard); if you choose By Queue, a different hierarchy will appear, with a list of queues at the root level, and a list of interfaces utilizing a queue will appear when you click on each queue. You can edit queues from either tab and get the same result. If you are creating new queues, you will likely find that the easiest way to add queues is to start on the By Interface tab. From there, you can create a queue on a single interface, and then make the queue available on other interfaces by clicking on the By Queue tab and using the Clone Shaper to this Interface button.

Once you have selected a queue on an interface to edit, several options will appear. The Enable/Disable checkbox gives you the ability to disable a queue and any children queues, if the checkbox is unchecked. The Name edit box allows you to change the name, and the priority edit box allows you to set a priority level from 0 to 7, with higher-numbered priority levels taking precedence over lower-numbered ones—but this field will be ignored if the queue is an HFSC queue. HFSC queues can be identified by the fact that their configuration pages have a section called Service Curve (sc).

The Queue Limit edit box allows you to enter the queue limit. This limit is expressed in terms of total packets. The Scheduler options checkboxes allow you to apply additional traffic shaping algorithms to the queue. There is a Default Queue checkbox that will make the queue the default queue for the interface selected. There are several other options:

• Random Early Detection: With this algorithm, the traffic shaping queue is a buffer that, once full, will drop packets. This is often referred to as tail drop, since packets are dropped from the end of the buffer. This can be a problem, since when the network is congested, all buffers can become full, with many packets being dropped. Random Early Detection (RED) attempts to avoid this problem by randomly dropping packets as the buffer starts to fill up.
• Random Early Detection In and Out: This is a variation of RED, in which we still use the RED algorithm, but have separate in and out buffers. To make it more effective, the out queue will be more aggressive than the in queue in dropping packets. The idea is that the out queue will be controlled before any in traffic needs to be dropped. This type of queue is sometimes referred to as RED with In and Out, or RIO.
• Explicit Congestion Notification: This type of queue takes advantage of an extension to TCP/IP defined in RFC 3168 (2001). This extension provides for end-to-end notification of network congestion.
• CoDel Active Queue: This type of queue was developed to address perceived shortcomings in RED/RIO. The latter is based on the assumption that average queue length is a sign of network congestion (the more items in a queue, the more congested it is). CoDel rejects this assumption and uses the minimum amount of delay experience of any packet in the running window in order to measure congestion. CoDel's objective is to minimize the delay and keep the delay below five milliseconds. If the minimum delay rises above five milliseconds, then packets are dropped from the window. This continues until the delay falls below the allowed level. This type of queue assumes that there are good queues and bad queues. Good queues handle bursts of traffic with only minor increases in delay. Bad queues will fill up upon a burst of traffic and stay filled. CoDel ignores the good queues and focuses on lowering the delay on bad queues.

In the Description edit box, you can enter a brief, non-parsed description for your own reference.

The preceding options are available for queues that employ PRIQ or CBQ; however, if HFSC was chosen, there are other options available on a section of the page labeled Service Curve (sc). The first option is Bandwidth, which simply allows you to set the maximum bandwidth of the queue. The remaining service curve options allow you to configure the service curve.

Each service curve has three parameters: m1, d, and m2. If you followed the discussion of HFSC earlier in this chapter, you should already know what these are. m1 and m2 represent two portions of the service curve. d represents the dividing point between m1 and m2. For the first d milliseconds, the queue receives the bandwidth defined by m1. After that, the queue gets the value defined by m2. There are three configurable service curves for each of the queues, which are defined as follows:

• Max bandwidth for the queue (Upper Limit): This curve limits HFSC bandwidth to that which is available upstream
• Min Bandwidth for the queue (Real Time): This service curve guarantees a precise minimum bandwidth, regardless of class hierarchy
• B/W share of a backlogged queue (Link Share): This curve distributes bandwidth according to a class hierarchy

You can click the Save button when you are done. You can also choose Add new queue (create a brand new queue) or Delete this queue (eliminate the current queue).