Subject: [TICTOC] TICTOC questionnaire

From: Stewart Bryant <[email-masked]>
Date: Mon, 09 Jun 2008 10:15:04 +0100

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
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

---

From: David R Oran <[email-masked]>
Date: Mon, 9 Jun 2008 10:18:22 -0400

Here's my questionnaire response. Note that my response is as an  
individual contributor wity strong interest in the work and its  
outcome, *not* as an IAB member.

> * Name
David Oran
> * Are you going to attend the upcoming interim meeting
Neither, unfortunately. My schedule got too crazy. See you in Dublin!
>   instrumentation / measurement
Yes, particularly for media applications with short term accuracy in  
the 100s of microseconds or better and very low long-term drift.

>   it work better/different)
Yes, particularly in the ability to timestamp packet generation/ 
arrival/departure to accuracies in the 10's of nanoseconds.

>   time of day over the general purpose Internet
Yes. This is in fact my highest priority usage. Related to this is to  
have one time standard that can scale to different accuracies in  
frequency, phase, and ToD over different physical networks, sub-nets,  
and links without needing different protocols, APIs, etc., and only  
requiring on-path support in order to increase accuracy to the needs  
of particular applications.

>   legal time
No, except TICTOC needs to be resilient to attack and have protocol  
support for secure identification (authentication?) of clocks.

>     4) define a new protocol with backwards compatibility
Between (1) and (4) I have a preference for (1).
I support (2) as long as it interoperates seamlessly with NTP. My  
preference is to do (2) in the context of a protocol running over a  
single NTP "hop" as a way to improve the accuracy of NTP.

>  UTC?  Local time ?   TAI ?  arbitrary phase ?  others ?
I think UTC and TAI are mandatory. Others can/should be accommodated  
if it does not unduly complicate the protocol or the overall system.
>  What is the best format ?
No opinion.

>  derived (e.g. local time from UTC, leap-seconds, etc)
Although I don't have a strong opinion here  I would not be  
disappointed if TICTOC decided to punt the local time issue entirely.  
since leap-seconds are a global variable, I don't see any technical  
barrier to handling this in the protocol as the means to represent  
both TAI and UTC.

> * Should a separate "frequency-only" service be defined ?
No opinion.

>   What about a special "time when frequency is locked"
No opinion.

>   from stringent to undemanding ?
No strong opinion, but I am somewhat queasy about binning because it  
causes arguments at the edges of the bins and may lead to  
interoperability problems, especially if derivative standards choose  
poorly or in an incompatible fashion. We've seen this in other  
domains, e.g. IEEE 802.1 QoS classes versus IETF PHBs.

>  from algorithms (informational). Do you agree ?
Agree, with the proviso that it is OK to have things in the standards  
track protocol documents which put cnstraints on the classes of  
algorithms and their externally-measurable properties.

>   performance) when it is not. Do you agree ?
Yes, except I would put it the other way around. "TICTOC must be a  
fully functional internet timing protocol without requiring on-path  
support for any of its functions, but may exploit on-path support when  
available for improved accuracy and performance." There is a subtle  
mind-set difference between the two formulations which I think matters.

>  reduced performance) when it is not.  Do you agree ?
Yes, with the same sense reversal above: "TICTOC must be a fully  
functional internet timing protocol without requiring hardware support  
in servers and /or clients for any of its functions, but may exploit  
such hardware when available for improved accuracy and performance."

>   Number of clients per server -
No Opinion.
>   Number of servers on network -
No Opinion.
>   Number of hops / maximum propagation time -
I'm not sure this is a first-order scaling property. It has two  
visible effects (possibly more)
a) settling time
b) transitive trust weak-link problems.
I'd like to see more discussion on these.

> * Is it acceptable for the time server to save state
I think this question is not well formulated. Use of per-client state  
is a tricky protocol design issue and needs to be traded off against  
all sorts of other properties. I'd rather go down the design path  
having decided this too soon.

> * Which modes are required ?
All other than broadcast. I see no need for broadcast given all  
interesting networks support multicast over a broadcast infrastructure.

