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" <[EMAIL PROTECTED]>
Date: June 13, 2008 8:56:19 AM GMT-07:00
To: <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
Of Stewart Bryant
Sent: Monday, June 09, 2008 5:15
To: [EMAIL PROTECTED]
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
[EMAIL PROTECTED]
https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________
ntpwg mailing list
[EMAIL PROTECTED]
https://lists.ntp.org/mailman/listinfo/ntpwg
_______________________________________________
LEAPSECS mailing list
[email protected]
http://six.pairlist.net/mailman/listinfo/leapsecs
