Subject: [TICTOC] RE: new TICTOC charter page

From: "STUART VENTERS" <[email-masked]>
Date: Fri, 16 Nov 2007 10:25:49 -0600

Ron,

The most demanding emerging application seems a pretty high bar.
As you get close to it, somebody will always raise it.
(Consider keeping lawyers or physicists with the best possible transaction timestamps.)

I'd like to see TICTOC choose solutions for some achievable levels of accuracy and availability representative of a few specific applications.  Candidates include: synchronizing distributed computers (which ntp does pretty good), packet SLA measurement systems, telco legacy support, business transaction timestamping, and perhaps factory and military platform synchronization.  Priority should be given to solutions that work over packet paths reliably achievable with existing equipment.  If new equipment with on-path support is the only way to support an application, then TICTOC should say so.  (A solution means both the timing equipment requirements and also the packet path engineering required to support it.)

Availability doesn't have to be perfect, but rather as good as existing methods subject to backhoe, equipment failure, and vandalism.  This should leave enough wiggle room to allow well engineered methods depending on packet arrival statistics.  (Well engineered doesn't mean that they work perfectly with any PDV, it means that they meet the accuracy and availability requirements with any arrival statistics that the traffic engineered packet path can provide when it's not broke.)

Accuracy depends on application.  Nanosecond level accuracy is certainly achievable with packet timing hardware on each end of each link (aka on-path support).  It may turn out that Microsecond level accuracy is achievable without on-path support thru reasonable engineering of the packet path.  Millisecond level accuracy is already achievable over many packet paths.

Regards,

Stuart

<<<Ron Cohen said:

I have the opposite opinion.

TICTOC in my opinion must come up with a solution that provides
synchronization in the quality that will answer the most demanding
emerging application. In an non-accurate definition it must provide GPS
quality of time and frequency over PSN. In order to provide such timing
service such that service and telecom providers can rely upon it must be
proven that in any PDV the required performed is achieved. To do this
you must have on-path support. As I wrote in a previous email, the
on-path support does not have to be implemented everywhere across the
core, it needs to be implemented from the location time information is
available to the interface where it needs to be delivered. In essence I
believe that we should take a similar approach to 802.1as in spirit,
i.e. that the solution is fail proof and detailed (including the
algorithms). 

It is true that there are scenarios where the on-path support is not
available, or not available yet. In such environments synchronization
over packet can be delivered, with the understanding that the quality of
synchronization and the quality of assurance for this synchronization is
limited. I believe that for this purpose an IEEE1588v2 profile should be
built as well as NTPv4 solutions should be examined. I don't see how we
select one protocol over the other and therefore should probably, for
this scenario, promote both.

Best,

Ron>>>

_______________________________________________
TICTOC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tictoc