[LEAPSECS] events? (was Fwd: TICTOC questionnaire)

[Rob Seaman]

Hi,

This questionnaire has been going around in support of the TICTOC  
effort.  I was taken by the very first question regarding the new  
protocol:


> PROTCOL DETAILS (those who do not feel we should develop a new  

> protocol may skip)

> *  What needs to be present in timing distribution packets ?

>   Only timestamp(s) ?

>   Internal algorithm parameters to improve accuracy ?

>   Events (leap seconds, etc)


First, one has to ponder whether any time distribution protocol  
actually transports timestamps, per se.  Rather a local clock is  
synchronized to remote clock(s), but the timestamps originate from the  
local clock.

But it struck me that we have often used language, as here, that  
treats a leap second as a physical "event".  This is not correct.   
(And I say this as chair of an international working group to describe  
astrophysical events, see http://voevent.org.)

An event implies a measurable quantity - a simple or complex data  
structure representing one or more empirically determined parameters.   
That is, the report of an event conveys dependent variable(s)  
expressed on a grid of independent variable(s), typically time.

As we have discussed long since, however, a leap second is purely a  
representational artifact superimposed on an underlying monotonic  
timescale.  Nothing "happens" at a leap second - at least, nothing  
that isn't introduced (rightly or wrongly) by our systems themselves.

Intercalary scheduling may provoke state transitions in our systems.   
These state transitions may employ some event driven design paradigm.   
But these are choices made by an architect, not requirements implicit  
in the system.

Rob Seaman
National Optical Astronomy Observatory
--

Begin forwarded message:


> From: "Odonoghue, Karen F CIV NSWCDD, W13" <karen.odonoghue at navy.mil>

> Date: June 13, 2008 8:56:19 AM GMT-07:00

> To: <ntpwg at lists.ntp.org>

> Subject: [ntpwg] FW: [TICTOC] TICTOC questionnaire

>

> Folks,

>

> As you are no doubt aware, there is a newly chartered working group  

> in the

> IETF in the area of time (tictoc). This questionaire is in  

> preparation for

> an interim meeting next week. If you are interested in these types  

> of questions,

> you should probably pay attention to that mailing list.

>

> Regards,

> Karen

>

> -----Original Message-----

> From: tictoc-bounces at ietf.org [mailto:tictoc-bounces at ietf.org] On  

> Behalf

> Of Stewart Bryant

> Sent: Monday, June 09, 2008 5:15

> To: tictoc at ietf.org

> Subject: [TICTOC] TICTOC questionnaire

>

> TICTOC Working Group

>

> The primary goal of the TICTOC meeting next week will be to generate  

> the

> TICTOC protocol requirements.

> We know that applications requirements drive protocol requirements,  

> and

> we will be looking for application based evidence to back up the

> protocol requirements, but we will not be using the application  

> network

> system tutorial approach that we have seen at the last three TICTOC

> meeings. We need to walk away from this meeting with the  

> fundamentals of

> the protocol agreed in principle.

>

> With that in mind we have compiled a set of questions that we think

> drive the protocol requirements. We request that you fill in as much  

> of

> the questionnaire  as  you are able before the start of the UK day on

> Friday 13th June, and we will summarize the responses ready for the

> meeting. That way we can start the meeting with some common

> understanding of what we agree on and what we need to resolve.

>

> Regards

>

> Yaakov and Stewart

>

>

> GENERAL

>

> * Name

>

> * Are you going to attend the upcoming interim meeting

>   A) in person

>   B) via dial-in

>

> * Relevant applications that interest you -

>

>   cellular backhauling

>

>   instrumentation / measurement

>

>   industrial

>

>   networking (e.g. instrumenting the net, or making

>   it work better/different)

>

>   time of day over the general purpose Internet

>

>   legal time

>

>   other

>

> * Which of the following best describes what you feel

>   TICTOC should do ?

>

>     1) define minor extensions to NTPv4

>     2) define 1588 profiles

>     3) define a new TLV-based protocol

>     4) define a new protocol with backwards compatibility

>        to NTP

>

> * What type of time do we need to distribute (multiple

>  answers are possible) ?

