Summary

  • Wesley Eddy coauthored the IETF TIPTOP architecture published on 31 October 2026. Its example path uses two tuned end hosts and two deep-space forwarders, while at least five other nodes keep ordinary IP stacks.
  • When an intermittent link is down and no other route exists, a forwarder may hold IP packets in a bounded queue. A full queue must drop packets; a reboot or corrupted memory can erase them. An explicit route may be stale by the time the queue drains.

The packet has no appointment with the antenna

Earth-to-Mars transmission takes four to 24 minutes one way in the IETF working-group draft coauthored by Marc Blanchet, Wesley Eddy and Tony Li. Rotation, orbital motion and conjunction can interrupt the link altogether. The draft allows a packet to wait in a forwarding device for minutes, hours or days until a contact becomes possible. That wait moves the problem from the packet header to the operator's storage plan.

The IP header survives the trip intact. IPv4's “time to live” has long behaved as a hop count; IPv6 calls the field Hop Count. Hours in a queue do not spend those hops. Eddy and his coauthors instead place the unusual work at the edge of the intermittent link. A TIPTOP forwarder may keep packets locally when its interface is down and the destination has no alternate route. When a route returns, on that link or another, the forwarder can send what it kept.

“Keep” needs a number. The draft describes a deep queue with a configured bound and drop policy. Once storage fills, packets fall out according to choices such as traffic class, source, destination or flow label. Rebooting the node, clearing its buffer or an uncorrectable memory upset can lose them too. The forwarder still offers best effort; reliable transport handles recovery end to end. A mission that buys storage without specifying which packets yield first has postponed its priority decision until the queue is full.

The architecture's example command path makes the boundary visible. A mission operations center and spacecraft each run a tuned TIPTOP end host. One forwarder sits at the communications provider, another at the vehicle. At least five ordinary IP nodes can stay in between. An orchestration system uses the contact plan to point antennas, configure modems and schedule routing entries. The drawing describes an incrementally deployable architecture; it supplies no record of a particular Mars mission delivering packets through that path.

The route ages while the packet waits

Ordinary routing neighbours repeatedly exchange liveness messages. That bargain breaks down when the neighbour takes many minutes to hear back or disappears between contacts. The draft favours controllers and scheduled routes within such domains. BGP may still join domains, but the long-delay link should not carry the usual neighbour exchange. A domain spanning it has to advertise reachability through a proxy.

The sharper trap is an explicit path. A controller may put a packet on a specific route toward a storage node. By the time the node wakes and empties its queue, the remainder of that route can be invalid. Stuffing a backup path into every packet costs scarce link capacity. The authors favour allowing the intermediate node to compute the remaining path. The packet can wait; the route has no obligation to wait with it.

The draft gives no deployed TIPTOP queue trace or loss counter. A forwarder log with contact times, occupancy, drops and route recomputation would show when delay turned into delivery.

Original record