Dynamic MBS for egress queue group queues

Dynamic MBS is used to constrain the maximum delay experienced by the traffic forwarded through an egress queue group queue when the operational PIR of the queue is modified as part of the HQoS algorithm.

The approximate maximum delay of traffic through a queue because of the length of the queue, when the queue is not using HQoS, is relative to its administrative PIR and can be approximated as (MBS[kB] ✕ 8) / PIR[kb/s]) in seconds. A queue’s PIR is set to max, and its administrative PIR is set to the rate of the port to which the queue is attached.

When using HQoS, the PIR is modified by the HQoS algorithm to give an operational PIR that is equal to or lower than the administrative PIR. As the operational PIR changes, the delay through the queue can also change if the length of the queue is fixed. Reducing the operational PIR could increase the delay, while increasing the operational PIR could reduce the delay. Enabling dynamic MBS on a queue allows the system to change the administrative MBS of the queue in a ratio of operational PIR to administrative PIR, giving an operational MBS, which aims to maintain the maximum queue delay. A queue’s drop tails and WRED slope parameters are defined as percentages of the MBS and are, therefore, adjusted accordingly.

When any of the queue parameters are reduced, packets that are already in the queue are not affected and are forwarded. Reducing these parameters constrains the latency for newly arriving packets, but those packets already in the queue before the new parameter values were set are forwarded with the delay associated with the actual queue depth when the packet was enqueued (based on the previous parameter values).

The configured CBS is used as a minimum operational MBS. The maximum MBS is capped by the maximum administrative MBS (1 GB).

If the operational MBS changes such that its value is similar or equal to the configured CBS, the system increases the CBS to ensure that buffers can be requested from the correct portion of the buffer pool (shared or reserved). This operation is automatic, and the CBS reverts to its configured value if the MBS is increased sufficiently. The automatic increase in the CBS could, however, cause the resv-cbs red or amber alarms to be raised if the increase in the related queues’ CBS results in the total CBS assigned (but not necessarily used) matching or exceeding the resv-cbs red and amber thresholds.

If a LAG is used together with pool-per-queue, the related hardware queues exist in their own pool in the egress WRED megapool on a specific FP and the operational MBS is used to size the shared part of the pool with the sum of the CBS defining the reserved part of the pool.

Dynamic MBS is supported for both native FP and pool-per-queue queues within an egress queue group template, which can be applied to access or network Ethernet ports and used for egress network interface traffic, egress SAP traffic, and subscriber egress policed traffic.

The configuration of dynamic MBS and queue depth monitoring are mutually exclusive.

Dynamic MBS is configured as follows:

configure
    qos
       queue-group-templates
          egress
              queue-group queue-group-name create
                  queue queue-id

The operational MBS can be shown using the show pools and show qos scheduler-hierarchy commands.

The following example shows the use of dynamic MBS. A queue group template is applied to port 5/1/1 configured with multiple queues using HQoS, one of which has the following parameters:

queue-group "qg1" create
  queue 1 best-effort create
       parent "s1" 
       rate 50000
       mbs 1000 kilobytes
       dynamic-mbs
   exit

Without any traffic in the other queues constraining the operational PIR on this queue, the MBS used is the administrative MBS.

*B:PE# show pools access-egress 5/1/1 queue-group "qg1" instance 1
...
===============================================================================
Queue : accQGrp->qg1:1(5/1/1)->1
===============================================================================
FC Map               : not-applicable
Dest Tap             : not-applicable   Dest FP          : not-applicable
Admin PIR            : 50000            Oper PIR         : 50000
Admin CIR            : 0                Oper CIR         : 0
Admin MBS            : 1008 KB          Oper MBS         : 1008 KB
High-Plus Drop Tail  : 1008 KB          High Drop Tail   : 1008 KB
Low Drop Tail        : 888 KB           Exceed Drop Tail : 792 KB
CBS                  : 0 KB             Depth            : 0
Slope                : not-applicable

If traffic is sent to the other queues in the queue group such that the operational PIR of queue 1 is reduced to 25 Mb/s, the show output changes to:

*B:PE# show pools 5/1/1 access-egress queue-group "qg1" instance 1
...
===============================================================================
Queue : accQGrp->qg1:1(5/1/1)->1
===============================================================================
FC Map               : not-applicable
Dest Tap             : not-applicable   Dest FP          : not-applicable
Admin PIR            : 50000            Oper PIR         : 25000
Admin CIR            : 0                Oper CIR         : 0
Admin MBS            : 1008 KB          Oper MBS         : 504 KB
High-Plus Drop Tail  : 1008 KB          High Drop Tail   : 1008 KB
Low Drop Tail        : 948 KB           Exceed Drop Tail : 900 KB
CBS                  : 0 KB             Depth            : 0
Slope                : not-applicable

The output shows that the operational MBS is now 50% of the administrative MBS and that the queue’s drop tails have changed accordingly.