IT certification

Before Cisco created LLQ, Cisco created two other tools that added a single priority queue toanother queuing tool. IP RTP Reserve was the first of these two tools to be introduced, followedby the IP RTP Priority feature. With current IOS releases, Cisco recommends not using theseolder tools, but instead suggests using LLQ. However, because IP RTP Priority is currently onQoS exams, a brief explanation is warranted.IP RTP Priority provides many features like LLQ, but with a few differences. It adds a PQ toeither WFQ or to CBWFQ. It classifies VoIP payload traffic by classifying packets in a range ofUDP port numbers, from which it only selects traffic from the even-numbered (VoIP payload)ports. Like LLQ, the PQ created by IP RTP Priority always gets serviced first, but the bandwidthreserved for this queue is policed to prevent it from taking over all bandwidth. Table 4-14summarizes the main features and compares the features with LLQ.

Some Cisco documentation claims that you can only have one low-latency queue inside a singlepolicy map. In other words, only one class can use the priority command, making it a lowlatencyqueue. Other Cisco documentation claims that you can have more than one low-latencyqueue in a single policy map.As it turns out, you can have multiple low-latency queues in a single policy map. Why wouldyou need more than one low-latency queue in a policy map, and how would it work? Well, it’sactually pretty simple, now that you know how to configure LLQ.First, imagine a policy map that has one low-latency queue configured with the priority 400command. This queue needs 320 kbps for a single video conference call, plus three G.729 voicecalls totaling about 80 kbps. If only the three voice calls and the single video-conference calloccur, the LLQ configuration works fine, the policer does not drop any packets, and the voiceand video packets are processed as FIFO within that LLQ class. As always, packets in the lowlatencyqueue get serviced ahead of packets in the other non-LLQ classes.Compare that configuration to a policy map with two low-latency queues defined—one forvoice with a priority 80 command, and another for video conferencing with priority 320configured. What’s really different about this than the first configuration? The policing, butnot the queuing.With multiple low-latency queues, each class is policed at the configured rate. For instance,with all voice calls going into the class with priority 80, three G.729 calls are supported, butnot more than that. With video-conferencing traffic going into the class with priority 320, onlythat single video call is supported.The fact that the different types of traffic are policed separately in the second example providesthe motivation to use multiple low-latency queues. Suppose that a fourth voice call were made,and the CAC tools in place did not prevent the call, meaning that more than 80 kbps of voicetraffic was being sent. With a single low-latency queue, both video and some voice packets

would be discarded due to policing, because the cumulative rate for all traffic would exceed

400 kbps. The policer would have no way to decide to discard just the extra voice, but not video,

because the policer acts on all traffic in the class. However, with the two lower-latency queues

configuration, only the voice calls would lose packets due to policing, and the video conference

would not have any packets dropped by the policer.

In effect, with multiple low-latency queues, you get more granularity in what you police. In fact,

the most typical reason to use multiple low-latency queues is to support voice in one queue, and

video in another.

Queuing does not differ when comparing using a single low-latency queue with multiple lowlatency

queues in a single policy map. IOS always takes packets from the low-latency queues

first, as compared with the non-low-latency queues (those with a bandwidth command), just

like before. However, IOS does not reorder packets between the various low-latency queues

inside the policy map. In other words, IOS treats all traffic in all the low-latency queues with

FIFO logic.

In short, using multiple low-latency queues in one policy map does enable you to police traffic

more granularly, but it does not reorder packets among the various low-latency queues.

Unfortunately, the DQOS and QoS courses and exams disagree with each other about where

you can have more than one low-latency queue. The DQOS course states that only one lowlatency

queue is allowed in a single policy map, whereas the QoS course states that multiple

low-latency queues are allowed. So, you may talk to colleagues who have seen some Cisco

documentation, or taken the DQOS class, and swear that only one low-latency queue is allowed.

Thankfully, the chances are low that you would see a question distinguishing this fine point.

However, you should be aware of the differences in documentation and the courses, so we made

it a point to draw attention to the differences here.

Low Latency Queuing sounds like the best queuing tool possible, just based on the name. Whatpacket wouldn’t want to experience low latency? As it turns out, for delay (latency) sensitivetraffic, LLQ is indeed the queuing tool of choice.LLQ is simple to understand and simple to configure, assuming you already understandCBWFQ. LLQ is not really a separate queuing tool, but rather a simple option of CBWFQapplied to one or more classes. CBWFQ treats these classes as strict-priority queues. In otherwords, CBWFQ always services packets in these classes if a packet is waiting, just as PQ doesfor the High queue.

