Subject: [TICTOC] Section headings for requirements document

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 14 Apr 2008 10:45:58 +0300

Hi all, 
 
Stewart and I just finished merging the problem statement and Kurt's ITP
draft, 
together with all the requirements statements we found in presentations
given at the BOFs, and came up with the following proposed table of
contents
for the TICTOC requirements draft.
 
We suggest starting from these headings at the interim meeting in June. 
We encourage all of you to provide text for these sections.
Of course, suggestions for changes in the sections or subsections are
also welcome.
 
Y(J)S
 
========================================================
1 Introduction
2 Terminology
3 Application requirements 
  3.1 Time Service
  3.2 Frequency Service
4 Problems with Existing Time and Frequency Distribution Mechanisms  
  4.1 Non-packet distribution
  4.2 Packet distribution
5 Time scale issues
  5.1 Time definition and translations (TAI, UTC, local time)
  5.2 Required accuracy
  5.3 Resolution
  5.4 Time format
  5.5 Handling discontinuities (leap seconds, monotonicity, handover)
6 Network dependencies
  6.1 Layers and encapsulations (including MPLS)
  6.2 Path asymmetry
  6.3 Handling congestion
  6.4 On-path support
7 Network topology
  7.1 Autodiscovery
  7.2 Optimal path selection
8 Protocol requirements
  8.1 Scalability (memory, computation and rate constraints)
  8.2 Service requests (accuracy, update rate, etc.)
  8.3 Compatibility
  8.4 Extensibility (TLVs, etc.)
  8.5 Profiling
  8.6 Packet format
  8.7 Algorithm independence
  8.8 Multicast, unicast, anycast
  8.9 Robustness
9 Host API
10 Algorithms
  10.1 Best Master
  10.2 Frequency locking
  10.3 Ranging
  10.4 Mitigation (minimum gating, etc.)
  10.5 Clustering and combining
  10.6 Disciplining
11 Performance measurement and management
12 OAM
13 Network management
14 Supporting protocols (DNS, DHCP, IGP)
15 Security Considerations
  15.1 Client authentication 
  15.2 Server authentication
  15.3 Secure traceability
 
_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 14 Apr 2008 11:22:55 +0300

Yaakov and all,
Maybe it is worth to add a "Local oscillator dependencies" section to the table of contents?

While TICTOC definitely shall not develop anything in this area, understanding these dependencies (and, possibly, aligning the expectations of the quality of the recovered clocks with the requirements for the local oscillator quality) would be IMHO highly beneficial for the community.
For those who doubt whether such dependencies exist: consider two extreme uses cases:

 *   A client with a locally available PRC
 *   A client without any local reference clock.

(But do not expect me to write this section; rather, count me in the community that would benefit from such a section:-).

Regards,
           Sasha

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaakov Stein
Sent: Monday, April 14, 2008 10:46 AM
To: [email-masked]
Subject: [TICTOC] Section headings for requirements document

Hi all,

Stewart and I just finished merging the problem statement and Kurt's ITP draft,
together with all the requirements statements we found in presentations
given at the BOFs, and came up with the following proposed table of contents
for the TICTOC requirements draft.

We suggest starting from these headings at the interim meeting in June.
We encourage all of you to provide text for these sections.
Of course, suggestions for changes in the sections or subsections are also welcome.

Y(J)S

---

From: "FERRANT JEAN-LOUP" <[email-masked]>
Date: Mon, 14 Apr 2008 10:28:24 +0200

Yakov,
 
when  is the meeting finally?
 
Regards
 
Jean-Loup

De : [email-masked] [mailto:[email-masked]] De la part de Yaakov Stein
Envoyé : lundi 14 avril 2008 09:46
À : [email-masked]
Objet : [TICTOC] Section headings for requirements document

Hi all, 

 
Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 14 Apr 2008 13:00:03 +0300

Jean-Loup
 
As we have not heard anyone call out against this latest proposal
we are checking the availability of facilities in Paris for June 16 - 18.
 
Y(J)S

From: FERRANT JEAN-LOUP [mailto:[email-masked]] 
Sent: Monday, April 14, 2008 11:28 AM
To: Yaakov Stein; [email-masked]
Subject: RE: [TICTOC] Section headings for requirements document

Yakov,

Regards
 
