12.5. Advanced QoS Policy Command Reference

This command enters the context to configure an advanced QoS policy. This command contains only queue and policer child control parameters within a child-control node.

The parameters within the child-control node are intended to allow more precise control of the method that hierarchical virtual scheduling employs to emulate the effect of a scheduling context upon a member child queue or policer.

When a policy is created, it may be applied to a queue or policer defined within a sap-egress or sap-ingress QoS policy. It may also be applied to a queue or policer defined within an ingress or egress queue-group template. When a policy is currently associated with a QoS policy or template, the policy may be modified but not deleted (even in the event that the QoS policy or template is not in use).

While the system maintains default values for the advanced configuration parameters, no default adv-config-policy exists.

The no form of this command removes the specified advanced policy.

This command contains parameters that are intended to allow more precise control of the method that hierarchical virtual scheduling employs to emulate the effect of a scheduling context upon a member child queue or policer.

This command edits the parameters that control the child requested bandwidth and parental bandwidth distribution for all policers and queues associated with the policy.

This command modifies or controls the bandwidth distribution phase of the parent virtual scheduler.

This command edits the parameters that control the child given bandwidth for all policers and queues associated with the policy.

This command enters the context to edit the parameters that control the child's above-offered-allowance bandwidth. These parameters are only applicable when the port scheduler is configured to use the above-offered-allowance-control algorithm, otherwise they are ignored.

This command configures the percentage of the delta (from the beginning to the end of the current H-QoS below CIR or above CIR pass) of the aggregate rate consumed by its other members that can be given to a queue at the end of an H-QoS below CIR pass and above CIR pass. This command is only applicable when the port scheduler is configured to use the above-offered-allowance-control algorithm, otherwise it is ignored.

The no form of this command reverts the delta-consumed-agg-rate percent to its default value.

This command configures the percentage of the delta (from the beginning to the end of the current H-QoS below CIR or above CIR pass) of the higher tier rate consumed by its other members that can be given to a queue at the end of an H-QoS below CIR pass and above CIR pass. Higher tier refers to the Vport aggregate rate and port scheduler level, group, and maximum rates.

This command is only applicable when the port scheduler is configured to use the above-offered-allowance-control algorithm, otherwise it is ignored.

The no form of this command reverts the delta-consumed-higher-tier-rate percent to its default value.

This command configures the percentage of the unconsumed aggregate rate that can be given to a queue at the end of an H-QoS below CIR pass and above CIR pass. This command is only applicable when the port scheduler is configured to use the above-offered-allowance-control algorithm, otherwise it is ignored.

The no form of this command reverts the unconsumed-agg-rate percent to its default value.

This command configures the percentage of the unconsumed higher tier rate that can be given to a queue at the end of an H-QoS below CIR pass and above CIR pass. Higher tier refers to the Vport aggregate rate and port scheduler level, group, and maximum rates.

This command is only applicable when the port scheduler is configured to use the above-offered-allowance-control algorithm, otherwise it is ignored.

The no form of this command reverts the unconsumed-higher-tier-rate percent to its default value.

This command is used to limit the operationally configured shaping or policing rate on the child associated with the policy. After the parent virtual scheduler or policer control policy determines the appropriate rate for a given child, a separate operation decides the actual PIR that should be configured for that child. When the parent determines that the distributed rate is equal to or less than the child’s offered rate, the configured operational PIR will be equal to that determined rate. But when the parent determines that the child’s offered rate is less than the available bandwidth the child could consume, the operational PIR may be set to a value larger than the distributed bandwidth. This extra rate is not currently used by the child since the offered rate is less. The system provides this extra bandwidth in case the child’s offered rate increases before the next sampling interval is complete, in order to mitigate the periodic nature of the child’s operational PIR adjustments. The increase in the offered rate is not subtracted from the parent’s remaining distribution bandwidth for lower priority children, only the determined rate is considered consumed by the parent virtual scheduler or policer control policy instance. The actual operationally configured PIR will never be greater than the child’s administratively defined PIR.

This ‘fair share’ PIR configuration behavior may result in the sum of the children’s PIRs exceeding the aggregate rate of the parent. If this behavior violates the downstream QoS requirements, the above-offered-cap command may be used to minimize or eliminate the increase in the child’s configured PIR.