Like the other queuing tools with WFQ in the name, CBWFQ uses features that are similar tosome other queuing tools, and completely different from others. CBWFQ is like CQ, in that itcan be used to reserve minimum bandwidth for each queue, but it differs from CQ in that youcan configure the actual percentage of traffic, rather than a byte count. CBWFQ is like WFQ inthat CBWFQ can actually use WFQ inside one particular queue, but it differs from WFQ in thatit does not keep up with flows for all the traffic.Many people find it difficult to keep the details memorized. To help overcome confusion, thefeatures of CBWFQ are covered in the next several pages. At the end of this section, somesummary tables list the key features and compare CBWFQ to some of the other queuing tools.To begin the coverage, examine Figure 4-19, which outlines the typical queuing features insequence.

Flow-Based WFQ, or just WFQ, classifies traffic into flows. Flows are identified by at least fiveitems in an IP packet:• Source IP address• Destination IP ADDRESS• Transport layer protocol (TCP or UDP) as defined by the IP Protocol header field• TCP or UDP source port• TCP or UDP destination portDepending on what document you read, WFQ also classifies based on the ToS byte. In particular,the CCIP QoS exam expects WFQ to classify based on the ToS byte as well as the fiveitems listed previously. The DQOS course, and presumably the DQOS exam, claims that it classifieson the five fields listed previously. Most documentation just lists the five fields in the precedinglist. (As with all items that may change with later releases of the exams and courses, lookto www.ciscopress.com/1587200589 for the latest information.)Whether WFQ uses the ToS byte or not when classifying packets, practically speaking, does notmatter much. Good design suggests that packets in a single flow ought to have their Precedenceor DSCP field set to the same value—so the same packets would get classified into the sameflow, regardless of whether WFQ cares about the ToS byte or not for classification.The term “flow” can have a couple of different meanings. For instance, imagine a PC that isdownloading a web page. The user sees the page appear, reads the page for 10 seconds, andclicks a button. A second web page appears, the user reads the page for 10 seconds, and clicks

another button. All the pages and objects came from a single web server, and all the pages and

objects were loaded using a single TCP connection between the PC and the server. How many

different combinations of source/destination, address/port, and transport layer protocol, are

used? How many different flows?

From a commonsense perspective, only one flow exists in this example, because only one

TCP connection is used. From WFQ’s perspective, no flows may have occurred, or three flows

existed, and possibly even more. To most people, a single TCP flow exists as long as the TCP

connection stays up, because the packets in that connection always have the same source

address, source port, destination address, and destination port information. However, WFQ

considers a flow to exist only as long as packets from that flow are queued to be sent out of an

interface. For instance, while the user is reading the web pages for 10 seconds, the routers finish

sending all packets sent by the web server, so the queue for that flow is empty. Because the

intermediate routers had no packets queued in the queue for that flow, WFQ removes the flow.

Similarly, even while transferring different objects that comprise a web page, if WFQ empties

a flow’s queue, it removes the queue, because it is no longer needed.

Why does it matter that flows come and go quickly from WFQ’s perspective? With class-based

schemes, you always know how many queues you have, and you can see some basic statistics

for each queue. With WFQ, the number of flows, and therefore the number of queues, changes

very quickly. Although you can see statistics about active flows, you can bet on the information

changing before you can type the show queue command again. The statistics show you information

about the short-lived flow—for instance, when downloading the third web page in the

previous example, the show queue command tells you about WFQ’s view of the flow, which

began when the third web page was being transferred, not when the TCP connection was

formed.

Weighted Fair Queuing differs from PQ and CQ in several significant ways. The first and mostobvious difference is that WFQ does not allow classification options to be configured! WFQclassifies packets based on flows. A flow consists of all packets that have the same source anddestination IP address, and the same source and destination port numbers. So, no explicitmatching is configured. The other large difference between WFQ versus PQ and CQ is thescheduler, which simply favors low-volume, higher-precedence flows over large-volume,lower-precedence flows. Also because WFQ is flow based, and each flow uses a different queue,

the number of queues becomes rather large—up to a maximum of 4096 queues per interface.

And although WFQ uses tail drop, it really uses a slightly modified tail-drop scheme—yet

another difference.

IOS provides several variations of WFQ as well. This section concentrates on WFQ, whose

longer, more descriptive name is Flow-Based WFQ. For those of you taking the QoS exam,

Appendix B covers several variations of WFQ—namely, distributed WFQ (dWFQ), ToS-based

