In message <11712.963201005@coconut.itojun.org>itojun@iijlab.net writes
>

>	which part is a design flaw? 

If we're going to do rate control, lets do it properly.  Computer
traffic of all kinds is bursty; we want a rate-limit knob which can
handle short-term bursts without requiring a larger longterm rate than
you'd like.

Have a token bucket which accumulates "credit" gradually over time, up
to some maximum, at which it pegs.  To send packets, deduct a packet's
worth of credit from the bucket. if there isn't a full packet's worth,
drop the packet.

think of it as a finer-grained version which subsumes both the
ratecheck functions we have accreted.

That handles bursts much better than the one-knob filters we seem to
have. Unless I'm reading the wrong source, and seeing the wrong
effects when waiting for named queries.


>	we can integrate ALTQ (alternate queueing framework,

Please, let us not _require_ ALTQ.  There's significant benefit
to be had from some simple rate-limiting, without necessarily
buying into a fullblown QoS framework.  At least, that's my take.