The fastest edge still misses the 20 ms budget

The Fastest Compute Site Still Misses the 20ms Budget

Why it matters

An IETF cloud-VR example sends the request with the shortest processing delay to the wrong edge. Only one choice adds compute and network delay together and clears the 20 ms service budget.

Daniel Kade30 October 2026 at 21:02 UTCReading Time 2 minLast update: 30 October 2026

The fastest compute site is not necessarily the site that clears the full service budget.

Summary

The RFC’s illustrative site with the fastest compute takes 22.4 ms end to end; the site with the lowest network delay takes 23.4 ms. Both miss the example’s 20 ms target.
A third site combines 5 ms of compute and 5 ms of network delay for a stated 19.4 ms total. The figures are scenario assumptions, not field measurements.

The edge with the fastest processor loses. In RFC 10054’s cloud-VR example, Site 1 needs 4 ms to compute the frame, the best of the three. Its network path adds 9 ms, however, and the RFC gives the complete motion-to-photon delay as 22.4 ms. The application’s illustrative budget is 20 ms. The attractive compute number buys a result that misses the requirement.

Choosing by network delay alone fares worse. Site 2 has the lightest network path at 4 ms, but its compute delay is 10 ms under heavy load. Its stated end-to-end total is 23.4 ms. Site 3 is ordinary on both dimensions: 5 ms to compute and 5 ms across the network. Together they yield 19.4 ms, the only stated total below the example’s 20 ms line. A difference of three or four milliseconds separates failure from success in the RFC’s scenario.

That is the concrete case behind Computing-Aware Traffic Steering. The service instance is not useful merely because it is close, nor because its processors are idle. The user experiences the chain: device work, transport, server rendering and return path. The RFC’s cloud-VR illustration divides 20 ms among sensor sampling (less than 1.5 ms), display refresh (7.9 ms), rendering (5.5 ms) and round-trip network delay (5.1 ms). Compute and network each consume a material part of the budget. Optimizing one while ignoring the other can select the wrong site.

RFC 10054 is an Informational problem statement and requirements document, and its scenarios are limited to a single domain. It is not evidence that a particular deployment runs this selection logic. The point is narrower and more useful: a scheduler’s ranking rule needs the service’s end-to-end objective, not a proxy that looks good in one dashboard column.

Source: IETF RFC 10054.