> * We need to support transport over (multiple answers
Seems awfully tricky - I'd give this low priority.
>   UDP/IP
For backward compatibility. does not need to be a "first class citizen"
>   RTP/UDP/IP
Yes.
>   DCCP/IP
Yes.
>   Ethernet
No (as long as you mean without IP)
>   MPLS
No (as long as you mean without IP).
>   multiple domains with multiple protocols
Define "domain" in the context of TICTOC. Can't answer until you do.

>   by setting time but maintaining monotonicity
By any of those depending on client configuration.

>  completely distributed method
No opinion.
> PROTCOL DETAILS (those who do not feel we should develop a
Skipping for now but if we need to visit any of these you should re- 
ask these questions.
>    DNS ? DHCP ? new protocol ?
Yes, Yes, plus anycast. Possibly SRVLOC. Possibly ZeroConf/Bonjour.  
Definitely not a new protocol if TICTOC is the only user.
> *  How are on-path support elements discovered ?
No strong opinion, but either the discovery protocol or a query/ 
initialization capability in TICTOC itself should explicitly  
communicate the capabilities of the server. It may be useful to  
communicate client configuration/capabilities to the server as well.

>    How is an optimal path that exploits these elements
Need a clear definition of "optimal". There are multiple dimension to  
the optimality:
- best long term accuracy
- best short term frequency
- lowest communication overhead
- most trustworthy.

>    AS and time delivered outside it?
No. AS is a routing concept.

> * Which of the following authentication mechanisms is required ?
Both server an mutual seem necessary. Unidirectional client by server  
does not seem necessary unless somebody believes time is a sensitive  
quantity from a privacy perspective :-)

>   of middleboxes
If we design a protocol that needs middleboxes, I'll scream. If we  
think we need to support "trivial server/client" implementations I can  
support that, especially if it's an alternative to middleboxes.
> * What time source traceability is needed?
The best we can obtain within reason and without seriously  
compromising accuracy or robustness.

> * Is encryption of timing packets needed ?
I can't think of a good reason. On the other hand, I can't think of a  
reason to not allow it.

DaveO.

---

From: "Pietilainen, Antti (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 11 Jun 2008 17:10:13 +0300

Please find my response below. Note the X's identifying selections.
Best regards, Antti

>* Name
Antti Pietilainen
>   A) in person  X
>   cellular backhauling X
>     2) define 1588 profiles   X
As the only existing precision time standard, I see 1588 as the right
starting point. IEEE 802.1AS did that selection too instead of defining
a new method or trying to tweak NTP.   
>  derived (e.g. local time from UTC, leap-seconds, etc)
Depends on application. At least TAI.
>
>
>* Should a separate "frequency-only" service be defined ? X
Frequency sync can typically work out well without intermediate node
support. Time sync at mobile network precision requires intermediate
node support in almost all cases. Therefore, one needs to consider the
two problems.
>   What about a special "time when frequency is locked"
Sorry, don't understand.
>   from stringent to undemanding ?
I personally pursue max. 200-300 ns accuracy loss over the network (for
WiMAX). If others tell their requirements, then we would see the spread
of requirements.
>  If so, how may categories and where are the dividing lines ?
Limit discussion about these topics if possible. Accuracy and resolution
are included in existing time protocols, ITU-T Q13/SG15 covers jitter
and wander specs.
>  consider the creation of an unique timing class?
I don't fully understand the question. Probably no need to create a
unique timing class.
>  from algorithms (informational). Do you agree ?
Agree. I propose to leave algorithms out of scope altogether. Of course,
one has to have algorithms in mind to decide upon packet rates, etc.
>   performance) when it is not. Do you agree ?
That's should be pursued (and 1588 does it).
Yes.
>   Number of clients per server - Answer: a few thousand
>   Number of servers on network - Answer: a few per mobile network
>   Number of hops / maximum propagation time - Answer: Max. 20.
Propagation time depends on the speed of light and required service etc.
Let's say 50 ms max, < 5 ms preferred.
Yes.
No opinion.
>* Which modes are required ?
Multicast and unicast
>   UDP/IP   X (especially over Ethernet)
>   RTP/UDP/IP
>   DCCP/IP
>   Ethernet
>   MPLS     X e.g. UDP/IP/(Ethernet) over MPLS
>   other    X Typical stacks expected for leased lines
>   multiple domains with multiple protocols X The stack could grow by
two MPLS headers and decrease back before reaching destination. VLAN
tags could come and go on the way.
>   by setting time but maintaining monotonicity
Implementation specific, i.e. out of scope
>  completely distributed method
Use best master clock algorithm or select by management.
>
>
>PROTCOL DETAILS (those who do not feel we should develop a new 
>protocol may skip)
>
(skipped)
>    DNS ? DHCP ? new protocol ?
Configured through management or use best master clock algrorithm (if
multicast)
>    How is an optimal path that exploits these elements
Best master clock algorithm if multicast, otherwise maybe by management.
No opinion.
>* Which of the following authentication mechanisms is required ?
No opinion at this stage.
>* What time source traceability is needed?
I suppose most applications require the same time as available through
GPS. 
>* Is encryption of timing packets needed ?
No

---

From: [email-masked]
Date: Wed, 11 Jun 2008 10:36:36 -0700

I agree with Antti.

Regards,

Pat

             "Pietilainen,                                                 
             Antti (NSN -                                                  
             FI/Espoo)"                                                 To 
             <antti.pietilaine         <[email-masked]>                
             [email-masked]>                                                 cc 
             Sent by:                  [email-masked]                     
             tictoc-bounces@ie                                     Subject 
             tf.org                    Re: [TICTOC] TICTOC questionnaire   

             06/11/2008 07:08                                              
             AM                                                            

Antti Pietilainen
Sorry, don't understand.
Yes.
Yes.
No opinion.
Multicast and unicast
(skipped)
No opinion.
No

---

From: "Alex Tal" <[email-masked]>
Date: Thu, 12 Jun 2008 15:03:13 +0300

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stewart Bryant
Sent: Monday, June 09, 2008 12:15 PM
To: [email-masked]
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 Alex Tal

   A) in person - X
   B) via dial-in

   cellular backhauling X

   industrial

   legal time

   other

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

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

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

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

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

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

   of clients ? N

   broadcast
   multicast Y
   unicast Y
   anycast

   TCP/IP Y
   UDP/IP Y
   RTP/UDP/IP Y
   DCCP/IP Y
   Ethernet Y
   MPLS Y
   other
   multiple domains with multiple protocols Y

Not sure I understand the defitions above ...

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

   Only timestamp(s) ?

NETWORKING ISSUES

SECURITY

   of server by client Y
   of client by server Y
   of middleboxes T

* Is encryption of timing packets needed ? Optional

END

---

From: Al Morton <[email-masked]>
Date: Thu, 12 Jun 2008 13:53:58 -0400

Stewart,

This is response based on David Oran's reply,
but slightly modified.

Thanks for your response, Dave.
We seem to have some common needs,
so this a pseudo +1.

Al

> > * Name

Al Morton

No

> > * Relevant applications that interest you -

Yes

>the 100s of microseconds or better

By short term, I would say T ~= 900 seconds.

>and very low long-term drift.

By very low long-term,
I would say delta-t ~= 0.002 sec and T ~= 86400 seconds.

This (measurement/instrumentation)
is my (Al's) highest priority use-case.

>arrival/departure to accuracies in the 10's of nanoseconds.

I think I can settle for 1's of microseconds on this.

> >   time of day over the general purpose Internet
<Dave's description deleted.)

> >     4) define a new protocol with backwards compatibility

I can live with any of these, but with a preference for
NTPv4 compatibility.

>interoperability problems, ...

So, looking at the continuum of well-formed numerical requirements from
many applications, if the fairly clear categories emerge, then
the categorization makes sense.  If not, then not.

> >   Number of clients per server -

~1000

---------- <no other modifications below!> ---------------------------

---

From: "Laurent Montini (lmontini)" <[email-masked]>
Date: Thu, 12 Jun 2008 23:04:20 +0200

GENERAL

* Name	MONTINI

   A) in person	Yes
   B) via dial-in

   cellular backhauling			
Yes

   industrial				
Example? otherwise IEEE1588 is available

   time of day over the general purpose Internet	
Potentially
we can either maintain NTP (distinct protocols) or define same standard
we should target the solution to support such application 

   legal time
Potentially
if security is required then we can define one standard
we should target the solution to support such application

   other

Note: for each relevant application, we may distinguish different levels
(e.g. in wireless area).

GIVING PRIORITY

Better to leverage what already exists.
However I would not like defining TICTOC protocol by twisting another
protocol for the only reason it exists.
 
     1) define minor extensions to NTPv4		1 (using
improvement from PTP)
     2) define 1588 profiles				1 
To be considered as P1.
     3) define a new TLV-based protocol		3 
     4) define a new protocol with backwards compatibility
        to NTP						2 (using
improvement from PTP)

IEEE1588 (or even NTP) profile would be P1 for frequency only, but then
it can be done as an ITU-T profile based on PTP profile - a PTP profile
description (IEEE1588 parameters only) would not be sufficient for
telecom.
However for time, I'd like first assessing the requirements (not only
from apps perspective only but from architecture viewpoint) against PTP
protocol and not try making use of shoehorn to define a PTP profile(s)
for telecom time delivery. If PTP and possibly PTP improvement can be
done without breaking PTP, then 1588 profile can become suitable. 
At least options 4 & 3 would demand defining properly the telecom
requirements (not apps reqts which are rather known).

  UTC?  			yes
  Local time ?   		Definition? 
				Assuming independent timescale and
epoch, yes
  TAI ?  			yes
  arbitrary phase ?  	Definition? Assuming PPS, yes
  others ?

No opinion

No opinion

* Should a separate "frequency-only" service be defined ?
Not the most critical concern. This can be handled by a TP profile at
ITU-T.
However if specific protocol requirements as such as O&M, security are
listed for frequency, it would be worth working on unique solution.

* Should we divide the application space into categories
   from stringent to undemanding ?
Definition of consumer profiles may be interesting but may drive to too
many options.
If too many options, this could increase operation cost.
If targetting only most stringent category support for all apps, this
could increase CapEx.
It may be up to operator to choose either supporting multiple categories
or a subset and using the most stringent category for different (not
all) apps.

No opinion.
Should category include other functions (e.g., security, management)?

* It is proposed to separate protocols (standards-track)
  from algorithms (informational). Do you agree ?
	YES
	However algorithm shall be considered along with metrics.

* 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
On-path support shall not be mandatory.
On-path support should be used to improve the performance.
On-path support functions shall be defined distinctively.
On-path support improvement shall be bounded (min) and measurable.
Client should be able to know (at setup or later) if any on-path support
is available.

