Re: Choosing WRED Min and Max Thresholds

From: Matt Eason <matt.d.eason_at_gmail.com>
Date: Tue, 2 Nov 2010 15:30:23 +0800

I was just thinking Petr is the man to answer this question :)

I learnt the topic from him in the first place lol.

Matt

On Tue, Nov 2, 2010 at 11:44 AM, Petr Lapukhov
<petr_at_internetworkexpert.com>wrote:

> 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
Received on Tue Nov 02 2010 - 15:30:23 ART

This archive was generated by hypermail 2.2.0 : Sun Dec 05 2010 - 22:14:55 ART