Subject: Re: [ntpwg] Guidelines for Defining Packet Timestamps

From: Yaakov Stein <[email-masked]>
Date: Sun, 30 Jul 2017 13:33:55 +0000

This was never delivered, so I am trying again.

Y(J)S

-----Original Message-----
From: Yaakov Stein 
Sent: 18/07/2017 12:46
To: [email-masked]; [email-masked]
Subject: Guidelines for Defining Packet Timestamps

Tal and everyone else, 

For some reason Meetecho didn't let me raise my hand or enter the queue today, so I couldn't efficiently make my comments on this draft (which I hadn't seen, and still haven't read).

Yes, the technicalities of the number of bits and when time zero was are important, but there are other issues that should be considered, and will help deciding on a time format.

1. How precise do we need the time ? (based on the expected accuracy, but also on the requirement) 2. For what time duration do you need non-ambiguity?

Note that the answers to 1 and 2 dictate the minimal number of bits required, but you may want to round up to multiples of bytes/16b words/doublewords/etc and you might decide on a kludge where the most significant bits are placed somewhere else.

3. Does this time need to be locked to some global time, 
     or is it only going to be used to compare two timestamps using this same timebase?
    For example, to avoid transmission collisions you only need agreement, not global time.
    A related question is
4. How much degradation is allowable from that source to the users? 
    The SMC and ESMC protocols do a nice job in telling us whether we are locked in frequency to a PRC, which PRC, if we are in holdover, etc.
5. If the answer to 3 was "global time", then atomic based (TAI) or earth rotation based (UTC).
     If earth based, then how do we get the information on leap seconds? 
     If you can do without the headache of leap seconds, it is really nice, but ...
6. If the answer to 5 was earth-based, then is someone going to want to convert this time to a local timezone? 
     If so, how? Of course, if you are connected to the Internet then the TZ database is available, but in many cases it isn't.

Before getting into the number of bits, we need to further ask:
7. Assuming that the precision required in 1 above is tighter than a second, how do we represent the < 1 second part - 
     by fractional seconds (NTP) or integer xsec (where x is milli, micro, nano, pico, depending on the answer to 1)
    The answer to this question may be a matter of taste, or may affect calculations.

Finally, based on the answers to the above you can specify 8. How many bits are used and how are they fielded?

Of course, if one of the well-known time formats (NTP-128b, NTP-64b, NTP-32b, PTPv1 format, PTPv2 format, UNIX, etc) fits, then there could be a preference to (re)use it.

Y(J)S

-----Original Message-----
From: TICTOC [mailto:[email-masked]] On Behalf Of Karen O'Donoghue
Sent: 17/07/2017 19:27
To: [email-masked]; [email-masked]
Subject: [TICTOC] Reminder: NTP / TICTOC working group meeting (18 July, 07:30 UTC)

Folks,

Just a quick reminder that the ntp and tictoc joint working group meeting will be tomorrow at 9:30 am CEST (7:30 am UTC). I know this is a bad time for our regular US based remote participants, but perhaps those of you on the west coast could join. 

Link to agenda: 
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fproceedings%2F99%2Fagenda%2Fagenda-99-ntp-00.txt&data=01%7C01%7Cyaakov_s%40rad.com%7Cb18503ca9b714dfbd76f08d4cd30a7e2%7Cf9047108cc2c4e4897a343fad1b3bf9d%7C1&sdata=HQpKhtgmDOMqaebwEZ2VZiMfNtmGrtULyAMyiYoRof0%3D&reserved=0

Remote participation details are available on the meeting website…
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmeeting%2F99%2Findex.html&data=01%7C01%7Cyaakov_s%40rad.com%7Cb18503ca9b714dfbd76f08d4cd30a7e2%7Cf9047108cc2c4e4897a343fad1b3bf9d%7C1&sdata=1QIysN8j7ye2BY6DdCqaBAF1fJ9HfcekpKXPBEc3XHE%3D&reserved=0

Karen

_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg