ChronoRoute

Network simulation

One packet, hop by hop

This page demonstrates ChronoRoute's improved packet transmission mechanism. Each packet carries its source route in a T-CRH (an IPv6 Routing Header, type 253) and, for every hop, the latest time it should arrive there. Below is a real probe from our ns-3 simulation on the real Starlink 53.2° / 463 km shell: Chennai to London, 7 satellites. One laser link on its path was slowed from 1 Gb/s to 200 kb/s while staying up, so a hello-based link-state protocol still sees it as healthy.

Label: REAL satellite positions (SGP4 on CelesTrak elements) Label: REAL T-CRH header bytes Label: MODELLED laser links, link rate, queues, the slowed link

0°10°20°30°40°50°60°70°80° 10°20°30°40°50° Slowed laser link: STARLINK-35318 - STARLINK-35575 (still up) ChennaiSTARLINK-35634 (SID 8231)STARLINK-35081 (SID 8206)STARLINK-35575 (SID 8223)STARLINK-35318 (SID 8204)STARLINK-35641 (SID 8225)STARLINK-35614 (SID 8222)STARLINK-35585 (SID 8228)London Chennai 1. STARLINK-35634 2. STARLINK-35081 3. STARLINK-35575 4. STARLINK-35318 5. STARLINK-35641 6. STARLINK-35614 7. STARLINK-35585 London
Positions of the path's nodes at the send time, drawn on a latitude/longitude grid (a drawing aid; the simulation uses 3D positions). The orange segment is the slowed laser link (STARLINK-35318 to STARLINK-35575).

What each node saw

At every hop the node reads the deadline for itself from the header (Epoch_Base plus the per-hop budgets) and compares it with its own clock (unit 0.1 ms, GPS time). Arrival and deadline are shown in milliseconds after the packet entered the network.

HopNodeSID Segments LeftDeadline (ms) Arrival (ms)Margin (ms) No-fault arrival (ms)Result
ingress Chennai 0xF00C 7 -0.1 -0.1 header created
1 STARLINK-35634 0x2027 7 3.9 2.0 1.9 2.0 on time
2 STARLINK-35081 0x200E 6 11.6 6.6 5.0 6.6 on time
3 STARLINK-35575 0x201F 5 19.3 11.2 8.1 11.2 on time
4 STARLINK-35318 0x200C 4 27.0 27.5 -0.5 15.9 LATE: DEV set, Dev Hop 4
5 STARLINK-35641 0x2021 3 34.6 32.1 2.5 20.5 DEV already set
6 STARLINK-35614 0x201E 2 42.3 36.7 5.6 25.1 DEV already set
7 STARLINK-35585 0x2024 1 50.0 41.3 8.7 29.7 DEV already set
8 London 0xF01E 0 53.4 43.1 10.3 31.5 DEV already set

Hop 4 (STARLINK-35318) is the far end of the slowed link: the probe arrived 0.5 ms after its deadline there, so that node set the DEV flag and wrote its hop number into Dev Hop. The same probe in the paired run without the fault reached that node 11.1 ms before the deadline. The packet still reached London (delivered), because this run uses the continue policy: it records the miss and keeps the planned path.

The header bytes, as they arrived

Only three bytes change in flight: Segments Left (counts down at every hop), Flags (the DEV bit 0x01 is set at the late hop) and Dev Hop. Everything else, including Epoch_Base and the per-hop budgets, is fixed at the ingress.

ingress 1104fd0710080000d37370f8f01e2220244d201e4d20214c200c4d201f4d200e4d20272700000000 SL 7, Flags 0x10
hop 1 1104fd0710080000d37370f8f01e2220244d201e4d20214c200c4d201f4d200e4d20272700000000 SL 7, Flags 0x10
hop 2 1104fd0610080000d37370f8f01e2220244d201e4d20214c200c4d201f4d200e4d20272700000000 SL 6, Flags 0x10
hop 3 1104fd0510080000d37370f8f01e2220244d201e4d20214c200c4d201f4d200e4d20272700000000 SL 5, Flags 0x10
hop 4 1104fd0410080000d37370f8f01e2220244d201e4d20214c200c4d201f4d200e4d20272700000000 SL 4, Flags 0x10
hop 5 1104fd0311080400d37370f8f01e2220244d201e4d20214c200c4d201f4d200e4d20272700000000 SL 3, Flags 0x11 (DEV)
hop 6 1104fd0211080400d37370f8f01e2220244d201e4d20214c200c4d201f4d200e4d20272700000000 SL 2, Flags 0x11 (DEV)
hop 7 1104fd0111080400d37370f8f01e2220244d201e4d20214c200c4d201f4d200e4d20272700000000 SL 1, Flags 0x11 (DEV)
hop 8 1104fd0011080400d37370f8f01e2220244d201e4d20214c200c4d201f4d200e4d20272700000000 SL 0, Flags 0x11 (DEV)

SL Segments Left Flags (DEV = 0x01, unit code in 0x30) Dev Hop Epoch_Base SID + budget entries

Before and after

  • Hop-by-hop link-state routing (OSPF-style hellos): the slowed link answers hellos, so it stays "up" and keeps carrying traffic; nobody is told it has become slow.
  • A compact source route without time (CRH-16, RFC 9631): the packet follows the same path, but no node can tell that it is behind schedule.
  • T-CRH (ours): the same path plus one budget byte per hop. The first node after the slow link sees the miss from the packet itself, with no extra control traffic, and can switch to a fallback.

In this run, 598 of the 600 probes that crossed the slowed link were flagged late, and 0 of the same probes were flagged in the paired run without the fault. The first flag came 17.1 ms after the slow-down began. This shows a strong overload; the E1 experiment shows the limits: smaller delays fit inside the deadline slack and are not detected at the registered false-alarm limit, and a local queue monitor detects several fault types more often.

Source: results/network-walk/20261011T223851Z/manifest.json (commit 00f06d7), extracted by tools/network_walk.py from results/course-milestone/c5-463-10s-small-seed1; walk.json SHA-256 603f05a5d734cde8…. Starlink does not use T-CRH; its real routing is not public.