Why Do I Need WRED on My Network?

Why Do I Need WRED on My Network?
WRED makes early detection of congestion possible and provides differentiated
services for multiple classes of traffic. Like basic RED, it also protects against global
synchronization as long as flows are compliant to congestion notification, like TCP.
For these reasons,WRED is useful on any output interface where you expect
congestion to occur. However, it is most effective in backbone networks that
aggregate many paths from remote sites. If the routers at the edge are marking
traffic into classes with IP precedence,WRED can act more intelligently in the
backbone with its drop decisions.
WRED was primarily designed for use in IP networks dominated by TCP.You
should use caution when evaluating WRED if your network has a large amount of
UDP traffic, because UDP traffic simply does not respond to packet drop in a
manner that would allow WRED to provide any relief.With TCP, dropped packets
indicate congestion, so the packet source will reduce its transmission rate.With
other protocols, like UDP, it is left to higher layer protocols, such as the application
itself, to respond to dropped packets by slowing down transmission.With
www.syngress.com
Advanced QoS for AVVID Environments • Chapter 8 251
UDP, this usually does not happen.When packets are dropped from a UDP transmission,
the source may continue to send packets at the same rate.Thus, dropping
packets does not decrease congestion, and WRED is ineffective. Making sure that
adaptive flows get their fair share of bandwidth in comparison to nonadaptive
flows may be possible using flow-based RED (see “Flow-Based Random Early
Detection” sidebar).
Additionally if your network is not strictly IP, you may not gain the benefit
of the IP precedence weighting of WRED.WRED treats non-IP traffic as precedence
0, the lowest precedence.Therefore, non-IP traffic will be lumped into a
single bucket and is more likely to be dropped than IP traffic.This may cause
problems if most of your important traffic is something other than IP.The case
for QoS may encourage you to advocate transforming your network into a
strictly IP network or, at least, tunneling non-IP traffic through the portions of
your network where QoS is required.