Hi Dave, I appreciate your concern, but in my opinion it is not related to the intended status, since clearly a "selfish" NTP client can load the NTP pool, and this is true both with and without Khronos. Obviously there is no need for any experiments or experimental period to realize that this kind of load is possible even with the existing NTPv4 with a client that is either "selfish", poorly implemented or malicious. Specifically, this concern about Khronos is addressed in the current version of the draft (as you indeed noted): While Khronos queries around 3 times more servers per polling interval than NTP, Khronos's polling interval can be longer (e.g., 10 times longer) than NTPv4, thereby, minimizing the load on NTP servers and the communication overhead. Moreover, Khronos's random server selection may even help to distribute queries across the whole pool. Cheers, Tal. On Tue, Jul 11, 2023 at 10:32 AM Dave Hart <davehart@xxxxxxxxx> wrote: > > On Tue, 11 Jul 2023 at 06:04, Tal Mizrahi <tal.mizrahi.phd@xxxxxxxxx> wrote: >> >> Regarding the question about the intended status of the document, >> there was quite a bit of discussion in the NTP working group about >> whether the document should be informational or experimental, and the >> decision was to proceed with informational. We believe that >> "informational" fits this draft for two reasons: firstly, an >> experimental evaluation was performed by the authors, and contributed >> to how Khronos is currently defined, and secondly, Khronos can be >> implemented without affecting or compromising interoperability with >> existing NTPv4 implementations. While the NTF implementation is in >> progress, we believe it should not affect the intended status of the >> current document. > > > Given that Ask Bjørn Hansen, the longtime unpaid and underappreciated administrator of pool.ntp.org has expressed his concern that Khronos presents an existential threat to pool.ntp.org due to the increased DNS query load in particular, keeping in mind that the DNS servers are not running traditional DNS software with static zones but rather custom DNS software to provide location-customized responses [1], and given there is no comparable alternative NTP pool upon which Khronos can rely, I would argue Experimental status or withdrawal of the draft entirely until an alternative pool can be provisioned is in order. > > Despite the authors' assertions that the increased query load on the pool DNS and NTP servers is negligible, in my opinion Khronos represents an extremely selfish tragedy of the commons risk by proposing widespread use of an approach which uses hundreds of servers per client to crowdsource time.. Yes, I am aware the designers believe only a dozen or so NTP servers will be queried and those queries will be 10 times less frequent than NTPv4's, but I am also aware that when conditions are right, hundreds of NTP servers will be queried simultaneously. Given the lack of third-party real-world experience of how infrequent such "panic mode" events will be in practice, I would counsel caution and at a minimum change the proposed status to Experimental. > > [1] https://github.com/abh/geodns > > Cheers, > Dave Hart -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
