[altq:1660] Re: Comment on my config.

[Nicolas Christin <nicolas@cs.virginia.edu>]

On Fri, 4 Oct 2002, Nicolas Christin wrote:

> JoBS - instead of CBQ - may seem like a pretty natural candidate for
> that, since it can enforce delay bounds. (CBQ cannot - not directly at
> least.)

Actually, I misspoke. The ALTQ implementation of CBQ can support delay
bounds. Sorry for the confusion.

However, in CBQ/ALTQ, a delay bound is mapped to a maximum queue size.
In practice, that means that, unless your link is extremely congested,
due to the (almost) static rate allocation used in CBQ, you may end
up dropping packets unecessarily. JoBS uses a dynamic rate allocation
based on the required service guarantees and the current backlogs of all
traffic classes, and allows for relaxing the delay bound at the expense
of the loss rates if need be.

As a practical example, if you tell it not to drop more than 1% of your
telnet traffic, it won't. If that means that instead of having a 10 ms
guaranteed delay (if that's what you chose), you sometimes end up with
11 ms, so be it.

The rationale behind that design choice is that losses are really bad
for TCP traffic (since all lost packets must be retransmitted), and can
actually generate large delays at the application level (due, again, to
retransmission).

Other than that, your config file seems reasonable at first glance.
However, the best thing to do is to try it out. It's much easier to see
what breaks down from network measurements than it is from just reading
a config file. It's like debugging C code - the code may look good, but
trying it sometimes makes you realize some stupid mistakes you didn't
catch at first glance.

By the way, same comment as with the previous poster: I don't recommend
using RED without ECN. It's been observed that improper parameter tuning
yields queue oscillations, which in turns yields rather unpredictable
queueing delays. You may even end up dropping more packets than with
DropTail, for no noticeable performance improvement.

In short, while a properly tuned RED gateway is great, a poorly tuned
one is actually going to degrade the observed performance. And tuning is
a pain in the butt, since it essentially depends on the traffic going in
at a given time. There's been quite a lot of research on that since `93.
(Self-tuning RED, Adaptive RED, etc.)

At least, if you choose to use RED, don't use the default parameters,
as it is unlikely that they will match your desired performance. (See
altq.conf(4) for learning how to tune the RED parameters in ALTQ.) A
good paper that discusses RED parameter tuning is "A Study of Active
Queue Management for Congestion Control," by Firoiu and Borden, Infocom
2000. It's bit technical, but it gives good guidelines for RED parameter
tuning.

I don't have anything against RED, by the way - just be careful when you
use it.

-- 
Nicolas Christin
Ph.D. Candidate, University of Virginia, Computer Science
http://www.cs.virginia.edu/~nicolas