I'm not sure this is relevant. This should be an implementation
decision. However a client may want to know if server (and intermediate
nodes) have specific hardware assistance.
So it shall work without special HW, the impact being the performance
and hence the adequation of the implementation wrt the category.
However if the definition of the hardware has an impact on the protocol
(not the reverse) thus I would revise my opinion.

   Number of clients per server -	
Probably dependent on the mode of transmission and category - from
multiple 10's to 1000's

   Number of servers on network -	
Not sure this is relevant except if considered from a specific angle,
e.g., from client viewpoint (how many servers the client can
see/handle), i.e., if there is a relationship with a service

   Number of hops / maximum propagation time - 
Yes
Description/characterization of the hops functions & performance is
critical; no opinion on propagation time. Max hops numbers will surelly
depend on the category (apps reqt) and on hops capabilities.

No opinion for server but would prefer not.
To be considered separately but not acceptable for (some form of)
on-path support (when applicable)

   Broadcast	No
   multicast	Probably Yes, but utilization to be clearly bounded
(e.g. link only)
   unicast		Yes
   anycast		Probably Yes

   TCP/IP		not for the freq/time transfer, possibly for O&M
   UDP/IP		maybe - P2 
   RTP/UDP/IP	yes
   DCCP/IP		yes
   Ethernet		is that under IETF scope? yes if this is IPoEth
(obviously)
   MPLS		maybe - P2; need to consider the T/S function
   other
   multiple domains with multiple protocols
multiple domains: yes (i.e. crossing distinct operators and/or time
domain) 
multiple protocols: i.e. time protocol IWF?

No opinion; may depends on application or category

No opinion; may depends on application or category

   Only timestamp(s) ?
Depends if separate O&M or control plane.

?

   Do you agree ?  If not - what resolution do you propose ?
No opinion. If new protocol, I have no objection.

TBD

Definition?

NETWORKING ISSUES

TBD; Probably dependent on application, category, domain/management
(i.e., sync service from provider). Thus can be both. Maybe ESMC. 

TBD. By O&M incl. maybe ESMC.

Can include on-path support element function and performance (as when
describing source clock quality, other parameters or criterias may be
defined for on-path support).

If AS means an operator (what AS does not mean), yes. 

SECURITY

   of server by client		
yes
   of client by server		
maybe (e.g. for O&M)
   of middleboxes
Probably if middleboxes mean on-path support elements.

Definition?

Don't think so.

END

---

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

> * Name

Kurt Erik Lindqvist

> * Are you going to attend the upcoming interim meeting

In person

>   other

Does that matter? I believe we need a better protocol for all the  
above applications, and we need to be able to run it over an IP  
network that we don't know the topology of. What we should do is  
gather the requirements from those applications in numbers and work on  
the best possible protocol from that....

>      3) define a new TLV-based protocol

A new TLV based protocol.

>  derived (e.g. local time from UTC, leap-seconds, etc)

Taken from draft-kurtis-tictoc-itp-req-00.txt :

9.  Time scale

    ITP uses a single timescale but should support a local timescale by
    signaling in the response to the client that there is additional
    information used.  The reasoning behind this construct is that a
    client should be able to retrieve actual time in a single packet
    exchange with the server.  The server however, needs a mechanism to
    tell the client that additional information would be needed in order
    for the client to process the data correctly (if that is indeed the
    case).  The additional information could also be "additional"
    information, i.e information that the server is aware of, but that
    won't affect the interpretation of the timescale in question.  The
    server will need a mechanism to distinguish between these two types
    of additional available information.  This data for any specific
    application can for example be a offset and rate of change of the
    offset.

    The client will request for the additional data upon receipt of the
    flagged answer.

    The ITP timescale will either be UTC with correct handling of leap
    seconds or a timescale that do not have leap seconds GNSS-time or
    TAI.

    If a timescale other than UTC is chosen, the ITP server has to be
    capable of providing the offset to UTC.

9.1.  Concerns for picking a time scale

    At the time of writing, there are really only hree time scales of
    importance for ITP, TAI, UTC and GPS time.

    GPS time is of course really a realization of TAI but with the 19
    second UTC offset present when the GPS scale was started.  As for
    TAI, since 1972, UTC and TAI have just differed by integer steps.

    It's worth observing that most users of precise time really want
    syntonization, not synchronization, so they don't really care about
    leap seconds, except as a nuisance that must be dealt with from time
    to time.  (GPS time is an excellent example; they care very much
    about being on Atomic Time, but not at all about the 19 seconds.)   
So
    it seems there are really only 4 choices when it comes to which time
    scale to base ITP on

    1.  Ignore time scales.  We will make the clients follow whatever  
