Summary

  • RFC 9616 measures RTT between Babel neighbours without synchronised clocks, then smooths the samples, maps them through bounded cost thresholds and applies hysteresis before route selection.
  • The recommended defaults deliberately treat every RTT below 10 ms as equally good and every RTT above 120 ms as equally bad, with a maximum penalty of 150. Those are stability choices, not universal service objectives.
  • A credible operating receipt keeps timestamp placement, samples, smoothing, parameters, hysteresis, route state, forwarding and application outcome as separate evidence.

The reassuring graph had one line. It was labelled route cost, and it went down. A release had enabled the delay extension on a Babel overlay; the path through a nearby tunnel now beat a path that crossed an ocean. That was exactly the class of problem RFC 9616 was designed to address. Hop count had made two tunnels look equal even though one stayed within Paris and the other travelled through Tokyo.

Then the operations team opened the service trace. Tail latency had risen. Retransmissions clustered behind a queue. One application flow had moved to the nominally cheaper route while a bandwidth-limited segment became the new bottleneck. The routing metric had done what it was configured to do. The mistake was the sentence attached to it: “lower cost proves better service.”

That sentence collapses five different things. RFC 9616 first creates an RTT sample between neighbours. An implementation smooths a sequence of samples. It maps the smoothed number into an abstract Babel link cost. Hysteresis determines whether a change is large and persistent enough to influence route selection. The selected route may then reach a forwarding table and carry packets whose end-to-end result depends on far more than neighbour RTT.

Each transition is useful. None inherits all the meaning of the layer before or after it.

Why delay entered the metric

RFC 8966 deliberately gives Babel latitude in metric construction. Common implementations use packet loss on wireless links and simple hop count elsewhere. That can be sensible until the network contains overlays, VPNs or tunnels. A local tunnel and a transcontinental tunnel can both count as one hop. The control plane then lacks the fact that distinguishes them.

RFC 9616 supplies that missing observation. A Babel speaker places a timestamp in each Hello. Its neighbour records when that Hello arrived. When the neighbour returns an IHU — “I Heard You” — alongside another timestamped Hello, the first speaker can calculate:

RTT = (t2 - t1) - (t2' - t1')

The elegance lies in the subtraction. Each difference is formed against one local clock, so the two routers do not need a common time origin or tight clock synchronisation. The method is attributed to Mills and reaches back to the HELLO work documented in RFC 891, with related clock practice familiar from RFC 5905.

The state is small: the last origin and receive timestamp for each neighbour. The wire addition is also narrow. IANA records Timestamp as Babel sub-TLV type 3 in the Babel Parameters registry. A Hello carries one 32-bit timestamp; an IHU carries two. Unknown sub-TLVs can be ignored by older implementations.

This is the kind of minimum common mechanism that deserves respect. It adds a verifiable signal without requiring a central clock, a universal controller or a mandatory global policy. But a minimal wire mechanism cannot decide what the signal should mean for every network.

The timestamp has a measurement boundary

Transmit timestamps should be taken as late as possible before a packet enters the network stack. Receive timestamps should be taken as early as possible after it emerges. Move either point and the measured interval changes. A timestamp created while a packet is still waiting behind local processing may include a queue that another implementation excludes. A receive timestamp recorded after scheduling delay may attribute host load to the link.

Two implementations can therefore exchange conforming timestamp fields while observing slightly different operational surfaces. The RFC's implementation note — temporarily placing padding in a packet and replacing it with a timestamp immediately before send — exists because placement is evidence, not plumbing trivia.

The values are microseconds in an unsigned 32-bit field. They wrap in roughly 71 minutes. Routers reboot; local clocks step; stored values become nonsensical. RFC 9616 recommends rejecting samples whose relevant timestamp appears to be in the future or more than three minutes old. A clean cost graph that omits the accepted and rejected sample counts cannot show whether it describes current delay, sparse survivors or a restarted neighbour.

Nor is neighbour RTT end-to-end application latency. It observes a protocol exchange over one adjacency. It does not include every later queue, transport retransmission, server wait, encryption operation, application dependency or reverse-path asymmetry. The sample is real. Its scope must remain real too.

Raw RTT would make the route chase itself

Delay changes when traffic moves. A low-RTT route attracts more traffic; more traffic can create congestion; congestion raises RTT; the route then looks worse and traffic moves away. With two parallel paths, a controller that follows every fresh sample can produce oscillation, packet reordering and harm to transport protocols.

Even without this feedback loop, bursty traffic generates occasional spikes. Two similar routes can trade places around the same value. The 2014 primary study, A delay-based routing metric, reports why naive delay is unstable and why the design adds limits. Its experiments are valuable evidence for the mechanism under tested conditions, not a promise about every workload.

RFC 9616 therefore recommends three transformations. First, smooth the series. Its example exponential average is RTT := α RTT + (1 - α) RTTn; alpha should lie between 0.8 and 0.9, with 0.836 as the recommended default. A high alpha gives memory to prior conditions. That reduces sensitivity to outliers and also delays recognition of a genuine change.

