[Ntp] Antwort: An RFC6921-compliant NTP implementation

[[e-mail]]

So I had this lying around in a forgotten folder of my inbox and only today managed to review it (and familiarize myself with RFC 6921, and appreciate the temporal context, which had completely eluded me).

Just wanted to say: outstanding work, Daniel!

And I do hope we hear more from this project, perhaps in a year or so (give or take 22 days)?

-----"ntp" <[e-mail]> schrieb: -----

An: "NTP WG" <[e-mail]>
Von: "Daniel Franke"
Gesendet von: "ntp"
Datum: 01.04.2021 02:02
Kopie: [e-mail]
Betreff: [Ntp] An RFC6921-compliant NTP implementation

Building on the groundbreaking results from CERN's OPERA experiment showing that neutrinos can be accelerated to superluminal speeds merely by loosening the contacts on a transmission cable, I'm pleased to report a mostly-successful experiment building an RFC6921 ("Design Considerations for Faster-Than-Light (FTL) Communication") compliant implementation of NTP.

As a preliminary test intended simply to verify the correct functioning of the experiment hardware, I positioned two hosts, both running unmodified NTP software, 25 light-milliseconds apart, and networked them point-to-point via a superluminal neutrino transceiver. I measured a ping time of 49.998ms, confirming FTL communication. As expected, NTP was able to operate normally in this rather unchallenging configuration.

FTL communication can lead to backward causality only when the communicating parties are in relative motion, and since the speed of our communication is only slightly greater than c, the communicating parties' speed of travel needs to be only slightly less than c. Even in the subluminal case, this already causes some problems for NTP. NTP is a clock synchronization protocol, but as soon as relativistic effects become non-negligible the whole notion of synchronicity needs to be abandoned; thus it needs to be carefully stated what NTP is even trying to accomplish. I decided on the following problem statement: given a client on a long journey through space, in continuous communication with a server located on Earth, allow the client to maintain a clock that will be synchronized with the server's clock at such point as the client ever rejoins the server's reference frame. The effects of time dilation mean that such a clock may run at a rate quite different from the proper time experienced by the client, but here we nonetheless have a well-defined goal, free of paradox. Note the necessity of restricting ourselves to discussing client/server mode; symmetric mode makes no sense in this setting.

The client will at all times need a priori knowledge of its velocity relative to the server, and must make the following adjustments to the usual NTP algorithms:

1. It must scale its clock frequency according to the time dilation formula, 1/sqrt(1-v^2/c^2). 

2. It must apply a Lorenz transformation to the receive and transmit timestamps, to bring these from the server's reference frame into the client's (the origin and destination timestamps are already in the client's reference frame).

3. It must adjust for the fact that its distance from the server may be different on one leg of a round-trip communication than it was on the other. This would be necessary even in a Newtonian universe, whenever the client and server are in relative motion.

These modifications are sufficient when only subluminal communication is involved, but in the FTL setting, backward causality creates an additional wrinkle, since a response mayan arrivan fore-when its corresponding request on-sent. As far as our basic formula for clock offset, ((t_2 - t_1) + (t_3 - t_4))/2, goes, this is just fine: it has no special behavior for negative values and needs no modification to accommodate them. The issue, rather, is that it mayant be immediately possible to validate the origin timestamp. Rather than discarding a packet with an unrecognized origin timestamp, the client must retain it until its next request on-generates, and check the match at that time.

I deployed an NTP client with the aforementioned modifications, again equipped with an FTL neutrino transceiver, out to a distance of roughly a light-hour, and then accelerated it back toward Earth, beginning tests once it reached 0.99999c (I won't bore with the details of the propulsion system because, since time flies, they're straightforward). For the duration of its trip, it reported nominal results consistent with successful synchronization, thus experimentally confirming the correctness of these algorithm modifications.

I will not be releasing the code from this experiment, for two reasons:

1. The aforementioned requirement to store an unbounded number of unauthenticated server packets until the client can determine whether it willan on-generate a matching origin timestamp constitutes an unfixable DoS vulnerability, and releasing known-vulnerable code would be irresponsible.

2. I no longer have it available, because when the returning client struck Earth's atmosphere at relativistic speed, the fireball destroyed the experimental apparatus, the server hosting my git repo, and most of Antarctica. Sorry about that.

_______________________________________________
ntp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ntp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ntp