Hi Warner, thanks for your input, it triggered some additional ideas. As co-author of the draft I'm adding some thoughts to this discussion - please find the comments to your statements inserted inline.
On 25.09.2017 15:17, Warner Losh wrote: > > > On Mon, Sep 25, 2017 at 12:37 AM, Tal Mizrahi <[email protected] > <mailto:[email protected]>> wrote: > > >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. I agree that timestamp interpretation (semantics) must be made explicit. But I argue that interpretation needs not be explicit part of _any_ timestamp field. Adding (a) interpretation by extending _any_ timestamp protocol field is one option. But there are many other ways to convey semantics. Examples include, but are not limited to b) preliminary (one-time) agreement between communicating parties (semantics negotiated once at connection establishment time and valid throughout the session) or even c) well-defined semantics in a textual standard or protocol specification. Variants (a)-(c) are all realistic use cases that have their pros and cons. A generic timestamp draft must support all of these use cases (and likely some more). > 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. > Becoming more technical: the greatest common factor that current protocols share wrt timestamps is a set of timestamp (data) fields of a specific size. This is what the timestamp draft already covers in detail. Interpretation - i.e., semantics - is currently up to the protocols that use these timestamp data fields. Some protocols define control fields on this purpose, but these are proprietary. This draft will eventually contribute exactly what is currently missing (and only present as a placeholder): a standardized control field that _can_ be used by protocols to extend timestamp data fields with semantics. Protocols that are willing to use the control field (and accept its overhead) can add semantics to their timestamps. In some cases it may even be used separated from timestamp data - for instance when negotiating a connection in the case (b) mentioned earlier. Prerequisite is that these semantics persist over connection lifetime, which may or may not be true and applicable. In other cases it may be meaningful for protocols to augment any single timestamp with semantics. A timestamp control field could, for instance, convey information on (estimated) local time synchronization accuracy (like IEEE C37.118/2011 does). Or on leap seconds. And there are many more cases. Btw, while writing these lines I realize that it may even be worth to differentiate between static timestamp semantics (valid over an association lifetime) and dynamical semantics (that are valid for the instant in time when the timestamp was generated). > > 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. Imho no timestamp format can ever prevent protocol designers from under-specifying their timestamps. But the timestamp draft will support them by providing guidance and eventually improve the status quo. Your practical expertise and the one of other experts in ntp is an invaluable help in figuring out the semantics that timestamps really need. Finding the right trade-off between features, flexibility, representation (size) and simplicity will be a major challenge. Likewise we must find solutions for conflicting requirements (for instance Rodney raised the topic of hardware support and the use of a control field). So there's plenty of work ahead but imo it's worth spending the effort. The discussion shows that there is a need for this draft and that ntp/tictoc is the right group to host it. This, again, supports the request for adoption as WG item. thanks again, Joachim _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
