Re: Choosing WRED Min and Max Thresholds

Gregory,

You are confusing different concepts here. Firstly, for the congestion.
Congestion is defined as a condition where "input request rate" exceeds the
system's "service rate". In our case, "service rate" is defined as DS3
serialization rate (accounting for framing, hardware driver processing time,
etc). The "request rate" is the amount of bits pers second switched egress
toward the DS3 circuit. As soon as "request rate" > "service rate", the
egress queue starts growing *unrestrictedly*. In other words, congestion
could be defined as condition where "service queue" is non-empty, signaling
the fact that output interface was not able to serialize a packet without
delaying it.

In fact, if you define interface "utilization" as the percentage of a time
interval that the egress interface is busy sending packets (from 0 to 100%),
then the queue depth could be approximated to some extent as:

Depth = Utilization/(1-Utilization) [based on general mass-service system
theory]

Keep in mind, though, that this formula quickly becomes inaccurate as
utilization approaches 100%: the "near full link utilization" queueing
theory is not very well developed still. However, you can quickly see that
with 50% interface utilization, the *average* queue depth will be:

Depth_50% = 0.5/(1-0.5)=0.5/0.5=1 packet.

That is, if during any random time interval, interface spends 50% of time
serializing packet with the remaining 50% being idle, then queue depth will
most likely be 1 packet. Notice that the queue depth grows rapidly as
utilization approaches 90%, illustrating the fact that keeping interface
utilized over 50% may have significant performance drawbacks.

Now for RED/WRED. At this point, you should clearly understand that
interface queue, whatever it is, simply holds the *excessive* packets that
the interface was not able to schedule due to overutilization. These packets
will be serviced at interface physical rate, as soons as the interface is
available for sending packets. WRED is just an active *queue management*
technique that accounts for the TCP behavior. By dropping packets early, it
slows down some endpoints and alleviates excessive congestion on the
interface that may overwise result from TCP flow synchronization. The term
"congestion avoidance" is misleading, as it should more correcly state
"congestion alleviation": WRED works only when interface is congested, i.e.
has non-zero output queue. As for optimum values for RED/WRED parameters
those are defined empirically, and I attached some "starting" values for
your consideration.

RED parameters (assuming the packets are MTU sized). Those are just starting
values, adjust them empirically for achieving maximum performance in your
particular scenario:

---
Pipe-Size = RTT_Seconds*Bandwidth_in_Bps/(MTU_Bytes*8)
Min_Threshold = 15%*PipeSize
Max_Threshold = 100%*PipeSize
Marking_Probability_Denominator = 1
Exponential_Weighting_Constant = log2(Bandwidth_Bps/(10*MTU_Bytes*8))
As you can see, those are based on some TCP performance metrics, notably the
"pipe size".
HTH
-- 
Petr Lapukhov, petr_at_INE.com
CCIE #16379 (R&S/Security/SP/Voice)
CCDE #20100007
Internetwork Expert, Inc.
http://www.INE.com <http://www.ine.com/>
Toll Free: 877-224-8987
Outside US: 775-826-4344
2010/11/1 Gregory Gombas <ggombas_at_gmail.com>
> Thanks for responding Matt,
>
> You're explanation is consistent with what I recall about the software
> queueing mechanism - which is that packets only end up in the software
> queue
> when there is congestion on the link.
>
> But here comes the paradox:
>
> If WRED is a congestion avoidance mechanism, how can it avoid congestion
> when it only acts on packets in the software queue (which only appear
> during
> times of congestion)?
>
> On Mon, Nov 1, 2010 at 10:48 AM, Matt Eason <matt.d.eason_at_gmail.com>
> wrote:
>
> > Hi Greg,
> >
> > I think the important point in this discussion is that the wred values
> only
> > apply to packets that are sitting in the software queue waiting to be
> > processed. For example, if your link is running @ 10% of its rated speed
> > i.e 4.4mbps on a DS3 then the packets are going to be sent out on the
> wire
> > without any delay and are not subject to software queueing as the circuit
> > speed is fast enough to serialise the packets straight onto the wire.
> >
> > On the other hand if you were sending enough data to clog your software
> > queue wred would kick in (depending on the queue depth). This is where
> the
> > min & max thresholds come into play.
> >
> > Most networks I have worked on run with the default values however
> certain
> > scenarios may benefit from custom values, it just depends :)
> > Cheers,
> >
> > Matt
> >
> > On Mon, Nov 1, 2010 at 9:34 PM, Gregory Gombas <ggombas_at_gmail.com>
> wrote:
> >
> >> Hi Gang,
> >>
> >> I am trying to choose the best WRED Min and Max Thresholds for a DS3.
> >>
> >> So far the best guide I could find was here:
> >>
> >> http://www.cisco.com/en/US/docs/ios/11_2/feature/guide/wred_gs.html
> >>
> >> However, neither the Cisco default values nor the recommended values on
> >> that
> >> page make any sense.
> >>
> >> For example, the default value for the WRED maximum threshold on a DS3
> >> interface is 40 packets.
> >>
> >> Assuming a maximum packet size of 1500 bytes that would mean the most
> >> throughput you would get on a DS3 interface with WRED would be 40
> packets
> >> *
> >> (1500 bytes per packet) * (8 bits per byte) = 480,000 bps or 480 kbps.
> >>
> >> Which means you would be at full drop at only 480 kbps?!?
> >>
> >> Even if you took the recommended setting of 367 packets for maximum
> >> threshold:
> >>
> >> 367 packets * (1500 bytes per packet) * (8 bits per byte) = 4,404,000
> bps
> >> or
> >> 4,404 kbps (1/10 the bandwidth of a DS3)
> >>
> >> I know the goal of WRED is to drop packets before you reach congestion,
> >> but
> >> dropping all packets when reaching 1/10th of the DS3 bandwidth seems a
> >> little ridiculous.
> >>
> >> Am I missing something here?
> >>
> >> Thanks,
> >> Gregory Gombas
> >> CCIE #19649
> >>
> >>
> >> Blogs and organic groups at http://www.ccie.net
> >>
> >> _______________________________________________________________________
> >> Subscription information may be found at:
> >> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net