Configure the Scheduler Buffer Size to Manage Egress Congestion
To control congestion at the output stage, you can configure the delay-buffer bandwidth. The delay-buffer bandwidth provides packet buffer space to absorb burst traffic up to the specified duration of delay. Once the specified delay buffer becomes full, packets with 100 percent drop probability are dropped from the head of the buffer.
The default scheduler transmission rate for queues 0 through 7 are 95, 0, 0, 0, 0, 0, 0, and 5 percent of the total available bandwidth.
The default buffer size percentages for queues 0 through 7 are 95, 0, 0, 0, 0, 0, 0, and 5 percent of the total available buffer. The total available buffer per queue differs by PIC type.
To configure the buffer size, include the buffer-size statement at the
[edit class-of-service schedulers
scheduler-name] hierarchy level:
[edit class-of-service schedulers scheduler-name] buffer-size (percent percentage | remainder | shared | temporal microseconds);
For each scheduler, you can configure the buffer size as one of the following:
-
A percentage of the total buffer. The total buffer per queue is based on microseconds and differs by routing device type.
-
The remaining buffer available. The remainder is the buffer percentage that is not assigned to other queues.
-
Shared from the interface’s buffer pool. On PTX Series routers, set a queue’s buffer to be up to 100 percent of the interface’s buffer. This option allows the queue’s buffer to grow as large as 100 percent of the interface's buffer if and only if it is the only active queue for the interface.
-
A temporal value, in microseconds. For the temporal setting, the queuing algorithm starts dropping packets when it queues more than a computed number of bytes. This maximum is computed by multiplying the transmission rate of the queue by the configured temporal value.
Note:In general, the default temporal buffer value is inversely related to the speed, or shaping rate, of the interface. As the speed of the interface increases, the interface needs less and less buffer to hold data, as it is possible for the interface to send more and more data.
Because available hardware resources to configure temporal buffer settings are limited, we recommend having a common temporal buffer configuration as much as possible.
In general, you can configure the scheduler buffer size for both port schedulers and hierarchical schedulers. For port schedulers, Junos calculates the shared buffer size based on the following:
-
If a port shaper is configured, Junos calculates the buffer size based on the port shaper.
-
If no port shaper is configured, Junos calculates the buffer size based on the port speed.
For hierarchical schedulers, Junos calculates the shared buffer size based on the following:
-
If a shaper is configured on the logical interface, Junos calculates the buffer size based on the logical interface port shaper.
-
If a port shaper is configure, but no logical interface shaper, Junos calculates the buffer size based on the port shaper.
-
If no shaper is configured, Junos calculates the buffer size based on the port speed.
Example: Configure the Delay Buffer Value for a Scheduler
You can assign to a physical or logical interface a scheduler map that consists of
different schedulers (or queues). The physical interface’s large delay buffer can be
distributed to the different schedulers (or queues) using the
transmit-rate and buffer-size statements at
the [edit class-of-service schedulers
scheduler-name] hierarchy level.
This example shows two schedulers, sched-best and
sched-exped, with the delay buffer size configured as a
percentage (20 percent) and temporal value (300,000 microseconds), respectively. The
sched-best scheduler has a transmit rate of 10 percent. The
sched-exped scheduler has a transmit rate of 20 percent.
The sched-best scheduler’s delay buffer is twice the specified
transmit rate of 10 percent. Assuming that the sched-best scheduler
is assigned to a T1 interface, this scheduler receives 20 percent of the total
500,000 microseconds of the T1 interface’s delay buffer. Therefore, the scheduler
receives 18,750 bytes of delay buffer:
available interface bandwidth * configured percentage buffer-size * maximum buffer = queue buffer 1.5 Mbps * 0.2 * 500,000 microseconds = 150,000 bits = 18,750 bytes
Assuming that the sched-exped scheduler is assigned to a T1
interface, this scheduler receives 300,000 microseconds of the T1 interface’s
500,000-microsecond delay buffer with the traffic rate at 20 percent. Therefore,
the scheduler receives 11,250 bytes of delay buffer:
available interface bandwidth * configured percentage transmit-rate * configured temporal buffer-size = queue buffer 1.5 Mbps * 0.2 * 300,000 microseconds = 90,000 bits = 11,250 bytes
To configure this example:
Example: Configure the Physical Interface Shaping Rate
In
general, the physical interface speed is the basis for calculating the delay buffer
size. However, when you include the shaping-rate statement, the
shaping rate becomes the basis for calculating the delay buffer size.
This example configures the shaping rate on a T1 interface to 200 Kbps, which means that the T1 interface bandwidth is set to 200 Kbps instead of 1.5 Mbps. Because 200 Kbps is less than 4xDS0, this interface receives 4 seconds of delay buffer, or 800 Kbps of traffic, which is 800 KB for a full second.
Complete Configuration
This example shows a Channelized OC12 IQ PIC in FPC slot 0, PIC slot 0 and a channelized T1 interface with Frame Relay encapsulation. It also shows a scheduler map configuration on the physical interface.
chassis {
fpc 0 {
pic 0 {
q-pic-large-buffer;
max-queues-per-interface 8;
}
}
}
interfaces {
coc12-0/0/0 {
partition 1 oc-slice 1 interface-type coc1;
}
coc1-0/0/0:1 {
partition 1 interface-type t1;
}
t1-0/0/0:1:1 {
encapsulation frame-relay;
unit 0 {
family inet {
address 10.1.1.1/24;
}
dlci 100;
}
}
}
class-of-service {
interfaces {
t1-0/0/0:1:1 {
scheduler-map smap-1;
}
}
scheduler-maps {
smap-1 {
forwarding-class best-effort scheduler sched-best;
forwarding-class expedited-forwarding scheduler sched-exped;
forwarding-class assured-forwarding scheduler sched-assure;
forwarding-class network-control scheduler sched-network;
}
}
schedulers {
sched-best {
transmit-rate percent 40;
buffer-size percent 40;
}
sched-exped {
transmit-rate percent 30;
buffer-size percent 30;
}
sched-assure {
transmit-rate percent 20;
buffer-size percent 20;
}
sched-network {
transmit-rate percent 10;
buffer-size percent 10;
}
}
}
Enabling and Disabling the Memory Allocation Dynamic per Queue
In the Junos OS, the memory allocation dynamic (MAD) is a mechanism that dynamically provisions extra delay buffer when a queue is using more bandwidth than it is allocated in the transmit rate setting. With this extra buffer, queues absorb traffic bursts more easily, thus avoiding packet drops. The MAD mechanism can provision extra delay buffer only when extra transmission bandwidth is being used by a queue. This means that the queue might have packet drops if there is no surplus transmission bandwidth available.
For Juniper Networks MX Series 5G Universal Routing Platforms and EX Series Ethernet Switches only, the MAD mechanism is enabled unless the delay buffer is configured with a temporal setting for a given queue. The MAD mechanism is particularly useful for forwarding classes carrying latency-immune traffic for which the primary requirement is maximum bandwidth utilization. In contrast, for latency-sensitive traffic, you might wish to disable the MAD mechanism because large delay buffers are not optimum.
MAD support is dependent on the FPC and Packet Forwarding Engine, not the PIC. No Modular Port Concentrators (MPCs) and IQ, IQ2, IQ2E or IQE PICs support MAD.
To enable the MAD mechanism on supported hardware:
buffer-size percent statement at the
[edit class-of-service schedulers
scheduler-name] hierarchy level:
[edit class-of-service schedulers scheduler-name] user@host# set buffer-size percent percentage
The minimum buffer allocated to any queue is 18,432 bytes. If a queue is configured to have a buffer size less than 18,000, the queue retains a buffer size of 18,432 bytes.
If desired, you can configure a buffer size that is greater than the configured transmission rate. The buffer can accommodate packet bursts that exceed the configured transmission rate, if sufficient excess bandwidth is available. For example:
class-of-service {
schedulers {
sched-best {
transmit-rate percent 20;
buffer-size percent 30;
}
}
}
As stated previously, you can use a temporal delay buffer configuration to disable the MAD mechanism on a queue, thus limiting the size of the delay buffer. However, the effective buffer latency for a temporal queue is bounded not only by the buffer size value but also by the associated drop profile. If a drop profile specifies a drop probability of 100 percent at a fill-level less than 100 percent, the effective maximum buffer latency is smaller than the buffer size setting. This is because the drop profile specifies that the queue drop packets before the queue’s delay buffer is 100 percent full.
Such a configuration might look like the following example:
class-of-service {
drop-profiles {
plp-high {
fill-level 70 drop-probability 100;
}
plp-low {
fill-level 80 drop-probability 100;
}
}
schedulers {
sched {
buffer-size temporal 500000;
drop-profile-map loss-priority low protocol any drop-profile plp-low;
drop-profile-map loss-priority high protocol any drop-profile plp-high;
transmit-rate percent 20;
}
}
}
Platform-Specific Buffer Size Configuration Behavior
Use Feature Explorer to confirm platform and release support for buffer size configuration.
Use the following table to review platform-specific behaviors for your platform:
| Platform | Difference |
|---|---|
|
ACX7000 Series routers |
For the |
| PTX Series routers |
PTX Series routers support the |