Queue templates configuration

Queue templates are groups of configuration information that apply to a set of queues. On 7250 IXR systems, the controlled set of queues are VOQs; on 7220 IXR-D2/D2L, D3/D3L, D4, and D5 or 7220 IXR-H2, H3, and H4 systems, the controlled set of queues are egress queues.

The maximum number of queue templates per system varies by platform. On 7250 IXR systems, the maximum is eight queue templates; on 7220 IXR-D2/D2L, D3/D3L, D4, and D5 or 7220 IXR-H2, H3, and H4 systems, the maximum is 62 queue templates.

The following parameters are configurable inside a queue template:

The MBS of each queue; this essentially defines the length of each queue. When the queue builds to the MBS level, further packets are dropped. Be aware that discards may occur before the queue reaches MBS (for example, resulting from shared buffer exhaustion, or from the effects of WRED slopes defined for the queue).
WRED slopes that define probability curves for discarding packets as a function of weighted average queue depth. WRED slopes are not supported for multicast queues.
ECN slopes that define probability curves for marking ECN-capable packets as having experienced congestion, instead of discarding them. ECN slopes are not supported for multicast queues.

If a VOQ or egress queue does not have a queue template binding, it inherits the settings of the default queue template. The default queue template has a platform-specific MBS default value, no defined queue utilization thresholds, no WRED slopes, and no ECN slopes. You cannot display the default queue template, but its effect is visible by reading the state of individual queues that lack a queue template binding.

Configuring queue templates

To create a queue template, use the qos queue-templates queue-template command. You can then define the parameters for the queue-template as described in the following sections.

The following example creates a queue template that you could use for any of the following:

a set of VOQs on a 7250 IXR
an egress queue on a 7220 IXR-D2/D2L, D3/D3L, D4, and D5
an egress queue on a 7220 IXR-H2, H3, and H4


--{ candidate shared default }--[  ]--
# info qos  
    qos {
        queue-templates {
            queue-template wred-ecn-1 {
            }
        }
    }

Note: This example is only the starting point of a full configuration. Subsequent sections build on this example to create a full configuration.

Queue depth (maximum burst size)

In a queue-template, the maximum-burst-size parameter sets the maximum length of an egress queue or set of VOQs. The queue depth is also known as the MBS. You must set the maximum-burst-size parameter to a nonzero value to configure WRED slope and ECN slope parameters.

On the 7250 IXR, the maximum-burst-size parameter applies to a set of VOQs. If the parameter is not configured, or is set to 0, the effective MBS of these VOQs is 256 MB.

On the 7220 IXR-D2/D2L, D3/D3L, D4, and D5 or the 7220 IXR-H2, H3, and H4, the maximum-burst-size parameter applies to a set of egress queues. If the parameter is not configured or is set to 0, the effective MBS of these egress queues is calculated based on a fair allocation algorithm. You can assign a nonzero MBS value to multicast queues, but Nokia does not recommend this configuration (especially if multicast traffic is being shaped by configuring peak-rate-percent), because it can lead to a shortage of multicast-related buffering resources on 7220 IXR-D2/D2L, D3/D3L, D4, and D5 or 7220 IXR-H2, H3, and H4 systems.

Configuring queue depth (maximum burst size)

To configure the queue depth within a queue template, set a value for the MBS using the queue-depth maximum-burst-size command.

The following example specifies the queue depth with a set maximum-burst-size:

--{ candidate shared default }--[  ]--
# info qos queue-templates 
    qos {
        queue-templates {
            queue-template wred-ecn-1 {
                queue-depth {
                    maximum-burst-size 20
                }
            }
        }
    }

WRED slope

In a queue template, you can configure WRED policies to handle congestion when queue space is depleted. Without WRED, when a queue reaches its maximum fill size, the queue discards any packets arriving at the queue (known as tail drop).

WRED policies manage queue depth. They help to prevent congestion by starting random discards when the queue reaches a user-configured threshold value. This behavior avoids the impact of discarding all the new incoming packets. By starting random discards at this threshold, an end system can adjust its sending rate to the available bandwidth.

The WRED curve algorithm is based on two user-configurable thresholds (min-threshold-percent and max-threshold-percent) and a discard probability factor (max-probability).

