How to charge based on accounting correctly
Hello, We have a system which sends radius accounting messages to our radius. Based on this accounting we charge subscribers. Interim accounting is enabled so for a normal session we get one Start, zero or more Interim-Update and one Stop packets. Every accounting packet except Start contains Acct-Session-Time which is "how many seconds the user has received service for" according to rfc2866. That means that it's always incrementing during a session. To charge a session in chunks we calculate a difference between the recent value and the previous one. In our case we get Interim-Update records every 15 minutes, so this difference between 2 sequential Interim-Update records is 900 secs +/- 2-3 secs. What happens when for some reason one Interim-Update records is lost? In such case we get diff - 1800 secs and everything is fine. However recently we discovered that a system which is sending accounting records will resend unconfirmed packets after some time (I do not mean Retransmit-Interval/Retransmit-Count feature which exists on most if not all NAS-es). The later means that in some cases we can get an Interim-Update packet with Acct-Session-Timeout = 1800 calculate a difference against a Start record (that is 1800 secs) and charge it, later get Interim-Update with Acct-Session-Timeout = 900. So my questions can be stated like this: 1. Is it better to charge the whole difference between current and previous Session-Timeout values and later ignore any previous packets which arrive out of order, or it's better to charge last 15 minutes (I get Interim-Update records every 15 minutes as already stated above) and do not care about missing parts (if any) of a session? 2. Is it a correct behavior of a NAS to store accounting information on it's internal disk if it can't get acknowledgment for accounting request/s and resend it later? Best Regards, George Chelidze
George Chelidze wrote:
To charge a session in chunks we calculate a difference between the recent value and the previous one.
Why not just update the users credit when the session is closed?
In our case we get Interim-Update records every 15 minutes,
No. You *hope* to get them every 15 minutes. You *cannot* rely on them occurring every 15 minutes. Since RADIUS packets aren't ordered, it is theoretically possible to get accounting packets out of order. e.g. start, update-2, update-1, update-3. You will need to ensure that you handle this, too.
1. Is it better to charge the whole difference between current and previous Session-Timeout values and later ignore any previous packets which arrive out of order, or it's better to charge last 15 minutes (I get Interim-Update records every 15 minutes as already stated above) and do not care about missing parts (if any) of a session?
Store the last "session length" for a session. If the current packet has a smaller session length, ignore the packet. Otherwise, look at the difference between the stored session length, and the session length in the current packet. Use that time for billing, rather than the time you received the packet.
2. Is it a correct behavior of a NAS to store accounting information on it's internal disk if it can't get acknowledgment for accounting request/s and resend it later?
Yes. Alan DeKok.
Hello Alan,
Why not just update the users credit when the session is closed?
Good question. The short answer is to charge as soon as possible.
Store the last "session length" for a session. If the current packet has a smaller session length, ignore the packet. Otherwise, look at the difference between the stored session length, and the session length in the current packet. Use that time for billing, rather than the time you received the packet.
That's the way it's implemented right now. Thanks
2. Is it a correct behavior of a NAS to store accounting information on it's internal disk if it can't get acknowledgment for accounting request/s and resend it later?
Yes.
How much time can it keep the data? I don't think it's a good idea to resend the data after several hours. Best Regards, George
participants (2)
-
Alan DeKok -
George Chelidze