[Ntp] An RFC6921-compliant NTP implementation

[Daniel Franke <[e-mail]>]

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.