the
        master says.  Effectively, this would mean that the clocks would
        be mostly set to UTC, but large offsets (seconds, hours, even
        days) would be possible.  Time transfers on an isolated network
      would be no trouble with this choice, but if the master clock had
        a leap second, time interpolation may have problems.

    2.  Adopt TAI.  This seems attractive, but really most clocks don't
        keep TAI, so it would mean either that every time transfer would
        have to have a leap second conversion or we would have to set up
        a world wide set of NTP like servers with TAI.  It also might
        cause difficulties if you want to do time transfers on an
        isolated network.  (The same is true for GPS time, which really
        has no reason to recommend it.)

    3.  Adopt UTC.  This is the NTP solution, but with a flag to allow
        for good interpolation / smoothing over leap seconds.

    4.  Adopt the full catastrophe.  Display UTC, use TAI for any
        interpolation / smoothing.  Realistically this means you need
        tiers or classes of service.  Class 1 would be with leap  
seconds,
        i.e., with outside information, Class 2 would be for isolated
        networks, and would thus mean that you are close to UTC at the
        start, but may have second level offsets over time.

    The optimal choice will depend on the likely users.  Metrology  
people
    tend to view ITP as something they provide, not something they use,
    so they don't care too much that it doesn't provide TAI.  If you
    think that TICTOC can get to the sub-microsecond level where the
    metrology people would use it, the best picks seems to be either
    choice # 4.  As the TICTOC WG should strive for an agnostic use
    approach, as well as high-quality this is the recommended pick.

10.  Event Flag (Leap seconds)

    In the ITP protocol, the server MUST be capable of setting a flag
    telling the client that there is more information for the client
    about an event.  The client will then start an exchange to follow up
    what the event is.

    This mechanism could be used to signal for example leap seconds.

    All the special events MUST have a TTL to reduce traffic.

I think that keeping the protocol agnostic to leap seconds but leave  
that as a flag mechanisms leaves for better protocol design than to  
hardwire it into the protocol.

>   What about a special "time when frequency is locked"

Do you mean a separate protocol? If so no.

>  from algorithms (informational). Do you agree ?

Yes. Not sure why algorithms would have to be informational though.

Yes.

Yes.

>   Number of hops / maximum propagation time -

Not sure I understand what you mean by scalability here ?

> * Is it acceptable for the time server to save state

I don't think it can be assumed they could (DoS).

> * Which modes are required ?

As in client/server communication? Well, unicast seems straightforward  
and anycast is normally simply leaving the server selection to the  
routing system. I guess there could be applications in multicast for  
this, but I am not sure.

>   multiple domains with multiple protocols

UDP over IP seems the most reasonable.

>  completely distributed method

Best clock selected by rating in packet, but if you have that I am not  
sure what the difference between that and your other alternatives?

Yes.

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

Yes. Packet resolution does not cost anything in this case.

> * What are the maximum and minimum update rates needed

This should be controllable by the server.

> * Are "follow-up" messages required ?

If the client decide it needs them.

>    DNS ? DHCP ? new protocol ?

Exitign configuration methods are enough and out of scope for tictoc.

>    How is an optimal path that exploits these elements

Not sure what you mean with optimal path. If there is support on a  
link that should be used on that hop. This is IP, we route per hop not  
on connections...

>    AS and time delivered outside it?

First of all I don't think an AS is necessarily the boundary here,  
organizational boundaries might be, but I don't think we should be  
making topological requirements or assumptions.

> * Which of the following authentication mechanisms is required ?

As proposed in the ITP draft,

7.  Secure identification of time source

    ITP MUST be able to support secure identification of a time source,
    such as a UTC(k).  The ITP protocol must also be able to  
authenticate
    the reference time.  The authentication certificate will be sent  
upon
    client request or by the server to client.

    Secure transfer client-server-client without (too much) server  
state.

> * What time source traceability is needed?

It should be noted what

> * Is encryption of timing packets needed ?

No.

Best regards,

- kurtis -

---

From: "Stefano Ruffini" <[email-masked]>
Date: Fri, 13 Jun 2008 13:49:47 +0200

Hi Stewart,

some inputs on the list of questions are provided below .

A general consideration is that several questions are heavily depending on the target requirements (sub-microsecond time sync ; 100 microsecond time sync , etc.) and arrangment in the network (end-to-end vs. methods with support from the transport network, e.g Boundary clocks in PTP or Stratum Clocks in NTP) .
Some more thinking on relationship between application requirements and how these would be reflected on the "requirements" for the packet based sync methods will probably be requried.
However when reducing the scope for th application,  some initial answer can be provided (see below) .

Best Regards
Stefano Ruffini

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: lunedì 9 giugno 2008 11.15
To: [email-masked]
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 Stefano Ruffini

   A) in person YES
   B) via dial-in

   cellular backhauling YES

   instrumentation / measurement YES

   industrial

   time of day over the general purpose Internet YES (is there a need for further studies on this point ?)

   legal time

   other

     1) define minor extensions to NTPv4 YES (this is the most deployed protocol in telecom , any application that can work with NTP or backward compatible modifications would certainly take advantage of NTP extensions).
     2) define 1588 profiles  cooperation with ITU-T is beneficial
     3) define a new TLV-based protocol Perhaps (if needed)
     4) define a new protocol with backwards compatibility
        to NTP  Perhaps if needed)

Note that "sub-microsecond applications" will involve special studies for instance related to IEEE1588 BC/TC or similar NTP functions.

