Congestion-avoidance mechanisms, such as Weighted Random Early Detection (WRED), are complementary to (and dependent on) queuing algorithms. Queuing/scheduling algorithms manage the front of a queue, whereas congestion-avoidance mechanisms manage the tail of a queue.
Congestion-avoidance QoS tools are designed to handle TCP-based data traffic. TCP has built-in flow-control mechanisms that operate by increasing the transmission rates of traffic flows (even though bounded by buffers and window sizes) until packet loss occurs. At this point, TCP abruptly squelches the transmission rate and gradually begins to ramp the transmission rates higher again. This behavior makes a strong case against the statement "QoS isn't necessary; just throw more bandwidth at it." If left unchecked, lengthy TCP sessions (as are typical with bulk data and scavenger applications) can consume any and all available bandwidth, simply because of the nature of TCP.
When no congestion-avoidance algorithms are enabled on an interface, the interface is said to tail drop. That is, after the queuing buffers have filled, all other packets are dropped as they arrive.
In a constricted channel, such as in a WAN or a ×××, all the TCP connections eventually synchronize with each other as they compete for the channel. Without congestion-avoidance mechanisms, they all ramp up together, lose packets together, and back off together. This behavior is referred to as global synchronization. In effect, waves of TCP traffic flow through the network nodes, with packets overflowing the buffers at each wave peak and lulls in traffic between the waves.



Random Early Detection Random Early Detection (RED) counters the effects of TCP global synchronization by randomly dropping packets before the queues fill to capacity. Randomly dropping packets instead of dropping them all at once, as is done in a tail drop, avoids global synchronization of TCP streams.
Instead of waiting for queuing buffers to fill before dropping packets, RED causes the router to monitor the buffer depth and perform early discards (drops) on random packets when the minimum defined queue threshold has been exceeded.
RED drops occur within the operational bounds of TCP retry timers, which slow the transmission rates of the sessions but prevent them from starting slow. Thus, RED optimizes network throughput of TCP sessions.
Because UDP does not have any retry logic, congestion-avoidance techniques such as RED (and variants) do not apply to UDP-based traffic.
The Cisco IOS Software does not support RED; it supports only Weighted RED (WRED). It is important to note that the random-detect Cisco IOS software CLI command enables WRED. However, if all the packets assigned to an interface or class have the same IPP or DSCP markings, the effective policy is simply RED

Weighted Random Early Detection WRED is an enhancement to RED that enables a degree of influence over the "randomness" of the selection of packets to be dropped. WRED factors the weight, or IPP, of the packet into the drop-selection process.
Within the WRED algorithm, a minimum threshold for a given IPP value determines the queue depth at which packets of that IPP value begin to be randomly dropped. The maximum threshold determines the queue depth at which all packets of that IPP value are dropped. These thresholds are tunable, as is the mark probability denominator, which determines how aggressively the packets of a given IPP value are dropped. (For example, a mark probability denominator value of 10 indicates that up to 1 in 10 packets of a certain precedence value will be dropped randomlythe maximum rate of 1 in 10 happens at the maximum threshold, and the drop rate is linear up to this maximum,
By default, WRED drops packets with lower IPP values sooner than packets with higher IPP values.

WRED can be configured as an interface command, but it is recommended that it be configured within the MQC syntax because this improves granularity, modularity, and manageability of the WRED algorithm.
As previously noted, WRED is dependent on queuing. Therefore, before WRED can be enabled on a class of traffic, a queuing option (usually either bandwidth or fair-queue) must be enabled on the class. Example shows an example of a WRED configuration applied to the default traffic class.
Example
WRED Policy Map Policy-map aaa
class class-default
fair-queue
random-detect
or
random-detect
dscp-based