[ntpwg] FW: [TICTOC] TICTOC questionnaire

Fri Jun 13 15:56:19 UTC 2008

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