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, 5, 0, 0, 0, and 0 percent of the total available bandwidth.
The default buffer size percentages for queues 0 through 7 are 95, 0, 0, 5, 0, 0, 0, and 0 percent of the total available buffer. The total available buffer per queue differs by PIC type, as shown in Table 26.
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 | temporal microseconds);
For each scheduler, you can configure the buffer size as one of the following:
For information about configuring large buffer sizes on IQ PICs, see Configuring Large Delay Buffers for Slower Interfaces.
Table 26: Buffer Size Temporal Value Ranges by Platform Type
For more information about configuring delay buffers, see the following subtopics:
By default, T1, E1, and NxDS0 interfaces and DLCIs configured on channelized IQ PICs are limited to 100,000 microseconds of delay buffer. (The default average packet size on the IQ PIC is 40 bytes.) For these interfaces, it might be necessary to configure a larger buffer size to prevent congestion and packet dropping. You can do so on the following PICs:
Congestion and packet dropping occur when large bursts of traffic are received by slower interfaces. This happens when faster interfaces pass traffic to slower interfaces, which is often the case when edge devices receive traffic from the core of the network. For example, a 100,000-microsecond T1 delay buffer can absorb only 20 percent of a 5000-microsecond burst of traffic from an upstream OC3 interface. In this case, 80 percent of the burst traffic is dropped.
Table 27 shows some recommended buffer sizes needed to absorb typical burst sizes from various upstream interface types.
Table 27: Recommended Delay Buffer Sizes
To ensure that traffic is queued and transmitted properly on E1, T1, and NxDS0 interfaces and DLCIs, you can configure a buffer size larger than the default maximum. To enable larger buffer sizes to be configured, include the q-pic-large-buffer (large-scale | small-scale) statement at the [edit chassis fpc slot-number pic pic-number] hierarchy level:
- [edit chassis fpc slot-number pic pic-number]
- q-pic-large-buffer large-scale;
If you specify the large-scale option, the feature supports a larger number of interfaces. If you specify small-scale, the default, then the feature supports a smaller number of interfaces.
When you include the q-pic-large-buffer statement in the configuration, the larger buffer is transparently available for allocation to scheduler queues. The larger buffer maximum varies by interface type, as shown in Table 28.
Table 28: Maximum Delay Buffer with q-pic-large-buffer Enabled by Interface
If you configure a delay buffer larger than the new maximum, the candidate configuration can be committed successfully. However, the setting is rejected by the packet forwarding component, the default setting is used instead, and a system log warning message is generated.
For interfaces that support DLCI queuing, the large buffer is supported for DLCIs on which the configured shaping rate is less than or equal to the physical interface bandwidth. For instance, when you configure a Frame Relay DLCI on a Channelized T3 IQ PIC, and you configure the shaping rate to be 1.5 Mbps, the amount of delay buffer that can be allocated to the DLCI is 500,000 microseconds, which is equivalent to a T1 delay buffer. For more information about DLCI queuing, see Applying Scheduler Maps and Shaping Rate to DLCIs and VLANs.
For NxDS0 interfaces, the larger buffer sizes can be up to 4,000,000 microseconds, depending on the number of DS0 channels in the NxDS0 interface. For slower NxDS0 interfaces with fewer channels, the delay buffer can be relatively larger than for faster NxDS0 interfaces with more channels. This is shown in Table 30. To calculate specific buffer sizes for various NxDS0 interfaces, see Maximum Delay Buffer for NxDS0 Interfaces.
You can allocate the delay buffer as either a percentage or a temporal value. The resulting delay buffer is calculated differently depending how you configure the delay buffer, as shown in Table 29.
Table 29: Delay-Buffer Calculations
For more information, see the following sections:
Because NxDS0 interfaces carry less bandwidth than a T1 or E1 interface, the buffer size on an NxDS0 interface can be relatively larger, depending on the number of DS0 channels combined. The maximum delay buffer size is calculated with the following formula:
For example, a 1xDS0 interface has a speed of 64 kilobits per second (Kbps). At this rate, the maximum delay buffer time is 4,000,000 microseconds. Therefore, the delay buffer size is 32 kilobytes (KB):
Table 30 shows the delay-buffer calculations for 1xDS0 through 32xDS0 interfaces.
Table 30: NxDS0 Transmission Rates and Delay Buffers
Set large delay buffers on interfaces configured on a Channelized OC12 IQ PIC. The CoS configuration binds a scheduler map to the interface specified in the chassis configuration. For information about the delay-buffer calculations in this example, see Table 29.
- chassis {
-
- fpc 0 {
-
- pic 0 {
- q-pic-large-buffer; # Enabling large delay buffer
- max-queues-per-interface 8; # Eight queues (M320 and T-series
platforms)
- }
- }
- }
Configuring the Delay Buffer Value for a Scheduler
You can assign to a physical or logical interface a scheduler map that is composed 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.
The 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 that of 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-best 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
- [edit]
- class-of-service {
-
- schedulers {
-
- sched-best {
- transmit-rate percent 10;
- buffer-size percent 20;
- }
-
- sched-exped {
- transmit-rate percent 20;
- buffer-size temporal 300000;
- }
- }
- }
Configuring 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. For more information, see Table 30.
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 1.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;
- }
- }
- }
In the JUNOS software, 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 M320, MX-series, and T-series routing platforms 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 PFE, not the PIC. All M320, MX-series, and T-series routing platform FPCs and PFEs support MAD, except for the T-series ES-FPC and Enhanced IV FPC. No IQ, IQ2, IQ2E or IQE PICs support MAD.
To enable the MAD mechanism on supported hardware, include the buffer-size percent statement at the [edit class-of-service schedulers scheduler-name] hierarchy level:
- [edit class-of-service schedulers scheduler-name]
- buffer-size percent percentage;
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:
- 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;
- }
- }
- }
