Summary

  • A delay value advertised for traffic engineering need not describe the waiting time experienced by ordinary business traffic. RFC 8570 recommends measurements that do not change significantly with offered load and exclude queueing delay.
  • Filtering, announcement thresholds and throttling make the advertised signal less sensitive than an unrestricted stream of observations. These controls serve network stability but do not eliminate the need to observe service performance.
  • The operational bargain belongs in the acceptance criteria: what the measurement includes, who may change it and which separate evidence will reveal an impaired customer experience.

The latency promise needs a noun

“We select the lowest-latency path” sounds like a complete answer to a buyer's question. It is not yet a complete description of a service. The word latency still needs an object: the delay of which packets, measured where, under what treatment and over which interval?

A path can be attractive because its relatively stable characteristics are favourable. A customer can nevertheless wait on that path when traffic accumulates in a queue. Selecting for the former and observing the latter are related activities, but they are not interchangeable. A procurement discussion that leaves the distinction unstated can produce an agreement in which the technical design and the commercial expectation both seem clear to their respective owners, while meaning different things.

This is not an allegation about a particular operator. It is a reading of a choice made explicitly in the standards for distributing traffic-engineering performance information. The choice is useful precisely because it does not attempt to make every observation do every job.

An intentional exclusion

RFC 8570, published in March 2019, defines IS-IS extensions for distributing link-performance information. Its introduction says delay measurements should not vary significantly with offered traffic load and should exclude queueing delay. For forwarding adjacencies, it offers examples such as measuring a traffic class with little queueing or combining component-link measurements. It does not prescribe one universal measurement implementation, nor the action a receiver must take with the result.

The distinction is deliberate, not a broken attempt to capture everything a packet experiences. A comparatively stable signal can help describe the underlying attractiveness of a path without making it track every fluctuation in the traffic already placed there. The information that is useful for this purpose can be insufficient for another purpose: deciding whether a business application is presently receiving acceptable service.

The OSPF counterpart, RFC 7471, expresses the same load-independence objective. Its suggested measurement techniques also show why the identity of the measuring traffic matters. A probe receiving favourable queue treatment may be suitable for isolating a reference delay. It cannot simply be assumed to experience the same waiting conditions as a different class of customer traffic.

There is no need to declare either observation false. The error would be to change the question after the measurement has been made.

The path changes when traffic moves

Consider a design scenario, not a reported network incident. A controller sees a currently less-busy path and moves traffic to it. The movement changes that path's load. If the controller immediately treats the resulting delay as a fresh instruction to move again, the observation is no longer merely a description of an external environment. It is partly a consequence of the controller's previous decision.

Whether such a system behaves well depends on much more than the existence of a delay field. The decision rule, available alternatives, measurement treatment and timing all matter. Nothing in this scenario establishes that an actual RFC 8570 deployment oscillated, or that excluding queues alone would guarantee stability. It explains why “make it more responsive” is not a complete engineering specification.

There is a second burden even before any controller moves traffic: routers have to process the information that is distributed. More frequent changes are not free simply because each value is small. A system that reacts quickly at the point of measurement must still be considered as part of the network that receives its announcements.

The commercial temptation is to market responsiveness as a single upward scale. Faster sounds better, so shorter intervals appear to be an unqualified improvement. In a shared control system, the relevant comparison is more demanding: faster at recognising what, with what downstream workload, and at whose risk if the additional activity becomes disruptive?

A value has a history before it arrives

The standards provide ways to moderate that activity. RFC 8570 requires configurable measurement and advertisement settings, generally uses averages or representative filters, and provides for thresholds, suppression and throttling. Its recommended defaults include a 30-second measurement interval and a 120-second announcement throttle. Static overrides are also supported for migration or when dynamic measurement is unavailable. These are configuration provisions, not guarantees of a customer's reaction time.

A displayed value therefore has several potentially different moments behind it: when the relevant traffic was observed, when an interval or filter produced the value, and when an advertisement carried it onward. A screen that shows only the time of the latest received announcement can conceal the age and construction of the underlying observation without containing a numerical error.

This matters when two teams compare records. One may have retained a series of individual observations. Another may have retained only the values that crossed an announcement threshold. A quiet second series does not tell the first team that nothing happened. It may tell them that nothing satisfied the policy for publishing another routing value.

Nor is the answer necessarily to advertise more. The better first question is whether the second series was commissioned as a record of service experience at all. Asking a routing advertisement to become the sole customer-performance history changes its purpose and potentially its cost.

A service observation has its own specification

RFC 7679, the IP Performance Metrics specification for one-way delay, provides a useful comparison. It defines an observation for a particular packet, from the first transmitted bit to the last received bit. Its reporting guidance requires the packet type and treatment to be identified accurately; size, protocol and special handling can affect the result. Calibration, the distinction between long delay and loss, and available path context also affect interpretation.

This does not mean an operator must replace its traffic-engineering measurement with that exact procedure. It means that a separate observation of service needs its own intelligible description. “An independent probe exists” is not enough if the probe is independent only in ownership while receiving the same unusually favourable treatment as the routing measurement.

A useful comparison starts with the intended workload. Does the observation cover the relevant direction? Does its traffic treatment correspond to the service being discussed? Has the measurement itself changed? If two results differ, those questions should be settled before the difference is attributed to congestion, a bad path choice or a supplier's failure.

RFC 7679 discusses minimum delay as an indication of lightly loaded propagation and transmission conditions, with higher values potentially indicating congestion. That is a useful distinction within an understood measurement. It is not permission to subtract two unrelated dashboard numbers and label the remainder queueing.

Manual does not necessarily mean misleading

A configured static value is an especially revealing case. It can be a legitimate bridge while measurement is introduced, or a practical choice where measurement is not available. The governance failure is not the mere presence of a manual setting. It is allowing people downstream to rely on a different account of what that setting represents.

If a team approves a path using a manually maintained reference, it should know that it is approving that arrangement. If the value later becomes dynamically measured, the same numerical units do not ensure that the old and new histories are directly comparable. A sudden improvement in the series could reflect a changed method rather than an improved network. The reverse is also possible.

The point is not to burden every observation with a new committee. It is to keep the measurement's operational identity intact as it crosses organisational boundaries. A value used by routing, capacity planning and commercial reporting may carry three different expectations. Reusing it is economical only while those expectations remain compatible.

Two useful answers

A stable path-selection reference and a sensitive record of service experience are not rival definitions of truth. They are answers to different questions. Keeping both can reveal precisely where a design is doing its intended job while a business still has an unresolved problem.

If the routing signal remains steady during a customer's reported impairment, the next step is not automatically to accuse the signal of failure or to dismiss the customer. The discrepancy calls for an examination of what each observation includes. If that examination shows that the impairment sits outside the routing metric's intended scope, there is still work to do—but it is now possible to assign the work honestly.

The evidence here is limited to published specifications and their design boundaries. No router configuration, customer complaint, route change or service outcome was tested. The leadership implication is an inference from that architecture: an organisation needs an owner for the space between the signal it uses to choose a path and the experience it has promised to deliver.