If the above-offered-cap command is used with a percent-based value, the increase is a function of the configured PIR value on the policer or queue. In this case, care should be taken that the child is either configured with an explicit PIR rate (other than max) or the child’s administrative PIR is defined using the percent-rate command with the local parameter enabled if an explicit value is not desired. When a maximum PIR is in use on the child, the system attempts to interpret the maximum child forwarding rate. This rate could be very large if the child is associated with multiple ingress or egress ports.

If the child’s administrative PIR is modified while a percent based above-offered-cap is in effect, the system automatically uses the new relative limit value the next time the child’s operational PIR is distributed.

When this command is not specified or removed, the child’s operational ‘fair share’ operational PIR may be configured up to the child’s administrative PIR, based on the actual parental bandwidth available at the child’s priority level.

The no form of this command is used to remove a fair share operational PIR rate increase limit from all child policers and queues associated with the policy.

This command is used to enable queuing of new packets when H-QoS determines that a queue should stop forwarding (operational PIR set to zero). The default behavior is to allow the queue to continue to use the previously determined operational PIR and set the queue’s MBS (Maximum Burst Size) to zero. This prevents new packets from being admitted to the queue until the PIR zero case terminates. The new behavior when enqueue-on-pir-zero is enabled is to set the operational PIR to zero and leave the queue’s MBS set to the normal value.

This command overrides the limit-pir-zero-drain command.

The no form of this command reverts to default behavior.

This command is used to create a step-like behavior where the operational PIR will round up to the nearest increment of the specified granularity before being applied to the child. The only exception is when the distributed bandwidth is less than 1% above a lower step value, in which case the lower step value is used.

This step-like behavior may be useful when the bandwidth used by an active child is well known. While the above-offered-cap command automatically adds a specified amount to the operational PIR of a child, the granularity command only increments the operational PIR to the next step value. While not expected to be used in conjunction, the above-offered-cap and granularity commands may be used simultaneously, in which case the above-offered-cap increase will be applied first, followed by the granularity rounding to the next step value.

If the granularity command is used with a percent-based value, the rounding up function of the configured PIR value on the policer or queue is based on the child’s administrative PIR. In this case, care should be taken that the child is either configured with an explicit PIR rate (other than max) or the child’s administrative PIR is defined using the percent-rate command with the local parameter enabled if an explicit value is not desired. When a maximum PIR is in use on the child, the system attempts to interpret the maximum child forwarding rate. This rate could be very large if the child is associated with multiple ingress or egress ports.

If the child’s administrative PIR is modified while a percent-based granularity is in effect, the system automatically uses the new relative rounding value the next time the child’s operational PIR is determined.

When this command is not specified or removed, the system makes no attempt to round up the child’s determined operational PIR.

The no form of this command is used to remove the operational PIR rounding behavior from all child policers and queues associated with the policy.

This command specifies the internal scheduler (tier 0) weight mode for the queues on a LAG on which the advanced configuration policy is applied.

This command is used to configure the system to use the minimum configurable PIR instead of an H-QoS derived zero operational PIR. The default behavior is to allow the operational PIR of the queue to remain the last configured value while setting the queue MBS to zero (preventing queuing of newly arriving packets). Retaining the previous PIR value may cause a momentary burst above an aggregate rate associated with the queue as it drains. Using the limit-pir-zero-drain command causes the queue to drain at the lowest rate possible (typically 1 kb/s) that limits overrun situations.

The no form of this command reverts to default behavior.

This command is used to initialize new queues associated with a LUB context to use a minimum PIR similar to the effect of the limit-pir-zero-drain command. When a queue is initially created in a LUB context, it defaults to a zero value PIR until H-QoS has an opportunity to configure an offered rate based operational PIR. Enabling this command forces a minimum rate operational PIR to be applied to the queue for use by enqueued packets prior to an H-QoS iteration.

The no form of this command reverts to default behavior.

This command modifies the offered rate measurement used to determine the bandwidth the queue or policer is requesting from its parent virtual scheduling context.

This command modifies the parameters that control the child requested bandwidth for all policers and queues associated with the policy.

This command is used to increase the measured rate of the policer or queue associated with the policy. The offered rate (capped by the administrative PIR configured on the queue or policer) is usually used unaltered by the parent virtual scheduler. The add command allows this measured rate to be increased by the specified amount or by a percentage of the administrative PIR. The resulting rate will not exceed the administrative PIR.

The parent scheduler uses the modified measured rate as the available work load for the queue or policer in determining how much bandwidth the child should receive from the bandwidth distribution algorithm.

