of 3) Cisco AutoQoS employs class-based
marking MQC mechanism for all Layer 2 frame and Layer 3 packet
marking as shown in Figure . Congestion Management
Congestion management tools assign a packet or flow to one of
several queues, based on classification, for appropriate
treatment in the network. When data, voice, and video are
placed in the same queue, packet loss and variable delay are
more likely to occur. You can increase the predictability of
network behavior and voice quality by using multiple queues on
egress interfaces and placing voice packets into a
strict-priority queue (low latency queuing [LLQ]) with
guaranteed bandwidth, separate from data packets. Congested
outbound WAN egress queues and serialization delays with
low-speed WAN links (link speeds less than 768 kbps) can both
result in variable delays and jitter impact on voice traffic.
Serialization delay is a function of both link speed and packet
size. Large e-mails and data downloads can cause voice quality
degradation, even in LAN environments. To alleviate the effects
of congestion and to provide enterprise applications with
guaranteed bandwidth and the lowest possible latency, Cisco
AutoQoS enables these Cisco IOS queuing tools: - LLQ
for real-time applications to experience the least latency in
egress queues and to ensure sufficient bandwidth on the output
link for optimal voice performance. LLQ processes traffic
classified into the DiffServ Expedited Forwarding (EF) class
(voice) as highest priority and places that traffic into a
separate, strict-priority queue. All other traffic is treated
using class-based weighted fair queuing (CBWFQ).
-
CBWFQ for data applications is utilized to provide sufficient
bandwidth and reduce interference between high-priority and
low-priority applications during periods of congestion. CBWFQ
processes traffic classified into DiffServ Assured Forwarding
(AF) classes (video and classified data) and the default class
for unclassified traffic (best effort).
- Weighted
round robin (WRR) with priority queuing (PQ) on Cisco Catalyst
switches processes traffic on egress switch ports using
DiffServ (DSCP is mapped to CoS at the ingress automatically),
ensuring priority for real-time traffic and predictable
bandwidth for other traffic types.
Cisco AutoQoS
uses percentage-based policies for increased scalability and
manageability. The same policy map can be applied on multiple
interfaces and on interfaces with varying bandwidth.
Shaping
Traffic shaping is a QoS mechanism used to
send traffic in short bursts at a configured transmission rate.
It is most commonly used in Frame Relay environments where the
interface clock rate is not the same as the guaranteed
bandwidth or committed information rate (CIR). Frame Relay
traffic shaping (FRTS) is the most common traffic-shaping
application in VoIP environments. Frame Relay scenarios usually
have a hub-and-spoke network where the hub link speed is higher
than any of the remote link speeds. In some cases, the sum of
the remote link speeds is higher than the hub link speed,
causing oversubscription. Without FRTS, the hub may try to send
traffic at higher rates than the remote links can receive,
causing the Frame Relay network to drop traffic arbitrarily.
However, the remote links could all send at an aggregate rate
that is higher than the hub can receive, again causing the
Frame Relay network to arbitrarily drop traffic. Because the
Frame Relay network has no Layer 3 or above intelligence, it
can drop VoIP traffic if contracts are violated. Therefore, you
need to control transmission rates into a Frame Relay cloud so
that you can control which packets are dropped and which
packets receive priority servicing. Cisco AutoQoS, depending on
the autodiscovered enterprise network environment, enables
either class-based shaping (for non-Frame Relay environments)
or FRTS mechanisms. Congestion Avoidance
Congestion-avoidance techniques monitor network traffic loads
in an effort to anticipate and avoid congestion at common
network bottlenecks. Packet dropping achieves congestion
avoidance. The router default is typically to use a crude
default packet-drop mechanism called tail drop. With tail drop,
packets are dropped during periods of congestion if they do not
fit into the egress queue, which equally affects all traffic
types, including high-priority traffic. Global synchronization
is another effect of tail drop and occurs as waves of
congestion crest, only to be followed by troughs during which
the transmission link is not fully utilized. Global
synchronization of TCP hosts, for example, can occur because
packets are dropped all at once. Global synchronization is
manifested when multiple TCP hosts reduce their transmission
rates in response to packet dropping, then increase their
transmission rates when the congestion is reduced. Cisco
AutoQoS utilizes weighted random early detection (WRED) to
avoid both the dropping of high-priority packets and global
synchronization. WRED increases the probability that congestion
will be avoided by dropping low-priority packets rather than
high-priority packets. Link Efficiency
Low-speed WAN
links can tremendously degrade voice quality. Voice traffic
could suffer from long delays before reaching the head of the
output line and from long transmission time and insufficient
bandwidth. When Cisco AutoQoS detects low-speed links during
the Auto Discovery phase, it minimizes these problems by
enabling two link efficiency mechanisms. Link fragmentation and
interleaving (LFI) is the method used to improve serialization
delay. Even when queuing is working at its best and
prioritizing voice traffic, there are times when the priority
queue is empty and a packet from another class is serviced.
Packets from guaranteed bandwidth classes must be serviced
according to their configured weight. If a priority voice
packet arrives in the output queue while these packets are
being serviced, the VoIP packet could wait a substantial length
of time before being sent. If a VoIP packet waits behind one
data packet, and the data packet is, at most, equal in size to
the maximum transmission unit (MTU) (1,500 bytes for serial
interfaces and 4,470 bytes for high-speed serial interfaces),
the wait time can be calculated based on link speed. For
example, this formula calculates the wait time for a link speed
of 64 kbps and MTU size of 1500 bytes: Serialization delay =
(1500 bytes * 8 bits per byte) / (64,000 bps)= 187.5 ms
Therefore, a VoIP packet may need to wait up to 187.5 ms before
it can be sent if it is delayed behind a single 1500-byte
packet on a 64-kbps link. VoIP packets usually are sent every
20 ms. With an end-to-end delay budget of 150 ms and strict
jitter requirements, a gap of more than 180 ms is unacceptable.
Some mechanism is needed that ensures that the size of one
transmission unit is 10 ms or less. Any packets that have more
than 10-ms serialization delay need to be fragmented into 10-ms
chunks. A 10-ms chunk or fragment is the number of bytes that
can be sent over the link in 10 ms. For a serialization delay
of 10 ms, the corresponding size of a packet or fragment
transmitted over a 64-kbps link would be 80 bytes. Cisco
AutoQoS enables one of two LFI mechanisms to fragment large
packets to protect voice, when low-speed links are
autodiscovered: - Multilink PPP (MLP) with interleaving
for PPP links
- Frame Relay Fragmentation (FRF.12) for
Frame Relay permanent virtual circuits (PVCs)
Compressed Real-Time Transport Protocol (cRTP) reduces the 40
byte IP + User Datagram Protocol (UDP) + RTP header to 2 to 4
bytes, reducing the bandwidth required per voice call on
point-to-point links. The header is compressed at one end of
the link and decompressed at the other end. Cisco AutoQoS
enables cRTP header compression when voice is transmitted on
low-speed links.
Content 5.2
Mitigating Common Cisco AutoQoS Issues 5.2.3
Automated Cisco AutoQoS DiffServ Class Provisioning Cisco
AutoQoS for the Enterprise defines as many as ten DiffServ