Acct-Delay-Time missing with RADIUS accounting

Alan DeKok aland at deployingradius.com
Mon Feb 22 13:14:28 PST 2016


On Feb 22, 2016, at 3:52 PM, Jouni Malinen <j at w1.fi> wrote:
> I was assuming that retries for Interim-Update would happen with the
> same timing as they do now, but instead of being retries with same
> statistics and new Acct-Delay-Time value, they would have new statistics
> and no Acct-Delay-Time (or 0 if we get to implementing Acct-Delay-Time
> for some cases).

  That's fine.

> In other words, if the attribute values are going to
> change, go ahead and update all the dynamic data at the same time. I
> don't really see why there would be need for retrying an Interim-Update
> with the old statistics.

  There isn't a need for old statistics.

  And (of course) RFC 2866 and later RFCs are silent on this topic.  :(

> Or is there some reason to avoid more frequent Interim-Update value
> updates?

  Every 5 minutes is lots.  More than that can be problematic.

  i.e. 10K users with 5 minute updates is ~30 packets/s.  20s updates are 500 packets/s.

> I'd assume not especially taken into account RFC 2869 language
> on NAS having option to override the interval and also use of a fudge
> factor on the interval..

  RFC 5080 Section 2.2.1 contains recommended behaviour for retransmits and jitter.  It doesn't, however, contain text about what to do when retransmissions overlap.

  I'll see if I can fix that:

http://www.rfc-editor.org/errata_search.php?rfc=5080

  Alan DeKok.




More information about the Hostap mailing list