[98789] in North American Network Operators' Group
RE: question on algorithm for radius based accouting
daemon@ATHENA.MIT.EDU (Alex Rubenstein)
Fri Aug 17 09:57:12 2007
Date: Fri, 17 Aug 2007 09:35:10 -0400
From: "Alex Rubenstein" <alex@corp.nac.net>
To: "Ian Mason" <nanog@ian.co.uk>
Cc: "Joe Shen" <joe_hznm@yahoo.com.sg>, "NANGO" <nanog@merit.edu>
Errors-To: owner-nanog@merit.edu
> > They should yield (approximately) the same result. But, to be
> > pedantic,
> > you haven't accounted for latency within the network.
> >
>=20
> Somebody should be whipped, either for:
>=20
> 2) You, for making even this aged arch-pedant wince. :-)
Ding!
> Seriously, can I also add that RADIUS interim accounting is almost
> essential in this scenario. Real world accounting and session
> boundaries
> 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.
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.=20
And, I've not seen the behavior you describe that requires interim.
