On Tue, Jul 11, 2023 at 10:03:19PM +0300, Michael Schapira wrote: > Following up on the above discussion, I wanted to point out that the load > on NTP servers induced by Khronos is something that we have extensively > analyzed, both theoretically and empirically. Please see > https://www.michaelschapira.com/_files/ugd/3b1e1e_278d283d14bf4dc994128eb4be88484a.pdf It seems your own analysis in the paper agrees that this indeed is a serious problem. Quoting from page 11: Overloading timeservers. We show that, if deployed at scale, the above discussed simple heuristic for assigning servers to clients, runs into the risk of inducing significant deviations from today’s load distribution, in which a large fraction of the timeservers experiences over 200x increase in load. Intuitively, this is because today’s practice of assigning timeservers to NTP clients with probability that is proportional to their netspeed values (see Section III-B) is at odds with Chronos’ uniform distribution of load across large sets of servers, irrespective of their netspeed values (which is needed for establishing its security guarantees [6]). Consequently, if the sets of servers with which Chronos clients synchronize, and the frequency of synchronization, are not chosen with care, low-netspeed servers will experience a huge surge in load. This definitely needs to be explained in the Khronos draft and maybe spell it out that Khronos must not be used with the normal zones in pool.ntp.org. The paper proposes a solution using a special zone where only selected fast servers are included, but that doesn't seem to exist yet. I don't remember seeing it proposed on the project's discourse (https://community.ntppool.org). -- Miroslav Lichvar -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
