skip to content

Why can't an NTPv4 server normally put its hardware transmit timestamp into the reply it is sending, and how do RFC 9769 interleaved modes fix that?

level: seniorimportance: nice to knowfreq 8%

answer

  1. the precise time exists only afterwards
  2. MAC and PHY beat user space
  3. send it with the next reply
  4. origin field as a cookie
  5. NTPv5 draft makes it a flag

basics

~20 s

A hardware transmit timestamp exists only after the packet has left, too late to write into it. RFC 9769 interleaved modes have the server send, in its next reply, the precise transmit timestamp of its previous reply, keyed by the origin field.

solid answer

~50 s

RFC 9769 lists four places to timestamp a packet: user space, the driver or kernel, the MAC and the PHY. User space is least accurate, the PHY most. Receive timestamps from hardware are no problem, but a hardware **transmit** timestamp is known only after the packet has gone, so in RFC 5905's **basic mode** — where a reply's transmit timestamp describes that reply — the server must write a less accurate software value, unless its hardware can rewrite the packet in flight. **Interleaved mode** puts the precise transmit timestamp of the *previous* reply into the *next* one. The client signals it by copying the server's receive timestamp, not its transmit timestamp, into the request's origin field; the server matches that against saved receive/transmit pairs. The cost is per-client state on the server and more complex validation; the gain is a transmit timestamp as accurate as the receive one.

code

pseudocode · 13 lines
pseudocode
on_request(req, rx_now):
    interleaved = req.receive != req.transmit
                  and saved.has_rx(req.origin)
    resp.receive = rx_now
    if interleaved:
        resp.origin   = req.receive
        resp.transmit = saved.tx_for(req.origin)
        saved.drop(req.origin)
    else:
        resp.origin   = req.transmit
        resp.transmit = software_clock()
    send(resp)
    saved.store(rx_now, hardware_tx_timestamp(resp))

go deeper

for a junior

Recall that timestamps taken in network hardware are more accurate than ones taken in software, and that the server's send time is the hard one to get right.

for a middle

Explain why a hardware transmit timestamp exists only after sending, and how interleaved mode delivers it in the next reply using the origin timestamp.

for a senior

Show that you know the operating costs - per-client server state, fallback to basic mode, stricter validation - and when hardware-timestamped NTP is enough versus moving to PTP.

for a principal

Weigh the accuracy gain against complexity and attack surface on public servers, and decide where to restrict interleaving or wait for NTPv5's explicit signalling.

## Where a timestamp can be taken NTP's offset and delay come from four timestamps, and every one is only as good as the place it was captured. **RFC 9769** (NTP Interleaved Modes, Standards Track, updating RFC 5905) lists four capture points for a software NTP implementation on a general-purpose operating system: 1. **User space**, in the NTP implementation itself — least accurate, since it misses system calls, queueing in the operating system, driver delays and hardware. 2. **The network device driver or kernel.** 3. **The data link layer** — hardware, in the MAC chip. 4. **The physical layer** — hardware, in the PHY chip, the most accurate. The asymmetry matters as much as the size: RFC 9769 notes that an asymmetry in timestamping causes an error in the offset NTP measures. ## The transmit-timestamp problem Receiving is easy: the hardware stamps the arriving request, the server reads that value and writes it into the reply as its receive timestamp. Transmitting is not. A transmit timestamp captured in the driver or hardware is available only **after** the packet was sent, so it cannot be written into that packet unless the driver or hardware understands NTP and rewrites the packet during transmission. RFC 5905 has no way to deliver a timestamp known only after transmission. A packet whose transmit timestamp describes the packet itself is said to be in **basic mode**, and in basic mode the server is stuck with an earlier, less accurate software value. RFC 9769 also explains why the obvious fix — a second packet carrying the precise time — was rejected: it would enable traffic amplification, or use packets of asymmetric length, which itself skews the measured offset. ## How interleaved client/server mode works Interleaved mode reuses the existing header with no new fields; the negotiation is implicit, through the origin timestamp, which RFC 9769 describes as a cookie: | | Basic mode | Interleaved mode | |---|---|---| | Client request's origin | the transmit timestamp of the last valid reply (zero on the first) | the **receive** timestamp of the last valid reply | | Server reply's origin | the request's transmit timestamp | the request's receive timestamp | | Server reply's transmit | the transmission of this reply | the transmission of the **previous** reply | The sequence: 1. The first exchange is always basic. The server saves the pair (its receive timestamp of the request, its hardware transmit timestamp of the reply). 2. The client's next request carries the server's receive timestamp from that reply as its origin. 3. The server finds a saved pair whose receive timestamp matches, and replies in interleaved mode with the saved, precise transmit timestamp — but only if the request's receive and transmit fields differ and the match exists. Otherwise it MUST NOT reply in interleaved mode. 4. The server SHOULD save the new pair either way, ready for the following request. The client then computes offset and delay with RFC 5905's formulas, but takes the four timestamps from two exchanges; RFC 9769 recommends one set for clients that filter on delay and offers a second that tracks the current offset more closely. Because the improved transmit timestamp shortens the measured delay, a client that filters on delay naturally prefers the interleaved measurements. ## Interoperability, safeguards and costs - Interleaved client/server and broadcast modes interoperate with implementations that support only basic mode; the interleaved **symmetric** mode does not fully, and is configured per association. - Servers and clients that support interleaving MUST NOT send a packet whose transmit timestamp equals its receive timestamp, so that the two modes stay distinguishable. - The server keeps state per client, SHOULD bound it with a fixed-length queue, and MAY restrict interleaved mode to particular addresses or authenticated clients. - Packet loss is recovered: the client reuses its origin and the server falls back to basic mode when it no longer holds the pair. - Clients MUST NOT rely on getting interleaved replies: an attacker sending floods or spoofed requests can force the server to drop its saved pairs. - RFC 9769 warns that the modes make NTP more sensitive to implementation errors. ## What the NTPv5 draft changes The **NTPv5 Internet-Draft** (draft-ietf-ntp-ntpv5-09, work in progress, not an RFC) keeps interleaving but makes it explicit: an **Interleaved Mode** flag in the header, and a **Server Cookie** field that identifies the earlier reply, instead of inferring the mode by comparing timestamps. PTP solves the same problem with **two-step** operation, sending the precise transmit time in a following message.

  • What does an RFC 9769 server do when an interleaved request's saved timestamps are gone?
    It must not reply in interleaved mode. It answers in basic mode and saves the new receive and transmit pair, so the client's next request can be answered in interleaved mode. RFC 9769 also asks clients to limit how many interleaved requests they send between replies.
  • How does a client tell whether a reply is in basic or interleaved mode?
    By the reply's origin timestamp. If it equals the transmit timestamp of the client's request, the reply is basic; if it equals the request's receive timestamp, it is interleaved. A reply matching neither is bogus and should not update the client's state.
  • Can an NTP client depend on a server always answering in interleaved mode?
    No. RFC 9769 says clients MUST NOT rely on it: floods or spoofed requests can force the server to drop its saved timestamps, and a server MAY restrict the mode to some addresses or authenticated clients. The client must keep working from basic-mode replies, and should limit how many of them it discards while waiting.

saying these in an interview costs you the question

  • A hardware transmit timestamp can always be written into the outgoing packet.
  • Interleaved mode adds a new extension field to the NTPv4 packet.
  • The server sends a second packet carrying the precise transmit time.
  • Interleaved client/server mode breaks clients that support only basic mode.
  • User-space timestamps are as accurate as PHY timestamps on a fast LAN.