Subject: [TICTOC] FW: TICTOC questionnaire

From: "Tim Frost" <[email-masked]>
Date: Thu, 12 Jun 2008 06:54:40 -0700

This is the response from Greg and myself.
Tim

------------------

GENERAL

* Name - Tim Frost

* 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

   industrial

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

   time of day over the general purpose Internet - YES

   legal time

   other

* Which of the following best describes what you feel
   TICTOC should do ?

     1) define minor extensions to NTPv4 - POSSIBLY
     2) define 1588 profiles - YES, for relevant applications 
                              (don't duplicate what is happening in ITU)
     3) define a new TLV-based protocol - NO
     4) define a new protocol with backwards compatibility
        to NTP - NO

NEW  5) define what is needed to make time distribution over the network
        work properly, 
     e.g. discovery,
          routing protocol extensions, 
          protection, 
          redundancy architectures, 
          QoS techniques that don't destroy time accuracy, etc

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

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

  - ANY or ALL depending on application

  What is the best format ? - depends on application

  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 ? - YES, if
required
                                                          by the
application

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

* Should we divide the application space into categories
   from stringent to undemanding ?

  - YES, ITU is also taking this approach, see attached slide from Miami
Q13 meeting (WD19)

  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 ?

  - YES, but we shouldn't be developing new protocols. We should be
working
    out how to use the ones we already have.

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

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

* What scalability constraints do you envisage ?

   Number of clients per server - 1000s
   Number of servers on network - ?
   Number of hops / maximum propagation time - <10, don't know

* Is it acceptable for the time server to save state
   of clients ? - YES, make the servers do the heavy lifting where
possible.
                  Also useful for OAM and fault monitoring.

   How much memory and for how long ? - don't know

* Which modes are required ?

   broadcast
   multicast - YES
   unicast - YES
   anycast

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

   TCP/IP
   UDP/IP - YES
   RTP/UDP/IP - POSSIBLE
   DCCP/IP
   Ethernet - YES, but this isn't IETF domain
   MPLS - YES
   other
   multiple domains with multiple protocols

* How should client time be updated by TICTOC ? - TBD

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

* How are multiple sources of clock to be handled ? - TBD

  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)

STOP. DON'T DO IT. WE HAVE PROTOCOLS ALREADY!! (note plural)

NETWORKING ISSUES

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

    DNS ? DHCP ? new protocol ? - TBD

*  How are on-path support elements discovered ? - TBD

    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? - YES, since no control outside

SECURITY

* Which of the following authentication mechanisms is required ?

   of server by client - YES
   of client by server - TBD
   of middleboxes - TBD

* What time source traceability is needed? - FULL

* Is encryption of timing packets needed ? - NO

END

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

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 13 Jun 2008 13:23:23 +0200

>  - YES, ITU is also taking this approach, see attached slide from  

I didn't get any slides...

Best regards,

- kurtis -

---

From: "Tim Frost" <[email-masked]>
Date: Fri, 13 Jun 2008 05:59:07 -0700

Sorry Kurtis,

1. I forgot to attach it - sorry!
2. I'm not sure if I am allowed to attach it, since it is in an ITU
working document
3. The original was created by Stefano Ruffini of Ericsson, perhaps he
could send it in, since he will also attend the meeting

See you next week,
Tim

-----Original Message-----
From: Kurt Erik Lindqvist [mailto:[email-masked]] 
Sent: 13 June 2008 12:23
To: Tim Frost
Cc: [email-masked]
Subject: Re: [TICTOC] FW: TICTOC questionnaire

Best regards,

- kurtis -

---

From: "Stefano Ruffini" <[email-masked]>
Date: Mon, 16 Jun 2008 16:39:17 +0200

Hi,

here is WD19.

I could take some time to shortly present it during this meeting. 

Best REgards
Stefano 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim Frost
Sent: venerdì 13 giugno 2008 14.59
To: Kurt Erik Lindqvist
Cc: [email-masked]
Subject: Re: [TICTOC] FW: TICTOC questionnaire

Sorry Kurtis,

1. I forgot to attach it - sorry!
2. I'm not sure if I am allowed to attach it, since it is in an ITU working document 3. The original was created by Stefano Ruffini of Ericsson, perhaps he could send it in, since he will also attend the meeting

See you next week,
Tim

-----Original Message-----
From: Kurt Erik Lindqvist [mailto:[email-masked]]
Sent: 13 June 2008 12:23
To: Tim Frost
Cc: [email-masked]
Subject: Re: [TICTOC] FW: TICTOC questionnaire

Best regards,

- kurtis -

---

From: Danny Mayer <[email-masked]>
Date: Sun, 22 Jun 2008 22:53:33 -0400

> 2. I'm not sure if I am allowed to attach it, since it is in an ITU

If you are not allowed to attach it then you are not allowed to discuss 
it within an IETF working group. The IETF is based on open documents and 
all must have equal access to all relevant documents.

Danny