On Fri, 4 Mar 2005, Lennert Buytenhek wrote:

On Thu, Mar 03, 2005 at 06:48:50PM -0500, John Heffner wrote:

quoted

All these AQM schemes are trying to solve a fundamentally different
problem.  With TCP at least, the only congestion experienced at this point
will be transient, so you do not want to send any congestion signals (drop
packets) if you can avoid it at all.  Making the limit as high as you can
tolerate seems like the best thing to me.

If the traffic does not terminate locally (f.e. when doing routing),
an insanely large queue has more disadvantages than advantages.

If you're routing those exact same TCP packets on the way to their
final destination, you run the risk of not sending out any congestion
signals in the cases where you should, making your forwarding latency
skyrocket (punishing all the other flows) in the process.

Yes.  In "as high as you can tolerate" latency is implicit. :)  This is
just as true whether forwarding or not.  Offhand I'd say 10 ms is a good
number (bursts should be shorter than this, but it's not too much
latency).

The forwarding case where you actually need congestion control, as opposed
to absorbing bursts, is pretty gross.  If you have a router (more likely
firewall) whose bottleneck is the CPU, then you're operating entirely in
you input queue.  Yuck.  In such a situation, if you don't want user
processes to get starved, you need to do throttling => bad for TCP.

  -John