the transmit queue is dependant on the hardware,
software, Layer 2 media, and queuing algorithm configured on
the interface. The default transmit queue size is determined by
Cisco IOS software, is based on the bandwidth of the media, and
should be fine for most queuing implementations. Some platforms
and QoS mechanisms automatically adjust the transmit queue size
to an appropriate value. Faster interfaces have longer hardware
queues because they produce less delay. Slower interfaces have
shorter hardware queues to prevent too much delay in the
worst-case scenario in which the entire hardware queue is full
of MTU-size packets. The length of the transmit queue depends
on several factors and is adjusted automatically based on the
configuration applied to the interface. To avoid too much delay
on the slow interface and to avoid bad link utilization, check
the length of the transmit queue and change it if needed. The
default length works fine in almost all cases. Figure
summarizes these points. The show controllers serial
0/1/0 command is used to see the length of the transmit
queue. The transmit queue length is shown as the tx_limited or
tx_ring_limit or tx_ring statement and varies depending on the
platform. Figure illustrates the output of the show
command showing the length of the transmit queue. In this
example, the hardware queue length is defined by the tx_limited
statement and equals two packets. Congestion on Software
Interfaces
Subinterfaces and software interfaces do not
have their own separate transmit queues; they use the main
transmit queue. Software interface types include dialers,
tunnels, and Frame Relay subinterfaces, and they will congest
only when their main hardware interface transmit queue
congests. The transmit (tx ring) state is an indication of
congestion of hardware interfaces caused by a congestion on the
main hardware interface. Figure summarizes these points.
Content 4.4 Configuring WFQ 4.4.1
Weighted Fair Queuing For situations in which it is
desirable to provide consistent response time to heavy and
light network users alike without adding excessive bandwidth,
the solution is WFQ. WFQ is one of Cisco’s premier queuing
techniques. It uses a flow-based queuing algorithm that does
two things simultaneously: - It schedules interactive
traffic to the front of the queue to reduce response
time.
- It fairly shares the remaining bandwidth among
the various flows to prevent high-volume flows from
monopolizing the outgoing interface.
The basis of
WFQ is to have a dedicated queue for each flow without
starvation, delay, or jitter within the queue. Furthermore, WFQ
allows fair and accurate bandwidth allocation among all flows
with minimum scheduling delay. WFQ makes use of the IP
precedence bits as a weight when allocating bandwidth.
Low-volume traffic streams, which comprise the majority of
traffic, receive preferential service, transmitting their
entire offered loads in a timely fashion. High-volume traffic
streams share the remaining capacity proportionally between
them, as shown in Figure . WFQ solves problems inherent in the
following queuing mechanisms: - FIFO queuing causes
starvation, delay, and jitter.
- Priority queuing (PQ)
causes starvation of lower-priority classes and suffers from
the FIFO problems within each of the four queues that it uses
for prioritization.
Figure summarizes these points.
Content 4.4 Configuring WFQ 4.4.2
WFQ Architecture and Benefits WFQ is a dynamic
scheduling method that provides fair bandwidth allocation to
all network traffic. WFQ applies weights to identified traffic,
classifies traffic into flows, and determines how much
bandwidth each flow is allowed, relative to other flows.WFQ is
a flow-based algorithm that simultaneously schedules
interactive traffic to the front of a hardware queue to reduce
response time and fairly shares the remaining bandwidth among
high-bandwidth flows. As shown in Figure , WFQ allows you to
give low-volume traffic, such as Telnet sessions, priority over
high-volume traffic, such as FTP sessions. WFQ gives concurrent
file transfers balanced use of link capacity; that is, when
multiple file transfers occur, the transfers are given
comparable bandwidth. The WFQ method works as the default
queuing mode on serial interfaces configured to run at or below
E1 speeds (2.048 Mbps). WFQ provides the solution for
situations in which it is desirable to provide consistent
response times to heavy and light network users alike, without
adding excessive bandwidth. In addition, WFQ can manage duplex
data flows, such as those between pairs of applications, and
simplex data flows, such as voice or video. Although WFQ
automatically adapts to changing network traffic conditions, it
does not offer the precise degree of control over bandwidth
allocation that custom queuing (CQ) and class-based weighted
fair queuing (CBWFQ) offer. The significant limitation of WFQ
is that it is not supported with tunneling and encryption
because these features modify the packet content information
required by WFQ for classification.
Content 4.4
Configuring WFQ 4.4.3 WFQ
Classification WFQ classification has to identify
individual flows. Figure shows how a flow is identified based
on the following information taken from the IP header and the
TCP or User Datagram Protocol (UDP) headers: - Source IP
address
- Destination IP address
- Protocol
number (identifying TCP or UDP)
- Type of service
field
- Source TCP or UDP port number
- Destination TCP or UDP port number
These
parameters are usually fixed for a single flow, although there
are some exceptions. For example, a quality of service (QoS)
design can mark packets with different IP precedence bit values
even if they belong to the same flow. You should avoid such
marking when using WFQ. The parameters are used as input for a
hash algorithm that produces a fixed-length number that is used
as the index of the queue. Figure outlines the steps for
implementing WFQ. WFQ uses a fixed number of queues. The hash
function is used to assign a queue to a flow. There are eight
additional queues for system packets and optionally up to 1000
queues for Resource Reservation Protocol (RSVP) flows. The
number of dynamic queues that WFQ uses by default is based on
the interface bandwidth. With the default interface bandwidth,
WFQ uses 256 dynamic queues. The number of queues can be
configured in the range between 16 and 4096 (the number must be
a power of 2). If there are a large number of concurrent flows,
it is likely that two flows could end up in the same queue. You
should have several times as many queues as there are flows (on
average). This design may not be possible in larger
environments where concurrent flows number in the thousands.
Content 4.4 Configuring WFQ 4.4.4
WFQ Insertion and Drop Policy Figure describes WFQ
insertion and drop policy. The WFQ system has a hold queue that
represents the queue depth, which means the number of packets
that can be held in the queue. WFQ uses the following two
parameters that affect the dropping of packets: - The
congestive discard threshold (CDT) is used to start dropping
packets of the most aggressive flow, even before the hold-queue
limit is reached.
- The hold-queue limit defines the
maximum number of packets that can be held in the WFQ system at
any time.
There are two exceptions to the WFQ
insertion and drop policy: - If the WFQ system is above
the CDT limit, the packet is still enqueued if the specific per
flow queue is empty.
- The dropping strategy is not
directly influenced by IP precedence.
The length of
queues (for scheduling purposes) is determined not by the sum
of the size in bytes of all the packets but by the time it
would take to transmit all the packets in the queue. The end
result is that WFQ adapts to the number of active flows
(queues) and allocates equal amounts of bandwidth to each flow