question on algorithm for radius based accouting

Joe_Shen · August 17, 2007, 1:53am

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

Alex_Rubenstein · August 17, 2007, 3:52am

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.

Hugh_Irvine · August 17, 2007, 5:23am

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

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

Ian_Mason · August 17, 2007, 12:30pm

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.

Alex_Rubenstein · August 17, 2007, 1:35pm

> 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.

Hugh_Irvine · August 19, 2007, 1:57am

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

Ian_Mason · August 21, 2007, 5:39am

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.