Juniper: CoS Schedulers

Schedulers is certainly one of the most important component of Quality of Service (QoS) on Juniper Junos. Schedulers defines the queue parameters your traffic will be subject to. Each queues can receives different scheduling parameters thus allowing for service differentiation.

On most Juniper platforms, including MX series, queues are serviced using the priority-queue deficit weighted round-robing (PQ-DWRR) algorithm. This algorithm provides queue prioritization, which means that all queues have a priority and they are all serviced accordingly; higher priority queues are serviced first. The deficit part of the algorithm's name steam from the fact a queue is allowed for some negative credits; credits which are later reported to the next time the queue is serviced. This allow for some transmission rate optimization at the queue level. On some Juniper platforms, in particular MX series, packets are serviced in a round-robin fashion as soon as they're in-profile. Out-of-profile traffic at the other side, is serviced using Weighted Round-Robin (WRR). WRR add a weight to the round-robin distribution, which means it de-queue packets proportionally to the weight, the latter being based on the transmission rate configured.

A scheduler in Junos, is made of the following components:

  • Transmission Rate
  • Queue Priority
  • Delay Buffer
  • RED Drop Profiles
Transmission Rate

The transmission rate is the amount of bandwidth allocated to a queue. It's similar to a Committed Information Rate (CIR). When the traffic is below the configured rate, the traffic is said to be 'in-profile', when it exceeds the allocated amount, the traffic is said to be 'out-of-profile'. You can configure the transmission rate using a fixed rate in bits per second (bps), using a relative percentage of the total interface's bandwidth, or using the remaining available bandwidth (or remainder). You can also turn the transmit-rate function as a queue policer or shaper using respectively the 'exact' and 'rate-limit' knobs. By default, queues can exceed their transmission rate if unused, free interface bandwidth exists.

Queue Priority

The queue priority defines the order in which queues are serviced. Queues with higher priority are serviced first by the scheduling disciplines. There's five software priorities, namely strict-high, high, medium-high, medium-low, and low. Strict-High is a special, low-latency priority queue or LLQ, which is always serviced before any other queue. Traffic flowing inside this queue is always considered as in-profile and can use up to the full interface's bandwidth. Lower priority queue can only be serviced when the strict-high queue has been emptied, therefore it can easily starve lower-priority traffic. It's recommended to add the transmit-rate's rate-limit option to the strict-high queue to prevent it from consuming the entire interface bandwidth and to ensure reasonable servicing delays.

Delay Buffer

The buffer determines the amount of data that can be stored or buffered when congestion occurs in a queue. All queues share the hardware buffer of the port they belong to. The port's buffer size varies by platforms (usually in the 50ms to 200ms range depending of FPC/PIC/MIC combination). The larger the buffer, the more the data can be stored and thus the larger is the latency. The buffer is somehow a trade-off between the amount of data that you do not want to drop while congestion occurs, and the amount of time you want to delay that traffic. For delay-sensitive traffic like SSH, you may want to keep that delay as short as possible. You can configure the delay buffer using a fixed temporal value, using a percentage relative to the port's available buffer, or using the remaining available (un-allocated) buffer.

RED Drop Profiles

Random Early Detection (RED) is certainly one of the most commonly used congestion avoidance algorithm. RED is basically a dual-threshold mechanism. One threshold is the queue or buffer fullness, the other is the drop probability (or likelihood a packet will be dropped). RED assigns to every packets a random value between 0 and 100. When a packet reach the head of a queue, it is plotted against the corresponding drop profile of the scheduler it belong to, using the fullness level of the queue. By example, if the random number assigned to the packet falls below the drop probability in relation to the current fullness level of the buffer, the packet is dropped. WRED is essentially a weighted version of RED, where some traffic are given more importance than other according to their specific drop profiles. RED has been developed to mitigate TCP global synchronization. TCP Global synchronization is an effect or phenomenon when multiple concurrent TCP sessions are increasing and reducing their transmission rates in unison. It create recurring periods of congestion and periods where bandwidth is mostly left underutilized. This is happening because each TCP sessions are affected by packet drops at the same time, and the TCP congestion algorithms effectively uses the packets drops as a criteria to slow down traffic rate. To specify drop parameters, you must create what is called a drop-profile. The drop-profile is essentially a collection of key, value parameters, where the key is the fullness level of the buffer/queue and the value is the drop probability. In Junos, you can choose among two type of drop-profile, namely 'segmented', which's the default and 'interpolate'. In contrast to the segmented type, the interpolated drop-profile use a mechanism to linearly graduate the values between two configured data-points or thresholds.

