Fact-checked by Grok 2 weeks ago

Weighted random early detection

Weighted Random Early Detection (WRED) is a congestion avoidance mechanism employed in network routers and switches to proactively manage queue overflows by probabilistically discarding packets before buffers become full, with drop decisions weighted according to the packet's priority as indicated by IP precedence or Differentiated Services Code Point (DSCP) values. This approach extends the foundational Random Early Detection (RED) algorithm, which uniformly applies random drops to prevent the inefficiencies of tail-drop queuing, such as global TCP synchronization and unfair bandwidth allocation. By integrating quality-of-service (QoS) markings, WRED ensures preferential treatment for higher-priority traffic, such as voice or critical data, while more aggressively dropping lower-priority packets during congestion. The core operation of WRED relies on monitoring the average depth using an exponential weighted moving average (EWMA), typically with a low weight factor (e.g., 1/512) to smooth out short-term bursts while responding to sustained congestion trends. For each arriving packet, WRED compares the average size against configurable minimum and maximum specific to the packet's precedence or DSCP level; if the average falls between these , the drop probability increases linearly from zero to a maximum value (e.g., 1/10), scaled by the precedence to favor higher —for instance, precedence 0 packets face stricter than precedence 7. Above the maximum , all packets of that are dropped, while non-IP or unmarked defaults to the lowest priority treatment. This weighted mechanism aligns with (DiffServ) architectures, where edge devices classify and mark packets to enable core network devices to enforce per- policies. WRED's benefits include improved fairness for responsive protocols like , reduced and for applications, and enhanced overall network utilization by avoiding and lockout phenomena common in simple queues. However, its effectiveness diminishes with non-responsive traffic (e.g., floods), necessitating complementary techniques like policing or . Widely implemented in enterprise and service provider routers since the mid-1990s, WRED supports scalable QoS in IP networks, though tuning parameters like thresholds and probabilities requires careful consideration of link speed, size, and traffic mix to balance drop rates across classes.

Overview

Definition and Purpose

Weighted Random Early Detection (WRED) is a queueing discipline designed for schedulers to manage avoidance, extending the foundational Random Early Detection (RED) mechanism by incorporating weights based on packet precedence or (). This allows routers to apply varying drop thresholds and probabilities to different traffic classes, thereby prioritizing higher-importance packets over lower-priority ones during periods of increasing . The primary purpose of WRED is to mitigate the effects of tail-drop queueing by proactively dropping packets before buffers reach full capacity, leveraging 's inherent control to signal senders to reduce transmission rates. This helps prevent global synchronization, where multiple flows simultaneously slow down and speed up, leading to inefficient network utilization. Additionally, WRED enables (QoS) differentiation by selectively targeting low-precedence traffic for earlier drops, ensuring that critical applications experience minimal disruption even as builds. At its , WRED seeks to promote fairness across diverse flows by avoiding toward aggressive or late-arriving connections, while reducing and for high-priority through targeted signaling. It achieves enhanced overall network efficiency without the overhead of maintaining per-flow state information, making it suitable for routers handling mixed volumes. These objectives align with broader goals of maintaining low delay and high throughput in packet-switched networks.

Historical Background

Random Early Detection (RED), the foundational algorithm for Weighted Random Early Detection (WRED), was developed in 1993 by Sally Floyd and at . The primary motivation was to mitigate global synchronization of connections in congested routers, where traditional tail-drop mechanisms caused multiple flows to reduce their transmission rates simultaneously, leading to inefficient network utilization. By probabilistically dropping packets early based on average queue size, RED aimed to signal congestion gently and distribute drops fairly across flows, thereby improving overall throughput and reducing bias against bursty traffic. WRED emerged in the late as a Cisco Systems extension of , designed to incorporate (QoS) differentiation by weighting drop probabilities according to IP precedence levels outlined in 1812. This adaptation allowed routers to preferentially protect higher-precedence traffic, such as that marked for expedited forwarding, while more aggressively dropping lower-precedence packets during . The development aligned with the growing adoption of (DiffServ) frameworks, enabling class-based QoS in IP networks. The key drivers for WRED's creation stemmed from the explosive growth of the in the mid-to-late , which strained best-effort networks and highlighted the need for prioritized handling of emerging applications like and video traffic over traditional data flows in enterprise and ISP environments. During this period, annual growth rates approached 100%, necessitating mechanisms for class-based to maintain for latency-sensitive services without overprovisioning . WRED's weighted dropping facilitated this by assigning lower probabilities to critical traffic classes, supporting the transition to multimedia-rich networks. WRED was integrated into software with Release 11.1 CC in 1996, marking its practical deployment in commercial routers. Concurrently, the (IETF) advanced related concepts in 2309, which recommended techniques like RED and suggested adaptations—such as varying parameters by traffic class—for environments requiring differentiated drop preferences, influencing WRED's standardization and broader adoption.

