[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: accuracy of timestamps
Jo,
We have firm customer requirements for billing accuracy with 1 second
resolution. This is a regulatory requirement in some countries (German, for
example). To comply with the tariffs for the service they wish to offer, the
billing system must meet this requirement.
Regards,
Ed
Ed Van Horne
NMTG - San Diego
Cisco Systems
-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On
Behalf Of johan.rh.hermans@alcatel.be
Sent: Tuesday, June 15, 2004 8:03 AM
To: radiusext@ops.ietf.org
Subject: accuracy of timestamps
Hello,
in my current work, I've recently seen some requirements about the
accuracy of timestamps to be used in RADIUS, especially in VoIP
environments. Some managers (and customers) started to demand that we
would store the start of stop of a session with 0.1 second precision
(+/- 0.5 seconds). They didn't want to use the EventTimestamp attribute
(in seconds) or the time-of-arrival with a correction of AcctDelayTime
(not accurate enough, because we don't know the RTT).
I remember that there has been a discussion when DIAMETER was designed,
whether NTP-style timestamps should use used, but SNTP was chosen (also
in seconds). I agree with this decision (statistics and all), but
there's no argueing with my boss or the customers :-) The customers even
started to quote some legal requirements (for phone service), so maybe
some other implementors have seen the same problem. How did the 3GPP
people have solved this problem ? I'm currently using the original VSA
(they're not using EventTimestamp), specified in seconds, and I've added
another VSA for the milliseconds part.
A related question :
EventTimestamp is defined as the number of seconds since 1/1/1970 00:00
UTC. This is recognized by every programmer as the UNIX-style time()
systemcall ofcourse, which returns the timestamp in UTC. You would use
localtime() to translate this into a readable string, which would also
add the correct timezone-offset. In this way, all reports will be in the
timezone of the AAA-server, despite that the original RADIUS-packets
might be generated in several different timezones (think USA, Australia,
Russia, China).
But some vendors seem to have taken a different route, and seem to add
the timezone-offset themselves, so you can't use localtime(). This might
be because the NAS doesn't know it's own offset to UTC, and it running
his clock in localtime. A good NAS would ofcourse use NTP, and then it
would report everything in UTC. But we've seen networks that report
completly different timestamps for different NAS'es, which might be in
different timezones or plainly misconfigured. And nobody is using NTP
ofcourse (*).
Can we clarify that EventTimestamp should be in UTC, and should not
contain a timezone-offset ? Or if that's impossible to do, maybe we can
add another attribute that tells us wether EventTimestamp is in UTC or
in a local timezone.
(*) small anecdote : recently, an East-European customer was complaining
that we generated incorrect timestamps, always 4 hours later. At first
we though that their NAS wasn't using UTC-timestamps (as mentioned
above), but that didn't turn out to be the case (it would have given a 2
hour difference). He had installed his AAA-server in GMT+2, instead of
in GMT-2 (there's a difference between Windows and UNIX here !). This
means that his server was located somewhere west of Ireland :-) When we
asked him if he didn't use NTP, he replied that NTP was always
reporting an incorrect timestamp (always 4 hours later !), so he decided
to disable NTP-support on his server. The problem was ofcourse the
timezone-offset on the server, not the NTP-clock. The NAS was actually
correctly configured.
So we asked him to correct it, and to turn on NTP again. He refused,
because it would mean that he had to reconfigure several dozens of
servers. They're still running a large network with that error (I can't
name the customer, but it's a well-known name). In order to correct the
"error in our software", he has also now misconfigured the NAS. And did
the same on every server wherever there was some software (webserver,
database, billing software, ...) that had the same error. Sigh.
--
Jo Hermans
Change is inevitable, except from a vending machine.
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>