problems with RED element ?

[Eddie Kohler]

Hi Brecht,

These are some more interesting results. Hmm.

First off, a friend at ACIRI who is also on this list, Jitendra Padhye,
says that in his experience, active queue management schemes can act pretty
weird with small numbers of flows. His quote was 'with two flows, RED is
allowed to do anything', or something liek that.

But that is not necessarily the only problem.

Some questions:
- How are the two flow's packets arriving at RED?
  If RED sees packets AAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBB
  it will of course drop mostly Bs.
  If it sees ABABABABABABABABABABABABABAB
  it might drop mostly Bs because of random number generator weirdness.
  If the ToDevice is waking up such that events work like this,
  1. PollDevice emits tons of As; they go into the queue
  2. PollDevice emits tons of Bs; they are dropped by RED
  3. ToDevice wakes up and drains the queue
  4. repeat,
  then again, you might see this B-dropping behavior.
  Any idea which it is?

Possible code issues:

RED is built around a EWMA, exponentially weighted moving average. Maybe
the EWMA is holding state for too long. You could tweak the EWMA parameters
and swee what that does. For example, in red.hh, use a FastDirectEWMA
instead of a DirectEWMA. This will lose memory of old congestion events
faster.

RED's random number generator might be bad. It is a simple linear
congruential generator (I think that's the right term). You could try a
different one.

Please let us know anymore information you have or can create.
Thanks!
love,
ed