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-
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
Received on Mon Nov 01 2010 - 14:40:26 ART
This archive was generated by hypermail 2.2.0 : Sun Dec 05 2010 - 22:14:55 ART