Summary

  • RFC 9699 is an Informational use case, not a deployment result or a standard certifying XR performance.
  • Bursty demand makes the distribution of missed deadlines more useful than an attractive average; moving computation closer changes the bottleneck rather than removing it.
  • An experience claim needs a defined workload, end-to-end measurement boundary and accountable owners across the headset, application, access network and edge service.

A server can be close to a headset and still be too late. Distance shortens propagation, but it does not say how long a frame waited behind other work, whether the radio uplink stalled or whether the scene information was already stale. For an augmented-reality application, a correctly rendered object delivered after the user's movement may be a wrong object in practice. This is an analytical example, not a reported failure at a named operator.

RFC 9699, published in December 2024, makes the underlying problem unusually clear. It describes an extended-reality use case for edge infrastructure, including an illustrative visit to the Tower of London. Its status is Informational. Neither the tourist scene nor its discussion of managed edge resources establishes that such a system has been deployed, tested at crowd scale or commercially validated.

The workload arrives as a scene, not a smooth pipe

The application has to track movement, acquire a world model, register virtual objects against the physical scene and generate images with temporal coherence. Those operations do not necessarily grow together. A change of scene can raise sensing and processing demand while the user is moving through a different radio environment. Offloading can ease work on a battery-powered device, but it adds a dependency on communication and remote execution.

The RFC describes heavy-tailed characteristics in traffic and demand, and warns that bursts challenge resource allocation. That is a reason to inspect the tail, not permission to assume every XR workload follows one mathematical distribution. A finite trace may miss unusual events; averaging the observed samples may still be useful for capacity planning while concealing the interruptions that determine usability. The pertinent question is how often work arrives too late, and whether those misses occur together.

Its discussion of earlier multi-user AR research also points toward uplink traffic, including larger transfers in scenes with fewer useful visual features. A sales demonstration centred on downlink speed may therefore be measuring the wrong constraint. The cited research is historical cellular AR work, not evidence that a current 5G product has a particular latency.

Twenty milliseconds is not a certificate

The RFC cites a 20-millisecond latency target and a preferable 7–15-millisecond range. In one budget, display consumes roughly 12–13 milliseconds, leaving little time for the remaining work. These are cited design figures, not a universal comfort threshold or measurements of today's headsets. The document also discusses server response time elsewhere: buyers must not silently substitute that narrower quantity for the full motion-to-display interval.

Even excellent stage-level percentiles do not simply add up to an end-to-end percentile. The stages can be dependent, their clocks imperfect and the sample sets different. A test that counts only completed tasks can look faster precisely because the slowest tasks vanished. Any acceptance report should expose abandoned, dropped and degraded work as well as successful returns. This is our proposed reporting discipline, not an RFC requirement.

Thermal relief needs similar care. A 2020 smart-glasses thermal paper models heat paths and compares the model with finite-element calculations; physical validation was future work. It supports taking materials and layout seriously, not declaring a measured battery or temperature benefit for a commercial headset. Remote computation can reduce one source of heat while radio activity and local processing remain.

A network promise ends somewhere

Deterministic transport can be valuable within its stated envelope. RFC 8655 places DetNet within a single administrative domain or cooperating closed domains. It does not promise bounds across any Internet path, and its transport architecture does not certify GPU queues, tracking accuracy or display behaviour. Naming DetNet, DiffServ or resource reservation cannot fill those gaps.

The useful comparison is a matched trial: the same scene, movement and demand mix under local processing and selected offload placements, with failures retained. The Puffer research programme offers a methodological warning: video-streaming approaches that look persuasive in simulation require comparison against simple baselines in the actual environment. That is ordinary video evidence, not an XR benchmark. The transferable lesson is how to test, not how much improvement to promise.

The commercial claim should therefore be narrow: this placement, for these devices and workloads, delivered this distribution of usable session time at this cost. RFC 9699 explains why that claim is worth investigating. It does not supply the result.