Jean-Loup

Hi all, 

 
Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 14 Apr 2008 13:00:17 +0300

Sasha
 
Yes, I agree that the issue is an important one from the point of view
of performance
(certainly the performance of frequency recovery will depend on the
local oscillator)
but I am not sure how it fits into a requirements draft.
 
I don't see stating that the application requirements change based on
the frequency reference available.
 
Perhaps we can add to the algorithm section that if a good frequency
reference is available,
then time clients should make good of it.
 
Do you have any other idea ?
 
Y(J)S

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Monday, April 14, 2008 11:23 AM
To: Yaakov Stein
Cc: [email-masked]; Ronen Sommer
Subject: RE: Section headings for requirements document

Yaakov and all,
Maybe it is worth to add a "Local oscillator dependencies" section to
the table of contents?
 
While TICTOC definitely shall not develop anything in this area,
understanding these dependencies (and, possibly, aligning the
expectations of the quality of the recovered clocks with the
requirements for the local oscillator quality) would be IMHO highly
beneficial for the community.
For those who doubt whether such dependencies exist: consider two
extreme uses cases:

(But do not expect me to write this section; rather, count me in the
community that would benefit from such a section:-).
 
Regards,
           Sasha

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Yaakov Stein
	Sent: Monday, April 14, 2008 10:46 AM
	To: [email-masked]
	Subject: [TICTOC] Section headings for requirements document

	Hi all, 
	 
	Stewart and I just finished merging the problem statement and
Kurt's ITP draft, 
	together with all the requirements statements we found in
presentations
	given at the BOFs, and came up with the following proposed table
of contents
	for the TICTOC requirements draft.
	 
	We suggest starting from these headings at the interim meeting
in June. 
	We encourage all of you to provide text for these sections.
	Of course, suggestions for changes in the sections or
subsections are also welcome.
	 
	Y(J)S
	 
	4 Problems with Existing Time and Frequency Distribution
Mechanisms  
	  5.5 Handling discontinuities (leap seconds, monotonicity,
handover)

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 14 Apr 2008 13:24:54 +0300

Yaakov,
Actually I've had in mind something else.

The NTP people have been stating for quite some time (and, presumably, correctly), that NTP has been optimized to cope with a certain type of the local oscillator meeting some minimal requirements. And my gut feeling has always been that NTP could  produce better results with a better local oscillator (probably with a different algorithm).

Hence I suspect (and I may be quite wrong here), that there is a theoretical limit of what you can achieve with clock recovery assuming given the quality of the local local oscillator (and, possibly, some other measurable parameters, .e. frequency of the time-carrying packets).

If (and it is a BIG IF) such kind of a dependency exists, then exposing it would be surely be beneficial (similar to the energy conservation law that prevents some people from trying to build perpetuum mobile and some others - from the need to find specific bugs in the perpetuum mobile designs:-).

What do you think?

Regards,
            Sasha

________________________________
From: Yaakov Stein [mailto:[email-masked]]
Sent: Monday, April 14, 2008 1:00 PM
To: Alexander Vainshtein
Cc: [email-masked]; Ronen Sommer
Subject: RE: Section headings for requirements document

Sasha

Yes, I agree that the issue is an important one from the point of view of performance
(certainly the performance of frequency recovery will depend on the local oscillator)
but I am not sure how it fits into a requirements draft.

I don't see stating that the application requirements change based on the frequency reference available.

Perhaps we can add to the algorithm section that if a good frequency reference is available,
then time clients should make good of it.

Y(J)S

Yaakov and all,

Regards,
           Sasha

Hi all,

Y(J)S

---

From: "Stefano Ruffini" <[email-masked]>
Date: Mon, 14 Apr 2008 12:30:37 +0200

Hi ,
 
in the area of frequency synchronization the characteristics of the clock in the end system (as well as in all other network elements participating in the timign distribution), is the key element in terms of the overall perfomance that can be guaranteed/achieved  (I would say the most important). 
Requirements on the network are depending on the characteristics of the oscillators and viceversa. 
In particular, especially when packets are used end-to-end, the characteristics of the oscillator in the end equipment will define the tolerance in terms of packet delay variation.
 
In the area of phase and time synchronization (probably where we should mainly focus the efforts) , the role and characteristics of the oscillators deployed in the network depends on aspects that are still under study, but I expect that also in this area they play an important role.
 