Core Mechanism

Relation to Random Early Detection

Weighted Random Early Detection (WRED) builds upon the foundational principles of , an algorithm designed to mitigate proactively. Both mechanisms employ probabilistic early packet dropping based on the estimated average queue length to signal sources to reduce their transmission rates before buffers overflow, thereby preventing global synchronization and maintaining low latency. This shared approach contrasts with tail-drop policies, which drop packets only when queues are full, leading to inefficient bursty behavior. RED was originally proposed by Sally Floyd and in 1993 as a class-agnostic primarily for best-effort traffic. In , all incoming packets are treated uniformly, with a single set of minimum and maximum thresholds defining the range where drop probabilities increase linearly from zero to a maximum value, ensuring random but controlled packet discards to avoid against short flows. This uniform application promotes fairness in avoidance but lacks for varied traffic priorities, making it suitable for homogeneous environments without quality-of-service (QoS) requirements. WRED extends RED by introducing weighting based on traffic classification, allowing differential treatment of packets to prioritize higher-importance flows during . Specifically, WRED replaces 's single threshold set with per-class configurations, where each class—defined by precedence values (0-7) or Differentiated Services Code Point (DSCP) markings—has its own minimum and maximum thresholds along with a distinct mark probability denominator. This enables lower-priority packets to be dropped more aggressively while protecting higher-precedence ones, enhancing QoS in diverse networks such as those supporting voice or video alongside data traffic. As a result, WRED addresses 's limitations in heterogeneous environments, providing a scalable mechanism for precedence-aware control.

Average Queue Size Calculation

The average queue size in Weighted Random Early Detection (WRED) is estimated using an exponentially weighted , a mechanism inherited from Random Early Detection () to provide a smoothed measure of queue occupancy. This approach filters out short-term fluctuations caused by bursty traffic, enabling the algorithm to respond to sustained rather than transient spikes. The core formula for updating the average queue size, denoted as \text{avg}, upon the arrival of a packet is: \text{avg} \leftarrow (1 - w_q) \cdot \text{avg} + w_q \cdot q where q is the instantaneous queue size (in packets or bytes), and w_q is the queue weight factor, typically set to a small value such as 0.002 to ensure the low-pass filter has a sufficiently long time constant. This update is performed for every packet arrival, approximating a low-pass filter that weights recent queue sizes exponentially while retaining memory of past states. In many implementations, w_q is expressed as $2^{-n} with n = 9 to $10, yielding values between approximately 0.002 and 0.001, which balances responsiveness to congestion with tolerance for bursts up to 50 packets. The purpose of this averaging is to prevent overreactions to brief buildups, which are common in traffic due to synchronized loss events, thereby promoting fairer sharing among flows. The weight w_q directly influences the filter's , with smaller values (e.g., w_q \geq 0.001) recommended to accommodate larger bursts without premature dropping. Computation occurs in during packet processing, though some variants use periodic timer-based updates for efficiency. For edge cases, the queue size is initialized to 0 at system startup or queue reset, ensuring it builds gradually from an empty . During idle periods when the queue is empty, the decays toward 0 to reflect reduced ; this is handled by raising the previous average to the power of m, where m approximates the number of packets that could have arrived during the idle time (t - q_{\text{time}}), often using \text{avg} \leftarrow \text{avg} \cdot (1 - w_q)^m with m = (t - q_{\text{time}}) / s and s as the average packet transmission time. This adjustment prevents the average from remaining artificially high after temporary idleness. The resulting informs subsequent drop probability decisions in WRED.

Weighted Features

Traffic Classification

