The Need for Queuing on Frame Relay Networks
Modern Frame Relay networks service a mixed variety of traffic types from users. Among the different types of traffic, mission-critical and delay-sensitive traffic are extremely susceptible to network latency. For example, delay-sensitive traffic, such as voice, is intolerant to network latency and delay largely because of the nature of the application. Network latency and delay could cause voice packets to be delayed, lost, or arrive out of order. This can severely impact the quality of the voice conversation conducted by the end users.
Most of the time, network latency and delay are the consequence of congestion on the network. When a network is not experiencing congestion, all packets are sent out an exit interface of a router as soon as they arrive at a router. However, when the network is congested, packets can arrive at a rate faster than the rate at which the outgoing interface can handle them. The router encountering congestion buffers the excess packets in queues until the congestion eases and there is available bandwidth to service the packets held up in the queues. However, if the traffic rate continues to increase, the state of congestion can become out of control. This condition inevitably causes the queues on the routers to overflow and arriving packets to be dropped from the queues.
On a Cisco Frame Relay device, two levels of queuing are involved. The congestion point can occur at the interface level or the Frame Relay PVC level. When congestion occurs, queuing is required to provide prioritization and to ensure that delay-sensitive traffic, such as voice and video packets, is not delayed or dropped. At the same time, certain queuing mechanisms ensure that traffic that is not mission critical or delay sensitive is allocated sufficient bandwidth for transmission. When queuing is set up on a congested interface, excess packets are enqueued when there is insufficient bandwidth for transmission. Subsequently, the packets are dequeued from the buffers when the network has enough bandwidth to transmit them.
A variety of different Frame Relay queuing algorithms exist to control how the packets are handled in these queues. The queuing mechanisms influence the order of transmission by determining the way the packets in the queues are serviced. For example, when priority queuing is adopted, delay-sensitive voice packets are typically given strict priority. These packets are enqueued in the highest priority queue. When the network is congested and there is limited bandwidth, the higher priority packets in the priority queue are always scheduled for transmission ahead of other traffic in lower-priority queues.
Cisco IOS software supports the following queuing mechanisms:
• First-In-First-Out (FIFO) FIFO is the most basic form of queuing. It does not involve any classification and prioritization. As its name implies, all packets are sent out the interfaces in the order that packets arrive.
• Priority Queuing (PQ) PQ provides strict priority by ensuring that one type of traffic (highest priority) is sent ahead of other traffic. This is usually accomplished at the expense of other lower-priority traffic. As long as high-priority traffic is present, lower-priority traffic might never get the chance to send its packets. The PQ system supports four queues: high, medium, normal, and low.
• Custom Queuing (CQ) CQ provides a round-robin method of queuing by allocating the available bandwidth to all classes of traffic. Some classes of traffic might be assigned a larger proportion of the bandwidth. Nonetheless, all traffic gets a share of the total available bandwidth. In CQ, the packet-count is used to determine the size of each custom queue. Up to 16 custom queues can be created by users on Cisco routers.
• Weighted Fair Queuing (WFQ) The general WFQ system uses a scheduler to ensure all traffic is treated fairly and dynamically, without users' intervention. The traffic is classified based on flows and each flow is serviced by a different queue in the system. The packets classified by WFQ as belonging to the same flow typically share the same source and destination IP address, the same source and destination port numbers, or the same transport protocol. Bandwidth is divided fairly across queues of traffic based on weights. Traffic with a lower weight is given a larger proportion of the bandwidth than higher-weight traffic. The weight factor is inversely proportional to bandwidth. Hence, WFQ effectively penalizes high-volume traffic but favors low-volume traffic. WFQ provides satisfactory performance to low-volume traffic, such as interactive telnet, that does not require large bandwidth but is sensitive to delay. However, WFQ does not work well with real-time traffic, such as voice, as it does not provide a priority queue to reduce delay and jitter. Figure 17-1 illustrates the WFQ mechanism.
Figure 17-1. Weighted Fair Queuing
[View full size image]
There are four types of WFQ, as listed:
- Flow-based WFQ Flow-based WFQ, simply known as WFQ, uses a dynamic scheduling algorithm to provide fair bandwidth allocation to all network traffic. To ensure fairness, WFQ separates the traffic into different flows, or conversations.
The WFQ algorithm first identifies the traffic on the network based on source and destination network addresses, protocol types, and session identifiers, such as socket or port numbers. Then WFQ applies priority, or weights, to the identified traffic to classify it into conversations. The IP precedence level determines the weight carried by each classified traffic type, and the weights are inversely proportional to the IP precedence. WFQ decides from the weights how much bandwidth a conversation is allowed relative to other conversations. Hence, WFQ allows the "fair sharing" of the bandwidth among low-volume and high-volume traffic flows. For instance, WFQ allows low-volume or interactive traffic, such as Telnet sessions, to be given a high priority over high-volume, high-bandwidth traffic, such as FTP sessions. The low-volume traffic normally has fewer packets in the conversation queue compared with the high-volume traffic. Therefore, when using WFQ, the low-volume traffic is not held up for long periods.
- Class-based WFQ (CBWFQ) CBWFQ extends the basic WFQ functionality by allowing users to define the traffic classes based on user-defined criteria and parameters, such as protocol numbers or network layer addresses. For example, extended access lists can be used to classify the traffic for CBWFQ. In CBWFQ, the weight of a class of traffic is determined by the bandwidth assigned to the class configured by the user. The bandwidth assigned to each class affects the order in which packets are sent. In the current Cisco IOS software, up to 256 classes of traffic can be defined with CBWFQ.
- Distributed WFQ This type of WFQ is a special high-speed version of WFQ that runs on the Versatile Interface Processor (VIP). VIP is supported on c7000 series routers with RSP7000 or c7500 series routers with a VIP2-40 or greater interface processor.
- Distributed class-based WFQ This extends CBWFQ functionality to the VIP on c7000/c7500 series routers.
• Low Latency Queuing (LLQ or PQ/CBWFQ) LLQ combines PQ with CBWFQ. Hence, LLQ is also commonly known as PQ/CBWFQ. Because CBWFQ does not provide a strict PQ system, LLQ creates a PQ and allocates delay-sensitive traffic, such as voice, to the PQ. The other classes of traffic, such as data, are serviced by the CBWFQ, and the remaining bandwidth is divided according to the classes configured by the user. The use of LLQ ensures low latency for delay-sensitive traffic, yet provides user-configurable WFQ for the other classes of traffic. Frame Relay PIPQ PIPQ provides an interface-level PQ scheme in which prioritization is based on the destination PVC instead of packet contents. The mechanism for Frame Relay PIPQ is very similar to the general PQ system used at the interface level. The only obvious difference between Frame Relay PIPQ and PQ is that the former can be used only on Frame Relay interfaces. PIPQ is discussed in this chapter. In order to fully understand Frame Relay PIPQ, you need to know the differences between interface-level queuing and PVC level queuing on Frame Relay interfaces. The differences are explained and discussed in the next section.
Most of the time, network latency and delay are the consequence of congestion on the network. When a network is not experiencing congestion, all packets are sent out an exit interface of a router as soon as they arrive at a router. However, when the network is congested, packets can arrive at a rate faster than the rate at which the outgoing interface can handle them. The router encountering congestion buffers the excess packets in queues until the congestion eases and there is available bandwidth to service the packets held up in the queues. However, if the traffic rate continues to increase, the state of congestion can become out of control. This condition inevitably causes the queues on the routers to overflow and arriving packets to be dropped from the queues.
On a Cisco Frame Relay device, two levels of queuing are involved. The congestion point can occur at the interface level or the Frame Relay PVC level. When congestion occurs, queuing is required to provide prioritization and to ensure that delay-sensitive traffic, such as voice and video packets, is not delayed or dropped. At the same time, certain queuing mechanisms ensure that traffic that is not mission critical or delay sensitive is allocated sufficient bandwidth for transmission. When queuing is set up on a congested interface, excess packets are enqueued when there is insufficient bandwidth for transmission. Subsequently, the packets are dequeued from the buffers when the network has enough bandwidth to transmit them.
A variety of different Frame Relay queuing algorithms exist to control how the packets are handled in these queues. The queuing mechanisms influence the order of transmission by determining the way the packets in the queues are serviced. For example, when priority queuing is adopted, delay-sensitive voice packets are typically given strict priority. These packets are enqueued in the highest priority queue. When the network is congested and there is limited bandwidth, the higher priority packets in the priority queue are always scheduled for transmission ahead of other traffic in lower-priority queues.
Cisco IOS software supports the following queuing mechanisms:
• First-In-First-Out (FIFO) FIFO is the most basic form of queuing. It does not involve any classification and prioritization. As its name implies, all packets are sent out the interfaces in the order that packets arrive.
• Priority Queuing (PQ) PQ provides strict priority by ensuring that one type of traffic (highest priority) is sent ahead of other traffic. This is usually accomplished at the expense of other lower-priority traffic. As long as high-priority traffic is present, lower-priority traffic might never get the chance to send its packets. The PQ system supports four queues: high, medium, normal, and low.
• Custom Queuing (CQ) CQ provides a round-robin method of queuing by allocating the available bandwidth to all classes of traffic. Some classes of traffic might be assigned a larger proportion of the bandwidth. Nonetheless, all traffic gets a share of the total available bandwidth. In CQ, the packet-count is used to determine the size of each custom queue. Up to 16 custom queues can be created by users on Cisco routers.
• Weighted Fair Queuing (WFQ) The general WFQ system uses a scheduler to ensure all traffic is treated fairly and dynamically, without users' intervention. The traffic is classified based on flows and each flow is serviced by a different queue in the system. The packets classified by WFQ as belonging to the same flow typically share the same source and destination IP address, the same source and destination port numbers, or the same transport protocol. Bandwidth is divided fairly across queues of traffic based on weights. Traffic with a lower weight is given a larger proportion of the bandwidth than higher-weight traffic. The weight factor is inversely proportional to bandwidth. Hence, WFQ effectively penalizes high-volume traffic but favors low-volume traffic. WFQ provides satisfactory performance to low-volume traffic, such as interactive telnet, that does not require large bandwidth but is sensitive to delay. However, WFQ does not work well with real-time traffic, such as voice, as it does not provide a priority queue to reduce delay and jitter. Figure 17-1 illustrates the WFQ mechanism.
Figure 17-1. Weighted Fair Queuing
[View full size image]
There are four types of WFQ, as listed:
- Flow-based WFQ Flow-based WFQ, simply known as WFQ, uses a dynamic scheduling algorithm to provide fair bandwidth allocation to all network traffic. To ensure fairness, WFQ separates the traffic into different flows, or conversations.
The WFQ algorithm first identifies the traffic on the network based on source and destination network addresses, protocol types, and session identifiers, such as socket or port numbers. Then WFQ applies priority, or weights, to the identified traffic to classify it into conversations. The IP precedence level determines the weight carried by each classified traffic type, and the weights are inversely proportional to the IP precedence. WFQ decides from the weights how much bandwidth a conversation is allowed relative to other conversations. Hence, WFQ allows the "fair sharing" of the bandwidth among low-volume and high-volume traffic flows. For instance, WFQ allows low-volume or interactive traffic, such as Telnet sessions, to be given a high priority over high-volume, high-bandwidth traffic, such as FTP sessions. The low-volume traffic normally has fewer packets in the conversation queue compared with the high-volume traffic. Therefore, when using WFQ, the low-volume traffic is not held up for long periods.
- Class-based WFQ (CBWFQ) CBWFQ extends the basic WFQ functionality by allowing users to define the traffic classes based on user-defined criteria and parameters, such as protocol numbers or network layer addresses. For example, extended access lists can be used to classify the traffic for CBWFQ. In CBWFQ, the weight of a class of traffic is determined by the bandwidth assigned to the class configured by the user. The bandwidth assigned to each class affects the order in which packets are sent. In the current Cisco IOS software, up to 256 classes of traffic can be defined with CBWFQ.
- Distributed WFQ This type of WFQ is a special high-speed version of WFQ that runs on the Versatile Interface Processor (VIP). VIP is supported on c7000 series routers with RSP7000 or c7500 series routers with a VIP2-40 or greater interface processor.
- Distributed class-based WFQ This extends CBWFQ functionality to the VIP on c7000/c7500 series routers.
• Low Latency Queuing (LLQ or PQ/CBWFQ) LLQ combines PQ with CBWFQ. Hence, LLQ is also commonly known as PQ/CBWFQ. Because CBWFQ does not provide a strict PQ system, LLQ creates a PQ and allocates delay-sensitive traffic, such as voice, to the PQ. The other classes of traffic, such as data, are serviced by the CBWFQ, and the remaining bandwidth is divided according to the classes configured by the user. The use of LLQ ensures low latency for delay-sensitive traffic, yet provides user-configurable WFQ for the other classes of traffic. Frame Relay PIPQ PIPQ provides an interface-level PQ scheme in which prioritization is based on the destination PVC instead of packet contents. The mechanism for Frame Relay PIPQ is very similar to the general PQ system used at the interface level. The only obvious difference between Frame Relay PIPQ and PQ is that the former can be used only on Frame Relay interfaces. PIPQ is discussed in this chapter. In order to fully understand Frame Relay PIPQ, you need to know the differences between interface-level queuing and PVC level queuing on Frame Relay interfaces. The differences are explained and discussed in the next section.