As an example, when external references are not available,  the holdover of the local oscillator can guarantee performance levels that depend on the charcateristics of this oscillator.
 
Best Regards
Stefano 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: lunedì 14 aprile 2008 12.25
To: Yaakov Stein
Cc: Ronen Sommer; [email-masked]
Subject: Re: [TICTOC] Section headings for requirements document

Yaakov,

 
 
What do you think?
 
Regards,
            Sasha

	Sasha

	 

	Y(J)S

	Yaakov and all,

	 
	Regards,
	           Sasha

		Hi all, 

		 
		Y(J)S

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 14 Apr 2008 13:43:45 +0300

Stefano,
Lots of thanks for the input.
It is this kind of information (with details) that I would like to see in the proposed chapter.

Regards,
          Sasha

________________________________
From: Stefano Ruffini [mailto:[email-masked]]
Sent: Monday, April 14, 2008 1:31 PM
To: Alexander Vainshtein; Yaakov Stein
Cc: Ronen Sommer; [email-masked]
Subject: RE: [TICTOC] Section headings for requirements document

Hi ,

Best Regards
Stefano

Yaakov,

What do you think?

Regards,
            Sasha

Sasha

Y(J)S

Yaakov and all,

Regards,
           Sasha

Hi all,

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 14 Apr 2008 15:19:18 +0300

Sasha
 
There is a direct link between, on the one hand 
 - the stability of the local frequency reference
 - the update rate, and 
 - the amount of frequency information you get from each update (or
conversely the noise on the frequency information)
and, on the other hand
 - the frequency accuracy obtainable.
 
There is furthermore a direct link between 
 - the frequency accuracy of the (disciplined) local reference, and
 - the update rate
and
 - the time accuracy obtainable.
 
These are physical constraints, and are independent on the algorithm
used.
 
If this is what you meant, then I fully agree.
 
These points are indeed important to consider when planning a timing
distribution system,
but I still don't see how they fit into a requirements document
(unless we are placing requirements on basic physics and math ...)
 
Y(J)S

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Monday, April 14, 2008 1:25 PM
To: Yaakov Stein
Cc: [email-masked]; Ronen Sommer
Subject: RE: Section headings for requirements document

Yaakov,
 
The NTP people have been stating for quite some time (and, presumably,
correctly), that NTP has been optimized to cope with a certain type of
the local oscillator meeting some minimal requirements. And my gut
feeling has always been that NTP could  produce better results with a
better local oscillator (probably with a different algorithm).
 
Hence I suspect (and I may be quite wrong here), that there is a
theoretical limit of what you can achieve with clock recovery assuming
given the quality of the local local oscillator (and, possibly, some
other measurable parameters, .e. frequency of the time-carrying
packets).
 
If (and it is a BIG IF) such kind of a dependency exists, then exposing
it would be surely be beneficial (similar to the energy conservation law
that prevents some people from trying to build perpetuum mobile and some
others - from the need to find specific bugs in the perpetuum mobile
designs:-).
 
What do you think?
 
Regards,
            Sasha

	Sasha
	 
	Yes, I agree that the issue is an important one from the point
of view of performance
	(certainly the performance of frequency recovery will depend on
the local oscillator)
	but I am not sure how it fits into a requirements draft.
	 
	I don't see stating that the application requirements change
based on the frequency reference available.
	 
	Perhaps we can add to the algorithm section that if a good
frequency reference is available,
	then time clients should make good of it.

	Y(J)S

	From: Alexander Vainshtein
[mailto:[email-masked]] 
	Sent: Monday, April 14, 2008 11:23 AM
	To: Yaakov Stein
	Cc: [email-masked]; Ronen Sommer
	Subject: RE: Section headings for requirements document

	Yaakov and all,
	Maybe it is worth to add a "Local oscillator dependencies"
section to the table of contents?
	 
	For those who doubt whether such dependencies exist: consider
two extreme uses cases:

	(But do not expect me to write this section; rather, count me in
the community that would benefit from such a section:-).
	 
	Regards,
	           Sasha

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Yaakov Stein
		Sent: Monday, April 14, 2008 10:46 AM
		To: [email-masked]
		Subject: [TICTOC] Section headings for requirements
