Firewall_qosSettings
Firewall Settings > QoS Mapping
Quality of Service (QoS) refers to a diversity of methods intended to provide predictable network behavior and performance. This sort of predictability is vital to certain types of applications, such as Voice over IP (VoIP), multimedia content, or business-critical applications such as order or credit-card processing. No amount of bandwidth can provide this sort of predictability, because any amount of bandwidth will ultimately be used to its capacity at some point in a network. Only QoS, when configured and implemented correctly, can properly manage traffic, and guarantee the desired levels of network service.
This section contains the following subsections:
Classification is necessary as a first step so that traffic in need of management can be identified. SonicOS uses Access Rules as the interface to classification of traffic. This provides fine controls using combinations of Address Object, Service Object, and Schedule Object elements, allowing for classification criteria as general as all HTTP traffic and as specific as SSH traffic from hostA to serverB on Wednesdays at 2:12am.
Once identified, or classified, it can be managed. Management can be performed internally by SonicOS Bandwidth Management (BWM), which is perfectly effective as long as the network is a fully contained autonomous system. Once external or intermediate elements are introduced, such as foreign network infrastructures with unknown configurations, or other hosts contending for bandwidth (e.g. the Internet) the ability to offer guarantees and predictability are diminished. In other words, as long as the endpoints of the network and everything in between are within your management, BWM will work exactly as configured. Once external entities are introduced, the precision and efficacy of BWM configurations can begin to degrade.
But all is not lost. Once SonicOS classifies the traffic, it can tag the traffic to communicate this classification to certain external systems that are capable of abiding by CoS tags; thus they too can participate in providing QoS.
The traffic can be conditioned (or managed) using any of the many policing, queuing, and shaping methods available. SonicOS provides internal conditioning capabilities with its Egress and Ingress Bandwidth Management (BWM), detailed in the Bandwidth Management. SonicOS’s BWM is a perfectly effective solution for fully autonomous private networks with sufficient bandwidth, but can become somewhat less effective as more unknown external network elements and bandwidth contention are introduced.
Site to Site VPN over Public Networks
SonicOS integrated BWM is very effective in managing traffic between VPN connected networks because ingress and egress traffic can be classified and controlled at both endpoints. If the network between the endpoints is non QoS aware, it regards and treats all VPN ESP equally. Because there is typically no control over these intermediate networks or their paths, it is difficult to fully guarantee QoS, but BWM can still help to provide more predictable behavior.
To provide end-to-end QoS, business-class service providers are increasingly offering traffic conditioning services on their IP networks. These services typically depend on the customer premise equipment to classify and tag the traffic, generally using a standard marking method such as DSCP.
The actual conditioning method employed by service providers varies from one to the next, but it generally involves a class-based queuing method such as Weighted Fair Queuing for prioritizing traffic, as well a congestion avoidance method, such as tail-drop or Random Early Detection.
SonicOS offers an integrated traffic shaping mechanism through its Egress (outbound) and Ingress (inbound) bandwidth management (BWM) interfaces. Outbound BWM can be applied to traffic sourced from Trusted and Public zones (e.g. LAN and DMZ) destined to Untrusted and Encrypted zones (e.g. WAN and VPN). Inbound BWM can be applied to traffic sourced from Untrusted and Encrypted zones destined to Trusted and Public zones.
Note Although BWM is a fully integrated QoS system, wherein classification and shaping is performed on the single SonicWALL appliance, effectively eliminating the dependency on external systems and thus obviating the need for marking, it is possible to concurrently configure BWM and QoS (i.e. layer 2 and/or layer 3 marking) settings on a single Access Rule. This allows those external systems to benefit from the classification performed on the SonicWALL even after it has already shaped the traffic.
BWM configurations begin by enabling BWM on the relevant WAN interface, and declaring the interface’s available bandwidth in Kbps (Kilobits per second). This is performed from the
Network > Interfaces page by selecting the Configure icon for the WAN interface, and navigating to the Advanced tab:
Egress and Ingress BWM can be enabled jointly or separately on WAN interfaces. Different bandwidth values may be entered for outbound and inbound bandwidth to support asymmetric links. Link rates up to 100,000 Kbps (100Mbit) may be declared on Fast Ethernet interface, while Gigabit Ethernet interfaces will support link rates up to 1,000,000 (Gigabit). The speed declared should reflect the actual bandwidth available for the link. Oversubscribing the link (i.e. declaring a value greater than the available bandwidth) is not recommended.
Note Once BWM has been enabled on an interface, and a link speed has been defined, traffic traversing that link will be throttled—both inbound and outbound—to the declared values, even if no Access Rules are configured with BWM settings.
Once one or both BWM settings are enabled on the WAN interface and the available bandwidth has been declared, a Ethernet BWM tab will appear on Access Rules. The Bandwidth tab will present either Inbound settings, Outbound settings, or both, depending on what was enabled on the WAN interface:
The configuration on the General tab will classify the traffic. In the above example, which assumes no other configured BWM rules, traffic from the LAN (Trusted) zone’s LAN Subnets destined to the VPN (Encrypted) zone’s 10.50.165.0 remote subnet, consisting of Service Group VOIP will be guaranteed 30% of the declared bandwidth (30% of 1500Kbps = 450Kbps), but it will not be permitted to exceed 80% (80% of 1500Kbps = 1200Kbps), leaving 300Kbps for other traffic.
Bandwidth Management as employed by SonicOS is based on an amalgamation of queue management and congestion avoidance techniques, but in empirical practice it most closely resembles Class Base Queuing (CBQ), as defined by Sally Floyd and Van Jacobson in Link-sharing and Resource Management Models for Packet Networks, while incorporating elements of RFC2309 Recommendations on Queue Management and Congestion Avoidance in the Internet and various credit-based flow control theory. The overarching goals of the SonicOS BWM scheme are:
• Simplicity – The processing overhead must be consistently and appreciably less than average packet transmission times.
• Robustness – The scheduler must perform well under predictable and unpredictable traffic conditions, and must not introduce undesirable side effects such as traffic bursts or synchronization issues.
• Fairness – The sharing of available bandwidth should be commensurate with the defined management scheme, particularly in the presence of poorly behaving or greedy traffic.
The available bandwidth on a WAN link is tracked by means of adjusting a link credit (token) pool for each packet sent. Providing that the link hasn’t reached a point of saturation, the prioritized queues are deemed eligible for processing.
Like CBQ, SonicOS BWM is based on a class structure, where traffic queues are classified according to Access Rules—for example SSH, Telnet, or HTTP—and then scheduled according to their prescribed priority. Each participating Access Rule is assigned three values: Guaranteed bandwidth, Maximum bandwidth, and Bandwidth priority. Scheduling prioritization is achieved by assignment to one of eight priority rings, starting at 0 (zero) for the highest priority, and descending to 7 (seven) for the lowest priority. The resulting queuing hierarchy can be best thought of as a node tree structure that is always one level deep, where all nodes are leaf nodes, containing no children.
Queue processing utilizes a time division scheme of approximately 1/256th of a second per time-slice. Within a time-slice, evaluation begins with priority 0 queues, and on a packet-by-packet basis transmission eligibility is determined by measuring the packet’s length against the queue credit pool. If sufficient credit is available, the packet is transmitted and the queue and link credit pools are decremented accordingly. As long as packets remain in the queue, and as long as Guaranteed link and queue credits are available, packets from that queue will continue to be processed. When Guaranteed queue credits are depleted, the next queue in that priority ring is processed. The same process is repeated for the remaining priority rings, and upon completing priority ring 7 begins again with priority ring 0.
The scheduling for excess bandwidth is strict priority, with per-packet round-robin within each priority. In other words, if there is excess bandwidth for a given time-slice all the queues within that priority ring would take turns sending packets until the excess was depleted, and then processing would move to the next priority ring.
This credit-based method obviates the need for CBQ’s concept of overlimit, and addresses one of the largest problems of traditional CBQ, namely, bursty behavior (which can easily flood downstream devices and links). This more prudent approach spares SonicOS the wasted CPU cycles that would normally be incurred by the need for re-transmission due to the saturation of downstream devices, as well as avoiding other congestive and degrading behaviors such as TCP slow-start (see Sally Floyd’s Limited Slow-Start for TCP with Large Congestion Windows), and Global Synchronization (as described in RFC 2884):
Queue management algorithms traditionally manage the length of packet queues in the router by dropping packets only when the buffer overflows. A maximum length for each queue is configured. The router will accept packets till this maximum size is exceeded, at which point it will drop incoming packets. New packets are accepted when buffer space allows. This technique is known as Tail Drop. This method has served the Internet well for years, but has the several drawbacks. Since all arriving packets (from all flows) are dropped when the buffer overflows, this interacts badly with the congestion control mechanism of TCP. A cycle is formed with a burst of drops after the maximum queue size is exceeded, followed by a period of underutilization at the router as end systems back off. End systems then increase their windows simultaneously up to a point where a burst of drops happens again. This phenomenon is called Global Synchronization. It leads to poor link utilization and lower overall throughput. Another problem with Tail Drop is that a single connection or a few flows could monopolize the queue space, in some circumstances. This results in a lock out phenomenon leading to synchronization or other timing effects. Lastly, one of the major drawbacks of Tail Drop is that queues remain full for long periods of time. One of the major goals of queue management is to reduce the steady state queue size.
Each packet through the SonicWALL is initially classified as either a Real Time or a Firewall packet. Firewall packets are user-generated packets that always pass through the BWM module. Real time packets are usually firewall generated packets that are not processed by the BWM module, and are implicitly given the highest priority. Real Time (firewall generated) packets include:
• WAN Load Balancing Probe
• ISAKMP
• Web CFS
• PPTP and L2TP control packets
• DHCP
• ARP Packets
• Web Sense
• Syslog
• NTP
• Security Services (AV, signature updates, license manager)
Outbound BWM Packet Processing Path
Determine that the packet is bound for the WAN zone.
Determine that the packet is classifiable as a Firewall packet.
Match the packet to an Access Rule to determine BWM setting.
Queue the packet in the appropriate rule queue.
Guaranteed Bandwidth Processing
This algorithm depicts how all the policies use up the GBW.
Start with a link credit equal to available link BW.
Initialize the class credit with configured GBW for the rule.
If that packet length is less than or equal to the class credit, transmit the packet and deduct the length from class credit and link credit.
Choose the next packet from queue and repeat step c until class credit is lesser or rule queue is empty.
Choose the next rule queue and repeat steps b through d.
Maximum Bandwidth Processing
This algorithm depicts how the unutilized link BW is used up by the policies. We start with the highest priority ring and transmit packets from all the rule queues in a round robin fashion until link credit is exhausted or all queues are empty. Then we move on to the next lowest priority ring and repeat the same.
Start with the link credit equal to the left over link BW after GBW utilization.
Choose the highest priority ring.
Initialize class credit to (MBW - GBW).
Check if the length of a packet from the rule queue is below class credit as well as link credit.
If yes, transmit the packet and deduct the length from class credit and link credit.
Choose the next rule queue and repeat steps c through f until link credit gets exhausted or this priority ring has all its queues empty.
Choose the next lowest priority ring and repeat steps c through f.
The above diagram shows 4 policies are configured for OBWM with a link capacity of 100 Kbps. This means that the link capacity is 12800 Bytes/sec. Below table gives the BWM values for each rule in Bytes per second.
|
For GBW processing, we start with the first queue in the rule queue list which is FTP. Link credit is 12800 and class credit is 1280. Pkt1 of 400B is sent out on the WAN link and link credit becomes 12400 and class credit becomes 880. Pkt2 is not sent out because there is not enough class credit to send 1500 Bytes. The remaining class credit is carried over to the next time slice.
We move on to the next rule queue in this list which is for H323. Pkt1 of 1500B is sent out and link credit becomes 10900 and class credit for H323 becomes 1060. Pkt2 is also sent from queue hence link credit = 10200 and class credit = 360. Pkt3 is not sent since there is not enough class credit. The remaining class credit is carried over to the next time slice.
Now we move onto Yahoo Messenger queue. Since Pkt1 cannot be accommodated with its class credit of 640 Bytes, no packets are processed from this queue. However, its class credit is carried over to the next time slice.
From VNC queue, Pkt1 and Pkt2 are sent out leaving link credit = 8000 and class credit = 360. Class credit is carried over.
Since all the queues have been processed for GBW we now move onto use up the left over link credit of 8000.
Start off with the highest priority ring 0 and process all queues in this priority in a round robin fashion. H323 has Pkt3 of 500B which is sent since it can use up to max = 2560 (MBW-GBW). Now Link credit = 7500 and max = 2060.
Move to the next queue in this priority ring which is VNC queue. Pkt3 of 500B is sent out leaving link credit = 7000B and class max = 140 (MBW-GBW - 500).
Move to the next queue in this priority ring. Since H323 queue is empty already we move to the next queue which is VNC again.
From VNC queue Pkt4 of 40B is sent out leaving link credit = 6960 and class max = 100. Pkt5 of 500B is not sent since class max is not enough.
Now we move onto next lower priority queue. Since priority rings 1 through 3 are empty we choose priority ring 4 which has the rule queue for FTP. Pkt2 of 1000B is sent which leaves with link credit = 6000 and class max = 280. Since there are no other queues in this priority, FTP queue is processed again. But since class max is not enough for Pkt3 of 1500B it is not sent.
Move to the next lower priority ring which is 7 for Yahoo Messenger. Pkt1 of 1200B is sent leaving link credit = 4800 and class max = 80. Since no other queues exist in this priority, this queue is processed again. Pkt2 of 1500B is not sent since it cannot be accommodated with max = 80.
At this point, all the queues under all priority rings are processed for the current time slice.
Inbound BWM can be used to shape inbound TCP and UDP traffic. TCP’s intrinsic flow control behavior is used to manage ingress bandwidth. To manage inbound UDP traffic, CBQ is used by the ingress module to queue the incoming packets. TCP rate is inherently controlled by the rate of receipt of ACKs; i.e. TCP sends out packets out on the network at the same rate as it receives ACKs. For IBWM, the sending rate of a TCP source will be reduced by controlling the rate of ACKs to the source. By delaying an ACK to the source, round-trip time (RTT) for the flow is increased, thus reducing the source’s sending rate.
An ingress module monitors and records the ingress rate for each traffic class. It also monitors the egress ACKs and queues them if the ingress rate has to be reduced. According to ingress BW availability and average rate, the ACKs will be released.
IBWM maintains eight priority rings, where each priority ring has one queue for a rule that has IBWM enabled. The IBWM pool is processed from the highest to lowest priority ring further shaping the traffic. IBWM employs three key algorithms:
Ingress Rate Update
This algorithm processes each packet from the WAN and updates the ingress rate of the class to which it belongs. It also marks the traffic class if it has over utilized the link.
Determine that the packet is from the WAN zone and is a firewall packet.
Add the packet length to the sum of packet lengths received so far in the current time slice. Deduct the minimum of (GBW, packet length) from link’s credit.
If the sum is greater than the class’s credit, mark the class to be over utilizing the link.
If the packet length is greater than the link’s credit, mark the link as well as the class to be over utilized.
Egress ACK monitor
This algorithm depicts how the egress ACKs are monitored and processed.
Determine that the packet is to the WAN zone and is a TCP ACK.
If class or interface is marked as over utilizing, queue the packet in the appropriate ingress rule queue.
Process ACKs
This algorithm is used to update the BW parameters per class according to the amount of BW usage in the previous time slice. Amount of BW usage is given by the total number of bytes received for the class in the previous time slice. The algorithm is also used to process the packets from the ingress module queues according to the available credit for the class.
A class will be in debt when its BW usage is more than the GBW for a particular time slice. All the egress ACKs for the class are then queued until the debt is reduced to zero. At each successive time slice, debt is deducted by GBW and if link BW is left, (MBW – GBW) is also deducted.
Compute BW usage in the previous time slice:
Compute average ingress rate using the amount of BW usage by the class.
If the BW usage is more than the class credit, record the difference as debt. If link BW is left over, deduct (MBW - GBW) from debt.
Compute the class and link credit for the current time slice:
• If the class is in debt, deduct GBW from debt and also from link’s credit, indicating that the class has already used up its GBW for the current time slice.
• If class is not in debt and there are packets arriving for this class, accumulate link credit; i.e. add GBW to credit at each time slice.
• Class is marked as over utilizing if debt is nonzero.
Process packets from ingress pool from highest priority ring to lowest priority ring.
Record class credit as remaining credit.
If remaining credit is greater than or equal to average rate, process the ACK packet and deduct average rate from remaining credit.
Repeat g until remaining credit is not enough or the ingress ACK queue is empty.
Repeat steps f through h for the next rule queue in the ring.
Repeat steps f through i for the next lowest priority ring.
Consider a class with GBW = 5 Kbps, MBW = 10 Kbps and Link BW = 100 Kbps. In terms of bytes per second we have GBW=640, excess BW = (MBW - GBW) = 640 and link BW = 12800.
|
Class credit starts with 640. In row 2, 1300 bytes are received for this class in the previous time slice. Since it is more than the class credit, debt = 20 (1300-GBW-excess BW). For the current time slice class credit = 620 (GBW - debt), debt = 0 and link BW = 12780 since 20 bytes of debt is already used up from GBW for the class.
Row 2a shows an egress ACK for the class. Since class credit is less than the rate this packet is queued in the appropriate ingress queue. And it will not be processed until class credit is at least equal to the rate.
In the following time slices, class credit gets accumulated until it matches the rate. Hence, after two time slices class credit becomes 1900 (620 + 640 + 640). The queued ACK packet is process from the ingress pool at this point.
In row 2a, an ACK packet is received that needs to be sent to the TCP source on the WAN zone. Sending this ACK immediately would have caused the TCP source to send more packets immediately. By queuing the ACK and sending it only after the class credit reaches the average rate, we have reduced the TCP’s sending rate; i.e. by doing this we have slowed down the ingress rate.
BWM with WAN load balancing works in the following manner:
If two interfaces are configured as WAN and load balancing is NOT enabled, BWM is only applied to the primary WAN interface.
If two interfaces are configured as WAN and load balancing is enabled:
• For Active/Passive Failover, BWM is done only on the active WAN interface.
• For Round Robin and Ratio options, link capacity is the sum of available BW for primary and secondary WAN interface and BWM is done on both interfaces.
• For Spill Over option, link capacity is Primary’s available BW and BWM is done on primary interface before the spill over occurs. And after the spill over occurs, the secondary interface’s capacity is used and BWM is done on the secondary WAN interface.
• Bandwidth Management (BWM) – Refers to any of a variety of algorithms or methods used to shape traffic or police traffic. Shaping often refers to the management of outbound traffic, while policing often refers to the management of inbound traffic (also known as admission control). There are many different methods of bandwidth management, including various queuing and discarding techniques, each with their own design strengths. SonicWALL employs a Token Based Class Based Queuing method for inbound and outbound BWM, as well as a discard mechanism for certain types of inbound traffic.
• Class of Service (CoS) – A designator or identifier, such as a layer 2 or layer 3 tag, that is applied to traffic after classification. CoS information will be used by the Quality of Service (QoS) system to differentiate between the classes of traffic on the network, and to provide special handling (e.g. prioritized queuing, low latency, etc.) as defined by the QoS system administrator.
• Classification – The act of identifying (or differentiating) certain types (or classes) of traffic. Within the context of QoS, this is performed for the sake of providing customized handling, typically prioritization or de-prioritization, based on the traffic’s sensitivity to delay, latency, or packet loss. Classification within SonicOS uses Access Rules, and can occur based on any or all of the following elements: source zone, destination zone, source address object, destination address object, service object, schedule object.
• Code Point – A value that is marked (or tagged) into the DSCP portion of an IP packet by a host or by an intermediate network device. There are currently 64 Code Points available, from 0 to 63, used to define the ascending prioritized class of the tagged traffic.
• Conditioning – A broad term used to describe a plurality of methods of providing Quality of Service to network traffic, including but not limited to discarding, queuing, policing, and shaping.
• Discarding – A congestion avoidance mechanism that is employed by QoS systems in an attempt to predict when congestion might occur on a network, and to prevent the congestion by dropping over-limit traffic. Discarding can also be thought of as a queue management algorithm, since it attempts to avoid situations of full queues. Advanced discard mechanisms will abide by CoS markings so as to avoid dropping sensitive traffic. Common methods are:
– Tail Drop – An indiscriminate method of dealing with a full queue wherein the last packets into the queue are dropped, regardless of their CoS marking.
– Random Early Detection (RED) – RED monitors the status of queues to try to anticipate when a queue is about to become full. It then randomly discards packets in a staggered fashion to help minimize the potential of Global Synchronization. Basic implementations of RED, like Tail Drop, do not consider CoS markings.
– Weighted Random Early Detection (WRED) – An implementation of RED that factors DSCP markings into its discard decision process.
• DSCP – (Differentiate Services Code Points) – The repurposing of the ToS field of an IP header as described by RFC2747. DSCP uses 64 Code Point values to enable DiffServ (Differentiated Services). By marking traffic according to its class, each packet can be treated appropriately at every hop along the network.
• Global Synchronization – A potential side effect of discarding, the congestion avoidance method designed to deal with full queues. Global Synchronization occurs when multiple TCP flows through a congested link are dropped at the same time (as can occur in Tail Drop). When the native TCP slow-start mechanism commences with near simultaneity for each of these flows, the flows will again flood the link. This leads to cyclical waves of congestion and under-utilization.
• Guaranteed Bandwidth – A declared percentage of the total available bandwidth on an interface which will always be granted to a certain class of traffic. Applicable to both inbound and outbound BWM. The total Guaranteed Bandwidth across all BWM rules cannot exceed 100% of the total available bandwidth. SonicOS 6.0 and higher enhances the Bandwidth Management feature to provide rate limiting functionality. You can now create traffic policies that specify maximum rates for Layer 2, 3, or 4 network traffic. This enables bandwidth management in cases where the primary WAN link fails over to a secondary connection that cannot handle as much traffic. The Guaranteed Bandwidth can also be set to 0%.
• Inbound (Ingress or IBWM) – The ability to shape the rate at which traffic enters a particular interface. For TCP traffic, actual shaping can occur where the rate of the ingress flow can be adjusted by delaying egress acknowledgements (ACKs) causing the sender to slow its rate. For UDP traffic, a discard mechanism is used since UDP has no native feedback controls.
• IntServ – Integrated Services, as defined by RFC1633. An alternative CoS system to DiffServ, IntServ differs fundamentally from DiffServ in that it has each device request (or reserve) its network requirements before it sends its traffic. This requires that each hop on the network be IntServ aware, and it also requires each hop to maintain state information for every flow. IntServ is not supported by SonicOS. The most common implementation of IntServ is RSVP.
• Maximum Bandwidth – A declared percentage of the total available bandwidth on an interface defining the maximum bandwidth to be allowed to a certain class of traffic. Applicable to both inbound and outbound BWM. Used as a throttling mechanism to specify a bandwidth rate limit. The Bandwidth Management feature is enhanced to provide rate limiting functionality. You can now create traffic policies that specify maximum rates for Layer 2, 3, or 4 network traffic. This enables bandwidth management in cases where the primary WAN link fails over to a secondary connection that cannot handle as much traffic.The Maximum Bandwidth can be set to 0%, which will prevent all traffic.
• Outbound (Egress or OBWM) – Conditioning the rate at which traffic is sent out an interface. Outbound BWM uses a credit (or token) based queuing system with 8 priority rings to service different types of traffic, as classified by Access Rules.
• Priority – An additional dimension used in the classification of traffic. SonicOS uses 8 priority rings (0 = highest, 7 = lowest) to comprise the queue structure used for BWM. Queues are serviced in the order of their priority ring.
• MPLS - Multi Protocol Label Switching. A term that comes up frequently in the area of QoS, but which is natively unsupported by most customer premise IP networking devices, including SonicWALL appliances. MPLS is a carrier-class network service that attempts to enhance the IP network experience by adding the concept connection-oriented paths (Label Switch Paths – LSPs) along the network. When a packet leaves a customer premise network, it is tagged by a Label Edge Router (LER) so that the label can be used to determine the LSP. The MPLS tag itself resides between layer 2 and layer 3, imparting upon MPLS characteristics of both network layers. MPLS is becoming quite popular for VPNs, offering both layer 2 and layer 3 VPN services, but remains interoperable with existing IPsec VPN implementation. MPLS is also very well known for its QoS capabilities, and interoperates well with conventional DSCP marking.
• Per Hop Behavior (PHB) – The handling that will be applied to a packet by each DiffServ capable router it traverses, based upon the DSCP classification of the packet. The behavior can be among such actions as discard, re-mark (re-classify), best-effort, assured forwarding, or expedited forwarding.
• Policing – A facility of traffic conditioning that attempts to control the rate of traffic into or out of a network link. Policing methods range from indiscriminate packet discarding to algorithmic shaping, to various queuing disciplines.
• Queuing – To effectively make use of a link’s available bandwidth, queues are commonly employed to sort and separately manage traffic after it has been classified. Queues are then managed using a variety of methods and algorithms to ensure that the higher priority queues always have room to receive more traffic, and that they can be serviced (de-queued or processed) before lower priority queues. Some common queue disciplines include:
– FIFO – First In First Out. A very simple, undiscriminating queue where the first packet in is the first packet to be processed.
– Class Based Queuing (CBQ) – A queuing discipline that takes into account the CoS of a packet, ensuring that higher priority traffic is treated preferentially.
– Weighted Fair Queuing (WFQ) – A discipline that attempts to service queues using a simple formula based upon the packets’ IP precedence and the total number of flows. WFQ has a tendency to become imbalanced when there is a disproportionately large number of high-priority flows to be serviced, often having the opposite of the desired effect.
– Token Based CBQ – An enhancement to CBQ that employs a token, or a credit-based system that helps to smooth or normalize link utilization, avoiding burstiness as well as under-utilization. Employed by SonicOS’ BWM.
• RSVP – Resource Reservation Protocol. An IntServ signaling protocol employed by some applications where the anticipated need for network behavior (e.g. delay and bandwidth) is requested so that it can be reserved along the network path. Setting up this Reservation Path requires that each hop along the way be RSVP capable, and that each agrees to reserve the requested resources. This system of QoS is comparatively resource intensive, since it requires each hop to maintain state on existing flows. Although IntServ’s RSVP is quite different from DiffServ’s DSCP, the two can interoperate. RSVP is not supported by SonicOS.
• Shaping – An attempt by a QoS system to modify the rate of traffic flow, usually by employing some feedback mechanism to the sender. The most common example of this is TCP rate manipulation, where acknowledgements (ACKs) sent back to a TCP sender are queued and delayed so as to increase the calculated round-trip time (RTT), leveraging the inherent behavior of TCP to force the sender to slow the rate at which it sends data.
• Type of Service (ToS) – A field within the IP header wherein CoS information can be specified. Historically used, albeit somewhat rarely, in conjunction with IP precedence bits to define CoS. The ToS field is now rather commonly used by DiffServ’s code point values.