Weighted Random Early Detection (WRED) classifies network traffic primarily by inspecting the (ToS) byte in headers, utilizing either IP precedence values ranging from 0 to 7 or Code Point (DSCP) values from 0 to 63. These classifications enable the mapping of packets to specific drop precedence levels, such as low, medium, or high, which determine the aggressiveness of packet discarding during congestion. For instance, in DiffServ-compliant implementations, DSCP values like those in Assured Forwarding (AF) classes are assigned to these levels, where AFxy denotes class x (1-4) and drop precedence y (1 for low, 2 for medium, 3 for high). Higher precedence traffic receives preferential treatment through elevated minimum and maximum queue thresholds, which postpone the onset of drops compared to lower precedence flows. Specifically, precedences 5 through 7, often reserved for critical applications like voice or network control, are configured with higher thresholds to minimize their drop probability, while best-effort traffic in precedences 0 through 3 faces earlier and more frequent discards. This differential handling ensures that priority packets experience less latency and loss, supporting quality-of-service objectives in congested environments. In router implementations, such as those from , WRED examines packet headers upon ingress to assign up to eight precedence classes based on IP precedence, with configurable profiles for each. Non-IP traffic, lacking precedence markings, defaults to the lowest precedence level (0), increasing its vulnerability to drops relative to marked flows. WRED's effectiveness is primarily optimized for TCP/IP traffic, which responds to packet drops by invoking congestion control mechanisms to reduce transmission rates. In contrast, protocols like , which do not inherently adjust rates upon loss, may not fully benefit from WRED's discriminatory dropping, potentially leading to persistent for such flows.

Drop Probability Computation

In Weighted Random Early Detection (WRED), the drop probability for a packet is determined based on the estimated average size and the traffic class (typically derived from IP precedence or Code Point values), using class-specific thresholds to prioritize higher-priority traffic. The mechanism extends the core Random Early Detection () approach by applying different parameters per class, ensuring that lower-priority traffic experiences earlier and more frequent drops during congestion. The basic drop probability function follows a piecewise linear model, as originally proposed in RED and adapted for WRED. If the average queue size is below the minimum threshold for the packet's class, the drop probability is 0, and the packet is enqueued. If the average queue size exceeds the maximum threshold, the drop probability is 1, resulting in a certain drop. Between these thresholds, the drop probability p_b increases linearly according to the formula: p_b = \max_p \times \frac{\text{avg} - \min_{\text{th}}}{\max_{\text{th}} - \min_{\text{th}}} where \avg is the average queue size (computed as described in the Average Queue Size Calculation section), \min_{\text{th}} is the class-specific minimum , \max_{\text{th}} is the class-specific maximum , and \max_p is the maximum drop probability for that (often set to a small value like 0.1 to avoid aggressive ). This linear ramp provides gentle early signaling, encouraging senders to reduce rates before occur. For weighted adjustment, each traffic class is assigned unique \min_{\text{th}}, \max_{\text{th}}, and \max_p values, allowing finer control over . Higher-priority classes typically receive larger threshold gaps (i.e., \max_{\text{th}} - \min_{\text{th}}) and higher minimum s, making drops less likely until queues are fuller; for instance, a low-priority class might have \min_{\text{th}} = 20 and \max_{\text{th}} = 40, while a high-priority class has \min_{\text{th}} = 35 and \max_{\text{th}} = 40, deferring drops for the latter. The maximum drop probability \max_p can also vary, often lower for higher classes to further protect them. This per-class tuning ensures that drop probabilities scale inversely with priority, maintaining fairness while protecting critical traffic. To implement probabilistic early detection, the computed p_b is adjusted to the actual drop probability p_a = \frac{p_b}{1 - \text{[count](/page/Count)} \times p_b}, where is the number of packets since the last for that (initially 0). A uniformly generated between 0 and 1 is compared against p_a; if the random value is less than p_a, the packet is and is reset to 0, otherwise the packet is enqueued and is incremented. This , with the adjustment, distributes drops evenly across flows, avoiding issues common in deterministic tail- schemes. In practice, for a given average queue size, the effective drop probability thus scales with the : lower-priority classes (e.g., precedence 0) may begin dropping at avg = 20, while higher-priority classes (e.g., precedence 7) remain unaffected until avg reaches 60 or more, depending on configured thresholds.

Configuration and Parameters

Key Parameters

