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.