Subject: Re: Time-stamp server. TimePrecision info

From: "Todd S. Glassey" <[email-masked]>
Date: Thu, 1 Apr 1999 18:45:25 -0800

-----Original Message-----
From: Robert Zuccherato <[email-masked]>
To: [email-masked] <[email-masked]>; 'Paul Koning'
<[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Thursday, April 01, 1999 10:59 AM
Subject: RE: Time-stamp server. TimePrecision info

>One point that I would like to clear up.  The present timestamping draft
>does not consider resolution of hours to be sufficient.  The reference to
>resolution of "less than a few hours" comes from an informative annex
giving
>an example of how the protocol could be used.  The resolution required by
>any particular application is not considered in the main document.
Remember
>this document describes just the protocol to be used by the TSA.
>
>That said, I agree with Denis.  I do not see the use of microseconds to be
>especially useful within this protocol.

OK Fine, but humor me - what's the harm in being able to represent them?

Todd

SNIP---

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 02 Apr 1999 10:28:06 +0200

> OK Fine, but humor me - what's the harm in being able to represent them?

 The TSA gets the clock first and then signs. I do not know any hardware
capable of signature in the micro-second range. The transmission delay is also
quite variable. The harm is giving false impression of precision.

Denis

---

From: Paul Koning <[email-masked]>
Date: Fri, 2 Apr 1999 10:31:12 -0500

>>>>> "Denis" == Denis Pinkas <[email-masked]> writes:

 Denis> Todd S. Glassey said:

 >>  >That said, I agree with Denis.  I do not see the use
 >> of microseconds to be >especially useful within this protocol.
 >> 

 Denis> The TSA gets the clock first and then signs. I do not know any
 Denis> hardware capable of signature in the micro-second range. The
 Denis> transmission delay is also quite variable. The harm is giving
 Denis> false impression of precision.

You just made an excellent argument for a precision field.  The
alternative is to infer it from the number of digits in the timestamp
itself, which is a kludge to say the least.  (For example, if you have 
a precision, or I would prefer to call it "tolerance" of +/- 10s,
would you omit the units digit of the seconds field?  That would be
correct but also very confusing.)

Transmission delay may or may not be variable depending on the channel 
used.  Signing may take more than a millisecond (or it may not; you
can buy chips today that will do it in 2 or 3, so you'll be able to do 
it in under a millisecond in a year or two).

But it's not a good idea to design the sizes of protocol fields so
they are just barely large enough for today's technology.  IPv4 at
least used 4 bytes rather than the 2 they would have used for host
addresses if they had used that approach.  A half dozen extra bytes
costs nothing, especially considering the size of a signature.  Better 
to future-proof the protocol by going AT LEAST down to microseconds,
or alternatively making the number of fractional seconds digits
unconstrained.

	paul

---

From: Stephen Kent <[email-masked]>
Date: Fri, 2 Apr 1999 11:32:08 -0500

Denis and Todd,

Do we agree that the timestamp represents the point at which a signature
was applied, independent of transmission delays and signing speed?  If so,
then I would not agrue against very fine granularity time stamps on thae
basis of thise delays. Instead, I would argue that there is a false sense
of precision being implied, and that we're better off just relying on the
sequence number to serialize time stamps issued by the same server within
the same tick.

If one believes that the time stamps have to represent finer granularity
because they will be compared with time stamps from other servers, then
there's a lot of work to do to convince me that the resulting
synchronization is feasible, and that there is a legitimate need for such.
Obviously the world lives with rather coarse precision and accuracy for
lots of business time stamp operations today.  maybe we need some
additional, credible, motivating examples.

Steve

---

From: Paul Koning <[email-masked]>
Date: Fri, 2 Apr 1999 12:47:05 -0500

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:

 Stephen> Denis and Todd, Do we agree that the timestamp represents
 Stephen> the point at which a signature was applied, independent of
 Stephen> transmission delays and signing speed?  

It seems to me it can only possibly mean one thing: it is the time
when the clock was read.  :-)  That time is later than the generation
of the request and earlier than the generation of the signature.

 Stephen> If so, then I would
 Stephen> not agrue against very fine granularity time stamps on thae
 Stephen> basis of thise delays. Instead, I would argue that there is
 Stephen> a false sense of precision being implied, and that we're
 Stephen> better off just relying on the sequence number to serialize
 Stephen> time stamps issued by the same server within the same tick.

