imp-drift

RFC 789 in eight nodes, for {{name}}.
state
modenormal
checksums + acksoff
packets in flight0
packets delivered0
packets dropped0
links cut0
network state1 version
actions
inject a phantom cycle
space pause · b broadcast · c triple · v pair · q quintet · f fix · r reset
click any node to broadcast a fresh routing update from it. click any link to cut it — click again to heal.
packet log
seq-number ring (mod 64)
the phantom triple: 8 > 44 > 24 > 8 (cyclic, under mod-64). no globally newest version. every IMP forwards forever.
legend
zero (initial state)
latest legit routing update
what's happening
Each IMP stores the latest known routing update from every other IMP, indexed by a 6-bit sequence number. On receiving an update it accepts if the incoming seq is "newer" than its stored one, then floods to its neighbours.

In RFC 789's failure, a memory fault produced three phantom versions whose sequence numbers formed a cycle in the modular comparison. Every IMP accepted whichever it received most recently, forwarded it, and cycled among the three forever. Nothing about the number three is special — any set of sequence numbers whose consecutive mod-64 gaps stay under 32 and sum back around to the start forms the same trap. Two values exactly 32 apart sit on the boundary the rule doesn't define. Five values spread evenly around the ring cycle just as hard, only slower.

Cutting a link splits the graph. A phantom cycle stranded on one side keeps spinning there alone; the other side stays clean until the link — and the stale state riding on it — comes back.
Rosen, E. C., "Vulnerabilities of Network Control Protocols: An Example," RFC 789, BBN, July 1981.