dWFQ, and QoS group-based dWFQ. Each has slight variations to the baseline concepts and

configuration of WFQ.

Ironically, WFQ requires the least configuration of all the queuing tools in this chapter, yet it

requires the most explanation to achieve a deep understanding. The extra work to read through

the details will certainly help on the exam, plus it will give you a better appreciation for WFQ,

which may be the most pervasively deployed QoS tool in Cisco routers.

Custom Queuing (CQ) followed PQ as the next IOS queuing tool added to IOS. CQ addressesthe biggest drawback of PQ by providing a queuing tool that does service all queues, evenduring times of congestion. It has 16 queues available, implying 16 classification categories,which is plenty for most applications. The negative part of CQ, as compared to PQ, is that CQ’sscheduler does not have an option to always service one queue first—like PQ’s High queue—so CQ does not provide great service for delay- and jitter-sensitive traffic.

As with most queuing tools, the most interesting part of the tool is the scheduler. The CQ scheduler

gives an approximate percentage of overall link bandwidth to each queue. CQ approximates

the bandwidth percentages, as opposed to meeting an exact percentage, due to the simple

operation of the CQ scheduler.

Priority Queuing’s most distinctive feature is its scheduler. PQ schedules traffic such that thehigher-priority queues always get serviced, with the side effect of starving the lower-priorityqueues. With a maximum of four queues, called High, Medium, Normal, and Low, the completelogic of the scheduler can be easily represented, as is shown in Figure 4-9.As seen in Figure 4-9, if the High queue always has a packet waiting, the scheduler will alwaystake the packets in the High queue. If the High queue does not have a packet waiting, but theMedium queue does, one packet is taken from the Medium queue—and then the process alwaysstarts over at the High queue. The Low queue only gets serviced if the High, Medium, andNormal queues do not have any packets waiting.The PQ scheduler has some obvious benefits and drawbacks. Packets in the High queue canclaim 100 percent of the link bandwidth, with minimal delay, and minimal jitter. The lowerqueues suffer, however. In fact, when congested, packets in the lower queues take significantlylonger to be serviced than under lighter loads. In fact, when the link is congested, userapplications may stop working if their packets are placed into lower-priority queues.

IOS voice gateways provide many services to connect the packetized, VoIP network to nonpacketized,traditional voice services, including analog and digital trunks. IOS gateways performmany tasks, but one of the most important tasks is to convert from packetized voice tononpacketized voice, and vice versa. In other words, voice traffic entering a router on an analogor digital trunk is not carried inside an IP packet, but the IOS gateway converts the incoming

voice to a digital signal (analog trunks only) and adds the appropriate IP, UDP, and RTP headers

around the digital voice (both analog and digital trunks). Conversely, when a VoIP packet

arrives, and the voice needs to be sent out a trunk, the IOS gateway removes the packet headers,

converts the voice to analog (analog trunks only), and sends the traffic out the trunk.

Although this book does not attempt to explain voice configuration and concepts to much depth,

some appreciation for IOS gateway configuration is required for some of the functions covered

in this book. In particular, Chapter 8, “Call Admission Control and QoS Signaling,” which

covers Voice call admission control (CAC), requires a little deeper examination of voice. To

understand classification and marking using dial peers, however, only a cursory knowledge of

voice configuration is required

CAR provides policing functions and marking. Chapter 5, “Traffic Policing and Shaping,”covers the policing details of CAR and CB policing. However, a quick review of policing beforegetting into CAR’s marking features will help you appreciate why CAR includes marking.Policing, in its most basic form, discards traffic that exceeds a particular traffic contract. Thecontract has two components: a rate, stated either in bits per second or bytes per second; and aburst size, stated in either bits or bytes. The traffic conforms to the contract if it sends at the rate,or below, and it does not send a burst of traffic greater than the burst size. If the traffic exceeds

the traffic rate over time, or exceeds the single burst size limit, the policing function drops the

traffic in excess of the rate and the burst size. Therefore, the simplest form of policing has two

rigid actions: either to forward packets or to drop them.

CAR’s marking function allows for additional policing action besides just forwarding or dropping

a packet. Consider a typical case where policing is used, as in Figure 3-14. ISP1 needs to

police traffic to protect customers who conform to their contracts from congestion created by

customers who do not conform. If the network is not congested, however, it might be nice to go

ahead and forward the nonconforming customer traffic. Doing so doesn’t really cost the ISP

anything, so long as the network is not congested. If the network is congested, however, ISP1

wants to discard the traffic that exceeds the contract before discarding traffic that is within its

respective contract.