The Time format should be flexibile.
It shall be noted that some application require continuous time scale (this means that leap second can be a problem: either easily accessible information on the leap seconds number or a protocol without leap seconds ) .

The main scope should be time and phase . 
For the relevant applications, Frequency can either be distibuted via non-packet based methods, or in case packet based methods are used, no specific work on the protocol should be required.

Definitely different considerations apply deopending on the application and related requirements.
The submicrosecond time-phase and 10-100 microseconds time-phase type of requirements shall be the focus.
See also previous answer.

YES

On-path support definition should be better clarified ; it currently involves too much different concepts.
The general understanding is that for some application/requirement (e.g. sub-microseconds phase-time sync), some "on path support " is required (excluding very special cases).

Server and client contribution to the overall perfomance is probably most significant when the network provides some "on path support" and the target is sub-microsend phase-time .

In the end to end solutions (packets carried trasparently over the packet network) , the contribution from the server is less significant (packet jitter in the network is the major contributor to the total "noise").

In any case the Client functions are fundamental (e.g. oscillator quality) .

Architectural aspects shall be investigated . These may depends on several factors  and on the application.

   broadcast
   multicast
   unicast
   anycast

To be investigated

   TCP/IP
   UDP/IP
   RTP/UDP/IP
   DCCP/IP
   Ethernet
   MPLS
   other

IP , MPLS, Ethernet, UDP/IP , RTP/UDP/IP 
are the main cases. Others may apply.

This will depend on applications and related requireemnts during failures in the sync distribution (e.g. "Time Holdover" aspects need some investigation)

To be investigated

I will come back for aspects covered in follwing session (lack of time)

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

   Only timestamp(s) ?

Leap seconds in case of UTC shall be presented. 

  The dividing line is constrained by the ambiguity introduced by network propagation times.

NETWORKING ISSUES

SECURITY

   of server by client
   of client by server
   of middleboxes

END

---

From: [email-masked]
Date: Fri, 13 Jun 2008 08:14:44 -0400

Stewart ,

Here are my answers.

Thanks,

Silvana 

Stewart Bryant <[email-masked]> 
Sent by: [email-masked]
06/09/2008 05:15 AM
Please respond to
[email-masked]

To
"[email-masked]" <[email-masked]>
cc

Subject
[TICTOC] TICTOC questionnaire

TICTOC Working Group

TICTOC meetings. We need to walk away from this meeting

Regards

Yaakov and Stewart

GENERAL

* Name 
Silvana Rodrigues

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

   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 - Yes

   legal time - No

   other

     1) define minor extensions to NTPv4 - this could be done within 
TICTOC
     2) define 1588 profiles - this should be addressed at TICTOC in 
conjunction with the work in ITU. Coordinate the work with ITU to make 
sure we get the best out of the two groups. 
     3) define a new TLV-based protocol - NO, we really do not need 
another protocol
     4) define a new protocol with backwards compatibility
        to NTP - NO, we really do not need another protocol

  UTC?  Local time ?   TAI ?  arbitrary phase ?  others ? - It depends on 
the application

  What is the best format ? - It depends on the application

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

   service ? - Yes

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

  If so, how may categories and where are the dividing lines ? - Please 
note that some of these are covered by ITU work.
  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 may or may not be 
necessary depending on the application

* It is proposed to separate protocols (standards-track)
  from algorithms (informational). Do you agree ? - Yes,we should work 
with the current protocols available and the algorithm should be out of 
scope.

* 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, I think there are 
some issues with Transparent clock, so TICTOC may work on that.

* 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 ? - It will depend on the 
application, for instance for femtobasestations the number I have heard is 
1000s of slaves, and it is different for other applications. 

   of clients ? - Yes

   How much memory and for how long ? - It depends on the implementation 

* Which modes are required ? - Multicast and Unicast

   broadcast
   multicast
   unicast
   anycast

   TCP/IP 
   UDP/IP - Yes
   RTP/UDP/IP - Yes
   DCCP/IP
   Ethernet - Yes
   MPLS - Yes
   other

* How should client time be updated by TICTOC ? - It depends on the 
application and implementation of the client.

* How are multiple sources of clock to be handled ? - It depends on the 
application. For instance Industrial Automation will use best clock 
algorithm, but other applications may use a different method.

PROTCOL DETAILS (those who do not feel we should develop a
new protocol may skip) - We SHALL NOT develop a new protocol

<skipped>

NETWORKING ISSUES

*  How should potential clients determine where to find
    a time server ? - This is an open issue that needs to be addressed.

*  How are on-path support elements discovered ? - This is an open issue 
that needs to be addressed.

    How is an optimal path that exploits these elements
    to be determined ? - It depends on the application

*  Should we distinguish between time delivered within an
    AS and time delivered outside it? - No opinion 

SECURITY

   of server by client - Yes
   of client by server
   of middleboxes

* What time source traceability is needed? - It depends on the application

* Is encryption of timing packets needed ? - NO

END

---

