Summary

  • RFC 9569 turns ALTO snapshots and incremental updates into named edges of a version graph. Continuity, a recoverable starting snapshot and forward-only compaction make the server’s declared history traversable.
  • That graph is a transport receipt, not a reality certificate. It does not prove the input measurement was current, dependent resources were applied consistently, the application followed the information or the resulting traffic performed better.

The client reached version 106 by following every available edge. Nothing in that sentence says version 106 described the network that existed when the application made its choice.

That distinction is the centre of RFC 9569, even though the document never turns it into a slogan. The RFC Editor record, IETF Datatracker, document history and errata search establish the standard’s identity and status. They do not establish that an ALTO server observed a live route, that a client used its answer or that an application improved.

A graph for changes, not a sensor for truth

The original ALTO protocol in RFC 7285 lets applications retrieve network information resources such as network maps and cost maps. RFC 8895 added Server-Sent Events for incremental updates. TIPS takes a different path: it makes each snapshot or incremental change an addressable HTTP resource that a client may pull explicitly, concurrently and out of order. The design can exploit HTTP/2 or HTTP/3 while still working over HTTP/1.1.

For each monitored resource, a TIPS view exposes an updates graph. A node is a server-declared version. An edge is the item that moves content from version i to version j. An edge from version 0 is a full snapshot; other edges can carry JSON Patch or JSON Merge Patch. Consecutive increments are mandatory. Shortcuts are optional. Different paths to the same node must produce the same content.

This is valuable machinery. It separates a retrievable transition from a transient event stream and gives every item a stable place in the view. But the graph begins after the server has already converted routing protocols, provisioning policy, dynamic network information or an external interface into an ALTO resource. A perfectly reconstructed version can therefore be perfectly faithful to a stale or incomplete input.

What the invariants actually preserve

RFC 9569 places three constraints on graph modification. Continuity requires every version between start-seq and end-seq, with each consecutive incremental edge present. Feasibility requires a full snapshot for the current starting version. “Right shift” allows the retained interval to move forward, never backward.

Those invariants preserve reachability inside the server’s declared history. They do not establish observation time, measurement source or external correctness. Path independence proves that two valid graph paths converge on the same represented state; it does not prove that state matches the world.

Compaction makes the boundary visible. A client asking for an edge older than the current start sequence can receive 410 Gone and request a new recommendation. A missing or closed view can produce 404 Not Found; an excessive future sequence can produce 425 Too Early. These responses are useful operational evidence. None says why the underlying network changed or whether the client’s last applied state remained safe.

Even the recommended edge is easy to overread. The server may choose it by message count, accumulated bytes or another implementation-specific cost. It is a recommendation for traversing the update graph, not a recommendation for routing application traffic.

Concurrency moves the burden; it does not remove it

TIPS permits multiple edges to travel concurrently and out of order. Dependent resources still need a consistent application order. A cost map may depend on a particular network-map version; receiving both payloads does not prove the client joined the right pair. RFC 9569 tells clients with enough resources to buffer updates and tells constrained clients to request a full snapshot. The protocol exposes the components of consistency. The client must still create it.

Infrastructure adds another join. If a stateful TIPS view exists on one backend while a Layer 4 load balancer sends a later request elsewhere, the request can be processed incorrectly. The RFC discusses shared state or Layer 7 placement keyed by the view path. A 200 OK for one edge cannot prove the whole view came from one coherent state authority.

The standard is equally candid about liveness. Earlier drafts tried to infer client life from a persistent HTTP connection. The final text rejects that approach because a proxy terminates one connection and opens another. The visible connection may be alive while the client behind it is not. RFC 9205 supplies the broader HTTP design discipline, while RFC 9113 defines the multiplexed HTTP/2 transport TIPS can use. Neither turns transport state into application state.

The IANA ALTO registry records the TIPS media types. That is coordination evidence, not deployment evidence.

An operator claiming optimization needs a longer chain: timestamped upstream observations; ALTO computation and version tags; the TIPS view and edge hashes; client base version and patch result; dependency versions and buffer decisions; evidence that the application consulted the result; the selected action; the observed traffic path; and a performance comparison against a named baseline. Without those joins, the graph proves that declared versions can be reconstructed. It cannot say that reality improved.

Heng Lu’s essay on reality layers prevents graph integrity from swallowing measurement truth. Running-Code Primacy moves authority from specification theatre to observed operation. Why BTW Media exists supplies the editorial test: report the transition receipt TIPS genuinely earns, then name the missing receipts before using the word “optimized.”

Sources