>

>  UTC?  Local time ?   TAI ?  arbitrary phase ?  others ?

>

>  What is the best format ?

>

>  Please address how other needed types of time are to be

>  derived (e.g. local time from UTC, leap-seconds, etc)

>

>

> * Should a separate "frequency-only" service be defined ?

>

>   What about a special "time when frequency is locked"

>   service ?

>

> * Should we divide the application space into categories

>   from stringent to undemanding ?

>

>  If so, how may categories and where are the dividing lines ?

>  Please consider

>      accuracy

>      resolution

>      aquisition time

>      Jitter

>      Wander

>

>  Are there other characteristics that would cause us to

>  consider the creation of an unique timing class?

>

> * It is proposed to separate protocols (standards-track)

>  from algorithms (informational). Do you agree ?

>

> * It is proposed that TICTOC exploit on-path support when

>   available, but be able to function (with reduced

>   performance) when it is not. Do you agree ?

>

> * It is proposed that TICTOC exploit special hardware in

>  server and clients, but be able to function (with

>  reduced performance) when it is not.  Do you agree ?

>

> * What scalability constraints do you envisage ?

>

>   Number of clients per server -

>   Number of servers on network -

>   Number of hops / maximum propagation time -

>

>

> * Is it acceptable for the time server to save state

>   of clients ?

>

>   How much memory and for how long ?

>

> * Which modes are required ?

>

>   broadcast

>   multicast

>   unicast

>   anycast

>

>

> * We need to support transport over (multiple answers

>   are possible) -

>

>   TCP/IP

>   UDP/IP

>   RTP/UDP/IP

>   DCCP/IP

>   Ethernet

>   MPLS

>   other

>   multiple domains with multiple protocols

>

>

> * How should client time be updated by TICTOC ?

>

>   by setting time to best estimate

>   by setting time but maintaining monotonicity

>   by slewing frequency

>

> * How are multiple sources of clock to be handled ?

>

>  Best clock selected by rating in packet

>  Best clock determined by calculation

>  combination of information from multiple clocks

>  completely distributed method

>

>

> PROTCOL DETAILS (those who do not feel we should develop a new  

> protocol

> may skip)

>

>

> *  What needs to be present in timing distribution packets ?

>

>   Only timestamp(s) ?

>

>   Internal algorithm parameters to improve accuracy ?

>

>   Events (leap seconds, etc)

>

>

> * It is proposed that time resolution of TICTOC

>   protocols be 1 picosecond.

>

>   Do you agree ?  If not - what resolution do you propose ?

>

>

> * It is proposed that the time be divided into two parts,

>   with 1 second being the dividing line.

>

>  The higher part is to be treated as data to be transported.

>

>  The dividing line is constrained by the ambiguity introduced by

> network propagation times.

>

>  Do you agree to the division ?  Do you agree to the

>  dividing line ?

>

>  What format should the fine granularity part be

>  (1/10, 1/2, other), and why?

>

>

> * What are the maximum and minimum update rates needed

>   to be supported ?

>

> * Is a profiling mechanism required ?

>

> * Are "follow-up" messages required ?

>

>

>

> NETWORKING ISSUES

>

> *  How should potential clients determine where to find

>    a time server ?

>

>    DNS ? DHCP ? new protocol ?

>

>

> *  How are on-path support elements discovered ?

>

>    How is an optimal path that exploits these elements

>    to be determined ?

>

> *  Should we distinguish between time delivered within an

>    AS and time delivered outside it?

>

>

>

> SECURITY

>

> * Which of the following authentication mechanisms is required ?

>

>   of server by client

>   of client by server

>   of middleboxes

>

> * What time source traceability is needed?

>

>

> * Is encryption of timing packets needed ?

>

> END

>

>

>

>

> _______________________________________________

> TICTOC mailing list

> TICTOC at ietf.org

> https://www.ietf.org/mailman/listinfo/tictoc

> _______________________________________________

> ntpwg mailing list

> ntpwg at lists.ntp.org

> https://lists.ntp.org/mailman/listinfo/ntpwg


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20080613/08a995b5/attachment.html>