Weighted Random Early Detection (WRED) relies on several key configurable parameters that govern its avoidance behavior across different classes or queues, allowing administrators to tailor drop probabilities based on priority levels such as precedence or Code Point (DSCP) values. These parameters enable fine-tuned control over when and how aggressively packets are dropped to prevent global synchronization in flows while ensuring weighted fairness. The (min_threshold) defines the average size at which dropping begins for a specific traffic class; below this level, no packets are marked or dropped probabilistically. For low-priority classes, this is typically set to 10-20 packets to allow some buffering before intervention, while higher-priority classes may have higher thresholds to reduce premature drops. This parameter ensures that mild does not immediately affect all traffic equally. The maximum (max_threshold) specifies the average size beyond which all incoming packets for that are dropped with certainty, marking the point of full avoidance. Common values range from 40-100 packets overall, with higher settings (e.g., up to 256 packets) for to prioritize their transmission during heavy load. This creates a linear ramp-up in drop likelihood between the minimum and maximum . The maximum drop probability (max_p), often configured via a mark probability denominator, represents the peak probability of dropping a packet when the average queue size reaches the maximum ; it is typically set to 0.1 (1/10) but can be tuned lower (e.g., 1/100) for less aggressive behavior or higher for stricter control. This parameter, adjustable per , influences the overall aggressiveness of WRED in signaling to endpoints. These thresholds and max_p feed into the drop probability computation for individual packets. The queue weight (w_q) is the smoothing factor used in the exponential moving average calculation of the average queue size, determining how quickly the average responds to instantaneous queue changes; a smaller value, such as $1/512 \approx 0.002, provides greater for in bursty but slower . It is derived from the and affects WRED's to short-term fluctuations versus long-term trends. The exponential weighting constant further refines the queue weight computation, typically defaulting to 9 (yielding w_q = 2^{-9} = 1/512) but configurable from 1 to 16 to balance responsiveness; lower values increase smoothing, making the average queue size less reactive to spikes. This parameter is crucial for environments with variable traffic patterns, as it helps avoid overreacting to transient bursts.

Implementation Guidelines

Implementing Weighted Random Early Detection (WRED) typically involves enabling the mechanism on router interfaces or within class-based queues, often using command-line interface (CLI) commands on Cisco devices. For basic setup at the interface level, administrators can enter interface configuration mode and issue the random-detect command to activate WRED with default parameters, which apply precedence-based thresholds. For example, on a serial interface, the configuration might look like: interface Serial5/0 followed by random-detect. To customize for specific precedence levels, use random-detect precedence <precedence> <min-threshold> <max-threshold> <mark-probability-denominator>, such as random-detect precedence 0 20 40 10 to set a minimum threshold of 20 packets, maximum of 40 packets, and a 1/10 drop probability at the maximum threshold for precedence 0 traffic. For more granular control in modern deployments, WRED is often combined with Class-Based Weighted Fair Queuing (CBWFQ) by applying it within a policy map under specific classes, enabling per-class queue management; this requires defining a policy map, associating classes, and attaching the policy to an interface via service-policy output. Tuning WRED begins with adopting default values—such as a minimum of 20 packets, maximum of 40 packets, and maximum probability of 1/10 for precedence 0—to establish a , then statistics to refine settings based on observed traffic patterns. Administrators should use commands like show queueing random-detect or show interfaces to track average depths, rates, and early drops, adjusting thresholds iteratively: for instance, increase minimum thresholds for bursty data traffic to allow higher utilization without premature drops, while ensuring the difference between minimum and maximum thresholds is sufficient (e.g., at least 20 packets) to prevent global synchronization. The exponential weighting constant, defaulting to 9, can be tuned via random-detect exponential-weighting-constant <exponent> for smoother averaging in volatile environments, but values below 9 may cause overreactions to short bursts. Common pitfalls in WRED implementation include setting overly aggressive thresholds, which lead to unnecessary packet drops and reduced throughput even under moderate load, or neglecting non-TCP traffic, which is invariably treated as precedence 0 and faces higher drop probabilities, resulting in unfairness toward UDP-based or flows. Insufficient space on the can exacerbate issues, as WRED relies on adequate queuing to compute average sizes accurately; deployments without at least 100-200 packets of per may fail to realize benefits. Additionally, WRED cannot coexist with certain queuing methods like Custom Queuing (CQ) or Priority Queuing (PQ) on the same , requiring careful policy design to avoid conflicts. Best practices emphasize integrating WRED with (DiffServ) for DSCP-based dropping via random-detect dscp-based, enabling finer classification in enterprise or service provider networks. Always test configurations under simulated load conditions using tools like generators to validate behaviors and stability before production rollout. For end-to-end (QoS), combine WRED with policing and shaping mechanisms in the policy map to cap ingress rates and smooth egress bursts, ensuring holistic congestion management without isolated .

