[radext] Re: Accounting overload with AP roaming

[Alan DeKok <[e-mail]>]

On Jul 3, 2026, at 2:22 AM, Alexander Clouter <alex=2Bietf=[e-mail]> wrote:
> Not trying to make this sound like a "but why haven't you just tried nerding harder", but for a time series database this is a niche they are very well suited for.
> 
> This can be complemented, or grafted onto an existing deployment by tiering your ingress. The front holds onto "live sessions" in a real-time database (RDB) and then flushes them to a historical database (HDB). This is a well used and understood pattern.

  And one which I've deployed lots.  The issue is that this design pattern solves a different problem.

> Those other operators still require non-coalesced Stop/Start/Update signalling. What should they do and how do they use the data?

  They should treat this like any other change of functionality.

  If we stop all progress because "it's a change", then we can't ever fix things.  And people who want to use this within their networks, on their equipment, will be forbidden from using it.

> I likely am mis-understanding and missing the simplicity here, but at the moment the only way I can see Periodic-Update working is to have a completely parallel event stream with its own Acct-Multi-Session-Id and Acct-Session-Id attributes so subscribers to that event stream get the data they expect.

  It shouldn't be a parallel stream.  It should replace start / interim-update / stop packets.

> I can see the attractiveness of reducing session count at source, but vendors (including Alan) are pushing the message "you do not know how to DB, we do, hire us to fix it" and then deploy tiering.

  Well, no.

  I've talked to people who are (1) using a custom RADIUS server purpose-built for their environment, and (2) using the whole modern stack with Kafka, real-time databases, etc.    They still disable accounting, because the stream of packets is too much.


  The idea that the efficiency doesn't matter is best exemplified by one vendor I worked with decades ago.  They had a mantra of "CPU is commodity, disk is commodity, memory is commodity".  They just wrote code under the assumption that faster systems would always make up for developer negligence.

  Big surprise, it didn't.  Other vendors with 1/10 the hardware outperformed them.  When the packet rates increased, the "big" vendor fell over, and the "small" vendor succeeded.

  Fast systems can always be overwhelmed when the input packet rate increases.    Dropping the load by a large factor is a potentially useful engineering solution.  It also lowers CAPEX because you need smaller systems to achieve the same load.

  Alan DeKok.