Tracking packet/s in the server

[Phil Mayers]

On 23/02/12 12:04, Alan DeKok wrote:

>    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...


Indeed.

RED-like behaviour makes sense if the sending system can detect the loss 
and *slow down*. It's not clear to me that this is the case; the NAS can 
re-send, and then stop re-sending, but will that actually decrease 
offered load at the radius server? I'd need to work it out on paper - my 
brain is full of DWDM at the moment! But it seems to me that, if you 
wanted RED-like behaviour i.e. reduce offered load at the radius server 
then the heuristic should be:

if queue_len > threshold:
   compute drop probability
   if (drop AND Acct-Status-Type==Interim)
     send immediate Accounting-Response code=ok

i.e. shut the NAS up immediately, for interim requests only, and don't 
execute the server {} block.

I think this would be a bad idea.

OTOH, it *might* make sense to expose the queue length / percentage as a 
control: variable to the server{} block; that way, if you wanted to, 
local sites could do this:

preacct {
   if (control:FreeRADIUS-Acct-QueueLoad > 50) {
     ok
   }
   else {
     ..
   }
}

[It's a shame there isn't an Accounting-Response code "Overloaded"; this 
could apply some kind of real-time delta to the Acct-Interim-Interval 
associated with the session(s) on the NAS, But that's rather pie in the sky]