One example of when an increase in the measured offered rate may be desired is when a queue or policer is handling VoIP traffic. A characteristic of VoIP is the step nature in how traffic is used. Each call typically adds a certain maximum amount to the overall load. By using the add command, the bandwidth required for the next added call may be included in the current measured rate. This allows the virtual scheduler to allocate sufficient bandwidth to the queue or policer so that when the call is made the scheduling algorithm does not need to run to increase the bandwidth.

A side effect of increasing the measured offered rate is that if the extra bandwidth is allocated by the virtual scheduler, the available bandwidth to lower priority queues or policers is diminished even though the extra allocated bandwidth may not be in use. If this is the case, the effect will be seen as an underrun in the aggregate output of the virtual scheduler.

If the add command is used with a percent-based value, the increase is a function of the configured PIR value on the policer or queue. In this case, care should be taken that the child is either configured with an explicit PIR rate (other than max) or the child’s administrative PIR is defined using the percent-rate command with the local parameter enabled if an explicit value is not desired. When a maximum PIR is in use on the child, the system attempts to interpret the maximum child forwarding rate. This rate could be very large if the child is associated with multiple ingress or egress ports.

Except for the overall cap on the offered input into the virtual scheduler, the child’s administrative PIR has no effect on the calculated increase if an explicit rate is specified.

If the child’s administrative PIR is modified while a percent based add is in effect, the system automatically uses the new relative increase value the next time the child’s offered rate is determined.

When the add command is not specified or removed, the child’s offered rate used by the child’s virtual scheduler is not increased.

The no form of this command is used to remove an offered rate increase from all child policers and queues associated with the policy.

This command is used to enable fast detection of initial bandwidth on a child policer or queue associated with the policy. Multiple offered rate counter reads may be performed per the sampling interval. The system accumulates these counter values and evaluates the delta at the conclusion of the sampling interval. When fast-start is enabled, the system identifies all children associated with the policy that enter the inactive state (current offered rate is zero). Any inactive ‘fast start’ child that has a positive offered counter during a sampling period bypasses the normal sampling interval and does an immediate offered rate evaluation.

This option is intended for use with children that would benefit from faster than normal startup detection, typically those of a real-time nature.

When this parameter is not enabled, the system uses the normal sampling interval behavior of both newly active and currently active children.

The no form of this command is used to restore the sampling-interval-based offered rate evaluation for newly active children.

This command is used to enable fast detection of lack of offered rate on a child policer or queue associated with the policy. Multiple offered rate counter reads may be performed per sampling interval. The system accumulates these counter values and evaluates the delta at the conclusion of the sampling interval. When fast-stop is enabled, the system bypasses the sampling interval for any currently active ‘fast stop’ child that has a zero offered counter measurement and does an immediate offered rate evaluation using the zero value.

This option is intended for use with children where other children would benefit from faster than normal inactive detection, typically those of a real-time nature.

When this parameter is not enabled, the system uses the normal sampling interval behavior of both newly inactive and currently active children.

The no form of this command is used to restore the sampling-interval-based offered rate evaluation for newly inactive children.

This command is used to adjust the sensitivity of the virtual scheduler to changes in the child offered rate. As the child offered rate is determined, it is compared to the previous offered rate. If the delta does not exceed the sensitivity threshold determined for the current offered rate, the change in offered rate is ignored for that iteration.

While it is assumed that changing the offered rate change sensitivity will be a rare occurrence, it may be prudent to react to smaller changes in the offered rate of a particular child policer or queue. Another possible reason for changing the sensitivity is that it may be desired to lower the impact of changes in offered rate on the virtual scheduler for a particular child by raising the granularity.

A side effect of higher sensitivity (lower granularity) is that the virtual scheduler may need to adjust the distributed bandwidth between all children more often, resulting in the possibility of lowering resources available to other virtual scheduler instances on the slot.

A side effect of lower sensitivity (higher granularity) is that the parent virtual scheduler may distribute insufficient bandwidth to the child resulting in dropped packets.

If the granularity command is used with a percent-based value, the sensitivity is a function of the configured PIR value on the policer or queue. In this case, care should be taken that the child is either configured with an explicit PIR rate (other than max) or the child’s administrative PIR is defined using the percent-rate command with the local parameter enabled if an explicit value is not desired. When a maximum PIR is in use on the child, the system attempts to interpret the maximum child forwarding rate. This rate could be very large if the child is associated with multiple ingress or egress ports.

Except for the overall cap on the offered input into the virtual scheduler, the child’s administrative PIR has no effect on the calculated sensitivity if an explicit rate is specified.

