question on algorithm for radius based accouting
hi, I 'google' algorithm for radius based accounting. but can't find anything. My question is: what's the best algorithm for constrcting broadband access record from radius accouting packets? To my knowledge, some system takes: Record Accouting-on packet arriving time -> record Accouting-Off packet's Acct-Session-Time and Acct-Delay-Time -> The Log-off time is calculated as: Accouting-on time + ( Acct-Session-Time - Acct_delay-Time) But, some other takes : Record Accouting-off arriving time --> record Accouting-Off packet's Acct-Session-Time and Acct-Delay-Time --> Log-on time is calculated as: Accouting-off arriving time - ( Acct-Session-Time - Acct_delay-Time) Are the two methods have the same effect on calculating result? If radius packets were sent to two accouting systems simulataneusly, while the two system takes the different algorithm, will there be any difference between the result of accouting ? regards Joe __________________________________ Yahoo! Movies - Search movie info and celeb profiles and photos. http://sg.movies.yahoo.com/
My question is: what's the best algorithm for constrcting broadband access record from radius accouting packets?
Read the RFC. No, I am being serious.
Record Accouting-on packet arriving time -> record Accouting-Off packet's Acct-Session-Time and Acct-Delay-Time ->
The Log-off time is calculated as:
Accouting-on time + ( Acct-Session-Time - Acct_delay-Time)
Or, take the acct record from logoff, and: (time stop acct record rec'd) - (acct-delay-time) Either will work. However, it's somewhat more common to do what I suggest.
Log-on time is calculated as:
Accouting-off arriving time - ( Acct-Session-Time - Acct_delay-Time)
Yes.
Are the two methods have the same effect on calculating result? If radius packets were sent to two accouting systems simulataneusly, while the two system takes the different algorithm, will there be any difference between the result of accouting ?
They should yield (approximately) the same result. But, to be pedantic, you haven't accounted for latency within the network.
On 17 Aug 2007, at 04:52, Alex Rubenstein wrote:
My question is: what's the best algorithm for constrcting broadband access record from radius accouting packets?
[snip]
They should yield (approximately) the same result. But, to be pedantic, you haven't accounted for latency within the network.
Somebody should be whipped, either for: 1) If you can find a network where that matters, even in the slightest, the oerson responsible for the design and/or maintainance OR 2) You, for making even this aged arch-pedant wince. :-) 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.
They should yield (approximately) the same result. But, to be pedantic, you haven't accounted for latency within the network.
Somebody should be whipped, either for:
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. And, I've not seen the behavior you describe that requires interim.
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 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.
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 scenario. Dialup connections are not usually long enough to warrant interim accounting. regards Hugh
On 19 Aug 2007, at 02:57, Hugh Irvine wrote:
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 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.
This sort of thing tends to happen in "wholesale" operations where the downstream has a congested link.
I've mostly seen it when loss of a link (voice trunks, L2TP tunnels) causes a lot of sessions to bounce at once. I possibly misspoke by saying RADIUS protocol when I probably ought to have said RADIUS subsystem. In these cases I strongly suspect a limit on buffer space at the NAS (or equivalent) end of things for keeping track of ACKs. I definitely used to see this on Max 4000s when I used to have a voice carrier who had a habit of dropping several trunks at a time losing me 100s of sessions simultaneously - it'd only be a few packets but it was enough to make the books not balance which is why it got spotted. And as the physical links involved were often in the 10s of feet region...
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 scenario.
Exactly.
Dialup connections are not usually long enough to warrant interim accounting.
regards
Hugh
Hello Joe - The Acct-Session-Time is what the NAS is reporting as the duration of the session, and the Acct-Delay-Time is the NAS reporting any delay in sending the accounting request (usually due to retransmissions). The time the accounting request(s) is(are) received by the RADIUS server host may or may not be relevant, depending on where the NAS and the RADIUS host are located geographically and whether or not the time on the RADIUS server host is "correct". The best approach is to generate an event timestamp which is the time the accounting stop is received minus the Acct-Delay-Time (if present). The start time is therefore the corrected timestamp minus the Acct-Session-Time. Note that RFC 2869 specifies an Event-Timestamp attribute which is meant to indicate the time on the NAS that the accounting event occurred, but I have never seen it used. regards Hugh On 17 Aug 2007, at 11:53, Joe Shen wrote:
hi,
I 'google' algorithm for radius based accounting. but can't find anything.
My question is: what's the best algorithm for constrcting broadband access record from radius accouting packets?
To my knowledge, some system takes:
Record Accouting-on packet arriving time -> record Accouting-Off packet's Acct-Session-Time and Acct-Delay-Time ->
The Log-off time is calculated as:
Accouting-on time + ( Acct-Session-Time - Acct_delay-Time)
But, some other takes :
Record Accouting-off arriving time -->
record Accouting-Off packet's Acct-Session-Time and Acct-Delay-Time -->
Log-on time is calculated as:
Accouting-off arriving time - ( Acct-Session-Time - Acct_delay-Time)
Are the two methods have the same effect on calculating result? If radius packets were sent to two accouting systems simulataneusly, while the two system takes the different algorithm, will there be any difference between the result of accouting ?
regards
Joe
__________________________________ Yahoo! Movies - Search movie info and celeb profiles and photos. http://sg.movies.yahoo.com/
NB: Have you read the reference manual ("doc/ref.html")? Have you searched the mailing list archive (www.open.com.au/archives/ radiator)? Have you had a quick look on Google (www.google.com)? Have you included a copy of your configuration file (no secrets), together with a trace 4 debug showing what is happening? Have you checked the RadiusExpert wiki: http://www.open.com.au/wiki/index.php/Main_Page -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows, MacOS X. Includes support for reliable RADIUS transport (RadSec), and DIAMETER translation agent. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. - CATool: Private Certificate Authority for Unix and Unix-like systems.
participants (4)
-
Alex Rubenstein -
Hugh Irvine -
Ian Mason -
Joe Shen