* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ntp Status Pages

Network Time Protocol (Active WG)
Int Area: √Čric Vyncke, Erik Kline | 2005-Feb-25 —  

IETF-108 ntp minutes

Session 2020-07-31 1100-1240: Room 3 - Audio stream - ntp chatroom


minutes-108-ntp-00 minutes

          NTP Session - IETF 108
          July 31, 2020
          11:00 UTC
          Meeting Minutes
          Chairs: Karen O'Donoghue, Dieter Sibold
          Minutes: Tal Mizrahi
          Meeting material: https://datatracker.ietf.org/meeting/108/proceedings#ntp
          [This list is for informative purposes, and some people may be
          missing. Bluesheets will be published separately.]
          Karen O'Donoghue
          Dieter Sibold
          Tal Mizrahi
          Neta Schiff
          Miroslav Lichvar
          Martin Langer
          Mark Baushke
          Marco Davids
          Erik Kline
          Xiaolan Wan
          Denis Reilly
          Leif Johansson
          Warren Kumari
          Rich Salz
          Jose Alvarez-Hamelin
          Dhruv Dhody
          Harlan Stenn
          Eric Orth
          Kristof Teichel
          Kimura Yamato
          Yali Wang
          Doug Arnold
          Kenneth Murchison
          Ragnar Sundblad
          Robert Story
          Simon Vera-Schockner
          Hiroyuki Goto
          Presenter: Karen O'Donoghue
          - Karen presented the note well.
          - Karen presented a brief introduction to using Meetecho.
          - The agenda for this session was presented.
          Document status:
          - Two documents in the RFC editor's queue: the timestamp format draft,
          and the NTS draft. There is currently a delay in the editor queue.
          - Mode 6 draft: Karen will take it offline with Erik to proceed with
          the shepherd writeup and the AD review.
          - YANG data model draft: the shepherd writeup is in progress.
          - Port randomization document: has been updated, and the issues have
          hopefully been adressed. It seems to be ready for working group last
          call, since there was no further discussion. Karen and Dieter will
          proceed with WG last call.
          - Alternative NTP port draft: it is still an individual draft.
            -  Miroslav: I believe we said in the last meeting that the draft is
            ready for an adoption call. No changes since then.
          - Roughtime: we discussed it in the last interim, and it has not been
          updated since then.
          - Chronos update - to be presented by Tal.
          Presenter: Tal Mizrahi
          - The draft has recently been revised so that Chronos is a Watchdog.
          - Most of the time you use the NTPv4 algorithm, but if Chronos detects a
          suspected attack, then the client starts using the Chronos algorithm. This
          allows enjoing the precision of NTPv4 most of the time, and enjoying
          the security of Chronos when under attack.
          - Karen: who is working on an implementation?
          - Tal: Neta and the people at the Hebrew university.
          - Neta: we are working on an implementation, but we would love if other
          people who are interested in implementing would contact us and we could
          work together.
          - Dieter: is the Chronos filtering algorithm identical to NTPv4?
          - Tal: it is not identical, but a bit similar. It is based on
          well-established agreement algorithms from the literature, where you
          ignore the highest third and lowest third of the samples, and then take
          an average or a median of the remaining samples.
          - Karen: this version has been around since March. Let's have some
          feedback from the working group. Tal / Neta - please ask the working
          group for some feedback on the mailing list. We also need to discuss
          informational vs. experimental.
          NTPv5 Modular Architecture
          Presenter: Doug Arnold
          - This is a proposal to divide NTP into a timing engine and a protocol
          - This enables cases where there needs to be a dedicated or
          application-specific timing engine.
          - Miroslav: if we define a timing engine - it seems like this is
          a recommended design of a server and client, but not mandatory to
          implement. Is it going to be in a separate document?
          - Doug: if there is going to be more than one timing engine it would make
          sense to have it in a separate document. There would be an architecture
          document that describes the concept and interfaces, and the timing engine
          would be in a different document.
          - Karen: chair hat off, there is no specific plan which documents will be,
          as we are just in a discussion phase. We have not updated the charter yet,
          and do not have consensus yet.
          - Doug: the motivation for all of this is that it is already being done
          in NTPv4, even though it does not comply to the standard NTP. Different
          implementations use different algorithms than RFC 5905. It seems like
          this is needed.
          - Karen: some individual drafts along these lines would be helpful.
          - Dieter: would it make sense to separate the clock control from the
          timing engine?
          - Doug: you mean that clock control is a separate entity, and the timing
          engine just analyzes the NTP messages.
          - Dieter: right, and sometimes people have different requirements about
          how often the clock needs to be adjusted.
          - Doug: it is possible. Note that we do not want too many subsystems,
          in order to avoid to many combinations, but it can be discussed.
          - Dieter: the packet structure still contains the timestamps, right?
          - Doug: right, that is done by the protocol engine. The timestamps come
          from either the operating system, or from a hardware engine, and can be
          used by the protocol engine for timestamping.
          - Mark Baushke: the IEEE 1588 has a better resolution than the NTP
          timestamp resolution. Do we need a better resolution?
          - Doug: that is a good point. In IEEE 1588 we did this in order to avoid
          updates for a long time. However, people like to use NTP in some scenarios
          or applications, and we may need better resolution than nanoseconds.
          - Mark: IEEE 1588 typically is implemented in hardware, but still NTP
          may need a better resolution.
          - Doug: in PTP (1588) we could not change the timestamp field, so we
          added the extra precision to the correction field. NTP servers have
          hardware timestamping, and many of the clients have the hardware that
          enables hardware-based timestamps.
          - Jose: if you want to synchronize over the Internet, it would
          be difficult to reach a sub-microsecond accuracy. If the network is
          symmetric a microsecond accuracy is possible. I have a proposal on the
          TICTOC working group for an accurate synchronization protocol.
          - Doug: right, a high resolution timestamp does not mean you can achieve
          high accuracy. In small networks with a small number of hops (such as
          financial networks), you can achieve a high accuracy.
          - Miroslav: we have a document on the Wiki about NTPv5 requirements. One
          of the issues is the precision of the timestamps. You are welcome to
          add comments to the Wiki or mailing list. White rabbit is reaching the
          resolution that NTP provides, so maybe a better resolution will not be
          required in the near future.
          - Doug: it is difficult to reach an accuracy/precision below 1
          nanoseocnd. The finance industry are used to NTP, and prefer it over PTP,
          and at the same time are looking into White Rabbit. It turns out that for
          trades a nanosecond resolution matters. There may be some applications
          that will require fine resolution.
          Hackathon Update
          Presenter: Martin Langer
          - There was an NTP hackathon last week.
          - Interop testing of NTS implementations.
          - All implementations talk to each other.
          - Some issues with operator filtering (of large NTP packets).
          - Miroslav: about the failures reported about the testing tool - it is
          not an issue for the current clients, but could be a real problem in the
          future when NTPv5. Some implementations of servers just assume that it
          is an NTPv4 client, but servers need to check whether it is NTPv4 or not.
          - Karen: thanks to Martin Langer, Miroslav Lichvar and Christer Weinigel
          for being the backbone of the team and pushing this through.
          NTPv5 Discussion
          - Karen: we are looking for charter updates, and we would like to start
          having implementations and drafts. There is a Wiki page that you can
          update with your suggestions.
          - Erik Kline: the charter is currently a bit out of date. Suggestions
          would be welcome for scoping the work, including motivation and
          suggestions for NTPv5. Karen and I will take a stab at rewriting the
          - Karen: it looks like people are interested, and there is a question
          of the scope.
          - Karen: we have been trying to hold regular interims. The  next one
          will be at the beginning of September.
          - Harlan: is there a reference implementations of the YANG data model?
          - Karen: the authors are not present. We may have an answer in the next
          few days as part of the shepherd writeup.
          Adjourned at 12:22 UTC.

Generated from PyHt script /wg/ntp/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -