accuracy of timestamps

[johan.rh.hermans@alcatel.be]

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/>