question on algorithm for radius based accouting
hugh at open.com.au
Sun Aug 19 01:57:59 UTC 2007
On 17 Aug 2007, at 23:35, Alex Rubenstein wrote:
>> Seriously, can I also add that RADIUS interim accounting is almost
>> essential in this scenario. Real world accounting and session
>> mis-match badly making it almost mandatory to use interim accounting
>> records to get an approximation of what the figures look like from
>> a billing perspective. I'll also add "watch out for missing records"
>> - I've found RADIUS to be the lossiest network protocol per foot of
>> cabling that I've ever used.
> I can't say I've seen this.
This sort of thing tends to happen in "wholesale" operations where
the downstream has a congested link.
> Having collected hundreds of millions of radius packets in my years
> (hell, we were running PM-2e's in 1996), and have written several
> accounting collectors, I can't say I agree.
> If you follow the specifications properly, unless you have issues with
> the transmitting device (read: BUG), RADIUS accounting has always been
> good to me.
You can sometimes improve this situation by transporting the RADIUS
requests over some form of TCP tunnel.
> And, I've not seen the behavior you describe that requires interim.
DSL and/or cable systems usually have long-held connections that
often cross billing boundaries - interim accounting is useful in this
Dialup connections are not usually long enough to warrant interim
More information about the NANOG