Tracking packet/s in the server

[Alan DeKok]

Brian Candler wrote:
> e.g. if queue is more than 50% full then randomly drop incoming packets
> with a probability of (1 - (cur_queue_size/max_queue_size)*2)

  That's a good heuristic.  The only downside is that the queue is there
precisely to handle spikes of traffic.  So it might be OK for the queue
to be half full.  It means that the server will gradually empty it, and
therefore be OK.

> However the only reason I can see to do this is if auth and acct are in the
> same queue, so the server gives priority to handling auth if the queue is
> getting full.

  They're all in the same queue, unfortunately.  That's why the new
configuration option is "auto_limit_acct", so it applies to accounting
packets.

  The addition of the rate-checking means that the packets get dropped
ONLY if the queue is growing.  If it's shrinking, then there's no reason
to drop packets, even if the queue is 75% full.

  That's pretty much what it does now.

  I'm not sure what benefits WRED would add.  Right now the "drop
packets" limit is a hard limit.  But dropping packets means that the
"add to queue" counter is NOT incremented.  The result is a few packets
will be dropped, the "input pps" will go below the "output pps", and it
will allow more packets to be added to the queue.

  The result is that the queue will be filled no faster than it's
emptied.  With WRED, the queue will continue to grow until it's full.
I'm not sure how that helps...

  Alan DeKok.