Applications and Performance

Deployment in Networks

Weighted Random Early Detection (WRED) is commonly deployed on routers from major vendors such as and at WAN edges to manage in wide-area networks, where it helps prevent buffer overflows on serial and Ethernet interfaces by selectively dropping packets based on queue thresholds. In local area networks (LANs), WRED is applied to prioritize (VoIP) and video traffic, assigning higher IP precedence or Code Point (DSCP) values to ensure low-latency applications receive preferential treatment during shared buffer contention. For Internet Service Providers (ISPs), WRED operates in core routers like 's MX series to control in high-traffic backbone environments, where it is enabled by default to handle overflow in output queues. It is also implemented in routers from vendors like and Arista. WRED is frequently integrated with Class-Based Weighted Fair Queuing (CBWFQ) to combine bandwidth allocation with congestion avoidance, allowing network operators to define classes for different traffic types and apply WRED thresholds within those queues on router interfaces. Since the early 2000s, it has been utilized in (MPLS) and (DiffServ) domains, where DiffServ-compliant WRED uses DSCP markings to determine drop probabilities, supporting pipe, short-pipe, and uniform tunneling modes for end-to-end QoS across MPLS networks. It also supports Explicit Congestion Notification (ECN) marking, enabling routers to set congestion bits in packet headers instead of dropping them, which improves efficiency in TCP-based flows within these modern infrastructures. A common case example involves prioritizing Expedited Forwarding (EF) traffic, such as real-time VoIP or video applications marked with DSCP 46, over Best Effort (BE) traffic in shared buffers; WRED applies lower drop probabilities to EF packets while increasing drops for BE (DSCP 0) to maintain during congestion.

Advantages and Limitations

Weighted Random Early Detection (WRED) offers several advantages in managing and providing (QoS). By selectively dropping packets based on traffic class and precedence, WRED reduces the likelihood of global TCP synchronization, where multiple flows simultaneously reduce their transmission rates, leading to inefficient utilization. It also ensures class-based fairness by applying lower drop probabilities to higher-priority , such as or critical data, thereby protecting these flows during . Additionally, WRED operates in a stateless manner, requiring no per-flow state maintenance, which simplifies implementation and scales well in routers. In performance evaluations, WRED has demonstrated improvements in for high-priority traffic compared to tail-drop mechanisms in moderate scenarios. Despite these benefits, WRED has notable limitations that can impact its effectiveness. It is largely ineffective against non-TCP traffic, such as UDP-based floods, because unresponsive flows do not back off in response to packet drops, potentially exacerbating congestion. Parameter tuning, including minimum and maximum thresholds and drop probabilities, remains empirical and error-prone, often requiring extensive testing to avoid suboptimal performance or unintended bias. Misconfiguration can lead to unfairness, where lower-priority traffic is disproportionately penalized or higher-priority flows still experience excessive drops. Furthermore, WRED is considered outdated for high-speed links exceeding 10 Gbps, where large buffers contribute to bufferbloat—excessive queuing delays—without adequate mitigation, as traditional thresholds fail to control queues effectively in high bandwidth-delay product environments. In terms of overall performance, WRED excels in moderate by maintaining low average sizes and preventing tail drops, but it falters in severe overloads, where queues fill rapidly and revert to tail-drop behavior, negating early detection benefits. To address these shortcomings, WRED is often combined with (ECN) to signal without dropping packets, or integrated with advanced (AQM) techniques like or for better responsiveness in diverse traffic conditions.

Comparisons

With Traditional Drop Methods

