Subject: RE: [TICTOC] Draft BOF description

From: "Sasha Vainshtein" <[email-masked]>
Date: Mon, 15 Jan 2007 15:55:00 +0200

Stewart,
Lots of thanks for a prompt response.

Please see a bit more inline below.

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Monday, January 15, 2007 3:19 PM
To: Sasha Vainshtein
Cc: Alon Shtern; [email-masked]
Subject: Re: [TICTOC] Draft BOF description

> 2) Applications that require precision time with a greater accuracy 
> than is currently available with NTP implementations. An example is 
> the measurement of one-way packet delay in modern packet switched
networks.
> 
> [Sasha] I am not sure that "the measurement of one-way packet delay in

> modern packet switched networks" per se counts as an application. Can 
> we possibly have another example?
>

Why not? There are plenty of folks that want to measure network delay
and jitter. 
The advantage of using it as the primary application is that everyone at
the IETF understands it.

[Sasha] What I've tried to say that while high-precision frequency
distribution is a mandatory precondition 
for deploying mobile telephony cell sites using PSN technologies, I am
not aware of a similar case with 
the high-precision packet delay measurements (does not mean that these
cases do not exist).

However in a larger body of text I am preparing for a problem statement
draft I have also said:

===========

Although the measurement of the characteristics of a packet network is
the best known telecommunications example, there are other operational
needs, for to synchronise operations at the MAC layer. The cable
industry recently defined a new intra-PoP time transmission mechanism
for just this purpose (Docsys Timing Interface), and WiMAX is looking
for relative time delivery to its transmitter sites.

In the test and measurement and industrial sector there is a desire to
mover from purpose build communications infrastructure with calibrated
wiring being run back to a centralize controller, to a distributed
system, in which instructions are distributed in advance to be executed
at a predetermined time, and in which measurements are taken remotely
and communicated back to a common point for correlation and analysis. 
Two examples of this are described below.

In the printing industry there is a need to control operations in
multi-stand printing machines. The paper travels through these machines
with a speed of nearly 100Km/h. At these speeds a 1us co-ordination
error between operations taking place at different places in the machine
produces a 0.03mm color offset, which is visible to the naked eye and
results in an unacceptable degradation in quality.

In the electrical power industry there is a need to improve the
measurement of power flows. One proposal is to deploy synchrophasors
widely in the network and correlate their output to determine demand. 
These devices need to be able to determine the time of measurement with
an accuracy of 1us.

The examples cited above are a small illustration of a trend that will
continue to grow as engineers realize the better scaling that can be
achieved with the action in the future, measure and correlate later
approach to systems design.

[Sasha] I even think that at least the printing industry example will be
understood by most people in the IETF.
(Since I do not know what exactly a synchrophasor is, I reserve my
judgment on the universal understanding of the 2nd one:-)

=============

The above examples are very high level summary of the detailed
description of the problem space provided by John Eidson in his new book
on IEEE1588.

> [Note that we need to explain the issues with NTP as it exists today, 
> but we need to make it clear that at this stage we make no judgment 
> about the solution.
> 
>  From a number of conversations that I have had an enhanced NTP looks 
> a good bet - however, I think that we need to be careful to put the 
> problem description before the solution choice]
> 
> Other applications that would benefit from the provision of an 
> improved time service span a range of industries: financial, test and 
> measurement, government, industrial etc. The early work in these areas

> indicates that the availability of high accuracy time as a commodity 
> allows the use of techniques that were previously impossible.
> We can therefore expect that the provision of high quality time 
> through the network infrastructure will generate a spiral of new 
> innovative applications that will in turn make greater demands on the 
> quality of time delivered to the end-user.
> 
> Three types of time service may potentially be needed, time, phase and

> frequency. A time service requires an absolute time reference; a phase

> service requires that two points in the network co-ordinate with each 
> other in a time sensitive way, but do not need wall-clock time; and a 
> frequency service is one that synchronize the frequencies of two or 
> more oscillators.
> 
> [Sasha] Do we have an example of an application that requires phase 
> synchronization?

I tend to use the term phase sync when I should really say non-wallclock
time. Most of the automation and instrumentation applications only need
all components to have the same time. Reference to UTC and a short
rollover time are not important.

[Sasha] OK
> 
> The accuracy provided by the existing NTP implementations does not 
> satisfy the needs of the most demanding of the applications described 
> above.
> 
> [Sasha] From the previous informal discussions I got an impression 
> that the main reason for insufficient accuracy is the limit placed on 
> the frequency of the NTP exchanges. Assuming that this is correct it 
> is worth, IMHO, to include this kind of restrictions into the 
> requirements document and also possibly in the BOF description?

No, there are also issues with path asymetry, and variations in store
and forward time.

[Sasha] Is not the issue of the path asymmetry also a discriminator
between the LAN environment and the IP/MPLS one?
If yes, maybe it is worth mentioning as one of the arguments not to go
with 1588v2 (which, IMHO, is about high quality time transfer).

Some vendors claim to be able to do good frequency transfer under such
conditions, but I am not aware of anyone claiming high quality time
transfer.

If anyone thinks that we can correct these errors end to end in such a
way that we can also do good time transfer I would be interested in a
description of the approach and the parameters of their assumption.

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

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

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 15 Jan 2007 14:26:40 +0000

> the high-precision packet delay measurements (does not mean that these

Sasha - The previous section covered frequency, and you are correct
that it is needed for mobile cell site case. Packet delay measurements
are needed to ensure that the edge and core network are fit
for purpose in many applications, including the support of
circuit emulation.

Not that CDMA cell sites do need time as well as frequency
although at the moment they get time from GPS. WiMAX also
needs time.

> judgment on the universal understanding of the 2nd one:-)

Well I don't think that there is space in the draft to discuss it,
but there is direct relationship between the inability to measure
power distribution in the electricity network the famous 17 August 2003 
blackout of the eastern portion of the North American network.

I will see if I can find a time to scan in the paragraph, it's quite
an interesting case.

> between the LAN environment and the IP/MPLS one?

Depends what path split value you set when you do the pathsplit
calculation :)

Seriously there are also more subtle issues about the path length
and it depends on the accuracy required.

> with 1588v2 (which, IMHO, is about high quality time transfer).

We can certainly call up the path split issue, but 1588 also has
a unicast mode that is notconstrained to a LAN.

- Stewart