Subject: [TICTOC] TICTOC questionnaire

From: Emmanuel Sicsik-Paré<[email-masked]>
Date: Fri, 13 Jun 2008 09:26:41 +0200

Dear all, 
 
Please find enclosed (as a word file), the filled questionnaire.
 
Best regards, 
 
Emmanuel Sicsik-Paré
_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

---

From: Peter Lothberg <[email-masked]>
Date: Thu, 12 Jun 2008 21:56:24 CEST

> GENERAL
* Name

Peter Lothberg

* Are you going to attend the upcoming interim meeting
   A) in person
   B) via dial-in

A

* Relevant applications that interest you -

   cellular backhauling

YES

   instrumentation / measurement

YES

   industrial

YES

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

YES

   time of day over the general purpose Internet

YES

   legal time

YES

   other

A format to describe a date while communication over the Internet

* 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

4 and TLV encode the new stuff

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

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

We need to distribute any Time or Phase, and identify what the source
is to be a general protocol.

To do time over the Internet we need UTC(k)

  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)

The question is TAI/GNSS or UTC timescales. (with or without
leap-second jumps)  Local time rules/notification is not a
time-protocol problem. (how about DHCP...)

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

   What about a special "time when frequency is locked"
   service ?

Who is confuced, me or someone else?

* 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?

All of the above is algorithm dependent, you can send packets, and you
can have "out-of-packet" time distribution ala 1588, but how the
packet looks, is kindof not the issue, as long as it carries enough
information at a rate needed for the chosen algorithm.

* It is proposed to separate protocols (standards-track)
  from algorithms (informational). Do you agree ?

If you want to do "time of day" over the internet, the algorithm has
to be standards track, it can still be separate from the protocol.

There are only two ways we can improve what's already avaliable;

      - Better algorithms
      - Media dependent HW support

* 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 ?

The Internet is based on IP, ip runs over any meadia that has a
mapping for how to transfer IP packets. The timing protocol has to
work over the Internet.

* 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 ?

It has to work over the Internet, over any existing or new media. 

If you have special requirements, it';s a media specific optimization
with or without hardware support.

TICTOC should have the "interface/api" to allow such support for
applications that require it.

* What scalability constraints do you envisage ?

   Number of clients per server -
    This is a traffic engineering problem, how much traffic per client
    and how many clients.

    I envision the prtocol to allow the servers (or peers) to flow
    control, admission control, resource control based on some policy
    implemented by the user

   Number of servers on network -

    Finance question.....

   Number of hops / maximum propagation time -
   ANY/ ANY

* Is it acceptable for the time server to save state
   of clients ?

   How much memory and for how long ?

   State might be required by authenthication shemes, again, it should
   be a resource management issue controled by the user, supported by
   the protocol. We are not building products.

* Which modes are required ?

   broadcast
yes
   multicast
yes
   unicast
yes
   anycast
What do we mean here?

* 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

  ****IP***** 

* How should client time be updated by TICTOC ?

   by setting time to best estimate
   by setting time but maintaining monotonicity
   by slewing frequency

Now we are confuced again, you have to decide if your client is to
recover time or frequency. 

If we recover time we need to generate a frequency that we use to
control the phase.

* 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

  This is Algorithm specific, and I guess each special application
  will have it's set of algorithms, in addition to the standardized
  time of day algorithm

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)

   - A TLV encoded protocol, if new algorithms want's to define new
     information. 

   - An event noticication method is needed

* It is proposed that time resolution of TICTOC
   protocols be 1 picosecond.

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

   - If we fix the packet format for time-of-day mode, 1 PS seems 
     logical.

     Some applications might require even better resolution in the
     speccific application, TLV.....

* 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.

I don't understand. The propagation delay is irrelevant as long as it
could either be estimated, or stays constant.

  Do you agree to the division ?  Do you agree to the
  dividing line ?

The best way of doing this is to define a datum format, for example
MJD, and then you say MJD,,fraction of day since midnight. Now the
resolution and precition can be arbritary.

So I disagree with the 1S..

  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 ?

Algorithm, Hardware, Resouce management deendent

* Is a profiling mechanism required ?

* Are "follow-up" messages required ?

They are a bad idea, as we do not have reliable transport at the IP level.

NETWORKING ISSUES

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

    DNS ? DHCP ? new protocol ?

    Any of the above, and you forgot that it's a well known multicast
    group that can be used for discovering the time servers today.    

*  How are on-path support elements discovered ?

    How is an optimal path that exploits these elements
    to be determined ?

General Internet problem, not specific to TICTOC

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

SECURITY

* Which of the following authentication mechanisms is required ?

   of server by client
   of client by server
   of middleboxes

YES

* What time source traceability is needed?

You want to knew where it came from, and how it was transfered from
the real clock to the TICTOC protocol

* Is encryption of timing packets needed ?

It's an IP protocol, don't we already have generic encryption
protocols that can be used?

END