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]