If the child’s administrative PIR is modified while a percent-based granularity is in effect, the system automatically uses the new relative sensitivity value the next time the child’s offered rate is determined.

The no form of this command is used to restore the default offered rate sensitivity behavior to all child policers and queues associated with the policy.

This command sets a time period that the current offered rate should be maintained for a child policer or queue when it is seen that the offered rate is decreasing. The offered measurement that triggers the hold time is used when the hold timer expires, unless a higher offered rate is seen in the interim. When a higher rate is observed, the hold timer is canceled and the higher offered rate is used immediately.

A possible reason to define a hold timer for an offered rate is to allow a child queue is to dampen the effects of a child with a fluctuating rate on the virtual scheduler. This works similar to the max-decrement in that the child holds on to bandwidth from the virtual scheduler in case it may be needed in the near future.

This parameter has no effect on an increase to the child’s offered rate. If the rate increase is above the change sensitivity, the new offered rate is immediately used.

When this command is not specified or removed, the virtual scheduler immediately reacts to measured decreases in offered load.

The no form of this command is used to remove any currently configured hold time for all child policers and queues associated with the policy. When the hold time is removed, any current hold timers for child policers are automatically canceled.

This command is used to limit how fast a child queue or policer can ‘give up’ bandwidth that it has been allotted from the virtual scheduler in a single iteration. If the child’s new offered rate has decreased by more than the maximum decrement limit, the system ignores the new offered rate and instead uses the old offered rate less the maximum decrement limit.

A possible reason to define a maximum decrement limit is to allow a child queue or policer to hold on to a portion of bandwidth that has been distributed by the parent virtual scheduler in case the child’s offered rate fluctuates in an erratic manor. The max-decrement limit has a dampening effect to changes in the offered rate.

A side effect of using a maximum decrement limit is that unused bandwidth allocated to the child queue or policer will not be given to another child as quickly. This may result in an underrun of the virtual scheduler’s aggregate rate.

The max-decrement limit has no effect on any increase in a child’s offered rate. If the rate increase is above the change sensitivity, the new offered rate is immediately used.

If the max-decrement command is used with a percent-based value, the decrement limit will be a function of the configured PIR value on the policer or queue. In this case, care should be taken that the child is either configured with an explicit PIR rate (other than max) or the child’s administrative PIR is defined using the percent-rate command with the local parameter enabled if an explicit value is not desired. When a maximum PIR is in use on the child, the system attempts to interpret the maximum child forwarding rate. This rate could be very large if the child is associated with multiple ingress or egress ports.

Except for the overall cap on the offered input into the virtual scheduler, the child’s administrative PIR has no effect on the calculated sensitivity if an explicit rate is specified.

If the child’s administrative PIR is modified while a percent based max-decrement is in effect, the system automatically uses the new relative maximum decrement limit value the next time the child’s offered rate is determined.

When the max-decrement command is not specified or removed, the virtual scheduler does not limit a decreasing offered rate to a specific limit.

The no form of this command is used to remove any currently configured maximum decrement limit for all child policers and queues associated with the policy.

This command is used to define the number of intervening sample periods before a new offered rate is measured and is only applicable when the policy is applied to a policer. By decreasing the sampling interval, the system will measure a child’s new offered rate more frequently. Inversely, increasing the sampling interval causes the child’s offered rate to be measured less frequently.

The overall number of offered rate measurements the system attempts within a given timeframe is not affected by the sample-interval command. If the system is asked to perform offered rate measurements more often on some policers, it will take longer to get to all children.

When this command is not specified or removed, the system evaluates the offered rate of each child after 1 sampling period.

The no form of this command is used to restore the sampling interval default of 1 sample period.

This command is used to weight the new offered rate with a portion of the previous offered rate. It would be expected that this command would mainly be used with the dec-only option enabled.

The adjustment to the offered rate is performed using the following formula when taf-value is not set to ‘0’:

Adjusted_Rate = ((Prev_Offered_Rate x (taf-value – 1)) + New_Offered_Rate) / taf-value

If the dec-only option is specified, the adjustment is only applied when New_Offered_Rate is less than the Prev_Offered_Rate. When taf-value is set to ‘0’, the adjustment is never applied.

The no form of this command is used to remove the time average factor adjustments to new offered rate measurements.

This command copies existing QoS policy entries for a QoS policy-id to another QoS policy-id.

The copy command is a configuration-level maintenance tool used to create new policies using existing policies. It also allows bulk modifications to an existing policy with the use of the overwrite keyword.

This command displays advanced QoS policy information.