It sounds like you're arguing that only significant digits should be
present in the timestamp.  The problem with that is that the server
has no way to do that, if you want to include network delays as part
of the tolerance implied by the digit count.

Better to indicate or document the various error sources explicitly.
Those the server knows about it can report if a tolerance (precision)
field is added.  Those relating to network latency the server cannot
know but the client can (bounded by delay between request and
response).

 Stephen> If one believes that the time stamps have to represent finer
 Stephen> granularity because they will be compared with time stamps
 Stephen> from other servers, then there's a lot of work to do to
 Stephen> convince me that the resulting synchronization is feasible,
 Stephen> and that there is a legitimate need for such.  Obviously the
 Stephen> world lives with rather coarse precision and accuracy for
 Stephen> lots of business time stamp operations today.  maybe we need
 Stephen> some additional, credible, motivating examples.

Synchronization of two devices to within a fraction of a microsecond
is perfectly feasible today.  Any GPS nav box does exactly that.

Given that it costs nothing to allow the extra digits, why is there
such a concern about doing that and future-proofing things?

	paul

---

From: Stephen Kent <[email-masked]>
Date: Fri, 2 Apr 1999 15:25:27 -0500

Paul,

>of the request and earlier than the generation of the signature.

A concise definition, but I think an unsatisfying one.  If the goal is to
compare time stamps from two servers who have very pricesly synchronized
clocks, as you note is easy to do with GPS, then internal processing delays
at each server seem likely to vary so much that very fine grained time
stamps cease being maeningful in many applications.  That's even before
asking about network delays.  So, I'm back to the last part of my previous
message.  Give us some examples where very fine grained time stamps from
different (synchronized) servers are meaningful.
	<snip>

>such a concern about doing that and future-proofing things?

Just because we CAN do something syntactically, that does not mean that we
should.  I'm a firm believer in trying to understand the implications of
the protocols that we develop, not just working on the details of the
protocols.

Steve

---

From: Paul Koning <[email-masked]>
Date: Fri, 2 Apr 1999 15:52:48 -0500

>>>> Paul, Denis and Todd, Do we agree that the timestamp
 >>>> represents the point at which a signature was applied,
 >>>> independent of transmission delays and signing speed?
 >>  It seems to me it can only possibly mean one thing: it is the
 >> time when the clock was read.  :-) That time is later than the
 >> generation of the request and earlier than the generation of the
 >> signature.

 Stephen> A concise definition, but I think an unsatisfying one.  If
 Stephen> the goal is to compare time stamps from two servers who have
 Stephen> very pricesly synchronized clocks, as you note is easy to do
 Stephen> with GPS, then internal processing delays at each server
 Stephen> seem likely to vary so much that very fine grained time
 Stephen> stamps cease being maeningful in many applications.  That's
 Stephen> even before asking about network delays.  So, I'm back to
 Stephen> the last part of my previous message.  Give us some examples
 Stephen> where very fine grained time stamps from different
 Stephen> (synchronized) servers are meaningful.

I suppose the definition I gave isn't terribly nourishing but it is, I 
think, the only possible honest one.  I suppose the question is "how
does that relate to externally visible events?"  That's easy to answer 
but only in terms of bounds and ranges of values.

Suppose I issue a request to a time stamp server at (local) time T1,
and get a reply at time T2.  The reply contains a timestamp S and an
error bound (precision, tolerance, whatever you call it) E.