From: "Odonoghue, Karen F CIV NSWCDD, W13" <[email-masked]>
Date: Fri, 13 Jun 2008 13:16:35 -0500

Stewart/Yaakov,

I just reread this message are realized the answers were due today.
I also forwarded it to the ntp group before rereading it...You can 
defer my answer and any potential answers from the ntp wg if you
can't get them processed in time. I was caught up in trying to 
resolve the answer to question 1, which I still can't answer...

This was answered over several quick sessions and I haven't got
time to sanity check it...

Karen

-----Original Message-----
GENERAL

* Name

Karen O'Donoghue

Good question. I'm planning to be there in person, but I won't
know for sure until possibly the end of today. Visa issues 
(caused by my organization not France...) I will either be
there in person or (as a last resort) via dial-in. 

   cellular backhauling - not directly 

   instrumentation / measurement - yes

   industrial - yes, in as much as that environment tends to resemble a
military platform

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

   time of day over the general purpose Internet - yes

   legal time - no 

   other

First 2, then 1 - but I understand Kurt's comment... there are two
possible
approaches... 
1. The clean slate approach
Define the requirements then engineer the solution. 
This is the perfect world right answer, but I'm not sure we are in a
perfect world. 
2. Leverage existing solutions
Identify incremental improvements and additions...
Given the marketplace reality and the capabilities of the group, this
may be the
way we need to go. 
I don't think we have enough consensus in the IETF to take the first
approach. 

Unless we redefine NTP or PTP this is already determined.
Additionally, I'm not sure that it matters that much as long as
the appropriate conversion algorithms are implemented. 
It should be either TAI or UTC with a perfect world preference for TAI.

Again... not an issue unless we are redefining one of the existing
protocols. 
If we are, I would defer to the hardware engineers to answer this one. 

My applications require UTC for policy reasons and monotonicity
for application requirements. Maybe someday UTC will be monotonic. 

I don't currently have a need for this in the applications I represent,
but I understand that others do. 

Yes

Yes

Yes

   Number of clients per server - yes
   Number of servers on network - yes
   Number of hops / maximum propagation time -

Total number of clients (general internet today)

I think it is easier to define scalable solutions if you don't
do this. As for how much memory and for how long, I defer to
chip designers. 

   broadcast
   multicast
   unicast
   anycast

This question seems a bit premature to me. I'm not sure 
how to answer it. 

   TCP/IP
   UDP/IP
   RTP/UDP/IP
   DCCP/IP
   Ethernet
   MPLS
   other

One of the first four... 
MPLS

Wouldn't this be part of the local clock algorithm. 
How the correction gets applied may not be a protocol or
interoperability issue. For my applications, I believe
the answer is setting time if the error is greater than
a TBD threshold and slewing frequency when the error is
less than that threshold.  

This depends on so many factors that I'm not sure how to answer.
The protocol needs to be able to automatically select from multiple
sources of clock based on a algorithm that determines the best source
taking into account scalabity and stability. I think what I am saying
is a combination of items 2 and 3 above. 

Even if I didn't feel that we should leverage the two existing
protocols,
I think these questions are a really premature. Having said that I
did a quick cut at preliminary answers

   Only timestamp(s) ?

All of the above

at least a picosecond, sure, without specifying format

Well, if what you are saying is should time be seconds and "something"
smaller as both NTP and PTP do, then I guess I agree. As for the
granularity,
that depends on the format and resolution above.

should support a really wide range with possible BCP information to
limit
damage from high rates on general infrastructure

Yes

Yes

NETWORKING ISSUES

Either DNS or DHCP 

by some sort of TBD discovery protocol 

no

SECURITY

   of server by client - yes
   of client by server - not really
   of middleboxes - unsure

So level of traceability would be desirable, but I'm not sure about
the full implications of this that some would support. 

no

END

---

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

> I don't think we have enough consensus in the IETF to take the first

To explain my earlier message a bit. What I am seeing are a lot of  
responses that are say "1588 is the answer". But I am still trying to  
understand what they thought the question was. As I understood it, the  
intent of the first part of the interim was to gather requirements so  
that we could determine the future path. That there is a need for a  
1588 profile, I am sure - but there are also other needs, and Karen  
gives a good illustration when she in her replies notes "Unless we  
redefine NTP or PTP this is already determined." and "Again... not an  
issue unless we are redefining one of the existing
protocols.". I.e we are not trying to understand if we need and/or can  
do better than today. We are limiting our problem scope to vested  
solutions.

Me and Peter tried to capture the trade-offs and possible concerns for  
the problem, and areas where we could do better in IETF protocol  
design and what the implications would be. And here comes what shoocks  
me - this is the first WG in the IETF that I have ever been active  
where there has been virtually no discussion about a proposed  
requirements document. None. I have no idea how to interpret that. I  
had expected that someone, at least one, would argue for or against  
the document, point by point. But all we got was silence. I am really  
surprised. Hence my email that I think we should uplevel and decide  
what problem we are trying to solve before we all agree that 1588 +  
maybe NTP modifications - are the solution.

