ON THIS PAGE
 

Latency-Based ECN

When you enable latency-based ECN, ECN marking is driven by per-packet queuing delay instead of, or in place of, traditional buffer-occupancy-based ECN. The Packet Forwarding Engine (PFE) measures instantaneous latency as the difference between ingress and egress pipeline timestamps and, when this latency exceeds a configured threshold, it marks the packet as congestion-experienced through ECN. On supported platforms, you can configure latency-based ECN as a scheduler attribute, with a unique latency threshold for each scheduler, and apply it through scheduler maps to supported physical Layer 3 interfaces, using a limited set of reusable latency profiles. On other supported platforms, you can define a global latency threshold and enable latency-based ECN on a per queue or per scheduler basis.

Understanding Latency-Based ECN for Class-of-Service Schedulers

Latency-based ECN operates on unicast traffic only, is color-blind with respect to drop precedence, and is mutually exclusive with buffer-based ECN on any given port and queue pair. By aligning congestion signaling directly with acceptable queuing delay for each traffic class, you maintain integration with existing CoS scheduling and drop-profile behavior while expressing congestion tolerance in terms meaningful to latency-sensitive applications.

Benefits of Latency-Based ECN for Class-of-Service Schedulers

  • Aligns congestion signaling with actual queuing delay, so ECN marks reflect the latency that applications experience rather than indirect indicators such as buffer occupancy.

  • Helps you limit queuing delay for sensitive traffic by marking packets as soon as latency exceeds the configured threshold, enabling upstream congestion control to react before delay becomes excessive.

  • Simplifies congestion behavior across drop precedences by using a color-blind model, so all packets in a queue are treated consistently regardless of loss priority.

  • Encourages a clear separation from buffer-based ECN, reducing configuration conflicts and misconfiguration risk on each port and queue.

Overview

When you enable latency-based ECN, the PFE measures per-packet queuing delay by subtracting the ingress pipeline timestamp from the egress pipeline timestamp and compares the result to a configured latency threshold. If the instantaneous latency for a unicast packet exceeds that threshold, the egress pipeline sets an internal congestion indicator that the system maps to ECN bits in the IP header. Because this decision occurs in the scheduler pipeline and uses a color-blind model, all packets in the queue, regardless of drop precedence or loss priority, use the same deterministic latency trigger for ECN marking.

Latency-based ECN operates independently of buffer-based ECN, but you must treat it as an alternative ECN mode on any given port and queue pair. If you configure latency ECN for a queue, you must not enable buffer-based ECN on that same queue. Commit-time validation rejects any configuration that attempts to combine both mechanisms. latency-based ECN applies only to unicast traffic on supported physical Layer 3 interfaces; it does not mark multicast, broadcast, unknown unicast, and multicast (BUM), or EVPN-VXLAN traffic. You also cannot configure latency-based ECN on aggregated Ethernet (AE) child interfaces.

Configure and Verify Latency-based ECN with a Per-Scheduler Latency Threshold

You enable latency-based ECN at the scheduler level by entering configuration mode and setting a latency threshold under the desired scheduler. You then reference this scheduler in a scheduler-map entry for the appropriate forwarding class and apply the scheduler map to a physical Layer 3 interface with standard CoS configuration. This method allows you to express congestion tolerance per traffic class in nanoseconds, making it easier to translate application latency requirements into concrete, per-queue thresholds.

You configure latency-based ECN as a scheduler attribute and then bind that scheduler to forwarding classes through scheduler maps, which you apply to supported physical Layer 3 interfaces. At the configuration hierarchy, you define a latency threshold in nanoseconds, from 1-1000000000 (1ns-1s), under a scheduler with the command:

The scheduler map associates that scheduler with specific forwarding classes, with the forwarding classes mapped to specific queues. When you apply the scheduler map to an interface, the hardware programs the corresponding per-queue latency profile. Because the underlying silicon supports only a limited number of distinct latency profiles, you typically reuse the same threshold values across multiple queues and interfaces to stay within the practical limit of seven unique latency-based ECN profiles.

Note:

This configuration is valid only if every queue that enables latency-based ECN has an explicit threshold, the number of distinct threshold values stays within hardware limits, and no overlapping buffer-based ECN configuration exists on the same port and queue. Otherwise, the commit fails and prompts you to correct the conflict.
  1. Enable latency-based ECN at the scheduler level by setting a latency threshold under the desired scheduler, for example:
    This sets a latency threshold of 50 microseconds for the sched1 scheduler.
  2. Reference this scheduler in a scheduler-map entry for the appropriate forwarding class, for example:
  3. Map the forwarding class to the desired queue, for example:
  4. Apply the scheduler map to a physical Layer 3 interface with standard CoS configuration, for example:

To confirm behavior, run the show class-of-service scheduler-map command. For example:

Use the show class-of-service scheduler-map index index-valuecommand to inspect each queue’s configuration, including the latency-based ECN threshold field, which reports the threshold in nanoseconds alongside traditional ECN and drop-profile settings. For example:

Configure and Verify Latency-based ECN with a Global Latency Threshold

You enable latency-based ECN at the global level by entering configuration mode and setting a latency threshold under class of service options. You then enable latency-based ECN on specific queues and/or schedulers.

  1. Enable packet latency tracking in the hardware. This allows you to track per-output queue latency data.
    Note:

    Enabling latency tracking does not automatically enable latency-based ECN marking.
  2. Configure the global latency threshold to indicate network congestion for ECN packets, in microseconds from 1-100,000, for example:

    In this example, if the ingress to egress latency for an ECN-capable packet exceed 28 microseconds, the packet is marked as congestion experienced (CE).

  3. (Optional) Enable latency ECN on a particular queue, for example:
    In this example, the device can mark packets as ECN on queue 0 when the latency threshold is exceeded.
  4. (Optional) Enable latency ECN on a particular scheduler, for example
    Note:

    If you configure latency-ecn on a scheduler in a scheduler map, you must also configure latency-ecn on the corresponding forwarding class.
    In this example, the device can mark packets as ECN on any egress interface that has scheduler sched1 applied to it.

To confirm behavior, run the show class-of-service options command. For example:

Use the show class-of-service forwarding-classcommand to show which forwarding classes and queues you've enabled latency-based ECN on. For example:

Use the show class-of-service scheduler-map scheduler-map-namecommand to show which schedulers you've enabled latency-based ECN on. For example:

Platform-Specific Latency-Based ECN Behavior

Use the following table to review platform-specific behaviors for your platforms.

Table 1: Platform-Specific Behavior

Platform

Difference

PTX10002-36QDD, PTX10002-60MR, PTX10004, PTX10008, and PTX12008

PTX10002-36QDD, PTX10002-60MR, PTX10004, PTX10008, and PTX12008 routers support defining a global latency threshold and enabling latency-based ECN on a per queue or per scheduler basis.

QFX 5240 Series

Starting with Junos OS Evolved Release 25.2X100-D20, QFX 5240 Series support defining a unique per scheduler (i.e., per port) latency threshold when configuring latency-based ECN.

Related Documentation