Second, map the smoothed value through a bounded cost function. Below rtt-min, the cost remains the nominal hop cost C. Between rtt-min and rtt-max, it increases linearly. Above rtt-max, it stops increasing at C + max-rtt-penalty. The recommended defaults are 10 ms, 120 ms and 150.

Third, apply hysteresis so modest variations in the middle range do not constantly replace the route. Stability is not an accidental side effect. It is an explicit objective purchased with slower response.

The plateaus are policy

The lower plateau says that every delay below the minimum may be treated as one class of good link. A 1 ms path and a 9 ms path receive no delay-based distinction under a 10 ms setting. That is useful when the difference does not justify churn. It is wrong when the application genuinely depends on discriminating among low-latency links.

The upper plateau says that every path beyond the maximum is equally undesirable for this component of cost. At 120 ms and 600 ms, the added penalty is the same. Capping prevents an extremely delayed or congested link from injecting unbounded instability. It also discards information that might matter when every available path is poor.

The penalty controls how strongly Babel avoids the upper class relative to nominal cost and other path segments. It does not express dollars, loss, throughput or business harm. A value of 150 is not “150 milliseconds of user pain”. It is a routing input inside the selected metric algebra.

These parameters are operator decisions even when copied from defaults. Lowering rtt-max can improve stability while removing discrimination among high-delay routes. Raising it preserves more distinction and may expose the network to more movement. The right values depend on topology, expected base delay, mobility, traffic shape and the service objective. A standards-track recommendation supplies a disciplined starting point, not a universal constitution.

Stability creates a time debt

Smoothing and hysteresis prevent the control plane from following noise. They also ensure that a real change is not reflected immediately. RFC 9616 warns that routing can remain suboptimal for seconds or minutes after RTT changes. In a fixed wide-area overlay, this may be the correct bargain. In a highly mobile network, the same memory can preserve yesterday's answer after the physical path has moved.

An operator should therefore ask two different questions. Is the route stable? Is the stable route still appropriate? Low churn answers the first. It cannot answer the second.

The monitoring window must include transitions. Tests that begin after the exponential average has settled will miss convergence debt. Tests that report only median RTT will miss the spikes that drive smoothing design. Tests that never alter load will miss the negative feedback loop. A useful validation changes latency, capacity and offered traffic separately, then records how samples, smoothed values, cost and selected path respond over time.

Hybrid compatibility is not semantic uniformity

RFC 9616 places its data in sub-TLVs that unaware implementations ignore. Extended and unextended Babel routers can coexist. The RFC says such a network may route suboptimally, but does not acquire loops or similar pathologies merely because support is mixed.

That is strong deployment engineering. It allows voluntary adoption and local refusal. It is not evidence that every router computes cost from the same observations. One portion of a network may use delay; another may fall back to hop count or its existing loss metric. A route selected across that boundary contains a composite judgment.

Inventory must therefore record capability by adjacency, not merely whether the extension exists somewhere in the fleet. During staged rollout, operators should compare path decisions at the boundary and test withdrawal or reboot of both capable and incapable nodes. “Backward compatible” means the mixed network continues to operate; it does not mean the mixed metric has one interpretation.

This boundary is distinct from the YANG management question in RFC 9647. A datastore may expose configuration and state. RFC 9616 determines how a particular delay signal may feed route cost. Visibility into a value is not proof that its sampling, parameters or downstream result are correct.

The privacy escape changes the metric

Timestamping adds another trade-off. The timestamps begin at an arbitrary origin, so they do not directly disclose wall-clock time, time zone or boot time. Yet sufficiently accurate timing can help an attacker infer physical location. The security section allows a node to omit Timestamp sub-TLVs; neighbours then fall back to hop-count routing.

That is not a cosmetic privacy toggle. It changes the evidence available to route selection. A privacy decision can therefore change which path the network prefers. Conversely, demanding the delay signal expands the observation surface.

The correct control is explicit: record which interfaces emit timestamps, what threat model justified the choice, what metric applies when they do not, and whether route quality changes materially. Do not label the fallback a fault merely because it declines the extension. The design preserves the right not to expose the signal.

Build the receipt in layers

A defensible receipt starts with timestamp provenance: implementation, send and receive placement, clock source, wrap handling, reboot behavior and stale-sample rejection. It then records raw accepted samples and outliers rather than only the final average.

The next layer freezes the decision parameters: smoothing algorithm and alpha, rtt-min, rtt-max, maximum penalty, nominal link cost and hysteresis state. Parameter changes should have an owner, reason, rollout window and rollback test. Defaults copied without a topology hypothesis are still decisions — merely undocumented ones.

The third layer records routing chronology: computed link cost, candidate routes, selected route, route-change cause and time to settle. The fourth proves execution: RIB and FIB state, next hop, packet path and loss. The fifth measures the service: application latency distribution, throughput, completion rate and user-visible error.

Only the complete chain can support the statement “this delay metric improved this service under these conditions.” A lower cost alone supports a smaller statement: the configured algorithm assigned a lower abstract cost to the observed path at that moment.

Sources