Best regards,

- kurtis -

---

From: "Chislow, Donald \(Donald\)" <[email-masked]>
Date: Fri, 13 Jun 2008 18:57:32 -0500

Stewart:
 
My responses in-line:
 
Regards,
 
Don
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stewart Bryant
Sent: Monday, June 09, 2008 2:15 AM
To: [email-masked]
Subject: [TICTOC] TICTOC questionnaire
 
Regards
 
Yaakov and Stewart

GENERAL
 
* Name
<Don Chislow - ALU>
 
* Are you going to attend the upcoming interim meeting
   A) in person
   B) via dial-in
<neither - via Jean-Loop>

   cellular backhauling
<Yes - backhaul>
 
   instrumentation / measurement
<Yes - for test & verification purposes>
 
   industrial
 
<Yes>
 
<Yes>
 
   legal time
<possibly - may become important w.r.t. security concerns>
 
   other

     1) define minor extensions to NTPv4
<do not favor developing new protocols>
 
     2) define 1588 profiles
<I think this is ITU-T SG15 charter - perhaps liaison?>

 
<Re: 1, 3, 4 you need to know what you can expect to get from the
current protocols 1588, NTP, including h/w enhancement> 

 
<suggest define a minimum set to include UTC, others can be derived or
optional>
 
<TBD>
 
<TBD>

* Should a separate "frequency-only" service be defined ?
<need to define the user space. Such an option will work for current
needs, but need to address time delivery as well>
 
   What about a special "time when frequency is locked"
   service ?
<not clear what you are trying to do with this?>
 
* Should we divide the application space into categories
   from stringent to undemanding ?
<Good to know the user space/needs, but what is the overall objective?>
 
  If so, how may categories and where are the dividing lines ?
  Please consider
      accuracy
      resolution
      aquisition time
      Jitter
      Wander
<if the group is serious about delivering quality time then it "has" to
include all salient parameters/metrics>
 
  Are there other characteristics that would cause us to
  consider the creation of an unique timing class?
<I don't know? What do you think would be involved?>
 
<Yes>
 
* 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 ?
<NO I would not support what I'd refer to as another "best-effort" time
service. Again if serious about timekeeping then I think you revert to a
more deterministic model for distribution>
 
* 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 ?
<NO - for similar reasons to above - not clear what "when it is not"
refers to? Use of the special h/w?>
 
* What scalability constraints do you envisage ?
<this will depend on application>
 
   Number of clients per server -
<e.g., mobile: 100s-1000s, wireline: probably <100? >

  Number of servers on network -
<this will differ for each carrier depending on their network
engineering philosophy, i.e., flatter vs. more hierarchical >

 Number of hops / maximum propagation time -
<this will be dictated by the performance metrics the applications
require >

* Is it acceptable for the time server to save state
   of clients ?
<yes - may need for OA&M>
 
<TBD>

   broadcast
   multicast
   unicast
   anycast
<I have to believe "unicast" is the mode of choice for performance
stability? - need to define why we need the others and what the
attendant performance expectations would be? >

   TCP/IP
<maybe>
   UDP/IP
<yes>
   RTP/UDP/IP
   DCCP/IP
   Ethernet
<yes>
   MPLS
<Yes>
   other
< naaa >

   by setting time to best estimate
   by setting time but maintaining monotonicity
   by slewing frequency
<TBD - likely a combination >

<NO>
 
  Best clock determined by calculation
<Yes - prefer computation based on Rx'd metric(s) ITU? >
 
<NO>
<NO>

 
   Only timestamp(s) ?
<required>
 
<possibly>
 
<I don't know>

   Do you agree ?  If not - what resolution do you propose ?
<Does the group think they can squeeze that level out? - I think most
applications would need something of the order of "nano-seconds" - must
evaluate the application need to establish this >

 
 
  Do you agree to the division ?  Do you agree to the
  dividing line ?
< NO I need to understand the thinking behind this >
 
  What format should the fine granularity part be
  (1/10, 1/2, other), and why?
<similar response to above/previous >

* What are the maximum and minimum update rates needed
   to be supported ?
<depends on various factors: processor, local OSC, network conditions,
etc. >
 
< very likely >
 
< very likely >

NETWORKING ISSUES

    DNS ? DHCP ? new protocol ?
< please no new protocols >

< TBD >
 
    How is an optimal path that exploits these elements
    to be determined ?
<TBD - network guidelines ? >
 
*  Should we distinguish between time delivered within an
    AS and time delivered outside it?
< what are you driving at here? The job is to deliver quality time, so
I'm thinking that you deliver it based on a budgeting methodology, i.e.,
it covers so many hops, the timing perf at some network interface is
then guaranteed to be w/in +/- "x" ppm or "y" us, etc. A carrier handing
off time out of the AS has to be able to ensure it is w/in the limits >

SECURITY

   of server by client
<yes> 
 
   of client by server
<yes>
 
   of middleboxes
< aaah! No middle stuff please >
 
<PRC>
 
< TBD >
 
END