Segmented & Interpolated RED Drop Profiles

Best Practice

The delay buffer and the transmission rate are two independent and unrelated parameters, however the general best practice is to match their values so they are proportionate to each other. By example, if you allocate 50% of the interface's bandwidth for a given scheduler, you may as well allocate 50% of the total port's buffer. It ensures you've enough bandwidth and buffer to accommodate most traffic flows.

Configuring & Applying CoS Schedulers

To configure and apply a CoS Scheduler in Junos, perform the steps outlined below:

  1. Enter the 'class-of-service' hierarchy and create a scheduler:
    [edit class-of-service]
    user@host# set schedulers be-scheduler
  2. Configure the Transmission Rate
    user@host# set schedulers be-scheduler transmit-rate percent 40
  3. Configure the Delay Buffer
    user@host# set schedulers be-scheduler buffer-size percent 40
  4. Configure the Scheduler Priority
    user@host# set schedulers be-scheduler priority low
  5. Create the RED Drop Profile
    user@host# set drop-profiles be-aggressive interpolate fill-level 50 drop-probability 20 
    user@host# set drop-profiles be-aggressive interpolate fill-level 75 drop-probability 40
    user@host# set drop-profiles be-aggressive interpolate fill-level 100 drop-probability 100
  6. Reference the RED Drop Profile in the Scheduler
    user@host# set schedulers be-scheduler drop-profile-map loss-priority any protocol non-tcp drop-profile be-aggressive
  7. Create a Scheduler Map
    user@host# set scheduler-maps diffserv-cos-map forwarding-class best-effort scheduler be-scheduler
  8. Bind the Scheduler Map to logical interface(s)
    user@host# set interfaces fe-1/3/0 scheduler-map diffserv-cos-map
    user@host# set interfaces fe-1/3/1 scheduler-map diffserv-cos-map

The diagram below outlines the relation between the Junos CoS configuration elements.

Juniper CoS Configuration Diagram
user@host# show 
drop-profiles {
    be-aggressive {
        interpolate {
            fill-level [ 50 75 100 ];
            drop-probability [ 20 40 100 ];
interfaces {
    fe-1/3/0 {
        scheduler-map diffserv-cos-map;
    fe-1/3/1 {
        scheduler-map diffserv-cos-map;
scheduler-maps {
    diffserv-cos-map {
        forwarding-class best-effort scheduler be-scheduler;
schedulers {
    be-scheduler {
        transmit-rate percent 40;
        buffer-size percent 40;
        priority low;
        drop-profile-map loss-priority any protocol non-tcp drop-profile be-aggressive;
Verifying Schedulers Configuration
  • To verify the RED Drop Profile configuration use the show class-of-service drop-profile <profile-name> command.
  • To verify the Scheduler Map configuration use the show class-of-service scheduler-map <name> command.
    user@host> show class-of-service scheduler-map diffserv-cos-map 
    Scheduler map: diffserv-cos-map, Index: 29844
      Scheduler: be-scheduler, Forwarding class: best-effort, Index: 4154
        Transmit rate: 40 percent, Rate Limit: none, Buffer size: 40 percent, Buffer Limit: none, Priority: low
        Excess Priority: unspecified
        Drop profiles:
          Loss priority   Protocol    Index    Name
          Low             non-TCP     12727    be-aggressive               
          Low             TCP             1    <default-drop-profile>      
          High            non-TCP     12727    be-aggressive               
          High            TCP             1    <default-drop-profile>     

The schedulers configuration is relatively straightforward, although it may seem a bit confusing at first. I hope this article helped you to demystify a little bit of the Junos CoS configuration, and for those who have already worked with it, that it helped you to review your knowledge.

About the author Nicolas Chabbey

Nicolas Chabbey is a Network Engineer certified with Cisco Systems and Juniper Networks. He has begun his career in 2003, and has designed, implemented and maintained networks for enterprises and service providers. When he is not behind a computer, he is riding his mountain bike across the Swiss alps.

Previous Home Next


blog comments powered by Disqus