Re: Choosing WRED Min and Max Thresholds

From: Paul Negron <negron.paul_at_gmail.com>
Date: Mon, 01 Nov 2010 12:48:44 -0600

The key word is - "CONGESTION AVOIDANCE.

WRED, Shaping and Policing kick in BEFORE Congestion Occurs. Like the other
post hinted, it depends on the minimum threshold when you start to mark
(ECN) or drop packets.

-- 
Paul Negron
CCIE# 14856 CCSI# 22752
Senior Technical Instructor
www.micronicstraining.com
> From: "Joseph L. Brunner" <joe_at_affirmedsystems.com>
> Reply-To: "Joseph L. Brunner" <joe_at_affirmedsystems.com>
> Date: Mon, 1 Nov 2010 14:40:26 -0400
> To: Gregory Gombas <ggombas_at_gmail.com>, Matt Eason <matt.d.eason_at_gmail.com>
> Cc: Cisco certification <ccielab_at_groupstudy.com>
> Conversation: Choosing WRED Min and Max Thresholds
> Subject: RE: Choosing WRED Min and Max Thresholds
> 
> 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)?
> 
> Greg, you have to remember what TCP does in response to congestion.... even
> simulated, class based penalty congestion. Its going shrink the window until
> your "DS-3" mysteriously is slow as a dial-up for certain traffic classes.
> 
> You can play around with IPERF with different wred configurations to help get
> a better picture of this, and of course, wireshark at the sender's end.
> 
> Also, let's not forget hardware wred-
> 
> Here clearly, hardware queues themselves are being re-programmed to induce
> congestion for different transmit/receive queues each with different drop
> thresholds-
> 
> http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_pa
> per0900aecd80233956.html
> 
> 
> Another very interesting technology for WRED is of course, ECN (explicit
> congestion notification) and how different vendors implement this.
> 
> Check
> 
> http://research.microsoft.com/apps/pubs/default.aspx?id=67628
> 
> -Joe
> 
> -----Original Message-----
> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> Gregory Gombas
> Sent: Monday, November 01, 2010 1:08 PM
> To: Matt Eason
> Cc: Cisco certification
> Subject: Re: Choosing WRED Min and Max Thresholds
> 
> 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
> 
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
Received on Mon Nov 01 2010 - 12:48:44 ART

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