Subject: [TICTOC] TICTOC questionnaire response

From: "STUART VENTERS" <[email-masked]>
Date: Tue, 10 Jun 2008 17:21:12 -0500

Stewart,

I think the survey is a good idea.
  Hopefully more folks will take the time.

Regards,

Stuart

GENERAL

* Name
    Stuart Venters

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

* Relevant <new> applications that interest you -

   cellular backhauling   
     <Yes, both cdma with the TOD requirement 
      and just plain T1 transport with only the frequency requirement>

   networking 
     <Yes, TOD support for Ethernet OAM.
      (If having precision TOD helps making QOS work on the Internet, that would be interesting as well.)>

   other
     <Yes, timing of remote telco network elements which are fed by an Ethernet.
       (Historically a frequency transport application, but these days it's probably a TOD app.)>

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

     1) define minor extensions/<refinements> to NTPv4
     2) define 1588 profiles
     3) define a new TLV-based protocol
     4) define a new protocol with backwards compatibility
        to NTP <and/or 1588>

  <Short answer: probably 1, probably 2, definitely not 3, marginally possibly 4.>

  <We need a timing transport method which is competitive with GPS.
   Until vanilla packet switches provide on-path support,
     expecting such support seems a pipe dream except in special circumstances.
   That says we need to run without such support and there's little need to negotiate for it.
     (Of course this could change if an Ethernet switch chip vendor decided to do something.)>
   
  <TICTOC needs to sort out the situation with 2 protocols.
     Making yet another seems like the wrong direction.  
     Aside from negotiating on-path support,
       I don't see a new feature desire which would justify anything aside from refining what is already there.
     (Of course one example could change that.)>

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

    <The kind I get from GPS, sometimes just the frequency.
     Either NTP or 1588 format is fine.
     If GPS leaps, we need to follow suite.>

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

   <If would be useful if a server could say it knows the frequency, but not the time.
     This doesn't seem like a separate service, just a status of the existing ones.>

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

   <If a client has frequency, but the time is coming over a poor packet path,
     then sure, it can get the "time when frequency is locked".  Again, this doesn't seem like a special 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?

 <I think the metrics to define an application class are:
	Does it need TOD? If so, how close to GPS does it need to stay. (maybe in RMS and peak seconds)
      Does it need frequency? If so, what is the wander limit. (maybe in MTIE and TDEV)
      What acquisition time is required.  (maybe max time in seconds)>

 <I'm not sure that Jitter is needed as a part of a protocol spec since it can be filtered out outside the spec.
  I think accuracy and resolution are covered in closeness to GPS and the wander limit.
  If an application needs wander from an unknown but fixed offset to GPS, 
     then that seems like frequency which is also covered.>

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

  <In the Telco space, to make a stable chain for timing transfer, it's necessary/customary to constrain the PLL response at each link in the chain.  This seems likely with packet timing as well, and so should be part of the protocol.  Where the current spec goes way past this, it could be a separate informational RFC or just a 'may' in the standards-track one.>

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

   <On-path support is-great/should-be-used if you can get it,
      but so far, it doesn't seem to be getting much market traction (see above).
    Unfortunately, some applications won't work on some packet paths without it.  
    I think we need to figure out how to support the target apps with as little on-path support as possible,
      but provide a way to use it if it is available.>

   <If an application requires on-path support, but TICTOC doesn't have it, then TICTOC (as always) should deliver the best time it can but also provide the application with an approiate status.  Whether the app decides to continue to function or give up under these circumstances should be outside the TICTOC scope.>

   <Almost more importantly, we need to document when and where it is required for the target apps.>

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

  <I'm not sure I understand why if someone implements a part of an endpoint in software of special hardware should affect the spec.  It seems like what is important is what the implementation does, not how it does it.>

* What scalability constraints do you envisage ?

   Number of clients per server - <Perhaps hundreds to a thousand at the edge.>
   Number of servers on network - <Perhaps only 2 at the edge, use more if they are available.>
   Number of hops / maximum propagation time - <Perhaps a few (3-6) switches, RTT is often bigger than accuracy requirement.>

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

   <Would rather not.>

   How much memory and for how long ?

* Which modes are required ?

   broadcast
   multicast  <Maybe>
   unicast    <Yes>
   anycast

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

   <In short, less is more here.>

   TCP/IP   <No, the extra services it provides don't seem helpful to the problem at hand.>
   UDP/IP   <Yes>
   RTP/UDP/IP  <No, we have enough time stamps already.>
   DCCP/IP   
   Ethernet <Probably for 1588>
   MPLS     <No>
   other    
   multiple domains with multiple protocols

* How should client time be updated by TICTOC ?

   <For the time delivered by TICTOC to the application, I'm not sure why a protocol spec should care.>
   <For the time passed from node to node inside TICTOC, best estimate.>

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

* How are multiple sources of clock to be handled ?

  <For the time delivered by TICTOC to the application, I'm not sure why a protocol spec should care.>
  <For the time passed from node to node inside TICTOC, best estimate.>

  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)
<skipping>

* What are the maximum and minimum update rates needed
   to be supported ?
      <If there are few clients, then on a Gig link 100 or 1000 packets per sec is not a significant load.
        This may permit operation on paths which are otherwise hopeless.
        I think this needs to be supported between consenting units on a path engineered to handle it.>

* Is a profiling mechanism required ?

* Are "follow-up" messages required ?
      <For the 4 timestamp NTP client/server handshake,
           I think not for T1 because what the client puts in the request packet for T1 doesn't matter.  
       For the server T3 stamp, although it is not absolutely necessary, it might be nice, especially with crypto.
       It's also handy for some modes of on-path support.>

NETWORKING ISSUES

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

    DNS ? <Maybe> DHCP ? <Yes> new protocol ? <NO>

*  How are on-path support elements discovered ?

    <I think for now, until we can support the target apps with manual configuration and there is a reasonable likelihood of having on-path support, then on-path discovery should be tabled.>

    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  <Yes, optionally>
   of client by server  <No, unless someone has an example where it seems reasonable to have.>
   of middleboxes       <If you mean the boxes in the middle providing the on-path support, then Yes if the client is authenticating the server, it have to get the on-path boxes as well.>

* What time source traceability is needed?
   <Probably depends on the app, but if the app expects to be locked to GPS, then it needs to know if the timing path traces back to GPS or not.>

* Is encryption of timing packets needed ?
   <No, unless someone has an example where it seems reasonable to have.>

Regards,

Stuart Venters
Adtran

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