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 T-series, MX-series, and M320 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.
To enable the MAD mechanism, 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;
- }
- }
- }