Juniper JUNOSE 11.1.X - QUALITY OF SERVICE CONFIGURATION GUIDE 3-21-2010, Configuration Manual

Page: 53 / 398

This feature provides graceful buffer allocation as the global utilization goes higher;
queues with more buffer weight always obtain more buffers, but they do not undergo
a dramatic drop in threshold when the system moves from region to region.
JUNOSe software uses 128-byte buffers. When setting very small queue thresholds,
keep the following guidelines in mind:
■
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.
Guidelines for Managing Buffer Starvation
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
Guidelines for Managing Buffers
■ 21
Chapter 3: Configuring Queue Profiles for Buffer Management