On the 7220 IXR-D2/D2L, D3/D3L, D4, and D5 or the 7220 IXR-H2, H3, and H4, you can configure a WRED slope to apply only to TCP or to non-TCP traffic. This configuration can be useful because TCP has built-in mechanisms to adjust its sending rate in response to packet drops. TCP-based senders lower the packet transmission rate when some of the packets fail to reach the far end.

Configuring a WRED slope (7250 IXR)

On the 7250 IXR, to configure a WRED slope within a queue template, use the active-queue-management wred-slope command to configure the following:

the type of traffic that the WRED slope applies to (must be set to all, indicating both TCP and non-TCP traffic)
the drop-probability that the WRED slope applies to
the min-threshold, max-threshold, and max-probability WRED values

The following example specifies a WRED slope for low drop probability traffic flowing through a set of VOQs on a 7250 IXR. This WRED slope applies to both TCP and non-TCP traffic.

--{ * candidate shared default }--[  ]--
# info qos
    qos {
        queue-templates {
            queue-template wred-ecn-1 {
                active-queue-management {
                    wred-slope all drop-probability low {
                        min-threshold-percent 10
                        max-threshold-percent 25
                        max-probability 50
                    }
                }
            }
        }
    }

Configuring a WRED slope (7220 IXR)

On the 7220 IXR, to configure a WRED slope within a queue template, use the active-queue-management wred-slope command to configure the following:

the type of traffic that the WRED slope applies to: tcp or non-tcp
the drop-probability that the WRED slope applies to
the min-threshold, max-threshold, and max-probability WRED values

The following example specifies a WRED slope for TCP traffic that is classified as low drop probability flowing through an egress queue on the 7220 IXR-D2/D2L, D3/D3L, D4, and D5 or the 7220 IXR-H2, H3, and H4.

--{ * candidate shared default }--[  ]--
# info qos
    qos {
        queue-templates {
            queue-template wred-ecn-1 {
                active-queue-management {
                    wred-slope tcp drop-probability low {
                        min-threshold-percent 10
                        max-threshold-percent 25
                        max-probability 50
                    }
                }
            }
        }
    }

ECN slope

Some IP applications support the ECN mechanism. With ECN, IP packets originated by such applications are not discarded when they enter a congested queue; instead, they are marked in a special way. The marking uses the two ECN bits in the traffic class field of the IPv4 or IPv6 packet header. The receiver of IP packets marked as having experienced congestion can signal to the sender (through Layer 4 or higher protocols) that it should reduce its sending rate. The advantage of this feedback mechanism is that the sending rate can drop more gradually than the normal response of a TCP sender to packet discards. A more gradual back-off can result in higher effective throughput in the network.

An ECN slope is similar to a WRED slope. It is based on two user-configurable thresholds (min-threshold-percent and max-threshold-percent) and a marking probability factor (max-probability).

To use an ECN slope, you must configure explicit-congestion-notification.

Configuring an ECN slope (7250 IXR)

On 7250 IXR systems, the configuration requires you to specify an ECN DSCP policy; this is the DSCP rewrite policy that is used when an ECN field rewrite must be performed. In addition, you can only have one ECN slope per queue that applies to all drop-probability levels.

To configure an ECN slope:

In the explicit-congestion-notification context, specify the DSCP policy to use when ECN rewrite is enabled.
In the queue-template context:
- Create one entry applicable to all drop-probabilities using the active-queue-management ecn-slope command.
- Within that entry, set the desired ECN values ( min-threshold-percent, max-threshold-percent, and max-probability) using the active-queue-management ecn-slope command.

The following example specifies an ECN slope applicable to a 7250 IXR system:

--{ candidate shared default }--[  ]--
# info qos    
    qos {
        explicit-congestion-notification {
            ecn-dscp-policy normalize
        }
        queue-templates {
            queue-template wred-ecn-1 {
                queue-depth {
                    maximum-burst-size 20000
                }
                active-queue-management {
                    ecn-slope all {
                        min-threshold-percent 50
                        max-threshold-percent 50
                        max-probability 100
                    }
                }
            }
        }

Configuring an ECN slope (7220 IXR)

On the 7220 IXR-D2/D2L, D3/D3L, D4, and D5 or the 7220 IXR-H2, H3, and H4, you can have one ECN slope per drop-probability level of traffic flowing through an egress queue.

To configure an ECN slope:

Enable ECN using the explicit-congestion-notification command.
In the queue-template context:
- Create one entry per drop-probability using the active-queue-management ecn-slope command.
- Within that entry, set the desired ECN values (min-threshold-percent, max-threshold-percent, and max-probability) using the active-queue-management ecn-slope command.

The following example specifies an ECN slope applicable to a 7220 IXR-D2/D2L, D3/D3L, D4, and D5 or 7220 IXR-H2, H3, and H4 system:

--{ candidate shared default }--[  ]--
# info qos                                                                
    qos {
        explicit-congestion-notification {
        }
        queue-templates {
            queue-template 2 {
                queue-depth {
                    maximum-burst-size 100
                }
                active-queue-management {
                    ecn-slope high {
                        min-threshold-percent 0
                        max-threshold-percent 80
                        max-probability 90
                    }
                }
            }
        }
    }

Queue utilization thresholds

When a router receives a burst of traffic, and the incoming rate exceeds the available transmission rate, the router queues the excess traffic. If the burst lasts long enough, or it is followed by additional bursts, the queues may overflow, resulting in traffic loss.

To respond to onsets of congestion, you can subscribe to telemetry information that generates an event when specific queues exceed a specified occupancy level.

To assign a utilization threshold to a queue, you must apply a non-default queue template to the queue, and that queue template must specify a nonzero high-threshold-bytes value. When the utilization of the queue crosses the specified high-threshold-bytes value, a hardware interrupt is raised. The Nokia eXtensible Data Path (XDP) records the current system-time and clears the interrupt. In a scaled setup, XDP may take 10 to 15 ms to process and clear each interrupt, meaning multiple threshold crossings within a very short period of time across one or more queues using the same queue template may appear as only a single event in the telemetry stream. When the high-threshold-bytes value is 0, the functionality is disabled and no threshold events are generated for the queues covered by the queue template.

SR Linux supports queue utilization thresholds on 7250 IXR, 7220 IXR-D2/D2L and D3/D3L, and 7220 IXR-H2 and H3 systems; however, the behavior varies by system.

Note: You can only configure queue utilization thresholds for unicast queues; multicast queues do not support queue utilization thresholds.

Configuring queue utilization thresholds on 7250 IXR systems

On a 7250 IXR system, bind a queue template with a nonzero high-threshold-bytes value to an egress queue to assign that threshold value to all the VOQs that logically feed this egress queue.

You can configure each queue template that the system supports with a different high-threshold-bytes value as needed.

Configuring high-threshold-bytes

The following example configures the high-threshold-bytes value to 256255:

--{ candidate shared default }--[  ]--                              
# qos queue-templates queue-template 2 queue-depth high-threshold-bytes 256255 
--{ candidate shared default }--[  ]--                              
# commit stay 
All changes have been committed. Starting new transaction.

Each configured threshold value is rounded up to the nearest multiple of 256 bytes, up to a maximum capped value of MBS. You can observe the rounding (on a per VOQ-set basis) using the info from state interface qos output queue-statistics queue <queue-name> virtual-output-queue queue-depth output. (A VOQ-set consists of the VOQ for core 0 and the VOQ for core 1.)

Rounding high-threshold-bytes

In the following example, the high-threshold-bytes value was configured to 256255, but is rounded to the lower 256000 value (that is, a multiple of 256 bytes):

--{ candidate shared default }--[  ]--                              
# info from state interface ethernet-2/1 qos output queue-statistics queue unicast-0 virtual-output-queue 1 queue-depth
    interface ethernet-2/1 {
        qos {
            output {
                queue-statistics {
                    queue unicast-0 {
                        virtual-output-queue 1{
                            queue-depth {
                                maximum-burst-size 1203200768
                                high-threshold-bytes 256000
                            }
                        }
                    }
                }
            }
        }
    }

Note: To support named queues, the unicast-queue 0 parameter previously included in this example (in R22.6 and earlier) is updated to queue unicast-0 (in R22.11 and later).

The state tree maintains the time of the last threshold crossing in the interface qos output queue-statistics queue virtual-output-queue queue-depth leaf. This value represents the last time when either VOQ in the VOQ-set (core0/core1) exceeded the operational threshold. The value of this leaf is not cleared when you delete or modify the queue template that is bound to the queue/VOQs or the high-threshold-bytes configuration in the applied queue template.

Configuring queue utilization thresholds on 7220 IXR-D2/D2L and D3/D3L systems

On 7220 IXR-D2/D2L and D3/D3L systems, bind a queue template with a nonzero high-threshold-bytes value to an egress queue to assign that threshold value for that specific queue, as long as it is a unicast queue. The configuration of this leaf is ignored when this queue template is attached to a multicast queue.

No more than seven different configured high-threshold-bytes values are allowed across all the queue templates used. The management server rejects a commit that would leave more than seven different values after all adds, deletes, and modifies are processed.

Configuring high-threshold-bytes

The following example configures the high-threshold-bytes value to 2048999:

--{ candidate shared default }--[  ]--                                        
# qos queue-templates queue-template 2 queue-depth maximum-burst-size 2049024
 high-threshold-bytes 2048999 
--{ candidate shared default }--[  ]--                              
# commit stay 
All changes have been committed. Starting new transaction.

Each configured threshold value (that the management server accepts) is rounded up to the nearest multiple of 2048 bytes, up to a maximum capped value of MBS. For this reason, do not configure values that round to the same multiple of 2048 bytes. This configuration causes duplication among the high-threshold-bytes values, of which only seven are allowed. You can display the effect of this rounding using the info from state interface qos output unicast-queue queue-depth command.

Rounding high-threshold-bytes

In the following example, the high-threshold-bytes value was configured to 2048999, but is rounded to a lower 2048000 value (that is, a multiple of 2048 bytes):

--{ candidate shared default }--[  ]--                                       
# info from state interface ethernet-1/3 qos output unicast-queue 0 queue-
depth                                                                           
    interface ethernet-1/3 {
        qos {
            output {
                unicast-queue 0 {
                    queue-depth {
                        maximum-burst-size 2049024
                        high-threshold-bytes 2048000
                    }
                }
            }
        }
    }

The state tree maintains the time of the last threshold crossing in the interface qos output unicast-queue queue-depth last-high-threshold-time leaf. This value represents the last time the queue exceeded the operational threshold. The value of this leaf is not cleared when you delete or modify the queue template that is bound to the queue or the high-threshold-bytes configuration in the applied queue-template.

Configuring queue utilization thresholds on 7220 IXR-H2 and H3 systems

On 7220 IXR-H2 and H3 systems, bind a queue template with a nonzero high-threshold-bytes value to an egress queue to assign that threshold value to be used by each ITM that serves the queue. For a high-threshold event, the queue utilization threshold must be exceeded on either ITM.

Configuring high-threshold-bytes

The following example configures the high-threshold-bytes value to 254255:

--{ candidate shared default }--[  ]--                                        
# qos queue-templates queue-template 2 queue-depth maximum-burst-size 2049024
 high-threshold-bytes 254255 
--{ candidate shared default }--[  ]--                              
# commit stay 
All changes have been committed. Starting new transaction.

Each configured threshold value (that the management server accepts) is rounded up to the nearest multiple of 254 bytes, up to a maximum capped value of MBS. For this reason, do not configure values that round to the same multiple of 254 bytes. This configuration causes duplication among the high-threshold-bytes values, of which only seven are allowed. You can display the effect of this rounding using the info from state interface qos output unicast-queue queue-depth command.

Rounding high-threshold-bytes

In the following example, the high-threshold-bytes value was configured to 254255, but is rounded to a lower 254000 value (that is, a multiple of 254 bytes):

--{ candidate shared default }--[  ]--                                       
# info from state interface ethernet-1/3 qos output unicast-queue 0 queue-
depth                                                                           
    interface ethernet-1/3 {
        qos {
            output {
                unicast-queue 0 {
                    queue-depth {
                        maximum-burst-size 2049024
                        high-threshold-bytes 254000
                    }
                }
            }
        }
    }

The state tree maintains the time of the last threshold crossing in the interface qos output unicast-queue queue-depth last-high-threshold-time leaf. This value represents the last time when either ITM exceeded the operational threshold. The value of this leaf is not cleared when you modify or delete the queue-template that is bound to the queue or the high-threshold-bytes configuration in the applied queue-template.