Re: question on algorithm for radius based accouting

[Ian Mason <nanog () ian co uk>]

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