document

		Hi all, 
		 
		Stewart and I just finished merging the problem
statement and Kurt's ITP draft, 
		together with all the requirements statements we found
in presentations
		given at the BOFs, and came up with the following
proposed table of contents
		for the TICTOC requirements draft.
		 
		We suggest starting from these headings at the interim
meeting in June. 
		We encourage all of you to provide text for these
sections.
		Of course, suggestions for changes in the sections or
subsections are also welcome.
		 
		Y(J)S
		 
		  5.1 Time definition and translations (TAI, UTC, local
time)
		  5.5 Handling discontinuities (leap seconds,
monotonicity, handover)
		  8.1 Scalability (memory, computation and rate
constraints)

---

From: Danny Mayer <[email-masked]>
Date: Mon, 14 Apr 2008 22:45:02 -0400

Stefano Ruffini wrote:
> Hi ,
>  
> in the area of frequency synchronization the characteristics of the 
> clock in the end system (as well as in all other network elements 
> participating in the timign distribution), is the key element in terms 
> of the overall perfomance that can be guaranteed/achieved  (I would say 
> the most important).
> In particular, especially when packets are used end-to-end, the 
> characteristics of the oscillator in the end equipment will define the 
> tolerance in terms of packet delay variation.
>  
> In the area of phase and time synchronization (probably where we should 
> mainly focus the efforts) , the role and characteristics of the 
> oscillators deployed in the network depends on aspects that are still 
> under study, but I expect that also in this area they play an important 
> role.
>  
> As an example, when external references are not available,  the holdover 
> of the local oscillator can guarantee performance levels that depend on 
> the charcateristics of this oscillator.
>  

It's also dependent on the temperature of the oscillator which is 
constantly changing especially if it's not in a controlled environment. 
NTP has been shown to be sensitive to temperature fluctuations diurnal 
and otherwise.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Mon, 14 Apr 2008 22:30:56 -0400

> better local oscillator (probably with a different algorithm).

A local reference clock will always give you better results than 
anything you can provide over a network since there are fewer 
uncertainties, asymmetries, network congestion and delays and switches 
and routers to go through.

> Hence I suspect (and I may be quite wrong here), that there is *a 
> theoretical limit* of what you can achieve with clock recovery assuming 
> other measurable parameters, .e. frequency of the time-carrying packets).
>  

Yes there is a theoretical limit but it's not easy to figure out what 
that limit is and for each piece of hardware it's going to be different.

> that prevents some people from trying to build /perpetuum mobile/ and 
> some others - from the need to find specific bugs in the /perpetuum 
> mobile/ designs/:-)./
>  

There are always dependencies. How important they are is not always clear.

Danny

---

From: David R Oran <[email-masked]>
Date: Tue, 15 Apr 2008 13:45:05 -0400

I'm not sure if this is helpful in the requirements domain, but I'll  
throw it out anyway.

A number of the properties of the local oscillator and the system it  
is embedded in put accuracy bounds on the local clock and on the  
precision of the frequency/phase/time passed on to dependent clocks.  
This seems clear.

What may or may not have value are requirements on the protocol  
machinery and the distributed version of the algorithms to have  
accuracy bounds explicitly represented so you can know the expected  
clock accuracy at any given node.

If the above is useful, I believe there in fact protocol and system- 
level requirements on REPRESENTING the sources of inaccuracy and their  
contribution to clock accuracy even if there are not requirements on  
the oscillators themselves.

DaveO.

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 16 Apr 2008 16:56:32 +0300

Dave

The sources of inaccuracy of oscillators (e.g. termperature variation ,
aging, etc)
and methods for quantifying the oscillator's stability (Allen variance)
are well known.

Regarding the effect of these inaccuracies on TOD, while I agree with
Stefano that 
there is still some work to be done, the connection is pretty
straightforward
(see, for example, my presentation to the last ITSF conference).

If you really think that adding this kind of background material to the
TICTOC requirement
document would add to its usefulness, then let's do it.
However, I am not sure that this is really helpful.

