Tracking packet/s in the server

[Alan DeKok]

Phil Mayers wrote:
> 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;

  RADIUS doesn't do that.

> the NAS can
> re-send, and then stop re-sending, but will that actually decrease
> offered load at the radius server?

  RFC 5080 defines how retransmissions are handled.  The NAS *should*
add jitter, and perform exponential backoff.

  Sadly, no one implements it. :(

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

  Nice.  <clickety-click>

$ git pull

  And see the last commit log.  No documentation or examples as yet.
That comes later. :)  You should be able to test it by setting
"auto_limit_acct = yes" in the "thread pool" section.  Then, use

	if (control:FreeRADIUS-Queue-Use-Percentage > 30) {
		...
	}

  You won't ever see it greater than 50, due to the previous described
behavior of "auto_limit_acct".  Maybe the auto_limit_acct check should
be set to 75% of the queue size.  But my $0.02 is when that happens, the
system is pretty much dead anyways.

> [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]

  Yeah.  It's not going to happen.

  Alan DeKok.