So we know that the actual time S +/- E occurred sometime between T1
and T2 (with the assumption that both S and E are correctly
supplied).  In other words, T1 < S + E and T2 > S - E (and, of course, 
T1 < T2).  And that's all you know for certain.

If you make assumptions that may be warranted in *some* cases, such as 
roughly equal packet transit times each way, you can tighten this up
some.

Incidentally, this is very reminiscent of how you analyze time
synchronization protocols (not surprisingly).  Viewing things in terms 
of intervals is an approach you can find in the DEC Time Service
protocol spec; NTP borrowed some of that judging by notes in RFC
1305.

As for examples where fine grained time stamps are meaningful...

You can get time ticks accurate to a fraction of a microsecond today.
Real-time kernels can offer thread response times in the 10s of
microseconds or better (e.g., RT-Linux).  High end point to point
datalinks running at moderate utilization (e.g., full duplex 100BaseT) 
can provide latencies way below a millisecond for moderate size
packets.  And digital signature hardware can do decent size signatures 
in a millisecond or two.

So millisecond-accuracy timestamps from sets of servers can clearly be
meaningful today in some topologies, and sub-millisecond soon.

Does that mean that it makes sense from me to request sub-millisecond
resolution timestamps from ACME Timestamp Service, across the global
Internet, from my Win95 laptop?  No, but not all applications are like 
that.  If you have a real-time environment in a well-designed LAN
setting, fine grained timestamps are quite meaningful.  And, if you
want fine resolution time stamps for your real time process logs,
useful too.

	paul

---

From: Michael McNeil <[email-masked]>
Date: Sat, 03 Apr 1999 07:52:11 -0800

My comments below.

>>Stephen> == Stephen Kent <[email-masked]> writes:
>>>"Paul> == Paul Koning <[email-masked]> writes:

>>>Paul> It seems to me it can only possibly mean one thing: it is the
>>>Paul> time when the clock was read.  :-) That time is later than the
>>>Paul> generation of the request and earlier than the generation of
>>>Paul> the signature.

>>Stephen> (synchronized) servers are meaningful.

That's why every server's timestamps should include a precision field,
where these factors are taken into account in declaring how many bits of
the time data are significant.  This is basic scientific notation -- one
includes a statement of the precision to which the data are significant.

To answer your request for an example, Steve, I envision the widespread
timestamping of system and network events, which may need to be audited
in a post mortem following, say, a virus attack across many machines. 
If timestamps support a fine grained time resolution, then even events
which propagate within and between systems at computer speeds might be
identified and placed in their proper chronological sequence.

I say don't restrict timestamps to supporting only electronic analogues
of yesterday's paper processes (timestamping contracts, patents, etc.). 
It will be necessary to follow events operating at computer speeds.  The
potential (not mandatory!) resolution of timestamps should reflect this.

>roughly equal packet transit times each way, you can tighten this up

A number of probes of the time server will allow refinement of the
average round-trip latency -- refining, once again, the estimated
_precision_ of the time.  The timestamping server should then (I argue)
use this in stating the overall precision of the time in its timestamps.
The precision in timestamps must be kept in mind when comparing times
from two different (or even two timestamps from the same) time server.

This goes way beyond whether a microseconds or milliseconds field is
supported within timestamps.  Conceivably a timestamping server's time
might be off by seconds, perhaps many of them.  It could still issue
effective timestamps if it properly identifies how precise the time is.

>want fine resolution time stamps for your real time process logs,

I quite agree.  To my mind, some statements made in this discussion
suggesting there should be no microseconds or even milliseconds field
for time within timestamps are akin to suggestions that our numbering
system shouldn't contain a micro-th or pico-th digit.  Just because it's
possible in our numbering system to express a number down to the _nano_
level, say, doesn't mean anyone warrants that any particular number is
meaningful down to that level.  Instead, one identifies the degree to
which digits of the number are meaningful (with a + or - notation, say).