Note that RFC 2680 manages to define packet loss very well without
describing the physical sources of errors in, e.g., fiber optic
transmission.
RFC 2662 defines managed objects for ADSL lines, without explaining
Shannon or water-filling or discrete multitone modulation.
And the NTP documents to date have been pretty useful without
the type of information being suggested here (although you can certainly
find discussions on Dave Mill's site).

Why does TICTOC need to be different ? 

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of David R Oran
Sent: Tuesday, April 15, 2008 8:45 PM
To: [email-masked]
Cc: Ronen Sommer; Alexander Vainshtein; [email-masked]
Subject: Re: [TICTOC] Section headings for requirements document

A number of the properties of the local oscillator and the system it is
embedded in put accuracy bounds on the local clock and on the precision
of the frequency/phase/time passed on to dependent clocks.  
This seems clear.

What may or may not have value are requirements on the protocol
machinery and the distributed version of the algorithms to have accuracy
bounds explicitly represented so you can know the expected clock
accuracy at any given node.

If the above is useful, I believe there in fact protocol and system-
level requirements on REPRESENTING the sources of inaccuracy and their
contribution to clock accuracy even if there are not requirements on the
oscillators themselves.

DaveO.

---

From: David R Oran <[email-masked]>
Date: Wed, 16 Apr 2008 10:11:11 -0400

> and methods for quantifying the oscillator's stability (Allen  
Sure.

> (see, for example, my presentation to the last ITSF conference).
Could you send a pointer?

> However, I am not sure that this is really helpful.
I'm not advocating adding the background material. I'm suggesting that  
we ensure the requirements cover the necessary protocol and system  
architecture elements that are needed to ensure that the contributions  
to clock accuracy bounds are explicitly represented in the system, for  
instrumentation, fault isolation, clock selection, etc. NTP does a lot  
of this. I don't know IEEE1588 well enough to know if it has  
equivalent better, or worse capabilities. When we glue these together,  
what happens to these elements? How should the requirements capture  
these items?

> describing the physical sources of errors in, e.g., fiber optic
Sure. I must not be communicating well. Sorry.

> find discussions on Dave Mill's site).
Sure, but here we're trying to create a system architecture that spans  
NTP and IEEE1588, and results in a Time transfer system for the  
Internet. My message was directed at whether we have holes,  
particlarly in how frequency/phase/time inaccuracy is captured by the  
protocol(s) and coordinated across the whole system (where "whole  
system" is the Internet, not one fiber transmission system or one set  
of coordinated wireless base stations).

> Why does TICTOC need to be different ?
It needs to do what it needs to do. I'm not concerned whether this  
winds up being the same or different.

Cheers, DaveO.

> is
> accuracy

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 16 Apr 2008 17:38:52 +0300

Yaakov and all,
Please see inline below.

Regards,
          Sasha

> Sent: Wednesday, April 16, 2008 4:57 PM
> To: David R Oran; [email-masked]
> The sources of inaccuracy of oscillators (e.g. temperature
> variation, aging, etc) and methods for quantifying the oscillator's stability (Allen
> variance) are well known.
>
> Stefano that there is still some work to be done, the connection is pretty
> straightforward (see, for example, my presentation to the last ITSF conference).
[Sasha] Can you send a pointer please?
>
> If you really think that adding this kind of background
> material to the TICTOC requirement document would add to its usefulness, then let's do it.
[Sasha], Well, I do think it would be helpful.
> transmission.RFC 2662 defines managed objects for ADSL lines, without explaining
> the type of information being suggested here (although you
> can certainly find discussions on Dave Mill's site).
>
[Sasha] AFAIK, the IPPM WG never had been chartered to design a protocol
that decreases packet loss, or a protocol that copes with a certain level of packet loss.
The TICTOC WG, on the other hand, is presumably going to come up (eventually)  with
some solutions for distributing frequency and ToD over the network. And, what's more,
these solutions presumably will have independent interoperable implementations.
To me it makes some difference, and information about a component of the solution that
has major impact on the expected performance of these solutions is most helpful.
> [mailto:[email-masked]] On Behalf
> Of David R Oran

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 16 Apr 2008 19:12:36 +0300

> Could you send a pointer?

Apparently the ITSF site is only open to conference attendees,
so I just put a copy of the slides on my own site
http://www.dspcsp.com/timing/SyncE_1588.ppt

The presentation is on a specific technique for combining SyncE and 1588
(or NTP for that matter)
but the mathematics used is more general.

Y(J)S