Summary

  • RFC 891 made the same local HELLO exchange supply round-trip delay for route selection and clock offset for timekeeping, but the two results passed different acceptance tests.
  • The accepted minimum-delay path carried an offset; it did not choose the clock authority. A configured CLOCK-HID identified the master whose date and time could discipline the local clock.
  • Equal packet length, route state, hold intervals and clock validity kept “message received,” “route accepted” and “clock adjusted” from becoming one undifferentiated event.

The most revealing field in RFC 891 is not a packet type. It is an entry in the local Host Table. For each destination, a Fuzzball kept an output process, a measured delay, a clock offset, the time of the last update and a liveness counter. That row was simultaneously a forwarding memory and a timing memory.

This was a compact answer to a compact environment. The DCN local networks described in the document contained at most 256 hosts and gateways, commonly PDP-11 or LSI-11 “Fuzzballs,” linked by a mixture of point-to-point and multipoint media. Each machine could be a packet switch, a gateway and a service host. There was no separate local routing leader to tell everyone where to send traffic.

Instead, neighbors exchanged HELLOs. On the same network, those messages used Internet protocol number 63 and included Host Table delay-and-offset entries. A current IANA protocol-number registry still records 63 as “any local network.” The row preserves an assignment, not evidence that the DCN design remains deployed.

A round trip became reusable evidence

The delay calculation stretched across two directions of the exchange. A host used timing state from a received HELLO and the next HELLO it transmitted. RFC 891 emphasized that the method did not depend on the two clocks already agreeing or on a perfectly regular sending interval. Lost messages and reflected messages did not destroy the method.

That independence mattered because the measurement had to be useful before synchronization was complete. If a delay estimate required synchronized clocks, and synchronization required a chosen route, the design would have built a circular prerequisite. Round-trip observation broke that circle.

But the packet did not become universally trustworthy merely because its checksum and format were valid. A receiver discarded malformed or checksum-failing HELLOs. It then applied further local conditions to the information that survived. Precise timing required the last transmitted and received HELLOs to be the same length. If they were not, the host could still update a route while leaving the offset unchanged.

That small rule exposes the architecture. The message was shared; the decision gates were not. Routing could use evidence that the clock procedure declined to use.

Minimum delay selected a carrier, not a sovereign

For a reported destination, the receiver added the round-trip delay to its neighbor to the delay advertised by that neighbor. It retained the current output path unless another candidate beat it by a configured margin. The document’s example implementation used roughly 100 milliseconds as the switching threshold, a 120-second Host Table hold interval and a maximum path value of 30 seconds. Those values describe the implementation family, not constants for every network in every era.

When a path was accepted, its associated clock offset entered the Host Table with it. The fastest acceptable route therefore became the carrier of the timing observation. It did not get to name the time authority.

The master was identified separately by CLOCK-HID, a configured host ID. If the chosen route led toward some other host, its offset was routing state, not permission to discipline the clock as master time. Even an offset associated with CLOCK-HID still had to pass date-validity and local clock-correction rules.

This distinction prevents an attractive but false summary: “the nearest clock won.” RFC 891 did not run an election in which low delay conferred sovereignty. Configuration established who the master was; measurement established how the local host currently reached it and what offset it observed along that route.

Poison on the return link protected the path calculation

The same table exchange could create a routing loop if a host advertised a learned route back toward the link that supplied it. RFC 891 answered by substituting MAXDELAY on that return path. RFC 2453 later supplies familiar comparison terms—split horizon with poisoned reverse, triggered updates and counting to infinity—but it does not establish a direct line of descent from Hellospeak to RIP.

The safe claim is narrower. Both documents reveal why distributed distance reports need information about where a route came from. An advertised number detached from its input link can become self-confirming fiction.

Hold-down state added another boundary. A disappearing neighbor did not instantly become a clean blank row available for any new claim. The Host Table counted liveness and delayed re-entry. Route freshness, offset freshness and clock validity were related, but they were not the same clock.

The local clock could slew, step or refuse timestamps

RFC 891 distinguished physical, apparent and actual clocks. Small corrections were applied gradually by transferring a fraction of the accumulated difference, with suggested parameters keeping the maximum slew below roughly two milliseconds per second. A large correction could step the apparent clock.

A step triggered a hold interval during which timing timestamps were invalid. That refusal is as important as the correction itself. A machine that has just moved its clock cannot pretend that measurements spanning the discontinuity describe an ordinary round trip.

The design also needed a valid master date and time at least once each day because its apparent-clock representation rolled over at midnight UT. Route reachability alone could not supply the calendar context.

An earlier DCNET service in RFC 778 had already exchanged timestamps through ICMP and GGP to estimate one-way and round-trip delay. RFC 891 went further by placing delay, offset, reachability and route choice in the continuously maintained local table. The reuse saved a separate discovery and measurement plane, but it also made local provenance essential.

Hellospeak influenced NTP without being NTP

RFC 1059 later named the Fuzzball routing protocol “Hellospeak.” It explicitly said the design incorporated time synchronization into routing, strongly influenced the Network Time Protocol, and was unsuitable outside its local-network environment. That is documented influence, not protocol identity.

The first NTP proposal in RFC 958 moved time exchange to UDP and described a hierarchy and message representation. It also acknowledged that it did not specify synchronization and filtering algorithms, peer discovery or authentication. By RFC 1305, NTP described multiple-server filtering and selection, error bounds and a Fuzzball-derived logical-clock mechanism in a dedicated time-service architecture.

The historical movement was not from a crude combined packet to a merely larger packet. It was from an efficient local coupling to explicit selection, filtering and correctness surfaces suited to a wider service. The Fuzzball lesson survived most clearly as a warning: carrying a time observation, choosing a path and authorizing a time source are three decisions.

Sources and limits

This account uses RFC 778, RFC 891, RFC 958, RFC 1059, RFC 1305, RFC 2453 and the IANA Protocol Numbers registry. They establish specifications, implementation descriptions, documented influence and registry state. They do not establish present DCN deployment, identical parameters across every Fuzzball, authenticated master identity, symmetric path delay, a direct Hellospeak-to-RIP lineage or a guarantee that minimum round-trip delay yields the smallest clock error.