Per RFC-4330:
Although setting the Transmit Timestamp field in the request to the
time of day according to the client clock in NTP timestamp format is
not necessary in a conforming client implementation, it is highly
recommended in unicast and manycast modes. This allows a simple
calculation to determine the propagation delay between the server and
client and to align the system clock generally within a few tens of
milliseconds relative to the server. In addition, this provides a
simple method for verifying that the server reply is in fact a
legitimate response to the specific client request and thereby for
avoiding replays. In broadcast mode, the client has no information
to calculate the propagation delay or to determine the validity of
the server, unless one of the NTP authentication schemes is used.
To calculate the roundtrip delay d and system clock offset t relative
to the server, the client sets the Transmit Timestamp field in the
request to the time of day according to the client clock in NTP
timestamp format. For this purpose, the clock need not be
synchronized. The server copies this field to the Originate
Timestamp in the reply and sets the Receive Timestamp and Transmit
Timestamp fields to the time of day according to the server clock in
NTP timestamp format.
