Subject: [TICTOC] Answer to questionnaire

From: "FERRANT JEAN-LOUP" <[email-masked]>
Date: Fri, 13 Jun 2008 10:34:27 +0200

Stewart,

Here is the answer from Michel and myself.

Regards

Jean-Loup

General comments:
-In many parts of this questionnaire, the terminology refers to NTP or
1588; the Tictoc terminology needs to be defined asap.
-Are any of the questions related to existing patents?
-This questionnaire has been sent prior to the decision to develop a new
protocol

* Name
Michel Le Pallec, Jean-Loup Ferrant
* Are you going to attend the upcoming interim meeting
   A) in person :                            yes
   B) via dial-in

* Relevant applications that interest you -

   cellular backhauling                   yes

   instrumentation / measurement                 no

   industrial no

   networking (e.g. instrumenting the net, or making 
   it work better/different) 	                 yes

   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 		No
     2) define 1588 profiles	 in collaboration with other SDOs
(ITU-T...)
     3) define a new TLV-based protocol  Why not but this is no a
priority (second or third step)
     4) define a new protocol with backwards compatibility
     to NTP and IEEE1588 : first analyse performance of 1588/NTP with
on-path support

* What type of time do we need to distribute (multiple
  answers are possible) ?

  UTC? Yes     Local time ?   TAI ?  arbitrary phase ? May be   others ?

  What is the best format ?                     Is it so important now
at this step?

  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 ? 
As "Frequency only service" addresses the main needs of the mobile
market: yes,  but emerging wireless technologies are TDD oriented with
stringent time requirements

   What about a special "time when frequency is locked"
   service ? Should be In the Profiling space (with syntonization
support)

* Should we divide the application space into categories
   from stringent to undemanding ? Yes, but this is not in the Tictoc
charter which is focusing on highly accurate time and frequency
distribution

  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 ? Why not, particularly
if algorithms are already  developed (NTPV4 algorithms)

* It is proposed that TICTOC exploit on-path support when   available
On path support availability is questionable, On path support  has to be
clarified as well 
but be able to function (with reduced
   performance) when it is not. Do you agree ?
 No. Tictoc  focuses on highly accurate timing  Thus reduced performance
should not be acceptable in case of problem inside the on-path support
(ex mobile networks).
 Alternately, it might be possible to define classes of performance.

* 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 ? 
Unclear.  Special hardware in server/client has been understood as
"source of timing" and applications requirements/specifications. Thus,
this topic should be  an input of Tictoc

* What scalability constraints do you envisage ?
depends on different applications
   Number of clients per server -
   Number of servers on network -
   Number of hops / maximum propagation time -
Time distribution and Frequency distribution have to be considered
separately  for scalability issues. 

* Is it acceptable for the time server to save state
   of clients ? looks NTP terminology
Many applications, many answers

   How much memory and for how long ?

* Which modes are required ?

   broadcast
   multicast
   unicast
   anycast
For highly accurate time distribution, unicast mode should be the first
to consider. Frequency distribution modes are  more questionable
considering the expected level of performance
Depends on applications and possible classes of performance

* We need to support transport over (multiple answers
   are possible) -

   TCP/IP                 why not, what is the main interest? Messages
are sent periodically
   UDP/IP                 yes
   RTP/UDP/IP         no, NTP is already addressed
   DCCP/IP              Interest to be clarified 
   Ethernet (L2)       not in the TICTOC WG 
   MPLS                   yes
   other
   multiple domains with multiple protocols   yes

* How should client time be updated by TICTOC ?

   by setting time to best estimate,                               Not
enough deterministic
   by setting time but maintaining monotonicity,           Yes, but
depends on level of  time correction land clock update rate
   by slewing frequency:                                 may depend on
On-path Support relationship

* How are multiple sources of clock to be handled ?

  Best clock selected by rating in packet;                 metric? Some
are under definition in ITU
  Best clock determined by calculation
  combination of information from multiple clocks                  No
  completely distributed method

PROTCOL DETAILS (those who do not feel we should develop a
new protocol may skip)
Need for a new protocol still pending

*  What needs to be present in timing distribution packets ?

   Only timestamp(s) ?                             Timestamps are
mandatory

   Internal algorithm parameters to improve accuracy ?
Why not

   Events (leap seconds, etc):                leap seconds should be
suppressed shortly by ITU-R

* It is proposed that time resolution of TICTOC
   protocols be 1 picosecond.                   Is it realistic
considering hardware features?

   Do you agree ?  If not - what resolution do you propose ? study
application requirements to define resolution.

* 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 are the requirements?

  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 ?                  Depends on clock hardware
(stability...) and applications

* Is a profiling mechanism required ?
Profile/profiling has to be defined in the Tictoc context (different
from the IEEE1588V2 context)

* Are "follow-up" messages required ?
Not relevant at the requirements step, we are at the requirements stage
not at the solution stage

NETWORKING ISSUES

*  How should potential clients determine where to find
    a time server ?

    DNS ? DHCP ? new protocol ? 

*  How are on-path support elements discovered ?
Elements/parameters to be discovered has to be defined/clarified

    How is an optimal path that exploits these elements
    to be determined ?                 depends on  Network specification

*  Should we distinguish between time delivered within an
    AS and time delivered outside it?   yes

SECURITY

* Which of the following authentication mechanisms is required ?

   of server by client                yes
   of client by server                 yes
   of middleboxes                      to be clarified

*	What time source traceability is needed?               First
define time source traceability, is a quality level needed?

* Is encryption of timing packets needed ? inter-operator issues

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