[altq:1694] Re: Unstable cbq on Openbsd box

["Victor Worley" <vworley@p2p-innovations.com>]

Please be nice and add an Unsubscribe Link to your mailing list.



thanks

-----Original Message-----
From: Kenjiro Cho [mailto:kjc@csl.sony.co.jp] 
Sent: Friday, October 18, 2002 12:31 AM
To: nicolas@cs.virginia.edu
Cc: altq@csl.sony.co.jp
Subject: [altq:1684] Re: Unstable cbq on Openbsd box


Nicolas Christin wrote:
> > It was the red.
> >
> > but how can i configure it ? is there a doc/howto anywhre ?
> 
> That's a good question. There is *no* HOWTO on that. As a matter of
> fact, as I explained in a previous post [altq:1656], the difficulties
in
> tuning RED are the main reason why it is not really used by backbone
> operators, even though most routers support it. I refer to a paper
that
> you may find of interest in my post [altq:1660], that gives some
> configuration guidelines for RED.

You seem to have a bias against RED.
I agree that it isn't easy to tune the RED parameters not to oscillate
the queue for all possible scenarios, and the behavior of RED isn't
fully understood and can be improved.

Still, I believe that enabling RED is a good thing.
Although RED may not work well for certain scenarios, RED is usually
better than FIFO for normal congestions.

Apparently, Danny observerd retransmit timeouts when RED is enabled.
Since his setup is too simple to push RED out of its working range,
I suspect the TCP implementations of the end hosts failed to do proper
FastRetransmit/FastRecovery, and RED just triggered the bug.  But I
could be wrong.

> Kenjiro, I haven't taken a look at the altq/RED code in quite a while,
> and I'm unable to do that from where I am right now, but did you
> implement drop spacing?

We have a standard spacing mechanism found in ns-2.
From a comment in altq_red.c:
/*
 * early-drop probability is calculated as follows:
 *   prob = p_max * (avg - th_min) / (th_max - th_min)
 *   prob_a = prob / (2 - count*prob)
 *	    = (avg-th_min) / (2*(th_max-th_min)*inv_p_max -
count*(avg-th_min))
 * here prob_a increases as successive undrop count increases.
 * (prob_a starts from prob/2, becomes prob when (count == (1 / prob)),
 * becomes 1 when (count >= (2 / prob))).
 */

-Kenjiro