Traditional drop methods, such as tail drop, operate on a first-in, first-out () basis in network queues, discarding incoming packets only when the buffer reaches full capacity. This approach leads to bursty packet losses, where multiple packets from the same flow are dropped consecutively during overflow, disproportionately affecting bursty traffic like TCP sessions compared to smoother flows such as UDP. Additionally, tail drop often triggers global TCP synchronization, as multiple connections detect congestion simultaneously and reduce their transmission rates in unison, resulting in oscillatory traffic patterns with crests and troughs that underutilize the link. In contrast, Weighted Random Early Detection (WRED) employs a proactive by initiating probabilistic packet drops well before the queue fills, based on average queue size and precedence, thereby preventing the from reaching capacity and avoiding the onset of tail drops. This early detection decorrelates packet losses across flows through , mitigating global by spreading drops over time rather than concentrating them during overflows. WRED further enhances fairness by assigning lower drop probabilities to higher-precedence , protecting flows from excessive discards while statistically penalizing aggressive, high-volume connections that might otherwise dominate the . By signaling congestion sooner, WRED reduces average queueing delays, as queues remain shallower and better able to absorb bursts without overflow. A key scenario illustrating the difference occurs in lock-out conditions under tail drop, where a single aggressive can monopolize the space, starving other of and leading to unfair . WRED counters this by randomizing drops across all flows proportional to their share, ensuring more equitable distribution and preventing any one from hogging the queue. Simulations demonstrate WRED's performance advantages, achieving link utilization up to 98% under high load compared to 70-80% with tail drop, where and bursty losses degrade efficiency. Furthermore, WRED typically yields lower average delays (around 10 ms) and rates (2-5%) versus tail drop's higher values (20 ms delay and 10-15% loss) in congested networks.

With Other Active Queue Management Techniques

Weighted Random Early Detection (WRED), developed in the 1990s as an extension of Random Early Detection (RED), serves as a foundational (AQM) technique but exhibits limitations when compared to modern algorithms designed for contemporary network challenges like . Unlike WRED's reliance on fixed thresholds for queue length to compute class-based drop probabilities, newer AQMs emphasize dynamic, delay-focused mechanisms that require less manual tuning and adapt better to varying traffic loads. Proportional Integral controller Enhanced (PIE) improves upon WRED by using a control-theoretic approach to directly manage queuing rather than average queue length. While WRED applies probabilistic drops based on static minimum and maximum thresholds per traffic class, PIE dynamically adjusts the drop probability using the queue delay's gradient, targeting a low (e.g., 15 ms) while allowing short bursts. This results in more stable performance across diverse link rates and reduces the tuning complexity inherent in WRED's multiple parameters. PIE's self-tuning of proportional and gains further enhances its adaptability, making it suitable for environments where WRED's fixed thresholds lead to underutilization or excessive drops. Controlled Delay (CoDel) addresses WRED's shortcomings by shifting from threshold-based queue monitoring to sojourn time—the actual delay a packet experiences in the —as the signal. In contrast to WRED's sensitivity to queue length variations caused by bursts or rate changes, CoDel drops packets only when the minimum sojourn time exceeds a target (e.g., 5 ms) over an interval (e.g., 100 ms), effectively combating without configuration for link speed or round-trip time. This approach yields lower latency under while maintaining high throughput, outperforming WRED in dynamic scenarios like varying bandwidths from 64 Kbps to 100 Mbps. Queue CoDel (FQ-CoDel) extends CoDel by incorporating per-flow queuing via scheduling, providing fairness across flows that WRED lacks due to its aggregate queue treatment and potential for . FQ-CoDel isolates up to 1024 flows, prioritizing short/low-rate traffic like VoIP, which improves and equity in mixed-traffic networks. The algorithm diverges from WRED's probabilistic, class-weighted dropping by leveraging history and link idle events to adjust drop rates, eliminating the need for queue length estimation. Whereas WRED requires tuning multiple thresholds per class for adaptability, BLUE's event-driven mechanism— increasing drop probability on loss and decreasing it on idles—offers simpler configuration with fewer parameters and better responsiveness to load variations. Simulations demonstrate BLUE achieves lower rates and smaller buffer requirements than RED-based methods like WRED, particularly under heavy . As a precursor from the , WRED paved the way for AQM but its parameter-heavy tuning and queue-length focus make it less ideal for modern high-speed networks compared to IETF-recommended alternatives like and /FQ-CoDel. These contemporary algorithms, standardized in RFCs such as 8033, 8289, and 8290, are favored for / deployments due to their low-latency guarantees, auto-tuning, and robustness against , with FQ-CoDel integrated as a default in systems like kernels and routers.