Let's not forget and have to relearn notational lessons which scientists
and (non-software) engineers have long since had -- in self defense --
to burn into their brain cells.  Let's also not create new "millennium"
problems where we might easily initially allow a wide enough field.

Especially, let's get off this idea that any number of bits of allowed
width for the time representation implies that is what's intended to be
meaningful.  In my view, NTP many years ago did it about right (for at
least the short-term foreseeable future) in allowing specification of
fractional time down to 2^(-32) second -- about 20% of a nanosecond.

I doubt that, even today, any time server approaches this resolution;
but the fact that the field width is set at this fine-grained level
allows any server to get as close as it possibly can.  And by NTP's
identifying how close (precise) it is, one knows what bits to trust.

I also like NTP's suggestion that bits beyond the limit of meaningful
precision in the fractional representation be filled in not with 0 but
by a random pattern.  This allows, for example, a client to identify its
echoed-back submitted time in the server's signed response as uniquely
its own most recent request (even when its own time precision is no
better than a second, say), helping defeat replay attacks and the like.

I suggest two possibilities:  1) use the NTP time format for seconds and
fractional seconds.  Or, 2) specify a nanoseconds subfield for the time
representation format in timestamps -- don't stop with microseconds.  As
an equally important requirement, include a statement of precision whose
format should cover the range from many seconds down to the nanosecond.

--
Michael McNeil
[email-masked]

---

From: Paul Koning <[email-masked]>
Date: Mon, 5 Apr 1999 10:17:25 -0400

>>>>> "Michael" == Michael McNeil <[email-masked]> writes:

 Michael> To answer your request for an example, Steve, I envision the
 Michael> widespread timestamping of system and network events, which
 Michael> may need to be audited in a post mortem following, say, a
 Michael> virus attack across many machines.  If timestamps support a
 Michael> fine grained time resolution, then even events which
 Michael> propagate within and between systems at computer speeds
 Michael> might be identified and placed in their proper chronological
 Michael> sequence.

That's a nice example.

It sounds like it describes a collection of general purpose systems.
That somewhat limits the meaningful precision of the timestamps
because of the sloppy schedulers used in such systems.

You can also apply the same sort of example to real time systems.
Consider a distributed real time control system.  Suppose something
goes wrong, and after the fires are put out and the bits of concrete
have been bulldozed away, people start picking through the logs trying 
to figure out what sequence of events made things blow up.  You need
fine grain timestamps so you can unambiguously follow the directed
graph of cause and event.  For real time systems, sub-millisecond
timestamps are perfectly meaningful.

	paul

---

From: Stephen Kent <[email-masked]>
Date: Mon, 5 Apr 1999 13:29:58 -0400

Paul,

>timestamps are perfectly meaningful.

That's more of what I had in mind when I asked for a concrete example.
However, in a realtime system, it is not clear that the audit trails need
or could tolerate the overhead of signing every log entry.  They might need
accurate local clocks for the logs, but do they need time stamps from
network accessible servers?

---

From: Stephen Kent <[email-masked]>
Date: Mon, 5 Apr 1999 13:45:47 -0400

Michael,

<snip>

>identified and placed in their proper chronological sequence.

This identifies a need for distributed, perhaps secure, time servers, but
not necessarily time stamp servers.

<snip>

>from two different (or even two timestamps from the same) time server.

The time stamp server may serve a variety of folks, and the delays may well
differ for each of them.  Also, I'm confused by the suggestion that the
server  use feedback from the clients to provide more accurate estimates
for the delays. The clients are not trusted to provide such info.

With regard to the issue of providing syntax to represenet increased
precision vs. our need for it at this time, I reiterate the comments made
earlier, and in a recent message to Todd.  I agree that it is tempting to
provide room for additional precision, but I worry that the syntax may be
abused in two ways:

	- leading users to believe there is more significance than the
application context warrants
	- allowing some vendors to trumpet their ability to offer increased
precision as an important differentiator, when the system context makes
such differences moot.

Steve