Guidelines For Managing Buffer Starvation - Juniper JUNOSE SOFTWARE FOR E SERIES 11.3.X - QUALITY OF SERVICE CONFIGURATION GUIDE 2010-09-22 Configuration Manual

Software for e series broadband services routers quality of service configuration guide
Table of Contents

Advertisement

Guidelines for Managing Buffer Starvation

Copyright © 2010, Juniper Networks, Inc.
Specifying a maximum queue length of 0 bytes disables queuing of packets on the
queue.
Specifying a maximum queue length of 1–128 bytes creates a single 128-byte buffer
for the queue.
Specifying a maximum queue length of 129–256 bytes creates two 128-byte buffers
for the queue.
Packets and cells consume at least one buffer.
For example, a 64-byte packet consumes a single 128-byte buffer. If you specify a
maximum queue length of 256 bytes, then either two packets of 64–128 bytes in length
or a single packet of 129–256 bytes can be queued.
For example, suppose a line module with 4000 IP interfaces is configured with four
queues per IP interface, corresponding to four traffic classes. Suppose that queues in
two of the traffic classes are configured with a buffer weight of 24 to increase burst
tolerance. The following example configures the video queue:
host1(config)#queue-profile video
host1(config-queue)#buffer-weight 24
host1(config-queue)#exit
host1(config)#
When the egress memory is fully loaded, dynamic oversubscription is 0 percent, and the
8000 queues with the default buffer weight strictly partition 25 percent of the 32-MB
memory, leaving 75 percent of the memory for the queues weighted 24 (corresponding
to the ratio 75 percent:25 percent, or 24:8). Therefore, these queues have committed
thresholds of 1 KB each, and queues with the buffer weight of 24 have committed
thresholds of 3 KB each. As the egress memory becomes progressively less loaded, all
the queue thresholds increase proportionally, based on dynamic oversubscription, but
the queues with buffer weight 24 are always set with thresholds three times larger than
the default thresholds.
Buffer starvation most commonly occurs when queues or nodes exist in a large round
robin, usually in the default traffic-class group. When the round robin congests, the queues
back up and require more buffers. The traffic in the round robin starts to burst based on
a single node or queue. After a packet is dequeued, the node or queue can wait for
thousands of other queues to dequeue a packet before it can dequeue again. During this
time, the queue backs up.
If you configure different scheduler profile weights or assured rates for nodes in a large
and congested round robin, the buffer starvation becomes apparent. The problem occurs
when the heavy weighted nodes wait their turn in the round robin and thousands of other
nodes dequeue. While the heavily weighted nodes wait, the system needs to buffer them.
However, all queues receive the same buffer allocation by default. If the system goes to
higher buffer regions, it starts dropping packets for all queues. When the heavy weight
node finally transmits, it dequeues all buffers, but it cannot dequeue the packets that
were dropped. You do not achieve the expected bandwidth based on scheduler profile
weights.
Chapter 3: Configuring Queue Profiles for Buffer Management
21

Advertisement

Table of Contents
loading

This manual is also suitable for:

Junose 11.3

Table of Contents