Hi Warner, We are in full agreement that any considerations relating to the leap second should be defined.
I believe the main question here is whether leap second considerations should be defined in the recommended timestamp formats, or in the protocols that use them. One thing to remember is that this draft is intended to be generic, so that timestamp formats will be applicable to many different protocols such as OWAMP, TWAMP, TRILL loss/delay, MPLS loss/delay, and of course NTP. Therefore, there may be an advantage to having a common timestamp format that is sometimes used with respect to TAI (no leap seconds), and sometimes used with respect to UTC (leap second considerations are required). Whether leap second considerations are included in the timestamp format, or in the protocol that uses it, either way I fully agree that such considerations should be defined. Since there are advantages on either way, I would be happy to hear from other people on the list what they believe would be the best approach here. Cheers, Tal. On Mon, Sep 25, 2017 at 4:17 PM, Warner Losh <[email protected]> wrote: > > > On Mon, Sep 25, 2017 at 12:37 AM, Tal Mizrahi <[email protected]> > wrote: > >> Hi Warner, >> >> Thanks for the feedback. >> >> >> >Section 4.1 says "Further considerations may be discussed in >> >this section, such as required accuracy, or leap second handling." >> >Yet none of the formats make any allowance for leap seconds. >> >> Right. As I pointed out below, we have separated the *formats* from the >> *synchronization aspects*. The advantage of this approach is that a given >> timestamp format does not necessarily define the time standard (UTC / TAI), >> and specifically does not necessarily define the leap second handling. >> > > That's not an advantage by any means. If you don't know how to interpret > the data, it's useless. And leap seconds are part of the data, as much as > people want to ignore them. It's a flaw in the specification. You go to > great lengths to say that the PPT is seconds since a time in TAI. How you > count the seconds since the epoch is quite relevant. It's not just a > counter, but a corrected counter in NTP's case. And a counter and a > corrected counter are two very different things, since the math you can > safely do on them, and the meta data you need for some operations with them > differ. You can't escape that in defining the format because that's > critical to its use. And a corrected counter has ambiguities around the > leap second that are impossible to avoid without other metadata (NTP puts > that metadata into another bit of the NTP packet so you know, for example). > The details about the metadata likely can remain unspecified, but whether > or not leap seconds are swizzled in should not. > > >> That means that a specification that uses a recommended timestamp format >> should define the synchronization aspects, including leap second >> considerations if such exist. See the following text in the draft: >> >> A specification that uses one of the recommended timestamp formats >> should also include a section on Synchronization Aspects... >> ...such as required accuracy, or leap second handling. >> >> >> With that said, your point is well taken. In the next draft we will add >> some more text that clarifies this point, including an example in Section 5. >> > > As someone who has fought with formats being under specified, I can tell > right now that this will lead to trouble. You can't run away from the > Synchronization Aspects, at least not all of them. Having dealt with this > stuff for almost two decades in high precision time applications, and > having tried to separate out the two concepts to make things "cleaner" I > can attest from first hand experience that this is a mistake. > > Warner > > >> Regards, >> Tal. >> >> On Sun, Sep 24, 2017 at 6:06 PM, Warner Losh <[email protected]> wrote: >> >>> >>> >>> On Sun, Sep 24, 2017 at 7:37 AM, Tal Mizrahi <[email protected]> >>> wrote: >>> >>>> Hi, >>>> >>>> We have revised the draft based on the comments received in IETF 99, >>>> and based on the comments from Yaakov (thanks Yaakov). >>>> >>>> https://datatracker.ietf.org/doc/draft-mizrahi-intarea-packe >>>> t-timestamps/ >>>> >>>> The main changes compared to the previous version of the draft: >>>> - We have extended the discussion about the factors that may affect the >>>> choice of the timestamp format. >>>> - A new section has been added, called "Timestamp Use Cases". >>>> - The sychronization aspects have been separated from the timestamp >>>> format, allowing the timestamp format to be independent of how time is >>>> synchronized. >>>> >>>> Any further comments are welcome. >>>> >>> >>> Section 4.1 says "Further considerations may be discussed in this >>> section, such as required accuracy, or leap second handling." Yet none >>> of the formats make any allowance for leap seconds. In NTP headers, leap >>> second time stamps are marked with an out-of-band bit. In addition, all NTP >>> time stamps are adjusted by the cumulative number of leap seconds, yet that >>> relevant information is not included.PTP timestamps, on the other hand, are >>> a count of TAI seconds since 1970, which have no adjustments. >>> >>> When I was doing time and frequency recovery, these differences weren't >>> documented and many arguments ensued to get to the understanding of what's >>> actually on the wire, what the auxiliary bits mean, etc. I'd rather see >>> this document be explicit about such things rather than some vague hand >>> wave that will be interpreted in many different ways leading to even more >>> issues with leap seconds than we already have. >>> >>> Warner >>> >> >> >
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
