From: anthony.sequeira@thomson.com
Date: Wed May 09 2007 - 18:10:33 ART
Here is my attempt at plain English explanations:
Instead of waiting for congestion to be an issue, why not randomly drop
packets that are marked as low priority setting once a certain bandwidth
threshold is reached. This is WRED.
Doing this can help prevent Tail Drop of all packets that arrive at the
fully congested interface. Tail drop can result in Global
Synchronization - where all TCP senders start backing off the rate at
which they send traffic. This global synchronization leads to a poor
utilization of the interface bandwidth. The utilization pattern looks
like a saw blade (peaks and valleys) instead of a nice smooth pattern.
Using your bathroom analogy, global synchronization would mean that all
roommates waiting for the bathroom return to their rooms and wet
themselves. ;-)
Anthony J. Sequeira
#15626
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
John Gibson
Sent: Wednesday, May 09, 2007 4:54 PM
To: ccielab@groupstudy.com
Subject: WRED's purpose and reason ?
I heard someone said WRED prevents packets' bytes and
bits from being cut in the middle whiling queuing
to the output (software) queue, which wastes
processing
power, by setting the threshold of "stop queuing".
That couldn't be right I believe.
The software queues store pointers to the header
of a packet's bytes and bits. There shouldn't be such
a concern of bytes and bits of a packet being cut in
the middle while queuing to the software queue.
I believe:
WRED is the result of work of engineering probability
calculation which discovered some gain in throughput
that by avoiding the peaks and valleys of sending
packet rates. They have mathematical proof but the
intuitive view is simply that scrambling TCP's
sending rate retraction (triggered by a packet lost)
among different flows makes everyone more productive.
Imagine in a 1 bathroom apartment, 2 people with
different work shifts makes it more comfortable
to live together.
This archive was generated by hypermail 2.1.4 : Fri Jun 01 2007 - 06:55:20 ART